Purpose

The purpose of this document is to outline an application security strategy and roadmap for AWS Cloud SaaS applications, covering both application security concerns as well as AWS specific infrastructure. This is a checklist style article to help start conversations and give you information to perform further research. I’ve referenced other white papers and further reading available for more information throughout.

Application Security

An effective application security program will reduce security risk associated with code development while keeping disruption to the normal SDLC processes to a minimum. Ideally, this is done in an environment that fosters cooperation and transparency between AppSec professionals and the development team as a whole. If the entirety of the team is on the same page in regard to application security goals, and the maturity journey to get there, then the security team can operate as a service organization whose goal is enablement, rather than as a policing organization whose goal is governance.

Every decision made by the application security team should be held up against these standards:

• Does this decision serve the goals of the business?
• Does this decision match the existing culture (or culture you are trying to achieve)? In other words, does it set a poor precedence or create adverse side effects?
• Does this decision preserve the dignity of all the parties involved?

Also see: How to Scale an Application Security Program

Risk assessment, analysis, and reduction is a layer on top of these tests and ultimate is the goal you are trying to achieve. The ends do not justify the means, however, so an AppSec team can use these questions to not only achieve their goals, but to achieve them in the best manner possible. Minimum disruption. Maximum impact. Use carrots, not sticks.

Every successful application security program is made up of the following pillars:

Policies and Standards

• Policies connect the business need to the security requirements on the engineering team.
• Standards (e.g. architecture, coding, SDLC, and enabling technology) translate the policies into actionable prescriptive guidance for the team.

Education

• Education is tied directly to the policies and standards so it is hyper focused focused on enablement.
• Give the team the knowledge they need to achieve these goals and the motivation to want to.

Assessments and measurement

• This includes all assessment activities including threat modeling, architecture review, code review, pen testing, threat intelligence, etc.
• Use these measurements to determine if policies and standards need to be updated, then educate the team on these changes, and continue the loop to assess.

Put together, these pillars create a virtuous cycle of continuous improvement.

The following strategy translates these general principles into an actionable game-plan for a cloud-based SaaS application.

Understand applications that are deployed

• Make it easy to see all the component parts. Integrate security into the developer’s workflow. Automate as much as possible.

Understand application deployment methods

• Continuous Visibility. Don’t rely on surveys, spreadsheets, dashboards. Automate risk ranking for services based on dependencies, Internet exposure, assets involved. Focus effort on highest risks services.

Set policies and standards

• Compartmentalization.
  • Reduce attack surface. Reduce the need to move sensitive data around (e.g. Token Vault).
• Sanitize and Validate all Input
  • Data feeds, files, events, cookies, user input, all data storage, command line, environment vars, system properties.
  • Check for format, range, size, type.
  • Use allowlist validation whenever possible, fallback to denylist if necessary, but be careful.
• Never store secrets in code or config
  • Credentials, tokens, keys, etc.
  • Use tools to scan, policies to enforce, and figure out another location/vault for secret storage.
  • Use a vault service like AWS KMS, or Hashicorp Vault.
• Test for vulns in 3rd party and open source code
  • Scan for dependencies with known vulnerabilities.
  • Keep dependencies up to date.
• Enforce secure authentication
  • Define a secure password complexity requirement to meet business needs.
  • Store passwords using best practices (scrypt or Argon2 with the ability to upgrade)
  • Re-authenticate before especially sensitive operations (reduce CSRF).
  • TLS Client Authentication.
• Enforce least privilege
  • Specify least amount of authorization each role needs.
  • Create unit tests to attempt higher-privileged actions with lower-privileged roles.
• Protect sensitive data
  • Categorize your data and understand assets needing protection.
  • Determine where data is being used.
  • Determine where data is exposed (event logs, etc).
  • Encrypt sensitive data at rest (hashing passwords).
  • Be careful with data in memory (e.g. don’t use immutable data types in java).
  • Encrypt all data in transit.
  • Secure session data: Use sessionID and store session info on server; Encrypt cookies, use HttpOnly flag to deny script access, use Secure flag to ensure cookies are sent over HTTPS only, and SameSite to only allow access to your domain, and set expiration.
  • Protect against OWASP Top 10. Input validation, HTML encoding, parameterize queries.
  • Secure deployment/config standards and templates.
• Identify Key Vulnerabilities
  • For each vulnerability that is important to your platform, create development standards and mitigation plans.

Build Security Engineering into the SDLC

• Define Security Objectives as part of requirements and design
• Threat Modeling
• Architecture and Design Review for Security
• Code Review for Security
• Penetration Testing, both internal and 3rd party
• Security as part of Unit Testing and Integration Testing
• Deployment and Configuration Review

Employ Continuous Assessments

• Run SAST.
• Run inline scans in CI/CD pipeline, but keep them short.
• Run infrastructure and DAST scans after every deployment.
• Use a Cloud Security Posture Manager (CSPM) to find misconfigurations, detect overly liberal account permissions, monitor cloud environment for policy violations, and gain the ability to remedy some misconfigurations automatically.

Train the Team on Security

