19. Summary
Identify Threats during the design phase
Develop Safe code
Security scan the builds
Security scan the runtimes
Validate external components
Contain your risks
Test in production
Monitor continuously
DynamiNET
Notas del editor
Michael Howard put it at the 2006 OWASP AppSec Conference in Seattle, “Tools do not make software secure! They help scale the process and help enforce policy.”
We are beginning to understand what DevOps is. It is based on Automation
Putting the ’Sec’ into DevSecOps is work in progress with different levels of maturity
Automating security testing tasks is part of the solution (but not the complete solution)
But how does security testing fit into this DevOps model?
In this presentation, I will highlight some of the techniques and supporting tools available to you during the DevSecOps lifecycle
Let’s start from the Planning stage of the cycle
This is where a new feature, or a change to an existing feature, is designed
During the planning phase, the main Sec task is Threat Modelling
Threat modelling was demonstrated by Chris Rutter in October’s session (so I won’t go over it again here)
Identifying threats during the design phase is the cheapest and most effective way to mitigate risks before a line of code is written. Using STRIDE analysis allows you to identify potential vulnerabilities at the earliest phase of the cycle.
This task is probably best carried out manually, however, there are a few tools on the market that allow you to threat model
What makes a good threat modelling tool?
Has an extensible library of threats
Builds a threat model of the system
Provides mitigation steps for identified threats
Reporting (for regulatory purposes)
This type of tooling has been around for a while, but the manual process is still the most effective way of threat modelling
The next phase of the cycle is the process of actually writing code.
During development, there are a number of methodologies to support security
Unit tests.
Write unit tests that mimic the actions of an attacker and make them fail
Use Threat actor driven tests to write unit tests that identify threat surfaces
Write functional tests that manage security – username and password rules
Peer Reviews
Developers working together is an effective way to identify bad practices in writing code
Requires knowledge of security related best practices
Tooling
SAST – Static Analysis of application code. There are two types of tools:
Those that analyse the raw source code
Those that analyse the binaries
Look for tools that:
Educate developers
Provide incremental feedback (it’s quicker running incremental scans that full scans)
Integrate into the IDE AND pipeline (providing developers with instant feedback when coding AND during check-ins)
Support the languages and frameworks used by your development teams (not all tools and languages are supported, such as more recent versions)
Provide options to fix root cause issues
The tool should be able to identify the root issue rather than peripheral issues.
Fixing the root issue will make your product more secure than fixing lots of dependent issues.
Covers industry known standards OWASP, PCI, HIPPA etc.
So how does SAST work?
The tools examine the code to identify vulnerabilities such as storing passwords in the clear, non-paramaterised SQL commands or holding passwords in the clear within non-secure memory
What to look out for
Must integrate the tool within the development lifecycle to be effective (fixing issues as they are found)
Consider on premise versus cloud based solutions based on your requirements
Some companies offer either options
Licensing
Product based
Code based
Developer based
False Positives is a problem with all SAST tools so it is a good idea to work with a company that can provide some consultancy to minimise false postives
The Build phase is when components are integrated for the first time within the lifecycle
The best options during this phase is DAST (Dynamic Application Security Testing)
How does DAST work?
Identifies vulnerabilities in an application in its RUNNING state
Normally managed as a SaaS and supported by experts performing manual verification
A type of Black Box testing (there is no knowledge of the underlying code base)
Testers usually have a number of tools to support them which are used to identify potential issues
Manual verification of the issues discovered reduces the number of false positives discovered
The advantage of outsourcing this process is the availability of security experts who can analyse your code
It can be run in-house with internal testing teams
This is an expensive option and only scales to a certain point
Very few false positives
The testing phase within the lifecycle normally involves running a plethora of functional and non-functional tests
During this phase, the best options is IAST (Interactive Application Security Testing)
What is IAST?
It is a runtime analysis tool that sits inside a JVM
It identifies potential issues as the data flows through the application
There are two types of IAST:
Active
Induced
DAST is a precursor
Targeted testing
Passive
Self-Induced
Monitors applications passively during runtime (such as functional testing)
Good vulnerability coverage
Key advantages:
reduces false positives
Instant feedback
No configuration / experts required
However, this is the least mature of the ’AST’ tools with only a small number of vendors offering this service
Language coverage is not great
The release phase is when your software may become more dependent on external or third party components
These include web hosts such as Apache
Free and Open Source Software (FOSS)
Can often expose your applications to vulnerabilties
Need to compare OSS with known vulnerabilities with CVE (Common Vulnerability and Exposures)
Ensure your open source software is safe
Hardening
Ensure the your products do not contain any malicious content due from external sources
Patching
Ensure all items are up-to-date with patching
The Deployment phase is where your application is pushed into production
Deploying code to production is another opportunity to inject malicious content into your applications
Containers provide a way to deploy products and microservices onto physical or virtual machines
More granular control over what is deployed
Many Containers are accompanied by tools to validate hardening of the container
This is a very immature market
Many products out there
When the application is live there are multiple approaches to testing to catch security vulnerabilities that have made it to production
Bug Bounty Hunters - paid white hat hackers who identify vulnerabilities using a plethora of hacking techniques
Penetration testing (either external or internal) – Black box testing to identify security vulnerabilities and satisfy audits
Continuous Security Validation – validates against new threats in real time
System Information Event Monitoring tools (SEIM)
Monitor applications for real-time attacks (uses Correlation engine):
Data Aggregation – pulling data from logs such as Splunk
Alerting – identify immediate issues (DDoS)
Dashboards – to show the current health of the network
Compliance – ensure products follow governance and auditing processes
Forensic analysis – identify potential attacks that would otherwise go undetected
These are complex technologies requiring significant integration with existing enterprise security controls
Putting the Sec into DevOps is a maturing part of continuous delivery
As the speed of delivery of new products and features increases, so does the level of risk of introducing vulnerabilities into your products
There are emerging technologies such as Containers that are gaining momentum but security is struggling to keep up
However, bringing security good practices into the early parts of the lifecycle can mitigate many risks
Yet, new technologies bring their own risks
Stay patched
Use Open Source Scanning tools
Develop safe code
Identify threats during the design phases