Get My Score

Control Your Cloud

Control Your Cloud

This is the second blog in a series detailing workload best practices.

The first blog, Securing Modern Workloads, is available here

The Cloud Security Alliance has done a phenomenal work in defining various cloud controls you should act upon or at least be aware of when determining your responsibility and choosing qualified vendors or training in-house personnel. One such work is a Cloud Controls Matrix that highlights the Shared Security Responsibility Model and provides architectural references.

The matrix defines the following control domains:

  • Application and Interface Security
  • Audit Assurance and Compliance
  • Business Continuity Management and Operational Resilience
  • Change Control and Configuration Management
  • Data Security and Information Lifecycle Management
  • Datacenter Security
  • Encryption and Key Management
  • Governance and Risk Management Baseline Requirements
  • Human Resources
  • Identity and Access Management
  • Infrastructure and Virtualization Security
  • Interoperability and Portability
  • Mobile Security
  • Security Incident Management, E-Discovery, and Cloud Forensics
  • Supply Chain Management, Transparency, and Accountability
  • Threat and Vulnerability Management

This colossal list of controls further complicates cloud security and you quickly begin to look for the basics. Before you start, understand that:

  • Not ONE vendor can provide all the controls you need
  • You could potentially leverage the guidance and work already done by your cloud provider and its partners
  • ONE vendor could be great at a single control family but that’s not all that you need
  • It is hard to substitute one vendor/control for the other just citing minor overlaps

For example, if you have a vendor that provides Threat and Vulnerability Management, it can’t be a substitute for vendors providing Audit Assurance and Compliance or Change Control and Configuration Management. The chances of complete overlapping specializations are rare.

Control Primer

Let us cover some basics about the controls to set the context. Broadly, there are 3 categories of controls:

  • Administrative Controls
  • Physical Controls
  • Technical Controls

These can be combined into an acronym as APT controls.

Administrative controls surround people and process in your organization. These business controls are put in place by your company executives and cover business activities from secure hiring processes, security orientation of the employees, controlling purchases with separation of duties, or anything else to fertilize a secure organization DNA.

Physical Controls safeguard your premises, manage visitors, reduces employee and customers hazards and anything else to protect you and your business from physical assaults.

Technical Controls work with the various technologies around us. These include, for example, cryptography, authentication, logging, and configuration management. Vendors help you to put these controls in place.

Achieving PCI Compliance

Let us switch gears and talk about achieving the goal of PCI compliance. At the outset, here are the high-level PCI requirements.

If you are running PCI workloads on-premise, you own the fulfilment of the entire set of requirements above. Whereas, if you are running your PCI workloads in the cloud, your cloud provider most probably has taken care of the basics such as physical infrastructure.

One important consideration here is to understand the capabilities or skills required to work on such compliance requirements. You require 3-dimensional skills:

  • You require someone who understands these control requirements in-depth
  • You require someone who understands your infrastructure workloads and targets
  • You require someone who could then implement the controls suited to your targets

Let’s expand on each of these skills.

 

Understanding security control requirements in-depth

The security control requirements are typically written in a policy language. A policy language, even though easy to read, requires quite-a-bit of context and training to make sense and to understand its intent. You often hear people or vendors saying that these requirements are open to interpretation. You need to know the context to interpret this correctly. Such context is built by hours of experience and training. There are qualifications such as PCI PROFESSIONAL (PCIP)™ or CISSP that help you build this context. Without these qualified and experienced people in your team or within your vendor, it is likely that you are investing in something that might not stand the test of time.

 

Understanding your infrastructure workloads and targets in-depth

