Every organization needs a solid set of policies and procedures around securing their applications and interfaces. The AIS-01 control from the Cloud Security Alliance Cloud Controls Matrix provides guidance on establishing, documenting, communicating, and maintaining those policies to ensure applications are built and deployed securely. It's not the most exciting topic, but skipping it is asking for trouble down the road.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full matrix here.

The CSA CCM provides a comprehensive set of cloud security controls mapped to other industry standards like NIST, ISO, and CIS benchmarks. It's a great starting point for any organization looking to build out their cloud security program.

For more context, check out the OWASP Top 10 and the NIST Secure Software Development Framework.

Who should care?

This one is relevant for a few different roles:

• Software developers building cloud applications who need guidance on secure coding practices
• DevOps engineers responsible for deploying and operating applications securely
• AppSec leaders establishing the standards and governance for secure development
• CISOs and security leadership ensuring that applications meet the organization's risk tolerance

What is the risk?

The biggest risks that AIS-01 helps mitigate are:

• Insecure applications - Without clear policies and procedures, it's easy for insecure code to slip through the cracks and into production. This opens the door to vulnerabilities that attackers can exploit.
• Inconsistent practices - If every application team is doing their own thing, it's impossible to have any real assurance of the overall security posture. Inconsistency breeds weakness.

Implementing AIS-01 helps provide a baseline that all applications are measured against to reduce the likelihood of a breach due to an application vulnerability. The impact of a breach varies, but it's never good.

What's the care factor?

For most organizations, this should be a high priority control. Applications are the #1 attack vector these days. Insecure applications provide easy entry points for attackers to gain a foothold.

A single vulnerable application can undermine the security of the entire organization. It's often said that defenders have to be right 100% of the time, but attackers only need to be lucky once. Don't give them that chance.

The effort to implement AIS-01 pales in comparison to the potential cost of a breach. It's well worth the investment.

When is it relevant?

AIS-01 is relevant for any organization building or operating applications in the cloud. That's...pretty much everyone these days.

The only scenario where it might be less applicable is if you're dealing solely with pre-built SaaS applications and have no development happening at all. But even then, it's worth having policies for evaluating the security of vendors.

What are the trade offs?

Implementing application security policies and procedures does come with some costs:

• Time - It takes time to develop the policies, communicate them, and train the workforce. This can slow down development velocity in the short term.
• Friction - Introducing security checks and balances into the SDLC can be seen as red tape by some developers. It's important to balance security with usability.
• Money - Tools for static code analysis, dynamic testing, vulnerability scanning, etc. aren't free. There's also the cost of training developers.

However, these costs should be seen as an investment. Shifting security left and catching issues early is far cheaper than dealing with a breach down the line. The trade offs are worth it.

How to make it happen?

Here's a high-level roadmap to implementing AIS-01:

1. Assign ownership - Identify who will be responsible for creating and maintaining the policies. This is usually a joint effort between security and app dev leadership.
2. Establish the baseline - Determine which standards and frameworks you will align to (e.g. NIST, OWASP, etc). These provide a good starting point.
3. Develop the policies - Working with stakeholders, document the specific policies and procedures for secure application development. Key areas to cover include:
   • Secure coding standards
   • Security testing requirements
   • Vulnerability management processes
   • Secure deployment practices
4. Ensure the policies are actionable and measurable. Avoid vague statements.
5. Implement tools and training - Put the necessary tools in place to support the policies (e.g. static code analyzers, fuzz testers, monitoring solutions). Roll out training to developers on the new requirements.
6. Integrate into SDLC - The policies should be baked into the software development lifecycle, with clear gating between phases. Use automation where possible to make security frictionless.
7. Measure and enforce - Establish metrics to track policy adherence (e.g. % apps compliant, # vulns detected and fixed). Make it clear there are consequences for non-compliance.
8. Review and improve - Review the policies at least annually and look for opportunities to mature the program. Continuous improvement is the name of the game.

What are some gotchas?

A few things to watch out for when implementing AIS-01:

• Lack of buy-in - If the policies are seen as too draconian or not valuable, you'll face an uphill battle. Work with dev teams to strike the right balance and get their support.
• Tool sprawl - It's easy to go overboard with security tools. Be judicious and focus on the ones that provide real risk reduction. More isn't always better.
• Permissions gaps - Ensure the right roles have permissions to perform the necessary checks. For example:
  • Developers will need access to code scanning tools (codebuild:BatchGetBuilds, codebuild:StartBuild, etc)
  • Security teams need access to reporting and metrics (cloudwatch:GetMetricData, securityhub:GetFindings)
• Review the AWS IAM docs for the full list of permissions.
• Compliance theatre - Ticking boxes on a policy isn't enough. The practices need to have teeth. Regularly test your controls to ensure they're effective.

What are the alternatives?

There's really no alternative to having app sec policies and procedures. It's table stakes. The alternative is being breached.

That said, there are different approaches to implementing the policies. Using a cloud platform like AWS, Azure or GCP can provide guard rails and make some security best practices the default. This can reduce friction.

Low-code/no-code platforms can also help abstract some security complexities away from developers to reduce the burden. But they're not a silver bullet - you still need policies.

Explore further

This barely scratches the surface. To dive deeper, check out:

• OWASP SAMM - A framework for designing app sec programs
• CISA Secure Software Development Framework Guide - Guidance from the US CISA
• CIS CSAT - Consensus tool for assessing cloud security posture

Cloud Service Provider Best Practices

• AWS
• Azure
• GCP

But remember, reading about security is not a substitute for doing security. The most important thing is to get started building that app sec program brick by brick. Don't let perfect be the enemy of good. A decent set of policies that are actually followed beats a pristine document that sits on a shelf. Go forth and secure