Recommended
More Related Content
More from Michael Man
More from Michael Man (14)
Recently uploaded
Recently uploaded (20)
DevSecOps: Test Automation
- 1. Putting the Sec into By Glenn Wilson
- 3. DynamiNET
- 5. DynamiNET
- 6. = Source Code Analysis DynamiNET
- 7. DynamiNET
- 9. DynamiNET
- 11. DynamiNET
- 13. DynamiNET
- 15. DynamiNET
- 16. = Production Testingoperate Accredited Pen Testing DynamiNET
- 17. DynamiNET
- 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
Editor's Notes
- 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