Cloud Security Standards slogan is “If it cannot be measured, it cannot be managed“.
This is a statement that any auditor and security professional should abide by regardless of his focus.
How can someone have confidence, awareness, and assurances that he and the CSP are taking the correct steps to ensure that data is secured properly?
Frameworks and Cloud Security Standards hold the key here.
Why are users and entities still unconvinced that cloud computing is a good option, particularly from a security perspective?
The reason is simple: no international cloud computing standards or security standards exist.
In the absence of cloud-specific Cloud Security Standards that are universally accepted by providers and customers alike, you’ll deal with a patchwork of security standards, frameworks, and controls that are being applied to cloud environments.
These Cloud Security Standards include but are not limited to the following:
Possibly the most widely known and accepted information security standard, ISO 27001 was originally developed and created by the British Standards Institute, under the name of BS 7799.
The Cloud Security Standards was adopted by the International Organization for Standardization (ISO) and rebranded ISO 27001.
ISO 27001 is the standard to which organizations certify, as opposed to ISO 27002, which is the best practice framework to which many others align.
ISO 27001:2005 consisted of 133 controls across 11 domains of security, focusing on the protection of information assets in their various forms (digital, paper, and so on).
Since September 2013, ISO 27001 has been updated to ISO 27001:2013 and now consists of 35 control objectives and 114 controls spread over 14 domains.
Cloud Security Standards include these Domains:
- Information Security Policies
- Organization of Information Security
- Human Resources Security
- Asset Management
- Access Control
- Cryptographic
- Physical and Environmental Security
- Operations Security
- Communications Security
- System Acquisition, Development, and Maintenance
- Supplier Relationship
- Information Security Incident Management
- Information Security Business Continuity Management
- Compliance
By its nature, ISO 27001 is designed to be vendor and technology-agnostic (that is, it does not view them differently).
As such, it looks for the information security management system (ISMS) to address the relevant risks and components in a manner that is appropriate and adequate based on the risks.
Even though ISO 27001 is the most advanced security standard widely used today, it does not specifically look at the risks associated with cloud computing.
As such, it cannot be deemed as fully comprehensive when measuring security in cloud-based environments.
All Cloud Security Standards and frameworks assist in the structure and standardization of security practices;
However, they cannot be applied across multiple environments (of differing natures), deployments, and other components with 100 percent confidence and completeness, given the variations and specialized elements associated with cloud computing.
Due to its importance overall, ISO 27001 will continue to be used by CSPs and required by cloud customers as one of the key security frameworks for cloud environments.
Cloud Security Standards ISO/IEC 27002:2013
ISO/IEC 27002:2013 provides guidelines for organizational information security Cloud Security Standards including the selection, implementation, and management of controls taking into consideration the organization’s information security risk environments.
It is designed to be used by organizations that intend to select controls within the process of implementing an ISMS based on ISO/IEC 27001.
It can also be used by organizations to implement commonly accepted information security controls and develop their information security management guidelines.
Cloud Security Standards ISO/IEC 27017:2015
ISO/IEC 27017:2015 offers guidelines for information security controls applicable to the provision and use of cloud services by providing additional implementation guidance for relevant controls specified in ISO/IEC 27002 and additional controls with implementation guidance that specifically relate to cloud services.
ISO 27017 provides controls and implementation guidance for both CSPs and cloud service customers.
SOC 1/SOC 2/SOC 3
The Statement on Auditing Cloud Security Standards 70 (SAS 70) was replaced by Service Organization Control (SOC) Type 1 and Type 2 reports in 2011 following changes and a more comprehensive approach to auditing being demanded by customers and clients alike.
For years, SAS 70 was seen as the de facto standard for data center customers to obtain independent assurance that their data center service provider had effective internal controls in place for managing the design, implementation, and execution of customer information.
SAS 70 consisted of Type 1 and Type 2 audits.
- The Type 1 audit was designed to assess the sufficiency of the service provider’s controls as of a particular date, and the Type 2 audit was designed to assess the effectiveness of the controls as of a certain date (point-in-time assessment).
- Like many other frameworks, SAS 70 audits focused on verifying that the controls had been implemented and followed but did not focus on the overall completeness or effectiveness of the controls implemented.
- Think of having an alarm but not checking whether it was effective, functioning, or correctly installed.
- SOC reports are performed by Statement on Standards for Attestation Engagements (SSAE) 16, Reporting on Controls at a Service Organization.
- SOC 1 reports focus solely on controls at a service provider that is likely to be relevant to an audit of a subscriber’s financial statements.
- SOC 2 and SOC 3 reports address controls of the service provider that relate to operations and compliance.
- There are some key distinctions between SOC 1, SOC 2, and SOC 3:
SOC 1
SOC 1 reports can be one of two types:
A Type 1 report presents the auditors’ opinion regarding the accuracy and completeness of management’s description of the system or service as well as the suitability of the design of controls as of a specific date.
Type 2 reports include the Type 1 criteria and audit of the operating effectiveness of the controls throughout a declared period, generally between 6 months and 1 year.
SOC 2
SOC 2 reporting was specifically designed for IT-managed service providers and cloud computing. The report specifically addresses any number of the five so-called Trust Services Principles, which follow:
Security: The system is protected against unauthorized access, both physical and logical.
Availability: The system is available for operation and use as committed or agreed.
Processing Integrity: System processing is complete, accurate, timely, and authorized.
Confidentiality: Information designated as confidential is protected as committed or agreed.
Privacy: Personal information is collected, used, retained, disclosed, and disposed of in conformity with the provider’s privacy policy.
SOC 3
Reporting also uses the Trust Services principles but provides only the auditor’s report on whether the system achieved the specified principle, without disclosing relevant details and sensitive information.
A key difference between a SOC 2 report and a SOC 3 report is that a SOC 2 report is generally restricted in distribution and coverage (due to the information it contains), and a SOC 3 report is broadly available,
With limited information and details included within it (often used to instill confidence in prospective clients or for marketing purposes).
To review:
- SOC 1: This is intended for those interested in financial statements.
- SOC 2: Information technology personnel will be interested.
- SOC 3: This is used to illustrate conformity, compliance, and security efforts to current or potential subscribers and customers of cloud services.
Cloud Security Standards NIST SP 800-53
NIST is an agency of the U.S. government that makes measurements and sets Cloud Security Standards as needed for industry or government programs
The primary goal and objective of the 800-5323 standard are to ensure that appropriate security requirements and security controls are applied to all U.S. federal government information and information management systems.
The standard requires that risk be assessed and the determination made whether additional controls are needed to protect organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the nation.
The 800-53 standard “Security and Privacy Controls for Federal Information Systems and Organizations” underwent its fourth revision in April 2013.
- Primary updates and amendments include these:
- Assumptions relating to security control baseline development
- Expanded, updated, and streamlined tailoring guidance
- Additional assignment and selection statement options for security and privacy controls
- Descriptive names for security and privacy control enhancements
- Consolidated security controls and control enhancements by a family with baseline allocations
- Tables for security controls that support development, evaluation, and operational assurance
- Mapping tables for international security standard ISO/IEC 15408 (Common Criteria)
- Although the NIST Risk Management Framework provides the pieces and parts for an effective security program, it is aimed at government agencies focusing on the following key components:
- Multitiered Risk Management
- Security Control Structure
- Security Control Baselines
- Security Control Designations
- External Service Partners
- Assurance and Trustworthiness
- Revisions and Extensions
- Selecting Security Control Baselines
- Tailoring Security Control Baselines
- Creating Overlays
- Document the Control Selection Process
- New Development and Legacy Systems
One major issue that corporate security teams encounter when trying to base a program on the NIST SP 800-53 Risk Management Framework is that publicly traded organizations are not bound by the same security assumptions and requirements as government agencies.
Government organizations are established to fulfill legislated missions and are required to collect, store, manipulate, and report sensitive data.
Finally, a large percentage of these activities in a publicly-traded organization is governed by cost-benefit analysis, boards of directors, and shareholder opinion, as opposed to government direction and influence.
For those looking to understand the similarities and overlaps with NIST SP 800-53 and ISO 27001/2, there is a mapping matrix listed within the 800-53 Revision 4 document.
Cloud Security Standards PCI DSS
Visa, MasterCard, and American Express established PCI DSS24 as a security standard to which all organizations or merchants that accept, transmit, or store cardholder data, regardless of size or number of transactions, must comply.
PCI DSS was established following several significant credit card breaches.
It is a comprehensive and intensive security standard that lists both technical and nontechnical requirements based on the number of credit card transactions for the applicable entities.
Merchant Levels
| Merchant Level | Description |
| 1 | Any merchant regardless of acceptance channel processing more than 6 million transactions per year. Any merchant that the credit card issuer, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the credit card issuer’s system. |
| 2 | Any merchant—regardless of acceptance channel processing 1–6 million credit card transactions per year. |
| 3 | Any merchant processing 20,000 to 1 million credit card e-commerce transactions per year |
| 4 | Any merchant processing fewer than 20,000 credit card e-commerce transactions per year and all other merchants regardless of acceptance channel processing up to 1 million credit card transactions per year |
- For specific information and requirements, be sure to check with the PCI Security Standard Council
Merchant Requirements
- All merchants, regardless of level and relevant service providers, are required to comply with the following 12 domains/requirements:
- Install and maintain a firewall configuration to protect cardholder data.
- Avoid using vendor-supplied defaults for system passwords and other security parameters.
- Protect stored cardholder data.
- Encrypt transmission of cardholder data across open, public networks.
- Use and regularly update antivirus software.
- Develop and maintain secure systems and applications.
- Restrict access to cardholder data by business need-to-know.
- Track and monitor all access to network resources and cardholder data.
- Regularly test security systems and processes.
- Maintain a policy that addresses information security.
The 12 requirements list more than 200 controls that specify required and minimum security requirements for the merchants and service providers to meet their compliance obligations.
Failure to meet and satisfy the PCI DSS requirements (based on merchant level and processing levels) can result in significant financial penalties, suspension of credit cards as a payment channel, escalation to a higher merchant level, and potentially greater assurances and compliance requirements in the event of a breach in which credit card details may have been compromised or disclosed.
Since its establishment, PCI DSS has undergone several significant updates, through to the current version.
Due to the more technical and more black-and-white nature of its controls, many see PCI DSS as a reasonable and sufficient technical security standard.
People believe that if it is good enough to protect their credit card and financial information, it should be a good baseline for cloud security.
