Mitigating Fears Of Cloud Adoption: NIST SP800-53 And Data Protection Concerns

The Federal Government is increasingly focused on ways to expand the use of cloud computing to help meet increasingly constrained budgets and to increase efficiency. However, the security measures involved represent a whole new set of challenges. Not the least of which is the blurry line that starts to form at the “security perimeter”.  Gone is the well defined perimeter that comes with having systems and data “on-site,” controlled by government and contracted personnel.  Today, it has expanded to encompass cloud service providers (CSPs) and 3^rd party data and compute centers not entirely under government control. Some of that data is even being stored in other countries depending on the CSP and how it replicates customer data.

<Click To Tweet>: For #NIST SP800-53 - What you need to know about protecting your data in the cloud https://www.thalesesecurity.com/blog

For these reasons and more, SP 800-53 rev.4 has been updated to reflect a more “holistic” approach that considers the evolving technology and threat landscape.  Cloud computing is only one part of the interconnected and dramatically changing environment that agencies most now cope with, which also includes mobile computing; insider threats; application level security; supply chain risks; advanced persistent threats; as well as the trustworthiness, assurance, and resilience of information systems..  This post will focus on cloud computing. However many of the other issues are also part of the security risks associated with cloud computing.

If you are reading this, there is a good chance you’ve already started to think about these issues.  For cloud computing The real questions you should be asking are:

1. How can my  organization  project the same level of security on premise to the cloud?
2. How do I keep my organization’s data private in cloud computing’s shared resource environment?  Especially when control of infrastructure, monitoring and even physical access are absent or strictly limited?
3. Who will have access to my organization’s data beyond members of my organization? And how will I know?
4. How do I protect the integrity and control access to my organization’s data and applications in the cloud?
5. How do I safely move data from my organization’s on-site storage to cloud or elastic-type storage?
6. How can I ensure that my organization’s data is safe when I terminate use of a cloud storage provider?
7. How can I safely migrate data between CSPs?
8. Can a CSP’s system administrator access and view my content?
9. What will prevent a CSP System Administrator from taking snapshots of my VM environment and gaining access to my data as an insider threat?

If you visit Cloud.cio.gov, you’ll find a one stop shop for Federal cloud computing information.  This includes details about FedRAMP (the unified, government-wide risk management program focused on security for cloud-based systems) designed to help agencies prepare to securely use cloud-based resources.  Within these details is one item that I’m sure strikes fear into any agency moving their data to the cloud.  In the section “Data Survelliance” the first two sentences state: “When engaging with a CSP, it is important to remember that a third party will have complete access to your data. The personnel of the CSP are responsible for ensuring your information is secure at all times.” Now, I don’t know about you, but even with the strongest contractual security commitments, depending upon the CSP to policy themselves with privileged agency data is a major concern – A bet I’d not be willing to take.  Why can’t agencies control the access to their own data, and blind the CSP from seeing it?

Well, actually, it can be done.   Agencies can use cloud-based resources, and restrict access to critical data to appropriate users in their own organizations – when appropriate security controls are used.  Government should always be the custodian of access to data.  Not a 3^rd party.

With those appropriate security controls, access to both on premise and cloud-based data can be seamless.  If we look at the Access Control (AC) Family in NIST 800-53, it has a compliance baseline of Access Enforcement; Account Management; Separation of Duties; and Least Privilege.

Encryption is the first step - all data should be encrypted.  But, that’s only the first step.  Secondly, that encrypted data should be tightly wrapped with granular policy controls that dictate who, what, when, where, and how data will be decrypted.  E.g. only the database binaries themselves should be able to decrypt.  Root level users, Sysadmins, 3^rd party contractors, CSP Administrators have no need to view the data contents. Their job function is to manage an environment, not look at data.  Conversely, analysts and other business case users that do need to view data do not need to have administrative or root level privileges to an Operating System or environment.  It’s the enforcement of “least privilege” at work here.  However the controls to enforce least privilege must come from the kernel level, below the Operating System. Why?  If the control is at the OS or higher, a root level user can circumvent the control.  All of these access control capabilities should also be tied to the agencies identity and access management (IAM) infrastructure, so that when changes in personnel assignments and employment are made, a single change to status will automatically add/remove appropriate access to information.

Encryption key management is another critical issue when dealing with data that exists both on premise and in 3^rd party locations. Most key management systems rely on public key infrastructure (PKI) solutions that require distributing appropriate keys to individuals. This has its place in multi-factor authentication, identity management, and access control / authorization, but for data encryption it creates a management nightmare.  Using these keys to encrypt data requires assigning access to data based on encryption keys distributed to individual groups, and detailed mappings and dependencies for access to encrypted data.  We can do better than this.

Encryption keys for data at rest, whether on premise or in cloud, should reside in one place, not dolled out and copied to untold numbers of key fobs, users, and groups.  Let the encryption management system take care of encrypting and decrypting data on behalf of the users or systems attempting to access the data based on the granular policy controls put in place at the kernel level of the servers.  By utilizing encryption keys and management in this fashion, data that is to be abandoned from one CSP for another is easily crypto-shredded in the cloud by merely killing the key on the key management system, rendering the data useless.  There are no concerns of where all the keys exist because we know they are only in one place; under Government control.

In addition, keeping key management infrastructure on premise reduces the threat vector.  A cloud provider can’t access data without appropriate encryption keys – but they CAN manage that data, backup that data, create failover solutions and perform other management functions.  All without having data decrypted for them.

There are many more categories under the security control family of SP 800-53 Rev.4, but I believe the best chance government agencies have to thwart the next insider or outsider threat begins in how Government controls the data itself.  All the perimeter, network security, communication encryption, and SIEM, in the world is useless if the data itself, remains unprotected.

For more information regarding each of the categories in the Security Control Family of NIST SP 800-53, and how Vormetric can provide a direct mapping for mitigation of each of the control areas here, read out white paper located here.