Instructobit
A reference monitor is a concept usually used in operating system architecture to describe a system through which every action must pass, the reference monitor must authenticate and allow or deny every action that passes through it. For a security mechanism to meet the requirements of a reference monitor it must have the following properties:
- The reference monitor must always be invoked for every action performed on the system. A subject (user, process, etc.) must not be able to bypass the reference monitor by any means.
- The reference monitor must be tamper proof in that an attacker should never be able to exploit the authentication system in such a way that the certain checks within the mechanism are skipped or disabled.
- The reference monitor must be simple and easy enough to understand such that it may be fully monitored and every component of it thoroughly tested. It should be provable that the reference monitor’s authentication system is properly secured.
- The reference monitor must be evaluable in that it generates sufficient metrics and logs such as audit trails in order for the security expert to gauge the effectiveness of the mechanisms.
A reference monitor is frequently compared to the gate of a castle, acting as the only entry point to a protected environment where access can be highly controlled.
We can use this concept of an operating system reference monitor and apply it to our APIs in order to significantly improve overall security of the application as well as your ability to monitor and track security events.
Implementing a reference monitor within an API
To implement a reference monitor into your API, the first step you should take is to ensure all requests invoke the mechanism, there should be no functions excluded from this. One robust method would be to only ever call one primary function for every single call that is made to your API, within this primary function you can include your reference monitor and then call the specific function requested which can be passed as an argument to the primary function.
function primary(url){
authenticate()
call_function(url)
}
This approach also allows you to implement other useful functions that can be executed within the global handler such as various types of logging.
function primary(url){
activity_log(url)
authenticate()
security_log()
call_function(url)
audit_log()
}
Other frameworks such as Flask for Python have a request process that allows you to specify functions that run before and after every single request is made. As long as you are absolutely certain there is no way a request can slip through your authentication function.
It is best to use a standardized method such as a wrapper function, rather than calling your authentication for each endpoint as this leaves the possibility of human error such as forgetting to include the authentication in certain endpoints, a single global wrapper function also makes it easier to prove the completeness of your authentication system.
When creating your authentication system you need to ensure that it remains as simple as possible so that each component therein may be thoroughly tested, this will allow you to meet the last 2 requirements of a reference monitor. Your authentication mechanisms should be thoroughly tested for any security holes, it would be advisable to have professional penetration testers confirm the security of this module.
Keeping your authentication module modular and separating complex operations into their own functions can help keep your module easy to understand and therefore easier to test each component.
function authenticate(url){
anti_brute_force()
Identity verification()
password_verification()
can_access(url)
generate_token()
}
As the main point of entry into your API, you need to make absolutely sure that there are no vulnerabilities within this module. This also means constantly keeping up to date with the latest security technologies and ensuring any dependencies such as encryption modules are kept up to date.
The benefits of reference monitor protected APIs
Robust security
As explained above, a reference monitor applying the necessary requirements is highly secure and can be used to significantly increase your API's ability to fend off potential intrusions.
Complete mediation
With one single point of entry into your application, there can be no doubt as to whether a user (or other subject) has been properly authenticated by your mechanism, this saves a lot of testing time as the testing that needs to be performed per function is decreased. If you have confidence in your reference monitor, you can have confidence that every function will be protected by it.
Understandability
It is a requirement of a reference monitor to be as simple as possible as to allow it to be easy to analyze. This results in a code set that is easy to read and to understand the logic, allowing for modifications and improvements to be much more easily implemented. Additionally, it is far easier to spot potential flaws in neatly structured code when reviewed or even during the process of being written.
Shared reference monitors
If a reference monitor is separated from the application and functions as a standalone authentication system through which all requests going to multiple applications have to be authenticated, it can significantly reduce the amount of security testing required for those systems as well as improve the overall security of those applications as more focused testing can be done on the single module. You can read in more detail about the security benefits of code reuse here.
This kind of reference monitor can be implemented using a secure token system which functions as a key to each application within the domain.
Logging
The requirement of a reference monitor to be evaluable means there are logs for actions performed within the reference monitor, if there are failed attempts to pass the reference monitor, the administrator will be able to find out, this can also be externally monitored so that administrators can be immediately alerted. In the event of an attempted breach it will also allow you to perform more comprehensive investigations and collect as much evidence as possible.
Potential drawbacks of using a reference monitor
Performance
When increasing security, including additional checks and logging, as well as complete mediation of all functions within your API, performance is likely to suffer somewhat. However, with the barrage of security breaches that are occurring on a daily basis, the cost of externally facing applications suffering a breach is far higher than the cost in performance you may suffer from additional security.
Single point of failure
A reference monitor functions as the primary entry and authentication point for subjects requesting resources from your API, in the event that a security flaw is discovered by an attacker they may breach your security entirely, this threat is compounded when using the same reference monitor across multiple applications. However as security flaws are a threat in any application, and any application can suffer a breach, this is not a unique threat. In order to mitigate this threat as best as possible it is critical to ensure that your reference monitor is tamper proof, constantly kept up to date with the latest security technologies and updates, and well tested by security experts.
Increased storage requirements
With additional logging- especially the amount that a reference monitor requires to be evaluable- comes additional storage capacity requirements. This will be especially noticeable for high volume applications. A couple log entries may seem trivial, but you would be surprised how quickly they tend to build up! With larger applications it may be advisable to sync your log files to a dedicated storage server, then rotate them regularly on the application server.
If you'd like to contribute to this discussion feel free to leave a comment below!
References
Pfleeger, C., Pfleeger, S. and Margulies, J. (2015) Security in computing. Fifth.
Heckman, M. R. and Schell, R. R. (2016) ‘Using proven Reference Monitor patterns for security evaluation’, Information (Switzerland), 7(2). doi: 10.3390/INFO7020023.
Lundblad, A. (2013) ‘Inlined Reference Monitors : Certification,Concurrency and Tree Based Monitoring’.
