DevSecOps - Automation and Continuous Security
Reading Time: 7 Minutes
by | July 24, 2018
What is DevSecOps?
DevSecOps is a practice of implementing security at every step in the DevOps Lifecycle. According to the traditional method where penetration tests and vulnerability assessment was done after the build, DevSecOps is based on the concept of integrating security assessments and vulnerability tests at each point of the CI/CD pipeline. DevSecOps implements security within the DevOps workflow.
DevSecOps is the answer to integrating various enterprise challenges into a coherent and effective approach to software delivery. A central tenet of DevSecOps is that security is an integral and essential element of DevOps – the method by which enterprises innovate at speed and scale.
The DevSecOps Manifesto
Leaning in over Always Saying “No”
Data & Security Science over Fear, Uncertainty, and Doubt
Open Contribution & Collaboration over Security-Only Requirements
Relying on empowered development teams more than security specialists
Consumable Security Services with APIs over Mandated Security Controls & Paperwork
Business Driven Security Scores over Rubber Stamp Security
24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident
Shared Threat Intelligence over Keeping Info to Ourselves
Compliance Operations over Clipboards & Checklists
What's driving the DevSecOps Movement
As software continues to grow at a rapid pace in IT DevSecOps becomes the foundation of competitiveness in the modern marketplace. Every business must become an agile and innovative software delivery machine in order to survive.
Which leads all of us to the enterprise IT paradox: go faster and innovate. But always stay secure.
Modern Applications are mostly “assembled.” Developers often use and download vulnerable open source components and applications frameworks.
In the DevOps world organizations are building applications at such a faster rate that they have forgotten the Security aspect.
Cloud platforms and continuous delivery life cycles often circumvent traditional security process and checks.
Security Collaboration – it’s everyone's responsibility. Organizations must try to bring individuals of all abilities to a high level of proficiency in a short period of time.
How DevOps Security Practices differ from other Security Approaches?
DevOps security or DevSecOps is a holistic mindset approach rather followed by community-driven effort than a one-man size fits all approach in the standard security world.
DevSecOps focuses on building secure software by implementing security standards at each and every part of the DevOps pipeline from developing to the source code till deploying the application. Whereas standard security practices start after the deploying of the application.
Approach of an organization with DevSecOps is to make each and every person responsible for the software delivery to implement their own security practices. Each one is responsible for security measures.
DevOps Security focuses on the point of delivering secure software using continuous delivery architectures. It is community driven effort and strategy driven by learning and experiments.
Standard Security measures follow the practice of “ just a means of adding security into continuous delivery,“ whereas DevSecOps follow the practice of “ building security and compliance into the software.
Five Rules For A DevSecOps Practitioner
- Security starts with engineering, try to understand the fact developers are engineers whereas hackers are reverse engineers.
- Encourage good security hygiene in engineering.
- Continuous assessments and compliance checks .
- Real-time threat alerting across apps and services.
- Enable developers to drive iterative security changes.
Improving Your Security DNA
- Code Analysis
- Change Management
- Compliance Monitoring
- Threat Investigation
- Vulnerability Management
- Security Training
Code Analysis
- Secure the CI/CD pipeline.
- Release in small and frequent batches.
- Embed code analysis into Q/A.
- Use tools to detect that private keys or API s information is not pushed on the Version Control.
Change Management
- Empower teams to improve security practices and make changes.
- Quick review and approval process.
- Changes must leave audit trial.
- Meet compliance requirements.
Compliance Monitoring
- Enforce operational and security hygiene.
- Establish strict password policies.
- Audit everything from code pushes, pipelines, compliances.
- Monitor systems for bad behavior.
Threat Investigations
- Monitor app and services to detect and alert on threats.
- Instrument services to identify comprises.
- Built-in real-time alerting and controls.
- Develop ansible playbooks and response scenarios for IT and Security.
Vulnerability Checks
- Conduct vulnerability scans and practices.
- Conduct periodic scans of product builds.
- Code reviews and penetration test.
- Establish remediation SLA ’s.
Security Training
- Transform the team into security ninjas.
- Participate in industry conferences.
- Invest in security certifications.
- Educate employees on security risks.
- Prepare teams for incident responding.
Integrating Security into Continuous Delivery workflows
Let's see how and where to add security checks into a Continuous Delivery workflow.
Pre-commit
Lightweight, iterative threat modeling and risk assessments.
Static analysis (SAST) checking in the engineer’s IDE.
Peer code reviews (for defensive coding and security vulnerabilities).
Commit stage (Continuous Integration)
Compile and build checks, ensuring that these steps are clean and that there are no errors or warnings.
Try to identifying risk in third-party components.
Generating Alerts on high-risk code.
Automation of unit testing of security functions, with full coverage of code analysis.
Acceptance stage
Secure, automated configuration management and provisioning using tools such as Ansible, Chef.
Targeted dynamic scanning (DAST).
Automated functional and integration testing of security features.
Deep static analysis scanning.
Manual penetration testing using web exploitation frameworks such as Metasploit.
Production deployment and post-deployment
Automated deployment and release orchestration.
Automated runtime asserts and compliance checks.
Production monitoring/feedback.
Runtime defense.
Bug bounties.
Learning from failure
Depending on the risk and uncertainty profile of your organization and infrastructure, you shall need to implement these practices and controls.
Architecting Container Infrastructure for Security and Compliance
As organizations are benefiting from agility, scalability and they are even migrating to containers and microservices, Security and compliance parameters are often overlooked. Some of the most critical security listings for container infrastructure.
- Kernel Security
- Denial Of Service
- Image Security
- Credentials and Secrets
- Runtime Security
Kernel Security
When it comes to containers and microservices, all rely on a single kernel of the host machine. Most of the intrusions can be stopped if proper kernel security is implemented.
This is really efficient for multiple reasons you probably know already, but from the point of view of security it can be seen as a risk that needs to be mitigated
Docker Host and Kernel Security
If an attacker compromises your host system, then container isolation and security safeguards won’t make much of difference. Besides, containers run on top of host kernel by design.
Make sure your host and Docker engine configuration is secure. Wtry using the Docker bench audit tool to check configuration best practices.
Keep your base system reasonably updated, subscribe to security news feeds for the os and any software installed for 3rd party repositories, like the container orchestration platforms.
Using minimal, container-centric host systems like CoreOS, Redhat Atomic, RancherOS, etc.
You can use Mandatory Access Control to prevent undesired operations both on the host and on the containers at the kernel level using tools like Seccomp or Selinux.
Make sure you have the removed lethal kernel modules, packages such as xinetd, telnet can be lethal, privileges and access should be ensured accordingly.
Denial Of Service
Distributed denial of service DDOS attacks are some of the most pervasive and difficult attacks to prevent. These kind of attacks are using many distributed endpoints and systems in order to flood a web domain, application or service with an excess number of service requests or application calls.
Running penetration tests on software early in the development process is one way to thwart holes that enable L7 DdoS attacks.
Failed test requires a response. One such response is to automatically to build the software when the software fails the test. If development can't move forward without fixing the security holes, the security holes will be fixed.
Developers should not have to do a lot of digging to uncover these methods. Use resources such as Open Web Application Security Project ( OWASP ) clearly set these approaches apart and label each of them on their own.
Image Security
There a lot of images available on different repositories available on the internet doing all kinds of useful stuff, but if you are pulling images without any trust, authenticity or any type of vulnerability scanning, you are basically running an arbitrary software on your machine.
Certain parameters must be followed before using that docker image:-
- Where did the image come from?
- Do you trust the image creator, which kind of security policy they are using?
- How do you know nobody has been tampering with the image?
Best Practices to follow:-
- Do not run unverified software and/or from sources you don’t explicitly trust.
- Deploy a container-centric trust server using some of the Docker registry servers available in our Docker Security Tools list.
- Enforce mandatory signature verification for any image that is going to be pulled or running on your system.
Credentials and Secrets
Your software needs sensitive information to run such as user password hashes, server-side certificates, encryption key. The microservices deployed on containers are plenty and may constantly be created and destroyed.
You need an automatic and secure process to share this sensitive info.
Best Practices:
Do not use environment variables for secrets; this is a very common yet very insecure practice.
Do not embed any secrets in the container image. Like “The private key and the certificate were mistakenly left inside the container image.”
Deploy a Docker credentials management software if your deployments get complex enough, Do not attempt to create your own ‘secrets storage’ unless you know really really well what you are doing.
Docker runtime security monitoring
As we build Docker container images, we need to know exactly what goes into each layer of the container. We also must ensure that containers installed by third-party vendors do not download and run anything at runtime.