Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Catching Commits to Secure Infrastructure as Code

Catching Commits to Secure Infrastructure as Code

Originally presented at GoTo Chicago 2023.

Rosemary Wang

May 23, 2023
Tweet

More Decks by Rosemary Wang

Other Decks in Technology

Transcript

  1. 1

  2. OWASP Secure Coding Practices • Input Validation • Output Encoding

    • Authentication and Password Management • Session Management • Access Control • Cryptographic Practices • Error Handling and Logging • Data Protection • Communication Security • System Configuration • Database Security • File Management • Memory Management • General Coding Practices https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ 3
  3. Security Testing Static Analysis • “Shift-left” security testing • Policy

    as code • Unit / contract testing for security Dynamic Analysis • Vulnerability scanning • Continuous validation • Security monitoring 7
  4. Infrastructure as Code Infrastructure Environment FIX Allow traffic from database

    to DR site. RECONCILE Add rule to allow traffic from database to DR site. A region has an outage. 8
  5. Static Analysis Dynamic Analysis For you to fix quickly and

    maintain security requirements For someone else to know what security requirements exist 9
  6. 11

  7. Input Validation Verify… • Expected types • Expected values •

    Proper character sets • Potentially insecure values Static analysis 14
  8. Input Validation Examples: • Password should have at least 1

    symbol and 1 uppercase character. • Region should be in United States. • Private CA certificate key should be marked as sensitive. • Names should include standard environment. 15
  9. Input Validation Variable Validation Better for… • Team • Provider

    • Modules Unit Test Better for… • Multiple providers • Organizational policy • Dependencies 16
  10. variable "region" { type = string description = "AWS Region"

    validation { condition = can(regex("^us-", var.region)) error_message = "AWS Region must be in United States" } } Variable Validation 17
  11. resource "random_string" "boundary" { ## omitted lifecycle { precondition {

    condition = random_string.boundary.length > 3 error_message = "HCP Boundary requires username to be at least 3 characters in length" } } } Variable Validation, Inline with PreCondition 18
  12. deny[msg] { r := tfplan.variables r.aws_secret_access_key msg := "do not

    define AWS secret access key as part of variables, use AWS_SECRET_ACCESS_KEY environment variable instead" } Unit Test with OPA 19
  13. Data Protection • Implement access controls to state ◦ Data

    ◦ State • Encrypt in transit and at rest. • Sanitize sensitive values in logs or outputs • Ensure least privilege access to providers Static analysis Dynamic analysis 21
  14. Data Protection Examples: • Database should be encrypted. • Password

    should not be printed in output. • Virtual machine resource should have attached IAM role. • Infrastructure state should be limited to owners of workspace. 22
  15. Data Protection Static Analysis Better for… • Enforcement of secure

    practices • Testing valid dependencies Dynamic Analysis Better for… • Least-privilege API access • Continuous enforcement • Auditing data access 23
  16. deny[msg] { r := resource_changes[_] r.type == "aws_db_instance" r.change.after.storage_encrypted ==

    "" msg := sprintf("%v should have encrypted storage", [r.address]) } Static Analysis of Attributes with OPA 24
  17. deny[msg] { outputs := planned_values.outputs plaintext_password_outputs := [key | outputs[key]

    contains(key, "password") not outputs[key].sensitive ] count(plaintext_password_outputs) != 0 msg := sprintf("%v should be marked as sensitive outputs", [plaintext_password_outputs]) } Static Analysis of Practices with OPA25
  18. resource "aws_db_instance" "products" { ## omitted storage_encrypted = true lifecycle

    { postcondition { condition = self.storage_encrypted error_message = "encrypt AWS RDS database storage" } } } Continuous Enforcement with PostCondition 26
  19. System Configuration • Check versions or images • Ensure least

    privilege network access • Separate development and production • Analyze vulnerabilities and access • Assess drift • Remove idle / unused resources Need dynamic analysis 28
  20. System Configuration Examples: • Separate state for development and production.

    • Verify network policies and secure versions. • Tags should include environment. • Image should include secure base. • Scan running infrastructure for new vulnerabilities. 29
  21. System Configuration Static Analysis Better for… • Enforcement of secure

    practices • Complex logic for validation • Testing valid dependencies Dynamic Analysis Better for… • Network auditing • Continuous validation • Drift detection 30
  22. deny[msg] { ## omitted logic to parse VPC private_subnets :=

    {r.values.id | r := vpc_modules[_].resources[_] r.type == "aws_subnet" not r.values.map_public_ip_on_launch } public_subnets := cluster_subnet_ids - private_subnets count(public_subnets) != 0 msg := sprintf("EKS cluster %v should be in private subnets (%v are public subnets)", [cluster_id, public_subnets]) } More Complex Static Analysis with OPA 31
  23. 32

  24. 33

  25. How do I share tests? • Store tests in central

    location. • Tag / name / number tests for relevance. • Document secure configurations in tests. 35
  26. How to catch commits? Plan Unit Test Apply Integration Test

    Static Analysis Dynamic Analysis Plan Unit Test Apply Integration Test Static Analysis Staging Production 36
  27. Do I write them all myself? Use pre-written test suites

    or industry benchmarks. Infrastructure modules Production configuration 1 Create custom policy tests. Divide by… • Enforcement level • Business unit • Resource • Type 2 37
  28. 38

  29. What is important? • Prefer secure defaults over tests. •

    Choose a severity threshold. ◦ Identify mandatory rules. ◦ Use advisory as last resort. ◦ Try to enforce development environments. • Evaluate and make exceptions. 39
  30. How do you write secure IaC? • Capture practices into

    tests • Share tests • Catch commits using a pipeline • Write what you must • Choose what is important 41
  31. 45