Stalled at the intersection of dev ops and security v2
•
0 j'aime•357 vues
The majority of enterprises are very concerned about the security of the software they are developing, but how can they secure their software without slowing down their velocity - or put another way - how can they move past being stalled at the intersection of DevOps and Security? With this in mind, we explore the qualities of a security scanning tool that is "plug-and-play" with a modern devOps shop.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à Stalled at the intersection of dev ops and security v2
Similaire à Stalled at the intersection of dev ops and security v2 (20)
Dernier
Dernier (20)
Stalled at the intersection of dev ops and security v2
- 1. Matthew Barker, Technical Director, Sonatype1 STALLED AT THE INTERSECTION OF DEVOPS AND SECURITY
- 3. WHAT WE REALLY NEED! 3
- 4. SOFTWARE DEVELOPMENT MOVES FASTER THAN SECURITY WHY ARE WE STALLED 4 Explosive Use of Components Agile and Devops Enterprise Scale Use of Complex Frameworks
- 5. 5 WE TAKE SECURITY SERIOUSLY!
- 6. WHY ARE WE STALLED 6 ARE WE SERIOUS ABOUT SECURITY? • Card Skimmers (9%) • Insider Misuse (8%) • Crimeware (4%) • DoS Attacks (1%) See the problem?
- 7. ARE WE SECURING OUR SOFTWARE SUPPLY CHAIN? 7
- 8. COST OF ASSESSING VULNERABILITIES LATE IN SLC 8
- 9. SOME RECENT APPLICATION ATTACKS 9
- 10. HOW DO WE MOVE TO THE DEVOPS- SECURITY ACCELERATED INTERSECTION? WHAT IS NEEDED 10 Fast and Continuous Accurate Integrates Into Modern Devops tools Scalable Policy Driven Manages Supply Chain Prioritizes Vulnerabilities
- 11. Component Selection DEVELOPMENT BUILD AND DEPLOY PRODUCTION COMPONENT SELECTION PUBLIC REPOSITORIES A CONTINUOUS APPROACH PRECISELY IDENTIFY COMPONENTS & RISKS REMEDIATE EARLY IN DEVEOPMENT AUTOMATE POLICY ACROSS THE SLC MANAGE RISK ACROSS ENTIRE PORTFOLIO CONTINUOUSLY MONITOR FOR NEW RISKS 11
- 12. A Modern Security Scanning Architecture Modern Component Data Service Command Line Scanner with return value Real time policy check Email Alerts Includes production monitoring Fast, up to date, and accurate API Policy Server with Stored Analysis
- 13. QUESTIONS ? Matthew Barker mbarker@sonatype.com 505-239-4008
Notes de l'éditeur
- Love the bus – that’s got to be the security requirements!
- Great flow, but not sure I want to live or work in the building with the blue roof!
- Libraries and Components – Explosive growth in the use of components has dramatically increased the size and complexity of applications, making both static and dynamic less effective. We recently partnered with HP Fortify for this very reason, what they discovered is that their scans can’t go deep enough to find many of the known vulnerbilities. At’s it’s core it’s “Software Supply Chain Management” which will be the topic of the second session Frameworks – Application frameworks have their own sophisticated security controls that are difficult to verify. Their sheer complexity makes security analysis harder. Agile and DevOps – Continuous integration and delivery require continuous security results, and traditional application security approaches take too long, are not accurate enough, and can’t scale. EnterpriseScale – It’s not uncommon for enterprises to have hundreds or thousands of applications. Clearly solutions have to scale easily, and that means no experts as possible bottlenecks. Or put another way, if a developer has to wait for “George from security” or “the FOSS Board” to approve a component to use – you DON’T have a scalable solution.
- This has become a buzz phrase for companies doing almost nothing about security.
- Results of OWASP survey – 2014 Quiz - where to we get information on OSS vulnerabilities? What does “copyleft” mean? What is OWASP #9 (related to component usage)?
- Use of a vulnerable component is a DEFECT! We need to change our culture and start viewing securities issues the same as quality issues – they are both accumulated technical debt. What’s not even here is the cost of a breach, average cost around $3M!
- Anything with software that is “connected” is vulnerable to attack – and with the proliferation of wireless technologies such as WIFI and bluetooth – “The Internet of Things ”- means that we are more vulnerable then ever – think medical devices, automobiles, airplanes, you name it (REFRIGERATORS)? And if we can’t do a good job of securing our credit card data, how can we expect to do a good job with devices are lives are depending on? The International Data Corporation predicts that over 200 million devices will be connected to the internet by the year 2020, this could prove to be a significant problem, particularly since they are not routinely monitored for malicious activity. I need to ask again, do we really take security seriously?
- Fast and Continuous – As software development continues to accelerate, security tools have to be able to provide real time results continuously during development, test, staging, and even production. Otherwise they will irritate development and won’t get used. Continuous tools also save money by getting developers feedback instantly and early in the lifecycle. If your application security tools aren’t continuous, it’s time to change. Scalable – Application portfolios aren’t getting any smaller, yet traditional tools struggle just to cover a small percentage of your applications. The key to scalability is that your security tools have to be easy for anyone to use, even if they don’t know anything about security. If they require experts to install, configure, run, or handle the results they simply won’t scale. If your appsec tools can’t operate at enterprise scale, it’s time to change. Manages Software Supply Chain – You are only as strong as your weakest link - Yu-Chen will go into this and illustrate just how important this in the second session. Accurate – Nothing will kill an application security program faster than false alarms. These non-findings take just as long as real vulnerabilities to investigate, so they are expensive and frustrating with zero benefit. If you don’t feel like your tools are analyzing your applications with good vulnerability coverage and excellent accuracy, it’s time to change. Integrates into modern Devops tools – For accelerated security scanning, your security tools must fit into your existing Devops tools across the SDLC – tools such as Eclipse, Jenkins, Sonar, etc. If your security tools don’t integrate into your existing devops toolset, who is going to use them. Policy Driven - A policy driven approach is the only way to automate the security checks into your work flow and share valuable direction from your domain area experts. If you depend on raw data such as a CVE or OSS license, how would you expect developers with little knowledge about security or licensing to do the right thing? CONCLUSION: Software component driven development is a fast-moving unstoppable juggernaut. So application security has to adapt to changes in the way we build software. And that means constantly evaluating whether your toolset is compatible with the way you build software.
- Early and Ongoing Vulnerability Identification Provide tools throughout the development lifecycle to identify potential issues as early as possible to build a secure software supply pipeline – keep poor quality components off the shelf and continiously monitor and test components being used even after release of an application. Create Policies and Automatic Enforcement across the entire SLC Pay particular attention to your software supply chain Manage Risk Across Entire Portfolio – If you have a high risk component in many of your app’s, would it not make sense to remediate that first? You rools need to help you assess risk across applications and not be silo’ed! Who has time to continuously Monitor? The answer is - no one without automation.
- PS – Policy Server is at the heart of the architecture, provides clear policies for all other processes, and allows for assessment of risk across an entire Enterprise portfolio. API enables integration into other tools and custom reporting IDE – needs to give policy guidance to developers with a clear remediation path – catch problems before a single line of code is written CLS – return value is important so you can fail work flow steps such as code check in based on policy failures CI – important to be able to fail a build if developer checks in code that brings in bad components – similar to stopping the assembly line when a defect is found – Trust but Verify approach TT – ticket tracking important to be able to track remediation of found problems and enable an efficient work flow EA – Email alerts allow for visibility into the entire process and production monitoring of finished applications