Skip to content

Instantly share code, notes, and snippets.

@apolloclark

apolloclark/devsecops_maturity_model.md

Last active January 22, 2024 05:08
Show Gist options
  • Star 24 You must be signed in to star a gist
  • Fork 10 You must be signed in to fork a gist
  • Save apolloclark/d1a87d11ef990a2dad03eefa6c51f647 to your computer and use it in GitHub Desktop.
Save apolloclark/d1a87d11ef990a2dad03eefa6c51f647 to your computer and use it in GitHub Desktop.
Download ZIP
DevSecOps Maturity Model
Raw
devsecops_maturity_model.md

DevSecOps Maturity Model

DevSecOps has finally become popular within the wider IT industry in 2019. I started as a web developer in 2001, learned about testing automation, system deployment automation, and "infrastructure as code" in 2012, when DevOps was becoming a popular term. DevOps became common after the release of The Phoenix Project in Jan 2013. It has taken 7+ years for security to become integrated within the DevOps methodology. The following is a list of concepts I go through with project owners, project managers, operations, developers, and security teams, to help establish how mature their DevOps and security automation is, and to help them increase that maturity over time. This model is based on experience consulting with a variety of US Financial, Healthcare, and Department of Defense, organizations, and combines:

Criticality

PII and public facing = high
PII and internal facing = medium
no PII and public facing = medium
no PII and internal facing = low

What is a production system?

  • public facing
  • uses PII data
  • costs more than $5,000 / month

Self-service responses

  1. Use, a shared platform
  2. Ask, for platform support
  3. Buy, 3rd Party Hosted
  4. Train, your engineers
  5. Hire, new engineers

Maturity Levels

  1. None
  2. Ad-hoc, manually
  3. Quarterly, manually
  4. Monthly, semi-automated
  5. Weekly, fully-automated

Level 5 includes:

  • tests
  • reports
  • alerts
  • dashboards

Maturity Aspects

This list is a combination of multiple other security and devops maturity models. It is ordered in a way which enables each aspect to build upon the previous aspects. The specific ordering can be modified slightly, but will lead to missing coverage.

Summary

  1. Inventory Management
  2. Financial Cost Management
  3. Access Management
  4. CI/CD Build Automation
  5. Install and Patch Management
  6. Configuration Management
  7. Secrets Management
  8. Deploy Management
  9. Backup and Restore
  10. Resiliency
  11. Metrics and Logging
  12. Alerts
  13. Response Playbooks
  14. Automated Remediation
  15. Threat Modeling

1. Inventory Management

Threats

  • unaccounted resources will be exploited without notice
  • unaccounted resources will not be patched
  • unaccounted resources will be used at maximum cost

Solutions

Advice

The security teams should work with the Financial, Ops, and Dev teams (in that order) to establish how many cloud provider accounts are being paid for, who owns them, and who has access

2. Financial Cost Management

Threats

  • unncessary cost over-runs
  • unaccounted resources can be exploited financially, ex: bitcoin mining

Solutions

Advice

The security teams should work with the Finance, Ops, and Dev teams to establish cloud account and resource ownership. A good rule of thumb is: "It you are paying for it, you own it, and you need to maintain it."

3. Access Management

Threats

  • insecure default passwords, or old passwords , or shared passwords, or reused passwords, will be exploited

Solutions

Advice

The security teams should work with the Ops and Dev teams to establish who has access to cloud accounts and resources. Any form of access should be known and managed in a centralized system. Within AWS for example, this would mean every engineer has their own dedicated IAM User account, and is allowed to use IAM STS Assume Role to manage resources in multiple AWS accounts. Passwords should be complex and long, and rotated regularly. Engineers should be given password managers.

4. CI/CD Build Automation

Threats

  • old services without updates will be exploited
  • mitigation will be time consuming

Solutions

Advice

I have found Jenkins to be the most robust build platform. It has the highest number of plugins and integrations. For my open source projects, I use TravisCI for simple scoped builds to test Ansible roles, building Docker images, and building VM images. Avoid calling the command line directly at all costs. Also avoid using shell scripts. Both of them are difficult to maintain, debug, and are unreliable.

5. Install and Patch Management

Threats

  • insecure components will be attacked
  • mitigation will be time consuming

Solutions

Advice

I've used Grandle, Grunt, Packer, and Ansible Molecule. I've found Gradle to be the most mature of the three, though I prefer the simple Javascript syntax of Grunt. I have seen very few competitors to Hashicorp's Packer. I use Ansible roles, and therefor use Molecule.

6. Configuration Management

