Cloud architecture security - Part 2: Extrinsic controls

For securing cloud architecture there are some external control measures to be applied. Learn what these extrinsic controls should be and how to apply them.

The previous article in this series on cloud risk management discussed the criticality of secure architecture at the time of cloud definition. It also and looked at the physical and intrinsic controls involved in maintaining a secure cloud architecture.

Let us now cover extrinsic controls. These controls are typically those outside of the core cloud production servers and network devices.

Key management

As with any system—and more so for cloud architecture—the security of the data in motion (DIM), data in use (DIU) and data at rest (DAR) is through some form of encryption or the other. The cloud provider will also be the “key-keeper” in the literal sense, so service providers should bear these points in mind:

  • To ensure optimal use of computing resources, do a good risk management exercise to identify what data and VMs need to be protected, at what stage in the lifecycle, what key strength, and so on.
  • For any OTP, ensure that the “seed” is appropriately protected.
  • Ensure that the keys used to encrypt data encryption keys are generated and maintained in at least two separate parts with independent owners.

Security monitoring

The best way to preventing mishaps is to watch out for signs of weaknesses. For effective security monitoring in cloud architecture, take care of the following points:

  • Implement an intrusion and anomaly detection system across the cloud architecture, with centralized log management and log correlation.
  • Ensure a comprehensive structure for identifying and classifying security events.
  • Provide for automated alerts (SMS and email) for critical events.
  • Ensure near real-time response to events of any nature by qualified and experienced personnel.
  • Ensure effective DR for security systems so that expected or unexpected downtime does not lay bare your entire infrastructure.

Incident management

There is always the possibility of a serious incident or disaster occurring in a cloud architecture setup. To deal with this eventuality, a well-designed and practical incident management procedure is essential. Some best practices are:

  • Instead of shooting from the hip, get formal support or use a standard such as ISO 27035:2011, which provides a structured and planned approach to managing security incidents.
  • Ensure that you cover the entire cycle, including detect, report, respond and assess incidents.
  • Ensure that there’s good PR machinery at the service provider level. Letting clients and the regulatory bodies know about security incidents is mandated by law in many countries.
  • Ensure that the management regularly reviews incidents by means of regular MIS or personal meetings.

Periodic audits

No cloud architecture system is complete without an effective and efficient auditing system. A few points:

  • Have a well-defined audit plan covering the who, what, when and how of internal and independent audits.
  • In addition to the infrastructure, logs, and other routing aspects, the audits’ scope should include customer feedback and incidents logged in the IM procedure.
  • Chalk out a well-defined continual improvement path, which is regularly reviewed.
  • An audit is useless unless the management reviews, comments and extends support on the findings.
  • Proactively make audit reports—at least the executive summary—available to stakeholders and clients, as a sign of good faith.

Vulnerability management

Depending on the services you intend to provide through cloud infrastructure, vulnerability management can be critical. Here are a few points that often are the bane of most providers:

  • User organizations will most probably have their own vulnerability management program. Ensure that service providers give at least this level of compliance, if not more, for the provisioned resources.
  • Ensure a well-designed and practical system to identify and rank system vulnerabilities as per criticality.
  • Ensure that all patches are tested in a separate environment before rollout.
  • Some vulnerabilities (possibly critical) might be inherent to the system itself and cannot be ruled out—for example, an SQL-Injection bug in the software. To tackle such cases, ensure mitigating controls such as an application layer firewall.

Network controls

Finally, here are a few general controls at the configuration level for cloud architecture:

  • Ensure appropriate network segregation as per risk and functional levels such as application, databases, backups, externally accessed systems and internal administrative access systems.
  • Ensure isolation of VMs across tenants.
  • Ensure that cloud administrators with hardware access do not have access to the publicly accessible VMs and the data.
  • There have been instances of tenants intentionally installing compromised hosts into purchased VMs and then hacking into the underlying hypervisor, inducing resource drainage or even accessing other executing VMs. Ensure that appropriate isolation is maintained and resource provisioning adhered to.
  • Implement appropriate controls to ensure the integrity of VMs, infrastructure applications, network configurations, and all customer platform software and data.

These controls cover by and large the key risk areas of cloud architecture. In the next installment of this article series on cloud risk management, we shall take a detailed, practical look at the issues involved with identity and access management on the cloud.

Read the first part of this article on physical and intrinsic controls here.

This was last published in August 2012

Read more on IT risk management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close