[Editor’s note: This is the third article in a six-part series that looks at the primary considerations as well as the process of self-discovery that is required in the definition, development and implementation of private cloud computing. The articles were prepared by cloud experts at Logicalis, an international provider of integrated information and communications technology solutions and services.]
by Von Williams director of Information Security, Audits and Compliance for Logicalis
It is somewhat ironic that one of the main reasons IT directors give for preferring a private cloud in their data center over leveraging a public cloud is their concern for security. There appears to be some projection going on here. Unless an organization is in a regulated industry that requires proof of security (i.e., PCI DSS, HIPAA, FERPA, FISMA, ITAR), the level of security in many data centers today could best be characterized as “not so much.”
Admittedly, the overriding demands of keeping everything up and running leaves little time in many IT shops for diligent security. Where they exist at all, security policies are often incomplete, outdated and untested. The commitment to implement a private cloud environment in many data centers, as a result, provides a strategic opportunity to develop a comprehensive security policy from scratch.
A security initiative needs to be a detailed, disciplined process, but it doesn’t have to be overwhelming. Once you set a few processes in motion, developing a dependable security policy becomes a very logical, even mechanical, undertaking that proceeds by extending the right building blocks throughout the IT infrastructure. Technologies and procedures exist today that can ensure that your private cloud complies with your security policy. But you have to have a security policy to apply in the first place.
A best practices approach to upgrading and/or creating a security policy that is appropriate for your organization focuses on five basic security components: risk management, data ownership, data classification, auditing and monitoring, and security incidence response.
Risk management
The first step in the development of a security program needs to be a risk management policy that establishes how much risk your organization is willing to accept and identifies the security and privacy requirements needed to ensure compliance with the federal and state regulations that oversee your industry.
To be authoritative, a risk management policy needs to have the input and buy-in of key stakeholders including finance, HR and all the C-level people in the executive suite. Go as high as you can get. You’ll need top down support to implement your security policy throughout your organization.
The advantage of a thorough and thoughtful risk management policy is that it takes the mystery out of privacy and security requirements and replaces a nagging uncertainty with clearly delineated rules that can be extended confidently throughout your IT infrastructure as it grows to include private, public and hybrid clouds.
Data ownership
The champions and enforcers of the risk management policy are the designated data owners in specific business units who are ultimately responsible for the protection and use of a specific subset of information. This is where the buck stops.
The data owner decides the classification of the data that is to be maintained and is held responsible for any corruption of or unauthorized access to the data in his or her charge. Data owners are also responsible for ensuring that the necessary security controls are in place and proper access rights are being used, defining security requirements and backup requirements, approving any disclosure activities, and defining user access criteria.
Data classification
A primary role of a data owner is the thorough data classification of all data under his purview into three typical groups: private, confidential and public. A spreadsheet with financial data, for example, would be private and confidential. A memo about the company picnic would be public.
Once the data owner has made the classification, the level of security that needs to be associated with specific types of data becomes obvious. The classification determines who needs to access specific data — as well as who should not. Access controls and levels of encryption can then be set accordingly. The data classification policy also serves as a record of truth that you need to make available to everyone so that the appropriate security is consistently applied.
Auditing and monitoring
Once you have the controls in place, then you have to keep an unblinking eye on how well they work. This function is generally provided by a security incident and event monitoring (SIEM) system that records successful and failed login attempts into key systems, configuration changes and system activities. SIEM lets you see who is accessing your systems and how. Ideally, logs of who is getting into your systems should accurately reflect the access policies that you have in place. Importantly, SIEM also includes log correlation between various security components enabling you to reconstruct the series of events that led up to a security incident.