4.1 Requirements For A Secure System
In parallel with the explosion in hardware capability, security concepts also expanded, backed by lots of research effort. The net result of the research was that “finding and patching” security “holes” was not the way to go. Security “leaks” could not be plugged because there was no assurance that there would not be another undiscovered “leak”. There was no way to be sure that all possible IT “doors” were properly “guarded”.
Rather, security had to be designed into an operating system (and into an IT system) from the ground up. Note that security had two main operational components: (1) multi-user protection and (2) preventing unauthorized object accesses.
A lot of research was done in the 1960s to figure out how to deal with multi-user protection and preventing unauthorized system access. The results of this research revealed the necessary components of a secure, trustworthy system. These components are summarized below:
Secure System Requirements
Security Policy - System must enforce a well-defined security policy.
Marking - System must associate all objects with access control labels (sensitivity & access modes).
Identification - System must identify individuals and their various authorizations in a secure manner.
Audit Trail - System must keep & protect audit trail so actions may be traced to responsible party.
Evaluation - System must have hardware/software mechanisms that can be independently evaluated to assure that policy & accountability are enforced.
Continuous Protection - System must continuously protect trusted mechanisms that enforce policy & accountability from tampering.
4.2 The Reference Monitor
As part of these requirements for a secure system, the “Reference Monitor” concept was introduced. This was a logical structure built into the lowest level of the Operating System (O/S) which adjudicated the access of any subject to any object. The Reference Monitor is shown in the diagram below:
The reference monitor mediates all accesses of objects by subjects. With properly defined subjects and objects, the reference monitor (RM) provides a trusted – and verifiable - security policy enforcement mechanism. The reference monitor, combined with the principles of a secure system architecture, can provide trustworthy, verifiable enforcement of a security policy.
4.3 Where The Reference Monitor Is (or Is Not) Used
Some mainframe operating systems (e.g., OVMS) incorporated this concept at the lowest layer, right above the FLIH (first level interrupt handler). Most did not. The reason for not including the Reference Monitor was that the installed base of existing systems prevented radical modifications to the underlying software structures. Adding the reference monitor would have been a very radical modification, requiring (among other things) an entirely new file system. Simply put, the size and inertia of the installed base prevented the fundamental re-engineering and re-deployment required for a truly secure O/S.
Many institutions were very resistant to change because they had to operate 24-by-7 and could not simply shutdown, reinstall a new O/S, install new applications and reboot. So, although a solution to security was known and understood, simple economics prevented its widespread adoption. The "personal computer (PC)" side of this equation was even worse as the next part will show.
More to come. Stay tuned....