Multi-Level Security Information Systems, better known as MLS systems, have proven merit in the DoD arena in terms of providing a security net and thwarting threats to data and infrastructure within a unified system. Certainly this type of implementation would make sense commercially, but in the fast moving, ever-changing enterprise space, CTOs have historically been hesitant to adopt some of the advancements in these trusted operating systems on top of optimized hardware.
That doesn’t stop my ever curious industry colleagues from asking me for advice about the exact level of complexity involved with MLS, and whether or not the potential ROI and added security enhancements are real.
Provided the install, integration and execution pieces are managed correctly my answer is consistently the same. Maybe.
For those not familiar with military technology and terminology, the Defense Information Systems Agency (DISA) website defines MLS as:
- A capability that allows information about different sensitivities (classifications) to be stored in an information system.
- Allows users having different clearances, authorizations, and need to know the ability to process information in the same system.
- Prevents users from accessing information for which they are not cleared, do not have authorization, or do not have a need to know.
The federal government’s Trusted Computer System Evaluation Criteria (TCSEC), or what is often referred to as the ‘Orange Book’ defines MLS as, “a class of systems containing information with different sensitivities that simultaneously permits access by users with differing level of security clearances without risk of compromise.”
Basically, MLS is adept at thwarting threats while providing access to multiple users with multiple levels of security clearance, which would seemingly make it ripe for enterprise adoption. If only it were easy to implement and integrate with existing enterprise systems, I’d suggest that every CTO investigate the benefits of an MLS hardened infrastructure.
That’s not the reality though. In fact, I’d only suggest that those CTO’s with the threat and vulnerability knowledge base, team expertise and freedom to pioneer the evaluation of MLS hardware policies today.
What exactly makes MLS implementation so difficult to deploy? The first problem commercial enterprise CTOs have to deal with is a shortage of time and resources needed to devote to an MLS implementation. It takes time to get the implementation right and the corporate world is vastly different from the DoD. Though MLS technologies have existed for decades, best practices for MLS implementation are continuing to develop and remain poorly disseminated outside the security and intelligence communities. When you consider this limited access to information available in regards to MLS implementations, time and budget often kills the idea of implementing MLS commercially before it starts.
Technically, an MLS implementation requires a team of very savvy engineers. First, you must have a team of Linux administrators to properly configure and harden the Linux operating system. There is a saying in the Linux MLS world that every system change now requires three times as long, simply because it is now three times as complex, but ultimately much more secure as no individual has unfettered access to the system.
The basic setup and installation for a Redhat base install can take upwards of two days, even if you are an intermediate level RHEL system administrator. In addition, you will want to assure that there is proper data governance in place along with a matrix of which groups and users should have access to which data sets; generally the role based access controls is a separate security group outside of the system administrator group. Other critical pieces to consider include a proper monitoring and logging platform such as Splunk, and also a secure data store to assure important, non-ephemeral, persistent data is securely archived.
Fortunately, I do have some suggestions for making a commercial implementation a bit easier.
- Shorten the install time, by creating templates utilizing simple bash scripts to make the appropriate configuration file edits. Most enterprises already utilize automation deployment engines that could easily integrate these scripts for deployment and standardized enforcements across the infrastructure, such as Chef or Puppet.
- If you are utilizing virtualization, you can store golden images and clones for easier provisioning. It also helps to take snapshots as you iterate, as even the slightest mis-edits could “break” your install. Frequent snapshots can easily allow you to rollback to a last known, good state.
- Utilize turnkey solutions and clusters from certified MLS systems Integrators.
- Even if a company doesn’t choose to implement the entire reference MLS architecture, an important takeaway is to integrate system security “best practices” in the design phase. And do not bolt them right after deployment into production just to satisfy a compliance. Enterprises tend to focus too much on perimeter security (Guns/Guards/Firewalls) versus where they are most vulnerable — with employees that already have access to company and customer data.
To those industry colleagues and acquaintances who I have answered the MLS implementation question in the past with a “maybe,” please conduct your own investigation in relation to MLS rather than just taking it from me. I think that, with the right team in place and a calculated approach, implementing MLS in a commercial environment can prove a successful endeavor that can benefit any organization, whether in the government space or commercial.
Security is perhaps the most important concern on the enterprise level today, right next to storage, so an investigation into making your systems tighter and more robust is warranted. Market demand always necessitates technology innovation and the squeaky wheel typically gets the oil.
Unless, of course, it is too difficult to figure out how to grease the wheel properly.