This is where the heavy lifting is. You require someone who can ‘translate’ and ‘map` the security controls to target capabilities. Target of Evaluation (ToE) determines which controls can be mapped.

ToE capabilities differ. MS-Windows® does not provide the same capabilities as Red Hat Enterprise Linux®. So, a PCI set of controls on Windows® would be technically different from PCI set of controls on Red Hat®. Additionally, as an example, if you are using AWS cloud, the additional ToE for PCI controls becomes the AWS services you are using for your workload.

Let’s take an example.

Suppose, you are ‘translating’ and ‘mapping’ the PCI requirement “8.1.1 Verify Unique ID”.

On Linux machines, you must

  • Check for Duplicate UIDs
  • Check for Duplicate GIDs
  • Check for Duplicate User Names
  • Check for Duplicate Group Names

to assess these requirements and fix them if they are not in the desired state. Whereas, this requirement is automatically taken care by Windows® operating systems and hence you don’t need to check anything.

Linux® and Windows® vendors do not provide any kind of control matrix mapping to the capabilities. This is purely left for the user to select and implement the controls needed for the security requirements. In contrast, cloud service providers such as AWS provide a mapping of target capabilities against the security requirements. But, here again, AWS takes care of the PCI requirements from its perspective and there are requirements left for you to configure, implement and monitor.

Here is an example to illustrate the above discussion:

PCI Requirement - 8.2.3 Passwords/phrases must require a minimum length of at least seven characters.

Target of Evaluation (ToE) – Red Hat Enterprise Linux®, MS-Windows® and Amazon Web Services.

Mapped PCI Controls

  • Linux – Set minlen parameter to 7 in the /etc/security/pwquality.conf
  • Windows – Set Group Policy for Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Minimum password length to 7.
  • AWS – Set IAM account password policy parameter --minimum-password-length to 7.

So, now you get the difference and understand the pain and effort requirement for each ToE. Imagine to be doing this for all PCI technical level controls and for all your targets which may include:

  • Microsoft Windows 7, 8.1, and 10
  • Microsoft Windows Server 2008 R2, 2012 R2, and 2016
  • Red Hat Enterprise Linux 6.x and 7.x
  • Ubuntu 12.04, 14.04, and 16.04
  • Debian 7 and 8
  • SLES 11 and 12
  • Amazon Linux
  • Amazon Web Services
  • Microsoft Azure
  • Google Cloud Platform
  • Anything else

It is unsurmountable without the required specialization. When you look at the vendor claims of broad set of controls, you don’t really care if the chosen vendor has covered all the controls on earth. You should ask questions related to your requirements. You should be asking the right question “How deep is your Target of Evaluation?”. If you get answers like “Umm, we cover PCI for Red Hat only, or, no, we don’t really go at this level of checking”, then probably you should ask more relevant questions about the offering. At times, it is easy to get blinded by untrue overlapping claims and coverage.

 

Implementing the controls suited to your targets

From our discussions, so far, you understand that the ways to assess Linux® machines may be quite different from the ways to assess Windows® or AWS cloud elements. There are also subtle differences between scanning on-premise workloads and cloud workloads. Based on your ToE, you need to have appropriate skills or vendors to implement these controls. It is incorrect to assume that if a vendor can scan Windows, it can also scan AWS cloud elements or vice-versa. You need to place the controls on various targets and it is not one-size-fits-all.

Conclusion

It is misleading to believe that one vendor could help you provide all security control requirements. Standards such as PCI have a broad set of controls that require skills and specialization that might differ significantly from vendor to vendor.

Cavirin is well-positioned and staffed to understand your security control requirements both in the cloud as well as on-premise. Not only it has broad set of controls standards supported out of the box but also has depth in each coverage. From the Cloud Control Matrix perspective, Cavirin primarily covers controls related to

  • Audit Assurance and Compliance
  • Change Control and Configuration Management
  • Governance and Risk Management Baseline Requirements
  • Identity and Access Management
  • Infrastructure and Virtualization Security
  • Threat and Vulnerability Management

Cavirin covers your heterogeneous workloads both on public clouds as well as on hybrid clouds. We understand the challenges of requirements, such as above, that you face regularly and we are on a mission to exactly solve this one hard problem -  continuous risk assessment capabilities to keep you aware of security drift and continuously protect you.

 

0
0
0
s2sdefault

© 2018 Cavirin Systems, Inc. All rights reserved.