Has the reference monitor gone the way of the Dodo Bird? – Well, no.
I blogged here about the significance of NIST sp800-160. The goals and objectives of this initiative are worthwhile and necessary; NIST has recognized the need to build more secure systems. The full title of the document is;
“Systems Security Engineering: Consideration for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems”
I consider this self-explanatory; the purpose is not improving status quo hygiene and
best common practices. It is really about moving to a better model altogether. The draft is attempting to drive discussion of stakeholder interests, identifying security processes, life-cycle security, etc., that should be taking place, but are not. An important section is “AR‐2.1 Define the philosophy of protection for the system at the architecture level.” Because ultimately it is this section that determines whether the highest level security and assurance requirements will be deliverable, for whatever the stakes are. What is the point of conversations about security capabilities and requirements if the security mechanisms are not implementable in the architecture to deliver them?
This section informs us;
“The philosophy of protection encompasses the protection strategies, methods, and techniques employed in the application of security design principles and concepts to the system architecture. These security design principles and concepts include, but are not limited to: separation; isolation; encapsulation; non-bypassability; layering; modularity; hierarchical trust; hierarchical protection; and secure distributed composition.”
In general, these are things not given enough consideration in the design of networks, but they are all things that we refer to when talking about KSE contributions to defensive capability though. Beyond this, Appendix F provides a discussion of the fundamental security design and trust principles. In the post “Attain NIST sp800-160 goals with KSE” I pointed to section F.4.1, which concerns itself with approaches to trustworthy system development.
- the reference monitor;
- defence-in-depth adequacy; and
There are separation kernels around and although KSE also provides separation kernel capability, this post focuses on reference monitors. Here’s why;
The concept of a ‘reference monitor’ that supervises a computer’s access control functions is the basic idea behind a trustworthy operating system.
While the reference monitor by itself does not make a system trustworthy, it is essentially the heart of the security kernel which is the basis for a trustworthy system. This security mechanism is critical to achieve trustworthy systems which makes it central to success in achieving the stated goals of NIST sp800-160.
There is a difference between knowing one needs a reference monitor implementation, and building one. If it were easy to, these strategies would probably be commonly used today, but they’re not. On COTS systems, reference monitors have gone the way of the Dodo Bird. They were not built in to these systems. The general reason is that they were hard to do.
What is a reference monitor?
According to Wikipedia, the Reference Monitor concept was introduced as an ideal to achieve controlled sharing.
“The function of the Reference Monitor is to validate all references (e.g., references to programs, data, peripherals) made by programs in execution against those authorized for the subject (e.g., the user).”
“The Reference Monitor not only is responsible for assuring that the references are authorized to access shared resource objects but also to assure that the reference is the right kind (i.e., read, or read and write, etc.).”
As this explains, the reference monitor is a security mechanism that validates user behaviour requests on a system. The term reference validation mechanism (RVM) is referring to a reference monitor.
Reference Monitors are Authorization Engines
In other words, reference monitors are authorization engines to govern the behaviours of users on systems. Such controls should kick in post-authentication after authentication determines the identity of the user. Authorization dictates both initial allowed access for an authenticated user, and sets boundaries for acceptable subsequent use of accessed resources. Ideally, authentication and authorization should work in tandem to govern user behaviours. In the absence of authorization controls, authentication has been used as a proxy for authorization, and as we know, authentication has been all too easy to break, leaving no backup defence behind it.
The reference monitor concept goes back to a paper written by James Anderson for the USAF in 1972. It was the result of a panel of 10 security heavy thinkers, most of who would probably be considered a security “Hall of Fame” level. The panel was working on requirements for U.S. government computer systems to execute securely in the presence of malicious users. What do you know? A security mechanism designed to protect against the insider threat. In 1972.
The reference monitor concept percolated into existence through a series of security model discussions, gaining stronger support throughout the process. In the end, it was central to their report. It has been a feature of US military secure systems thinking since then. The Anderson Report formalized several important concepts that carried forward to the TCSEC Orange Book which was an evaluation criteria for trusted computing in the ‘80s. In other words, the reference monitor isn’t a new concept. It’s just been ignored or forgotten.
The reference monitor must enforce access control policies over users and the operations they may run, so that any malicious user is unable to circumvent those policies. It was deemed that to do that, the reference monitor must demonstrate the following properties characterized by the acronym NEAT.
- Evaluable (verifiable)
- Always invoked (always on)
- Tamper-proof (self-protecting)
The Insider Threat
Since the insider threat is now on everybody’s radar, we are reminded that the recommended security mechanism to combat abuse of authorized privileges, is the reference monitor. People have figured out that all attacks involve the misuse of insider credentials, even external vantage attacks. (It’s a two-fer!) The reference monitor denies unauthorized behaviours it detects in real-time, working as part of a strong trusted computing base. Because it enables one to set rules to either allow or deny access on a per user basis, it’s the control tool needed to set and enforce need-to-access and need-to-know rules, especially when combined with labelled security (MLS).
The lack of reference monitor type of controls makes it very hard to prevent insider abuses with little other user visibility in the network. When you see articles such as “Patching humans: pointless exercise or essential defence?“, ask yourself if the advice they offer would still be pertinent in an environment of trustworthy systems and reference monitor controls, able to enforcing access privileges and behaviours.
The prime reason why insider threat is a major problem today, is because the reference monitor hasn’t been implemented and put to use as was recommended years ago. Even in NIST sp800-160, the reference monitor is presented as an abstract, ideal concept.
KSE is a reference monitor
The good news is, people don’t have to settle for a theoretical model to emulate when they attempt to engineer trustworthy systems. There is a fully usable and working reference monitor available. KSE is a reference monitor. Any system that implements the KSE security sub-system becomes a mathematically verifiable reference monitor.
KSE features an innovative design that can be dropped on systems to deliver this security mechanism where it is needed. It’s a COTS security system for COTS systems. There have been reference monitors found in high end systems for high security environments, but never one usable and ready for widespread adoption across the commercial sector. Rule setting is intuitive and easily map to user activities with KSE. Even better, TUX AI will automate the implementation the next generation of KSE for SMBs as well.
KSE verifies all requests into the kernel and denies anything it does not accept from proceeding. It does a second check between the kernel proper and user space to verify that that what is leaving the kernel is consistent with the incoming request. Only approved requests will be allowed to proceed by KSE so that only proper system functions will be executed. It satisfies the all of the NEAT requirements, non-bypassable, evaluable, always invoked and tamper-proof.
KSE acts as a reference monitor in the ideal machine, and you can put it to work protecting against the insider threat, and against those who steal insider credentials. Remember, this security mechanism represents the foundation of security kernels, trustworthy systems and defensive capability. It’s not just an abstract model; the reference monitor is alive and kicking in the form of KSE.