The former Director of Central Intelligence Directives 6/3 established specific protection levels based on an information system’s assessed level of concern. In 2008 The Office of the Director of National Intelligence (ODNI) began releasing Intelligence Community Directives (ICD) that were to eventually supersede the DCID. I’m no longer an active practitioner of Certification and Accreditation so it is unclear to me whether the ICD 500 series has actually superseded or cancelled the DCID 6/3. From my interactions over the past 18 months I’m thinking that the DCID 6/3 is still alive combined with specific ICD 500 guidance and 800-53. Regardless, in my opinion the DCID 6/3 offers some great legacy guidance for multi-tenant clouds.
The Protection Levels (PL) defined in the DCID 6/3 ranges from PL1 – PL5. PL1 provided guidance on how to secure information systems with a very low level of concern to PL5, addressing information systems with extremely high level of concerns and multiple classification interfaces. Somewhere close to the middle was PL3, which provided guidance on how to secure systems that needed to operate in a compartmented mode.
Compartmented mode of operations refers to the existence of “need to know” or communities of interest, which requires separation of communications and information. The main difference between a PL3 system and PL4 is discretionary access control (DAC) vs. mandatory access control (MAC). Examples of DAC are file permissions, group access controls and virtual network paths. Examples of MAC are process labeling and physical network separation. DAC leverages many controls existent in most modern operating systems, applications and network virtualization mechanisms where as MAC typically requires operating systems that support process labeling or “type” enforcement like Solaris with Trusted Extensions or Red Hat SELinux.
When looking at most commercial and traditional government requirements for multi-tenancy cloud there are many similarities within the PL3 constructs for securing those implementations. A multi-tenant cloud is really nothing more than a set of highly compartmented computing resources, leveraging varying degrees of virtualization technology and role-based access controls. Different levels of security services in the forms of confidentiality, integrity and availability can be architected based on customers’ overall requirements. PL3 provides valuable guidance on the technical implementation details.
I had personal experience in the late 90’s building such a system. Multiple different customers’ networks and application services, to include voice, were collapsed over a single network across a few data centers. Data paths and application access were all controlled and isolated based on the individual compartments – and server virtualization was being implemented. I’m sure this wasn’t and isn’t the only system of its type in existence and the DCID 6/3 served as the mechanism for implementing the system’s security controls. This same system also went through a rigorous certification and accreditation process. It was much more difficult back then to create and maintain these isolated resource paths. We didn’t have user authentication mechanisms like Cisco TrustSec and components like security group tagging and 802.1ae that leveraged 802.1x to dynamically provision and secure these virtualized paths. TrustSec provides our present day environments with a real advantage when deploying multi-tenancy or any environment which needs to provide a fine layer of granular separation of computing resources based on authentication and policy.
As NIST and the Federal Cloud Commission continue to evolve their thinking on cloud and cloud security maybe the DCID 6/3, specifically PL3, can help establish guidance for achieving multi-tenant clouds of the future. After all, security is the number one inhibitor of the Federal Government moving to cloud based models so maybe we can leverage some good, legacy policy guidance coupled with newer technologies to help move into the future.