Establishing clear baseline security requirements for your applications is a critical first step to ensuring your software is built with security in mind from the start. Documenting these requirements provides a north star for developers to aim for and a measuring stick to assess progress against. Regularly reviewing and updating the baseline keeps it current as new threats emerge and lessons are learned.

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 matrix provides a comprehensive set of security controls specifically designed for cloud computing environments. It's a great resource for any organization operating in the cloud. For more on securing cloud applications, check out the AWS Well-Architected Framework Security Pillar.

Who should care?

This is relevant for:

• Software architects designing application security frameworks
• Developers building cloud-based applications
• DevSecOps engineers integrating security into CI/CD pipelines
• IT security managers overseeing application security programs

What is the risk?

Without a well-defined security baseline, applications may be developed with inconsistent security controls, leading to potential weaknesses and vulnerabilities. This increases the risk of:

• Data breaches exposing sensitive information
• Malware infections compromising systems
• Compliance violations resulting in fines and reputation damage While having a baseline won't eliminate these risks entirely, it significantly reduces their likelihood and potential impact by embedding security best practices into the development process.

What's the care factor?

For any organization building or running applications, this should be a high priority. Insecure software puts the business at risk of financial and reputational damage that could threaten its very existence. Even a small data breach can undermine customer trust. Proactively managing these risks through secure development practices is far more cost effective than responding to incidents after the fact. An ounce of prevention is worth a pound of cure.

When is it relevant?

Application security baselines should be established for any application that processes sensitive data or performs critical business functions. They are a must-have for public-facing web apps and APIs. However, they may be overkill for small utility scripts or internal tools, where the risk surface is minimal. The baseline requirements should be tailored to each app based on a risk assessment.

What are the trade-offs?

Establishing and enforcing a security baseline requires an upfront investment in defining the standards and modifying development processes to accommodate them. More security checks may slow down development velocity. Restrictive security controls can impact performance and usability. However, these costs are minor compared to the potential cost of a major security incident. You can't bolt security on after the fact.

How to make it happen?

1. Conduct an application risk assessment to identify key threats and vulnerabilities
2. Review industry standards like OWASP Top 10 and NIST 800-53 for recommended security controls
3. Work with architects and senior developers to define a minimum baseline of security controls required for all applications
4. Document the baseline requirements and make them easily accessible to all developers
5. Integrate automated security testing into the CI/CD pipeline to check for compliance with the baseline
6. Make the baseline a gate for deployment - don't allow apps to go live if they don't meet the minimum bar
7. Review and update the baseline at least annually based on new threats, technologies, and lessons learned

What are some gotchas?

• The security baseline must strike a balance between being strong enough to be effective but not so restrictive that it paralyzes development. Start with the most critical controls and add more over time.
• Automated tools can check for many common security issues but they are not perfect. Manual penetration testing is still important.
• Developers need adequate training on secure coding practices to meet the baseline. Integrate this into onboarding and ongoing education.
• Enforcement of the baseline requires the right tools and processes. You'll need a good static code analysis tool and a way to break the build if issues are found.
• Don't forget to secure the CI/CD pipeline itself. You'll need strong access controls to prevent tampering. The specific permissions depend on your toolchain but expect to tightly restrict who can modify build configurations and deployment scripts.

What are the alternatives?

There's really no substitute for an application security baseline. Ad-hoc security controls bolted on late in development are better than nothing but will leave gaps. At a minimum every app needs:

• Authentication and access control
• Input validation and output encoding
• Secure communication over HTTPS
• Secure configuration with no default passwords
• Error handling that doesn't leak sensitive info
• Logging of security events
• Prompt patching of known vulnerabilities

Explore further

• Open Web Application Security Project (OWASP) Top 10 Web Application Security Risks
• NIST Special Publication 800-53 rev 5, Security and Privacy Controls for Information Systems and Organizations
• AWS Resources:
  • Security Overview of AWS Lambda
  • Security Overview of AWS Key Management Service
  • Using VPC Endpoints with S3
• Related CSA CCM Controls:
  • IAM-06 Application Specific Roles and User Access
  • IPY-03 Sensitive Data Protection
  • TVM-04 Secure Application Coding Practices
  • LOG-01 Logging and Monitoring Policy and Procedures