Application Security at DevOps Speed and Portfolio Scale
•Download as PPTX, PDF•
1 like•1,319 views
Published on Nov 26, 2013 AppSec at DevOps Speed and Portfolio Scale - Jeff Williams Watch this talk on YouTube: https://www.youtube.com/watch?v=cIvOth0fxmI Software development is moving much faster than application security with new platforms, languages, frameworks, paradigms, and methodologies like Agile and Devops. Unfortunately, software assurance hasn't kept up with the times. For the most part, our security techniques were built to work with the way software was built in 2002. Here are some of the technologies and practices that today's best software assurance techniques *can't*handle: JavaScript, Ajax, inversion of control, aspect-oriented programming, frameworks, libraries, SOAP, REST, web services, XML, JSON, raw sockets, HTML5, Agile, DevOps, WebSocket, Cloud, and more. All of these rest pretty much at the core of modern software development. Although we're making progress in application security, the gains are much slower than the stunning advances in software development. After 10 years of getting further behind every day, software *assurance* is now largely incompatible with modern software *development*. It's not just security tools -- application security processes are largely incompatible as well. And the result is that security has very little influence on the software trajectory at all. Unless the application security community figures out how to be a relevant part of software development, we will continue to lag behind and effect minimal change. In this talk, I will explore a radically different approach based on instrumenting an entire IT organization with passive sensors to collect realtime data that can be used to identify vulnerabilities, enhance security architecture, and (most importantly) enable application security to generate value. The goal is unprecedented real-time visibility into application security across an organization's entire application portfolio, allowing all the stakeholders in security to collaborate and finally become proactive. Speaker Jeff Williams CEO, Aspect Security Jeff is a founder and CEO of Aspect Security and recently launched Contrast Security, a new approach to application security analysis. Jeff was an OWASP Founder and served as Global Chairman from 2004 to 2012, contributing many projects including the OWASP Top Ten, WebGoat, ESAPI, ASVS, and more. Jeff is passionate about making it possible for anyone to do their own continuous application security in real time.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to Application Security at DevOps Speed and Portfolio Scale
Similar to Application Security at DevOps Speed and Portfolio Scale (20)
Recently uploaded
Recently uploaded (20)
Application Security at DevOps Speed and Portfolio Scale
- 1. Application Security at DevOps Speed and Portfolio Scale Jeff Williams, CEO Aspect Security, Inc.
- 2. About Me
- 3. Application Security Is Healthcare
- 4. Sensors Are Revolutionizing Healthcare Your phone will know you’re sick before you do! Instrumenting the body means continuous realtime monitoring… Not periodic checkups
- 5. Traditional Tools and Techniques Are Failing… DevOps Agile Aspect Oriented Programming Libraries and Frameworks Serialized Objects Inversion of Control SOAP/REST Javascript Ajax Raw Socket Cloud Mobile
- 8. Defining “Portfolio Scale” The right defenses for every application are… Present Correct Used Properly
- 9. Defining “DevOps Speed” Application security happens continuously and in real time
- 10. One Thing at a Time… Is my portfolio protected against clickjacking?
- 11. Gathering Intelligence Controller Business Functions Presentation Third Party Libraries Framework Application Server Platform Runtime Operating System Data Layer
- 12. Security Intelligence Sources Vulnerability Trace HTTP Traffic Backend Connections Data Flow Control Flow Libraries and Frameworks Configuration Data
- 13. Designing a Clickjacking Sensor Data Sources Analysis Technique Environment Positive Dev SAST Negative CI Configuration DAST Sampling Data Flow IAST Intelligence Code Experiment Style Manual HTTP Control Flow Libraries Connections Test QA Passive Staging JUnit Security Choose based on: • Speed • Accuracy • Feedback • Scalability • Ease of Use • Cost Prod
- 14. Continuous ClickJacking Defense Verification A new HTTP sensor to verify that the X-Frame-Options header is set to DENY or SameOrigin on every webpage DEV CI Manual TEST QA Dynamic STAG Static SEC OPS Interactive Data Warehouse: Application Security Intelligence JUnit
- 15. Run Against Entire Portfolio TB RPC CM TY JJ F RH QP CO AS RA & IR XX X DD @ S Application Name Result Grade TBMarks 88% A RPC 0% F CaseyMotors 0% F Financials 72% C International Reporting 0% F … “Financials” ClickJacking Defense – C (72%) /home DENY /home/error.jsp - /home/index.jsp DENY /account /account/report.jsp … SAME-ORIGIN -
- 18. One Small Step Towards Continuous AppSec • We transformed clickjacking verification to devops speed and portfolio scale! Before Annual pentest Negative signatures One app at a time After Continuous monitoring Positive verification Portfolio wide Okay, clickjacking. Big deal.
- 19. More Sensors… I want a sensor to verify… My business logic makes access control checks My libraries are free from known vulnerabilities My forms are not susceptible to CSRF attacks My interpreters are protected against injection My encryption is implemented correctly My application has no unknown connections And much more….
- 20. Access Control Intelligence Sensor Source File Result @PreAuthorize TestSBMBugtrackerController.java @PreAuthorize("hasAnyRole('ROLE_BUG_CREATE','ROLE_BUG_EDIT')") UpdateSBMBugtrackerController.java @PreAuthorize("hasRole('ROLE_BUG_EDIT')") SelectBugtrackerController.java @PreAuthorize("hasRole('ROLE_BUG_CREATE')") CheckAppStatusController.java MISSING ViewConsoleEventsController.java @PreAuthorize("hasRole('ROLE_CONSOLE_VIEW')") DeleteEngineConfigController.java @PreAuthorize("hasRole('ROLE_ENGINE_PROFILES')") DownloadEngineController.java @PreAuthorize("hasRole('ROLE_ENGINE_DOWNLOAD')") EngineConfigController.java @PreAuthorize("hasRole('ROLE_ENGINE_DOWNLOAD')") ErrorController.java MISSING InboxController.java @PreAuthorize("isAuthenticated()") InstallationWizardController.java @PreAuthorize("isAuthenticated()") InviteAFriendController.java @PreAuthorize("isAuthenticated()") LoginController.java MISSING DeleteMessageController.java @PreAuthorize("isAuthenticated()") GetSystemMessagesController.java @PreAuthorize("isAdmin()") Control Flow SAST Intelligence CI
- 21. RO LE _A RO PP LIC LE AT _A IO RO PP LIC N_ LE AT DE _A LE IO PP TE RO LIC N_ LE GR AT _T O IO RO RA N_ U P CE LE RE S_ _T RA DEL ET RO E CE LE S_ TE _T SE RO RA CE NDM LE _S _E E A AIL RO NG IN RCH LE E_ _E NG D O RO W IN LE NL E_ _C ON PRO OAD RO SO F LE LE ILES _B _V RO UG TR IEW LE AC _B KE RO UG R_ TR LE VI AC _B K E EW UG RO R_ TR LE CR AC _A UD K E E AT RO R_ E IT LE DE _ E _ VI EW LET RO NG E IN LE E_ _L A IB R A CT I VI RY _S TY EA RC Generated Access Control Matrix from Code TracesGetBugtrackersController.java TracesGetUsersController.java TracesJIRAExportController.java TracesMergeController.java TracesSaveStatusController.java TracesSearchController.java O O O O O O TracesSendToBugtrackersController.java TracesTreeController.java TracesViewerController.java TraceViewerWorkingNotificationController.java ViewTracesController.java UpdateAppConfigurationController.java BannerController.java BillingAccountActivityController.java BillingApplyPaymentController.java BillingAppsController.java BillingExecuteOrderController.java O O O O O O O O O O O
- 22. Known Vulnerable Libraries Sensor Run DependencyCheck during every build Libraries (and do a build once a month even if nothing changed) SAST Negative CI
- 23. CSRF Defense Sensor HTTP Passive Positive QA • Run tests through ZAP • ZEST to check CSRF Token • Get results via ZAP REST API
- 25. Injection Sensors Use IAST tools for DFA vulnerabilities Data Flow IAST Negative Dev
- 26. Architecture, Inventory, and More… • What would you like to gather from all your applications? • Inventory? Architecture? Outbound connections? Lines of code? Security components? • All possible…. and all at devops speed and portfolio scale
- 28. Sensors? How do you know what sensors you need? 1) 2) 3) 4) The OWASP Top Ten? What your tools are good at? What your pentester thinks is important? Actually figure out what matters?
- 29. Aspect 2013 Global AppSec Risk Report Applications with at Least One Vulnerability in Category 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Higher Risk Lower Risk
- 30. What’s In Your Expected Model? Expected Requirements Threat Model Abuse Cases Policy Standards… There is no security without a model
- 31. What Are You Actually Testing? Pentest Code Review Tools Arch Review … Actual
- 32. Unfortunately… Expected Not being tested (aka RISK) Actual Doesn’t need testing (aka WASTE)
- 34. Aligning Sensors with Business Concerns Business Concerns Defense Strategies Actual Defenses Sensors Data Protection Fraud Minimize Sensitive Data Availability Role Based Access Control Encrypt Data in Storage and Transit Logging and Intrusion Detection Full Disk Encryption with TrueCrypt Programmatic Encryption with ESAPI TLS Everywhere with Venafi Libraries Present and Up-to-date Encryption Correctness with Junit Tests ESAPI Used Properly
- 35. Continuous Application Security! Translate “expected” into sensors New Threats, Business Priorities Expected Application Portfolio A A A A A A A A A A Application security dashboards A A Actual A A A A A A
- 36. How to Get Started Choose a sensor Build it with developers Deploy your sensor Create a dashboard using Excel
- 37. Transforming AppSec AppSec Optimization AppSec as Business Driver AppSec Strategy AppSec Monitoring AppSec Compliance We will never improve if our only metric is whether we are doing what everyone else is doing
- 38. Thank You! Please stop by the Contrast Security booth! @planetlevel
- 40. Expected:Tracking Coverage Infrastructure Security Secure Development Logging and Accountability Security Verification Data Protection ▼ Minimal data collection ▼… Incident Response ▼ Strong encryption in storage and transit ▼ All external connections use SSL ▼ All internal connections use SSL ▼ SSL hardened according to OWASP ▼ All highly sensitive data encrypted ▼ Encryption uses standard control ▼ Encryption uses AES, no CBC or ECB ▼ Universal authentication ▼… ▼ Pervasive access control ▼… ▼ Injection defenses ▼ Strict positive validation of all input ▼ Use of parameterized interfaces ▼ All parsers hardened ▼ XML parsers set to not use DOCTYPE ▼ Browser set no content sniffing header ▼ Etc… ▼ Use Hibernate and secure coding ▼ Use JQuery and secure coding ▼ Etc…
- 41. Enterprise Controls Dashboard Expected Defense Authentication Authorization Defense Present? Defense Correct? Applications Tested? Training and Support Cryptography Validation Escaping Tokens Logging Intrusion Detection Random Numbers Browser Security Safe API Wrappers Object Reference Management Error Handling
Editor's Notes
- My name is Jeff Williams. Some you may know me from my work on WebGoat, ESAPI, or the OWASP Top Ten, and a bunch of other open source projects.If any of you are smart, humble, and get things done – we have some amazing job openings at Aspect.And if you never want to wrestle with a static analysis tool again.... Come check out Contrast at our booth – I promise you it’s different!Today I’m going to talk about what I’ve learned helping organizations do application security at DEVOPS SPEED and PORTFOLIO SCALE.
- Imagine applications are people and vulnerabilities are sicknesses.We’ve got a few Doctors and some FANCY technology for them to use -- like Xray or MRI machines.These doctors are helping patients – but they’re reactive. We could have the best doctors in the world working on our patients AND NEVER make progress against the disease.It takes a DIFFERENTAPPROACH to target a disease than it does to help a patient.You can’t just “scale up” what you’re doing for individual patients..
- The healthcare world is undergoing a powerful transformation.On both the individual and population level, SENSORS are changing everything.This is great for patients as they can do their own monitoring.And in the AGGREGATE, this information can fight disease in new powerful ways.
- You might be thinking – well, our tools are pretty good. We just need to be better at running them.Unfortunately, traditional tools have not kept up with modern software development – both technology and processesFor example, most frameworks DON’T call request.getParameter() anymore. Or SQL statement.execute().So what is your static tool going to find? Do they know about every framework and pattern?They have lots of blind spots in the most important areas – like authentication and access control. They can’t handle complex frameworks, complex protocols, the explosion of libraries, or the speed of DevOps.And all the tools require experts, which introduces a serious bottleneck -- so we struggle to help Agile/DevOps type projects.
- I came to a hard realization…. I’m very proud of the progress we’ve made in appsec, but we are getting outpaced. The software guys are out there inventing the next crazy new thing right now. By the time we get involved, it’ll be cast in stone. And we’ll eventually figure out how to break it, and how to secure it… and then it will be too late. Again.So – I’m convinced that the only way forward is:AutomatedContinuous and RealtimeKeep security experts out of the critical path
- So what do we do?We have toGIVE UP on anything that doesn’t work at devops speed or portfolio scale.I’m sorry “expert” – that means your job is going to change. Because software development has changed.
- At the end of the day, the only success metric that matters is whether we’re doing a decent job of protecting all the apps in our portfolios. And even the best programs are nowhere close.Appsec is really more like public health actually. It’s not only about securing apps, it’s about securing a PORTFOLIO.And whether something works for a single application (patient) is almost irrelevant to whether it works across a portfolio.
- We really need this. I’ve worked with a lot of agile and devops projects. They can’t use results that aren’t very timely.If you can’t get developers feedback almost immediately, the cost skyrockets and the learning plummets.I don’t want to hear anyone badmouthing the security of Agile or DevOps projects. In my experience they are no better than others. And I believe they have a lot more potential to be better.
- So we’re going to need to automate some stuff.Let’s see if we can do just one simple thing across the portfolio at devops speed. How about clickjacking.
- Before I show you how to create those sensors, I want to explain the different intelligence that can help us.This is the information that can help us identify vulnerabilities. Too often we confuse the type of information with the technique for analyzing it.
- You can’t point at a diagram like this and say, SECURITY GOES HERE.SECURITY IS NOT just a single point in the code. It’s a PATH through an application that goes from custom code, to libraries, to frameworks, to platform and back again.So when we VERIFY security, we need access to lots of different types of information.What kinds of information are relevant? HTTP, Data Flow, Libraries, Control Flow, Configuration, and Backend Connections to name just a few.So what kind of TECHNIQUES can we use to verify that this app does the right thing in stressful situations?
- Positive vs. negative?SAST, DAST, IAST, Manual, Passive?DEV, CI, TEST, QA, SEC, OPS?
- The Beastie Boys brought you Check Your Head…. But I’m bringing you CheckYourHeaders!!!It’s
- But it’s one step towards Continuous AppSec….
- Access Control – static in CILibraries – static in staging – ah ha!Verb Tampering – check config – positive!Injection – IAST – great data flow w/o false alarmsCrypto Correct? – Manual -> Junit testsArchitecture!!
- Run DependencyCheck during every buildStruts2Need to find who has it fastNot all apps are in development and test
- For the Enterprise Security API project, we knew that we needed proof that the security controls we built were “CORRECT”So we wrote thousands of test cases to prove that the controls: * Performed their function * Were tamperproof and non-bypassableToday there are almost 5,000 companies using ESAPI. And we have had only 1 vulnerability identified. We immediately added a test case and we’ll never have that one again Here is a snippet of code from an ESAPI test case.
- Most organizations look like this…. They use all the techniques
- Here are Aspect’s results for MANUAL code review and penetration testing of 5,000,000 lines of code every month.
- Unfortunately, we don’t really have a clear picture of what we expect. Both our EXPECTED and ACTUAL are spotty. That means we don’t have a complete and clear EXPECTED model. We also don’t know exactly what was VERIFIED.I’ve seen folks testing for SQL injection on applications that don’t even have a SQL database. That’s just WASTE. When our tests don’t match up to our EXPECTED model, we aren’t getting good coverage. And even worse are things in the EXPECTED model that aren’t even getting tested.So we end up with a muddy, spotty picture of risks – which leads to bad decisions, exposure, breaches, etc…. This is not to say that we’re not adding value. BUT if we’re going to SCALE we have to get a lot more EFFICIENT.
- Unfortunately, we don’t really have a clear picture of what we expect. Both our EXPECTED and ACTUAL are spotty. That means we don’t have a complete and clear EXPECTED model. We also don’t know exactly what was VERIFIED.I’ve seen folks testing for SQL injection on applications that don’t even have a SQL database. That’s just WASTE. When our tests don’t match up to our EXPECTED model, we aren’t getting good coverage. And even worse are things in the EXPECTED model that aren’t even getting tested.So we end up with a muddy, spotty picture of risks – which leads to bad decisions, exposure, breaches, etc…. This is not to say that we’re not adding value. BUT if we’re going to SCALE we have to get a lot more EFFICIENT.
- Unfortunately, we don’t really have a clear picture of what we expect. Both our EXPECTED and ACTUAL are spotty. That means we don’t have a complete and clear EXPECTED model. We also don’t know exactly what was VERIFIED.I’ve seen folks testing for SQL injection on applications that don’t even have a SQL database. That’s just WASTE. When our tests don’t match up to our EXPECTED model, we aren’t getting good coverage. And even worse are things in the EXPECTED model that aren’t even getting tested.So we end up with a muddy, spotty picture of risks – which leads to bad decisions, exposure, breaches, etc…. This is not to say that we’re not adding value. BUT if we’re going to SCALE we have to get a lot more EFFICIENT.
- Unfortunately, we don’t really have a clear picture of what we expect. Both our EXPECTED and ACTUAL are spotty. That means we don’t have a complete and clear EXPECTED model. We also don’t know exactly what was VERIFIED.I’ve seen folks testing for SQL injection on applications that don’t even have a SQL database. That’s just WASTE. When our tests don’t match up to our EXPECTED model, we aren’t getting good coverage. And even worse are things in the EXPECTED model that aren’t even getting tested.So we end up with a muddy, spotty picture of risks – which leads to bad decisions, exposure, breaches, etc…. This is not to say that we’re not adding value. BUT if we’re going to SCALE we have to get a lot more EFFICIENT.
- I strongly encourage you to break it down with a structured defense strategy.You can achieve a LINE OF SIGHT. You CAN match up your sensors with Business Concerns, but not directlyIdentify your most important business concernsWork out defense strategies – PRIMARY, SECONDARY, PREVENTATIVE, REACTIVEOnce you specify your ACTUAL defenses, your sensors are OBVIOUS
- Talk about creating a cycle of evolve the model, deploy sensors, analyze results, make strategic decisions. This creates high-speed ITERATION and improvement.This leaves the people to ACTUALLY figure out what they care about. Now you can have that principled discussion about whether to allow SHA-1. You’ll have data about how many instances of SHA-1 you actually have, and how hard it will be to update.We lose 90% of the intelligence we gain during a penetration test… and we do it all over again next year.Penetration tests are great at:1) Identifying holes in the expected model2) Figuring out how to test expected model3) Defining (and maybe building) sensorsThat’s a business case for security.
- Later you can include in CI
- Close up with how we are transforming appsec the same way that new-relic transformed performance. Into something that ordinary folks can do themselves.
- Imagine this is your EXPECTED modelNow you have information from your sensors flooding in – telling you that your DEFENSES arePresentCorrectUsed ProperlyAcross your entire PORTFOLIOEven if you start with a very small percentage of your expected model, that’s work that you no longer have to do manually!