The insider threat isn’t easy to fix. We can fix it with Separation of Duty, but it requires planning ahead, discipline, and effort. But it’s essentially why banks can hire low-wage tellers and not worry about theft at the till (or at least not as much).
San Francisco lost control of their FiberWAN. It’s not clear how much this affected day to day operations, since the city appeared to still be working. And that in itself is a tribute to separation of duty.
Continue reading Fixing the Insider Threat: Separation of Duty
(circa 1970-85, maybe later)
The Forth programming system was developed in the late 1960s by Chuck Moore. It provided a very powerful, text based mechanism for controlling a computer and writing programs when RAM and hard drive space were extremely tight. Early implementations were routinely restricted to 8KB of RAM. Some early implementations relied exclusively on diskette drives that stored less than a half a megabyte of data.
Starting in the 1970s, typical Forth systems treated hard drives as consisting of a linear set of numbered blocks, each 1KB in size. The first block on the drive (block 0) contained the bootstrap program to get Forth started, and a small number of subsequent blocks might also contain binary executable code that was loaded into RAM when Forth started.
Following the blocks of executable code, the remaining hard drive blocks generally contained ASCII text and were referred to by number. If a programmer needed to modify part of a Forth program, he would edit the hard drive block that contained that program, and refer to the block by its number.
Here is an assessment of Forth’s file system in the context of the eight concepts noted above:
- File storage – each file was essentially of a fixed, 1KB size. Other measures had to be used to link multiple blocks together into longer sequences of data.
- Locating files – files were referred to by block number, and the number had to be remembered by the programmers.
- Free space management – programmers had to remember what blocks had not been used, or which blocks contained obsolete text that could be erased so the block could be reused.
- Easy to implement – Yes, yes, yes!
- Speed – Very fast at the hardware level, since no hard drive searching had to take place
- Direct vs. sequential – supported both
- Storage sizes – no built-in limit, but this obviously became impractical as drives increased dramatically in size
- Robustness – there is little on-disk structure to destroy, so the robustness becomes a social issue having to do with the reliabilty of the people using the system: will they forget, or resign, or otherwise be unavailable? Can others fill in the gaps left by missing people? Will the hard drive get too big for humans to keep track of its contents without a more conventional file system?
The one-time pad is the only encryption technique that has been mathematically proven to be uncrackable. While hard to use, it has often been the choice for highly sensitive traffic. Soviet spies used one-time pads in the 1940s and -50s. The Washington-Moscow “hot line” also uses one-time pads. However, the technique is hard to use correctly.
The exclusive or operation – a logical function applied to binary bits, like AND, OR, and NOT – is a fundamental encryption technique. It is often used in stream ciphers, which are widely used in web browsers when connecting to secure web servers.
Continue reading Encrypting with XOR: A Graphic Example
Whenever your browser establishes a “secure” connection to a web site, it encrypts the data. The encryption often takes place byte-by-byte, since the software can’t always predict how much data will be sent. This encryption style requires a stream cipher.
Continue reading Stream ciphers