Look at the Changes Since 1974
Commentary
Career
Commentary
Ware Report
Commentary
Anderson Report
Commentary
Conceptual Thinking + Engineering
Commentary
Computer Security Initiative
Commentary
Principles in TCSEC
- Define "security"
- Good conceptual design
- Faithful implementation
- Write it down
- Check your work
- Known counter-measures
- Difficult to address new issues in a timely fashion
Commentary
Trusted Computer System Evaluation Criteria
Commentary
The construction of the TCSEC was an exercise in giving partial credit. At the outset, the-best-security-we-know was posted at the high end: A1. The development of the lower levels was a matter of weakening the requirements in a rational fashion, down to C2, which was characterized as "best commercial practice." C2 (and its tarted up sibling, B1) were characterized as adequate to keep order among cooperating parties.
While everyone knew that market-forces-produced systems were insufficient for good security, the plan of providing partial credit and determining which situations could get by with lower security provided a transition path. Over time, the needed security features and assurances could gradually become commercially mainstream. This did work, 'though not as completely as was hoped.
Isolated Networks
Commentary
The pragmatic approach was to field isolated networks, different ones for each different security classification (or bundle of classifications). The advantage was that all users of the network, through the security clearance process, could be plausibly be viewed as "members of a community," cooperating colleagues.
- Field isolated networks
- Operational necessity for limited connection
Mostly Isolated Networks (MIN)
Commentary
Unfortunately, there are practical needs for the networks to have connections for limited, constrained communication. The diagrams typically leave out the connections between the networks, or use thin lines. But that near-invisibility is illusory. The connection should really be emphasized, rather than minimized. This pair of networks with a connection raises the need to consider what I call the "Computer Security Theorm."
- Tendency to underemphasize the importance of the connections
Intermediate Value Theorem
Commentary
The idea is shown here. If a network attaches two boxes, box A (at level alpha) and
box B (at a different level beta not equal to alpha), then some box in the network is multilevel (where "multilevel" means that it manages objects of more than one security level).
The proof sketch is fairly simple and proceeds by contradiction. Suppose not. Then every box on the network operates at a single security level. Then on any path from A to B, each box operates at the same level as the one preceding. That means that alpha, A's level, is the same as beta, B's level, a contradiction.
- Moving from one level to another transits some multilevel node
- Will the multilevel node be weak? or strong?
MIN Security
Commentary
Thus, in our MIN situation, the connected networks are a network. If each of the networks is single-level, then the multilevel box must be on the thin-line connection. MIN Security is posited in the boxes that mostly-isolate the networks. We'd like to think that the operational computers in those connections are the strongest ones we know how to make, but such is not the case.
- MIN security relies on the thin lines between networks
- Systems connecting the networks are too weak for their job
What Can We Do?
- Tell ourselves the truth
- Beware of those who claim we are safe and secure
- Utilize precious resources whenever and wherever appropriate
Commentary
Reference Implementations
Commentary
Consider a Yahoo!-like situation, with file servers, simple static web servers, simple SeaViews-like DBMS, and finally dynamic web servers. Also overlay thin-client architectures where appropriate. None of this stretches any envelope.
Attaching that Yahoo!-like portal to two (or more) MINs changes the security posture entirely. The market-driven, "please cooperate" solutions fall short. Not even close. But secure versions of all those networked piece-parts have been demonstrated before. This is not research. It is "Development," the forgotten step in the life-cycle.
Last year, I proposed an internal R&D project to build reference implementations of these building blocks, one version on each of the available high-security systems. Unfortunately, R&D programs have turned into "R" programs. My proposal lost points because it wasn't new research. It was also claimed that commercial vendors and integrators had this issue well in hand - contrary to what vendors told me as I prepared my proposal.
I believe my proposal was a good one, but too expensive for me to fund on my retirement savings. I hope someone else will take it up. I'd even spend some time over lunch to help lay out the program. Anyone?
U.S. VISIT
Commentary
Infrastructure Overlay
Commentary
US VISIT — One Site
- Multilevel platform or multiple single-level platforms
- Multilevel DBMS or multiple single-level DBMS
- Multilevel file store or multiple single-level file stores
- But ...
- There must be a multilevel component
Commentary
Before
Commentary
Work before the Bell-La Padula model gave it context. Here is a castle, an over-used analogy for strong systems. Existing systems, developed in response to "market forces," were tested by specially-chartered "Tiger Teams" and found wanting. The teams found flaws that allowed entry to the systems. More alarmingly, design flaws found in System A were often found in System B. Experienced Tiger Teams could reuse previous successful attacks with high probability of success.
Tiger Teams also illustrated that a successful penetration cast a long shadow. Simplest was inserting an unknown "backdoor," analogous to the secret entries of actual castles. (More about this on the next slide.) More serious is the possibility of tunneling under the walls, "undermining" them. This was an attack beneath the security features (the walls, in the castle analogy). In computer systems, one can ignore the security features if one can successfully attack the core of the operating system (or executive). Such an attack on the foundation makes the security features irrelevant. This kind of attack in the form of subversion requires the highest level of security to assure a solid foundation.
After the Tiger Team exercises, the demonstrated lessons were (a) that market forces had not produced strong, secure systems; (b) security has to be built in, not added on later (to prevent undermining attacks); and (c) there has to be a blueprint for building a really secure system - a "conceptual design" of a secure system. That conceptual design was the task assigned to Len La Padula and me.
- Market forces inadequate
- Need built-in security
- Backdoors show we need life-cycle CM
- Undermining shows we need strength down to bedrock
Backdoor
Commentary
The planted backdoor shown was identified by Roger Schell and Paul Karger and was implemented and popularized by Ken Thompson. The initial step is to create an altered version of login that by-passes the identification and authentication step. The compiled version replaces the legitimate version, with the altered source code also removed. The source code doesn't match the running object code, but the object code will admit anyone that provides the backdoor key, say "Joshua."
Of course, recompilation of the legitimate login source code will wipe out the backdoor. So step 2 is to produce an altered version of cc that re-inserts the login backdoor whenever login itself is re-compiled. Step 2 also protects the bad cc by reinserting all the cc alterations any time cc is re-compiled.
With a self-protecting backdoor with an obscure key (like the Easter Eggs in commercial products), the situation is lost, barring hand-compilation or recompilation of the compiler without use of the bad cc. To protect against the insertion of bad logic, tight configuration control is required, throughout the software's entire life time.
Subversion: Two-Card Loader
Commentary
In the old days, getting a program into a computer for execution was done using a program called the loader. Hardware was included in the computer that would read in the full-service loader (on punched cards), then transfer execution to the program then loaded. It was not practical to put an entire loader onto one punched card, so the loaders ended up being "two-card loaders." After the two cards were loaded, any program could be loaded and executed.
Consider hidden code in an operating system that constitutes a full-service loader, the 21st-Century version of the two-card loader. With such an artifact, a honed, pointed, polished attack could be run on the subverted system at any time in the future. Example 2CL subversions have been demonstrated whose "toehold" requires only six lines of code.
A 2CL subversion of a commercial operating system could tunnel under the system's "walls" and make all the advertized security features moot. Systems developed in response to market forces (B1 and C2) cannot be proof against such insertions and are indefensible in the most critical parts of our networks, the thin lines connecting our mostly-isolated networks.
Corollary to Santayana