• Security policies
• Security standards and best practices for architecture and code
• Lunch and Learns to discuss vulnerabilities, exploits, mitigations, breaches
• Code level mitigation instruction
• Hands-on style training to create emotional connection to vulnerability impact

AWS Infrastructure Security

The following steps translates the pillars into an actionable game-plan for an AWS infrastructure. (Adapted from: AWS Security Maturity Roadmap - Summit Route )

1. Inventory

• Identify all accounts.
• Integrate all AWS accounts into AWS Organizations.
  • This helps consolidate billing, create new accounts, and use Service Control Policies .(SCPs)
• Have an AWS account for security
  • Use for log collection.
  • Result is at least three accounts: Business, Security, and one for the AWS Organization.

2. Have Backups

• Create regular, offline, protected backups so you don’t repeat the failure of the Code Spaces company. They folded after an attacker deleted all their data and backups.
• Backups should go to separate AWS account in a different region - or off of AWS entirely.
• Use AWS Backup and S3 Replication Policies.

3. Visibility and Initial Remediation

• Turn on CloudTrail, GuardDuty, and Access Analyzer to send logs to Security Account.
  • Can be done via Organization root to apply to all accounts.
• Create and IAM role on each account that allows security account View access.
• Run a one-time scanning tool for tactical remediations.
  • CloudMapper, Prowler, or ScoutSuite.
  • Look for: Public buckets with sensitive contents, public AWS managed ElasticSearch servers, EC2s running publicly accessible services that should be private (e.g. ElasticSearch, databases, etc).
• Turn on S3 Block Public Access.
  • Disables buckets from being made public.
• Develop an account initialization script and new account process.
  • Ensure a secure baseline for new accounts.

4. Detection

• Detect issues from logs and events.
  • Integrate into a SIEM for monitoring and alerting.
  • Ensure you can: receive a notification from a GuardDuty alert from any account in any region, alert on AccessDenied errors, search on all actions taken by a principle in a time period.
• Perform regular scanning and assessment.
  • To catch what your logs and alerts cannot.
• Document your security guidelines.
  • To ensure teams know what they will be flagged for.

5. Secure IAM Access

• Use SSO for access.
  • Use SSO for all human users. Allows central management and ability to roll credentials when compromised.
  • Enforce strong passwords and MFA with your SSO provider.
• Remove all IAM users.
  • IAM User Keys never expire and the regularly end up in GitHub or other places where they can be discovered. Use IAM roles instead.
• Remove unused IAM roles.
  • Audit for those not used for a period of time.
• Reduce privileges of services roles to necessary services.
  • Use Access Advisor to determine minimum privileges.
• Implement pre-commit hooks for secret detection.
  • Check for secrets that are being committed to source code repos.
  • One solution is the detect-secrets project.

6. Reduce attack surface and mitigate compromises

• Apply SCPs.
  • Restrict regions, deny root user access, and protect important roles from being deleted (e.g. security role).
  • See: https://summitroute.com/blog/2020/03/25/aws_scp_best_practices/
• Have no publicly facing EC2s or S3 buckets.
  • Use ELB or CloudFront in front of them.
  • Allows use of AWS Shield for DDoS protection, and AWS WAF.
• Enforce IMDSv2 on all EC2s.
  • This metadata service allows EC2s to get credential information for their IAM roles. V1 could be vulnerable to SSRF attacks. V2 provides protection against these attacks through use of a secret token and is preferable.
  • https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ .

7. Reproducibility and ownership

• Use infrastructure as code (IaC).
  • Changes should only be allowed through IaC such as Terraform or CloudFormation.
  • Require code review on all changes that impact infrastructure.
• Control AMI and package sourcing.
  • Document guidelines on what Amazon Machine Images are allowed in your environment (whitelist).
  • Document what instance types and OSs are allowed.
  • Or you could build all your own AMIs and not allow use of public AMIs.
• Apply tagging strategy.
  • Ensure all resources are tagged with owners.

8. Enhance detection

• Deploy honey tokens.
  • Create fake access keys that make it easier to detect attacker.
  • https://summitroute.com/blog/2018/06/22/guidance_on_deploying_honey_tokens/
• Implement realtime monitoring.
  • CloudTrail logs take up to 15 minutes to appear in S3, so use CloudWatch Events for real-time monitoring.
  • Set up a rule in every account and region, then aggregate the events.

9. Auto remediation and privilege refinement

• Implement automated remediation.
  • This can include removing unused IAM roles, changing security groups that are too open, terminating EC2s in a test environment every evening, etc.
• Refine IAM policies.
  • Take the time to review and refine IAM policies to further restrict them.

10. Secure Network Communication

• Move all non-public resources into private subnets.
  • Relay outbound traffic through proxies.
• Restrict egress network traffic.
  • Use AWS PrivateLink to restrict access to resource to only come from certain VPCs and to restrict calls out to the Internet.

11. Incident preparation

• Limit the blast radius.
  • Break services into pieces so that if one is compromised, the impact will be lessened.
• Practice responding.
  • How long does it take to identify, understand, and react.