Climbing the Security Maturity Ladder in Cloud
These five steps will insure that you achieve the broadest coverage for onboarding your most sensitive workloads.
Astute CIOs are actively migrating to public cloud to take advantage of scalability, flexibility and inherent security at a lower cost. As Rob Alexander, CIO Capital One, said at the AWS re:Invent 2015 conference in Las Vegas, "We can provide higher security with AWS than with our own data centers."
But as companies begin onboarding more sensitive workloads to the cloud, such as confidential or regulation-protected data sets, they will require broader security services coverage. That’s why it’s imperative for CIOs and CISOs to evaluate where their security capability falls on the security maturity ladder for cloud—and set goals to reach the top.
Beginning with the baseline rung, the levels to assess are:
EXTEND—Native, incremental and third-party security control sets. New-to-cloud companies often use existing on-premise security tools and processes and apply them in the cloud, but this can present drawbacks. It can mean replicating the segmented network architecture of legacy environments, which can cause exponential cost increases because virtual security appliances must be provisioned, configured and managed within each of these virtual private networks.
A better approach is to augment a cloud provider’s built-in, certified security features with incremental or third-party security packages designed specifically for cloud, such as CloudPassage, Trend Micro or Evident.IO.
To be fair, on-premise security providers are adapting to cloud, but the process is complicated. Products must be re-engineered to address the lack of access to physical switch infrastructure, auto-scaling of resources, and license/compute models such as PaaS and SaaS.
In addition, on-premise security tools may lack APIs, which allow for programmatic management and automation capabilities—a key to enabling the cloud’s infrastructure-as-code efficiencies. Without options to integrate with other vendors or export data into a centralized security dashboard, it becomes increasingly costly and complex to manage disparate security products in cloud.
DESIGN & ARCHITECT—Security pre-baked into architectures and design patterns, aligned to approved technology stacks. Companies need a blueprint for how security tools will work in the cloud, and how to apply them consistently and effectively. In some cases, industry-specific requirements for security will apply when spinning up an environment.
One example is the healthcare sector. Supporting use cases for personal healthcare information data in the cloud requires not only a different architecture, but also different data flows, firewall rules and security protocols—all built and managed using verifiable processes and templates for compliance.
AWS, Microsoft and Google all offer templates to support a secure configuration directly in the technology stack, as well as automation-ready, pre-configured environment deployment capabilities for different data sets and one-click deployment to meet standards such PCI DSS and NIST. These templates can be tailored for individual companies, pre-approved by architecture and security teams, and re-utilized to update or re-create an environment.
PACKAGE—Standardized approach through security function abstraction. As companies onboard and manage applications in the cloud, and possibly across clouds, they can reduce the number of implementation patterns and streamline testing/auditing efforts by taking a unified approach to security by providing security functions via an abstraction layer.
The AWS Encryption SDK, for example, offers a framework for native AWS encryption in application development. Providing a security service abstraction layer via a security SDK or security microservices, developers on AWS (and other clouds) can develop and re-use pre-built, packaged routines to manage encryption across multiple platforms. This reduces implementation variations; promotes code re-use, which lowers development costs; and increases portability of an application portfolio. Using standard, pre-tested and approved SDKs, data protection libraries, and logging/monitoring routines also reduces development and testing time, lowers security testing findings and decreases the overall cost of remediation.
EXPOSE—Pre-configured for security operation center (SOC)/managed security services. Cloud environments are generally a whitespace for security operations teams due to tooling and knowledge constraints. Developing SOC capabilities that have explicit cloud-aware instrumentation, procedures and skilled resources performing operational processes in a cloud environment is key.
By designing with the end in mind, companies can more easily integrate SOC monitoring directly into critical application data and infrastructure hosted in cloud with pre-provisioned hooks for these services. Security routines and code libraries can either be imaged onto a technology stack or accessed from available security microservices.
Newer provider service offerings are another managed security integration point to consider: Microsoft Operations Management Suite (OMS), for example, provides a cloud-native service to perform security assessments, evaluate an environment’s security configuration and identify baseline drift. Additional services such as AWS Config provide inventory, state change and custom processing using AWS Lambda functions for a continuous security monitoring capability.
AUTOMATE & INTEGRATE—Shift security left through DevSecOps. Companies can further speed delivery and lower costs by automating security integration and testing. Instead of simply moving security testing to earlier in the process, DevSecOps is a holistic methodology for ensuring that security consistency is achieved from design through operations. For instance, companies could automate the design review and verify secure code patterns/SDK are integrated earlier in the lifecycle.
Consider the benefits of this DevSecOps scenario: Each time a developer submits code for commit/deploy, a series of static and dynamic tests evaluate for possible security issues. When the time is right, identified vulnerabilities generate an alert to the security team and the developer to remediate and verify the fix. Using pre-built secure code in this manner would dramatically lower the findings in the testing phase, and limit common security routines to a one-time fix.
Which of these rungs characterize your company’s security posture in cloud? To climb to the top, make an action plan to extend security control sets, design and architect for cloud security, package a security code library to support a security SDK, expose the right application and infrastructure hooks for managed services, and integrate and automate to shift security processes left through a DevSecOps approach.
Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada, July 22-27, 2017. Click for information on the conference schedule and to register.
Related Content:
About the Author
You May Also Like