Building an effective cloud security risk management program can seem like a daunting undertaking. We recently had a conversation with special guest Lori Higham, currently the Cloud Security Director at a large health insurer, where we discussed best practices and tips for implementing effective strategies to take an organization from zero to a well-secured, managed state.
Drawing on her extensive experience in developing and implementing cloud security strategies, here are the top 5 key takeaways from the conversation:
1. Have a Structured Strategy and Lean on Automation & Centralized Management
As discussed in the webinar, a first step organizations can take in building out a successful cloud security program is having a structured strategy. A few areas that Lori recommended to concentrate on include:
- Understanding the environment’s purpose/what the environment is intended to host
- Have a plan for how you intend to migrate the applications, including their dependencies, integrations, and the specific cloud services they will use
- Determine how cloud services should be architected and configured to support required capabilities
- Identify which capabilities of cloud services should be allowed or restricted
- Ensure there is a plan for automation and centralized management
On the topic of automation and centralized management, Lori emphasized how essential this is to ensure consistency and efficiency, especially for larger organizations. She also noted that automation should be applied to the end-to-end process – from alerting to how those detections are handled. However, this is the last step, as you can’t create automation without first having a well-defined strategy in place.
2. Ensure Strong Alignment Between Builders and Protectors
One of the major challenges in reaching a fully managed cloud security state, especially in large organizations, is ensuring close collaboration between DevOps and security teams. As discussed in the webinar, this collaboration is key to ensuring security guardrails and other security requirements are incorporated directly into Infrastructure as Code, e.g., Terraform, AWS CloudFormation.
By fostering strong communication and collaboration between these two groups, security guardrails are less likely to conflict with development goals. Both developers (responsible for building revenue-generating assets) and security teams (tasked with protecting those assets) need to align their efforts to prevent costly breaches and misconfigurations.
“As a team, you have the group responsible for building revenue-generating assets, and the group responsible for protecting those assets, and both are equally important.” Said Lori. “If you have a great security program but nothing to protect, it’s pointless. Likewise, if you have great assets and they become compromised by ransomware, that could result in stolen data and lawsuits. There has to be strong collaboration, where security is very clear on requirements and those requirements are baked into what DevOps is doing in terms of their automation, infrastructure as code, and also any additional guardrails that are put in place.”
3. Implement Global Policies
It’s crucial to establish global or organization policies as these set clear (and wide) boundaries, such as enforcing TLS 1.2, requiring customer-managed keys, or blocking the use of certain services.
One challenge, however, is that in larger organizations there can be many different business units, and different business units may require specific policies or exceptions. In these cases, you can create and manage policies for each. For example, using different AWS Organizational Units (OUs) or GCP folders, to apply different organization policies or exemptions as needed.
The difficulty with this, and something that should be considered, is the management overhead and complexity. For example, if you have 8 + different business units, each with a different approach, it becomes difficult to manage and can lead to a lack of standardization.
4. Leverage Infrastructure as Code (IaC) for Both DevOps and Security
Infrastructure as Code (IaC) is an essential tool not just for DevOps but also for security. When building out organizational policies, you don’t want security teams doing that manually. As Lori mentioned, IaC tools can help security teams automate and centralize their efforts, saving security teams a lot of time. By having requirements predefined, security teams can ensure everything is controlled from a centralized platform, reducing management overhead while maintaining consistency and standardization.
IaC also enables “secure by design”. By embedding security policies from the beginning using IaC, assets can be more seamlessly managed in a secure manner. This means that your infrastructure is not only automated but that security measures are integrated into your deployment and configuration processes.
Another key benefit of IaC that was discussed is streamlining remediation. If there is a misconfiguration, especially in complex environments with many microservices, such as hundreds or thousands of assets (e.g., Lambdas), you don’t want to chase down every individual instance. Using IaC, once you identify the issue, you can trace the problem back to a single line of code, modify that and propagate it across the entire cloud environment. This allows for efficient remediation at scale and ensures that similar issues won’t recur.
The importance and benefits of IaC for security is further explored in one of our other recent blogs on code to cloud security.
5. Use AI for What It’s Good At and Know Its Limitations
Artificial Intelligence excels at tasks like summarizing large volumes of data. When fed accurate data, it can quickly provide valuable insights, saving analysts time by automating repetitive tasks. However, as Lori mentioned, there are many use cases AI is just not as good at, and it’s important to recognize this. For example, AI is not reliable for tasks like fact-checking, and human experts must remain involved to verify results.
Another powerful application of AI, which was discussed, is simplifying the process of identifying the best resolution path for remediating and/or mitigating cloud vulnerabilities and misconfigurations. Because AI can assist in recursive problem-solving, it can simulate the impact of changes on your security risk backlog, which would be extremely challenging for even the best security team to do manually.
But also in this case, it’s still essential for DevOps and security experts to review any proposed changes before implementing them. AI is a tool for decision-making, not automated remediation. It’s about using AI as a guide to help prioritize risks and find optimal solutions, not to take action without human intervention.
Conclusion
Building a robust cloud security risk management program is an ongoing journey, but by focusing on these best practices – defining a strategy, leaning on automation and centralized management, aligning teams, enforcing global policies, leveraging IaC, and incorporating AI thoughtfully – your organization can build a strong, scalable security framework that evolves with your cloud environment.
You can check out the full webinar recording on demand here. To see how the ZEST platform is redefining cloud risk remediation and mitigation, contact our team.