Threats

  • having a wide range of the same service, with different versions, is tedious and time consuming to manage, ex: multiple versions of Java
  • builds should be consistent and repeatable
  • insecure defaults, and insecure configurations, will be attacked
  • auditing will be time consuming to manually track configurations
  • mitigation will be time consuming

Solutions

Advice

Focus on what is already deployed and collect how it is configured, using Augeas. Then, setup alerts on when a configuration has changed, using osquery w/ the Augeaus plugin. The DevSec Hardening Framework is a collection of Chef, Puppet, and Ansible scripts, to help ensure compliance such as the CIS Benchmark. Use Severspec / Goss (config), Infrataster (e2e), and Gauntlt (e2e security) to perform BDD testing. Use one of the Docker image scanners. Use the AWS security scanners.

7. Secrets Management

Threats

  • insecure default passwords, or old passwords, or shared passwords, or reused passwords, will be exploited
  • insecure passwords will be time consuming to update and rotate

Solutions

Advice

I have a gist for doing this within Jenkins.

8. Deploy Management

Threats

  • insecure cloud service configurations will be attacked
  • cloud service auditing will be time consuming to manually track configurations
  • cloud service mitigation will be time consuming for all untracked configurations

Solutions

Advice

I've worked with over a dozen development teams, all using AWS. The AWS Cloudformation tool is not usable for medium to large scale projects. There are multiple resource limits, which cannot be increased by talking with an AWS Account Manager. The Cloudformation template format is tedious to maintain, confusing to debug, and crashes in unexpected ways. However I have had very few issues using Hashicorp Terraform, which also allows for multi-cloud support.

9. Backup and Restore

Threats

  • data will be exfilled
  • data may be deleted irrecoverably

Solutions

Advice

This is more left to the Ops team, with some cross-training for Devs, and monthly checkins from the Security teams. Customers and internal clients will ask about "backup and restore strategy" during the start of a project, and before a go-live.

10. Resiliency

Threats

  • Unexpected downtime
  • DDoS attacks

Solutions

Advice

This is more left to the Ops team, with some cross-training for Devs, and monthly checkins from the Security teams. Customers and internal clients will ask about "backup and restore strategy" during the start of a project, and before a go-live.

11. Metrics and Logging

Threats

  • unmonitored assets will be attacked, without alerts
  • unmonitored assets will be difficult and time consuming to remediate

Solutions

Metrics

Logging

Behavior

Advice

I've used almost every product in this list. Splunk is the most powerful, but also the most expensive. Surprisingly fluentd is used natively within Microsoft Azure, Google GCP, and by Kubernetes, despite the parent company Treasure Data no longer offering enterprise support. I'm a huge fan of the Elastic ELK stack. I've been very impressed by Carbon Black's CB Defense.

12. Alerts

Threats

  • unmonitored assets will be attacked, without alerts
  • unmonitored assets will be difficult and time consuming to remediate

Solutions

Advice

Resist the urge to turn on alerts for everything. Only critical and high findings should have automated alerts. As those alerts become less frequent, and the response more automated, then you should slowly include medium severity finding alerts.

13. Response Playbooks

Threats

  • threat responses will be ad-hoc, inconsistent, and slow

Solutions

  • create Response Playbooks

Advice

In my experience, between multiple projects and companies, the playbook threats will be the same, ex: "Unauthorized Access from a Foriegn IP Address." The response will be very different, and will be a reflection of the companies social structure.

14. Automated Remediation

Threats

  • vulnerable and exploited assets will be time consuming to remediate

Solutions

Advice

This is a very new space, with lots of marketing hype and confusing, even from experienced DevOps + Security practicioners. My general advice is that the more homogenous and generic an environment, the easier automation will be. If there are custom Docker images, custom compiled languages, custom plugins, etc. then these automation tools will not know how to interact and manage them.

15. Threat Modeling

Threats

  • lack of visibility into risk

Solutions

  • owners
  • support engineers
  • architecture diagrams
  • dataflow transitions
  • data classifications
  • malicious user stories

Advice

For your first pass, just go through the DevSecOps Maturity Model, and get a scoring of where a given team / project is in their maturity. Wherever they have scored below a 5 in the model, should be where they should focus. The intention should not be to reward teams which are more mature, but to put more focus on the most immature teams, track their progress, and reward growth. Going from a 70pts to 75pts is not as impressive as going from a 15pts to 25pts.

References

https://blog.sonatype.com/a-devsecops-maturity-model-in-7-words

https://tech.gsa.gov/guides/dev_sec_ops_guide/

https://2018.open-security-summit.org/outcomes/tracks/owasp-samm/working-sessions/devsecops-maturity-model/

https://www.owasp.org/index.php/OWASP_DevSecOps_Maturity_Model

https://cloud.google.com/free/docs/map-aws-google-cloud-platform

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment