Appsec Agility: A Brief Tour
•Télécharger en tant que PPTX, PDF•
0 j'aime•18 vues
Slides for the presentation on application security in an Agile SDL that I gave at ProQuest on February 20, 2020.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Appsec Agility: A Brief Tour
Similaire à Appsec Agility: A Brief Tour (20)
Dernier
Dernier (20)
Appsec Agility: A Brief Tour
- 1. Appsec Agility A BRIEF TOUR
- 2. He/Him CISSP, C|EH, MSCE Information Security Executive, Consultant, Wise-Guy LinkedIn: https://www.linkedin.com/in/robbkeefer Robb.keefer@outlook.com Who is Robert Keefer?
- 4. Some Definitions Flaw: A weakness in an application. This may come about due to a missed best practice, a syntax or other error, misconfiguration, or a weakness inherent to the language or framework. Vulnerability: A flaw with a known exploit. All vulnerabilities are flaws, but not all flaws are vulnerabilities…at least not yet! Remediation: A change made in the code to address a vulnerability or flaw. A remediated flaw or vulnerability does not exist in the finished app any longer. Mitigation: The creation or documentation of a compensating control. A compensating control does not remove the flaw or vulnerability, but hopefully makes it impossible to exploit.
- 5. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- 6. The Twelve Agile Principles 1. Our highest priority is to satisfy the customer 2. Welcome changing requirements, even late in development. 3. Deliver working software frequently. 4. Business people and developers must work together 5. Build projects around motivated individuals. 6. Face-to-face conversation.
- 7. Twelve Principles Continued 7. Working software is the primary measurement of progress. 8. Agile processes promote sustainable development. 9. Continuous attention to technical excellence. 10.Simplicity is essential. 11.self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective.
- 8. Pro Security ANTI AGILE?=
- 9. Ask Yourself: Does insecure software value individuals and interactions? Does insecure software count as working? Is insecure software the result of customer collaboration? Does insecure software (or rather software development that doesn’t take security into account) respond appropriately to change?
- 10. The Twelve Agile Principles? 1. Our highest priority is to satisfy the customer. 2. Welcome changing requirements, even late in development. 3. Deliver working software frequently. 4. Business people and developers must work together. 5. Build projects around motivated individuals. 6. Face-to-face conversation.
- 11. Twelve Principles? 7. Working software is the primary measurement of progress. 8. Agile processes promote sustainable development. 9. Continuous attention to technical excellence. 10.Simplicity is essential. 11.self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective.
- 12. Appsec & Agile:
- 13. Hardening Sprints Security dedicated dev pass Often result of customer complaint ✅ Useful to resolve complex issues ✅ Shows dedication to security ❌ Delays product ❌ Seen as tedious ❌ Creates “Security at the End” mindset
- 14. User Stories Include security requirements in epic Adds to “definition of done” ✅ Easy to accomplish ✅ Handy metric ❌ Can add complexity ❌ Security stories are hard to score ❌ Incomplete approach
- 16. Agile Security Integrated lifecycle Breaks appsec programs into tasks aligned with project framework Highly customizable; mine is based on Microsoft’s SDL-Agile
- 17. SDL Tasks Pre-Project Tasks Security Training IRB/Other Boards Enterprise-Wide One-Time Tasks Requirements Gathering Initial Threat Model Tool implementation Final security assessment Per-Sprint Tasks Code Scans Bug Tracking Unit Reviews Bucket Tasks Update Threat Model Design/Update Privacy and Security Docs Update IR Plan
- 18. Tools of the Trade: SAST, DAST, AND OTHER PAINS IN THE *AST
- 19. Acronyms: SAST Static Application Security Tool Source code scanner Language dependent Unaware of infrastructure or mitigations
- 20. Acronyms: DAST Dynamic Application Security Tool Runs on external server Runs against compiled code Checks for API, web interface, SQL calls, etc. Uses CVS, OWASP Top 10, etc. to rate Different results inside firewall from outside “Black Box” testing
- 21. Acronyms: IAST Interactive Application Security Tool Runs on application server Real-time as application is used Aware of server, frameworks, backend, etc. “White Box” testing
- 22. Layered Approach: SAST Runs internally against code repositories Run from developer IDE if possible Trigger after set number of updates
- 23. Layered Approach: DAST Run outside of security perimeter, pointing to UAT Run after every deployment to environment Used to confirm flaws have been identified and remediated or mitigated
- 24. Layered Approach: IAST IAST: Installed on QA servers Runs constantly Reports as part of QA testing
- 25. Layered Approach: External Testing Used to supplement automated testing Separate team; either onboarded Red Team or external vendor Fuzzing tools, vuln scanners, manual testing Should not be confrontational!
- 26. Conclusion: Three Takeaways Application security is not anti-Agile; not being secure is anti-Agile. Application security principles can be folded into the development process, rather than bolted on to the end. No matter how many tools you deploy or tests you run, secure applications are developed by people, for people.
- 27. Thank You! Questions? References: Agile Alliance: http://www.agilealliance.org Microsoft SDL: https://www.microsoft.com/en-us/securityengineering/sdl Microsoft SDL-Agile: https://docs.microsoft.com/en-us/previous- versions/windows/desktop/ee790620(v=msdn.10) My LinkedIn (feel free to add me!): https://www.linkedin.com/in/robbkeefer
Notes de l'éditeur
- Thank you all for coming today! My name is Robert Keefer; I am an information security executive; I have about 20 or so years of experience in InfoSec and some of the requisite alphabet soup after my name to show it. My LinkedIn is on this slide and will be at the end if you want to know more about me, but today I’m here to discuss concepts around application security with you.
- Now, here is where a lot of security presentations insert the disaster stories. You know, the ones where the developer forgot to close an HTML tag and the local orphanage burned down. I don’t really like disaster stories most of the time, so I’m not going to do that here. Instead I’m going to talk to you a little bit about Agile.
- First, Some Definitions and Terms Flaw: A weakness in an application. This may come about due to a missed best practice, a syntax or other error, misconfiguration, or a weakness inherent to the language or framework. Vulnerability: A flaw with a known exploit. All vulnerabilities are flaws, but not all flaws are vulnerabilities…at least not yet! Remediation: A change made in the code to address a vulnerability or flaw. A remediated flaw or vulnerability does not exist in the finished app any longer. Mitigation: The creation or documentation of a compensating control. A compensating control does not remove the flaw or vulnerability, but hopefully makes it impossible to exploit. Note that a mitigated vulnerability still exists! This means that if the control fails, the application can be exploited. This is why we prefer remediation over mitigation.
- This is probably review for all of you, but it’s good to look it over every once in awhile. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
- The Agile Alliance (www.agilealliance.org) is an organization founded by some of the authors of the original manifesto. One of their tasks was to expand the concepts in the manifesto into the following 12 principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 7. Working software is the primary measurement of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. A department that is Agile will conform to more of these concepts and principles, and do so more closely, than a department that is not Agile. That does not mean, of course, that a department needs to adhere slavishly to all of the 4 concepts or 12 principles.
- Why did we just go through this review? Many people, both application developers and information security folks, act from the belief, often unstated, that security requirements conflict with Agile.
- Does security really conflict with the Agile Manifesto? Ask yourself: Does insecure software value individuals and interactions? Does insecure software count as working? (if a coffee maker squirts you in the face with scalding water while it brews, is that working?) Is insecure software the result of customer collaboration? (do you *really* think the customer wants credit card data to be easy for strangers to obtain?) Does insecure software (or rather software development that doesn’t take security into account) respond appropriately to change? Remember that flaws, even mitigated ones, may have exploits developed against them in the future.
- I would suggest that NOT focusing on security conflicts with the Agile Manifesto. It also conflicts with the 12 principles: -It doesn’t satisfy the customer (1) -It doesn’t provide competitive advantage for the customer (2) -It’s not working software—certainly not as the customer requires! (3,7)
- -Unaddressed flaws are bad for the business (4) -They certainly aren’t technical excellence! (9)
- So we can see that designing software without keeping security in mind is actually pretty far from Agile. So how can we include security in an Agile way?
- A “Hardening Scrum/Sprint/Pass” is just what it sounds like; taking a development pass to focus on resolving identified security issues, whether flaws, unresolved threat models, configuration issues, or the like, instead of developing new functionality. Sometimes these are done at behest of QA as well, but typically that sort of debt is resolved over multiple scrums. This is often done as a resolution to a customer complaint—in other words if you are doing hardening sprints then Something Has Gone Very Wrong Indeed. Why might you want to use this approach? Well, as we just discussed it can be a way to show a dissatisfied customer that you are now taking security seriously. For very complicated security issues, or ones that are mission critical, it may be worthwhile to set other development aside for awhile and focus on this particular thing. If you really haven’t been addressing security issues, then doing a hardening sprint can be a way to get some momentum going as well. However, it comes with what I consider some pretty significant downsides. First, any sprint that isn’t developing new features is a delay on the final product. Second, developers as a rule would prefer to develop neat new features rather than address debt, and unresolved security issues are debt. This means that a hardening sprint is seen as tedious, which is hard on the squad, hard on the department, and hard on the project managers who have to deal with the morale issues. Lastly, this approach allows the department to consider security as something you do “after” the features are developed, instead of being part of the development process. This makes the whole process less efficient and more error-prone.
- One way to overcome the inertia of hardening sprints is to make security part of the requirements. Often this is done by creating stories for security requirements and/or threat models and including them in the epic. By doing this we can make security part of the “definition of done”. The advantages to this approach are: First, it’s pretty easy to do. Most people are already comfortable working with stories, and these are just another type. It moves security concerns from a release gating factor to part of requirements gathering, with all the advantages that has (less overall effort, greater flexibility in implementation, and so on). And, it provides a handy metric that gives a rough idea of the level of security in a project and the level of effort being spent to increase that level. On the other hand, using stories as your sole method of application security has its own issues. There is the danger of increasing complexity beyond what is sustainable in an Agile team. Security stories can be challenging to score without additional information, such as threat models or risk analysis. It’s also an incomplete approach. Security can’t always be reduced to a set of requirements; it’s part of the application and project ecosystem.
- Which means that security can be aligned with the project’s lifecycle. There are a number of different approaches to this; the one that I use draws heavily from the SDL-Agile model developed by Microsoft.
- This model breaks application security into several tasks that align with the project lifecycle of your organization. Some of them are done pre-project, like security training and tools implementation, some are done once per project, some are done per-sprint, and some are bucket tasks, which are tasks that need to be scheduled during the project’s development, but aren’t necessarily done every sprint. Depending on the task and the team’s rhythm I try to do these every retrospective or every other retrospective.
- The Pre-Project Tasks include security training (this counts, by the way!), creation or maintenance of Incident Response Boards, other security Boards, and so on. Most of these are done yearly, and often at the enterprise, division, or department level. The One-Time Tasks are things like requirements gathering, initial threat modeling, tool decision and implementation, and final security assessment (usually fuzz testing/pentest, etc). The Per-Sprint Tasks include code scanning, unit reviews, bug tracking, and similar tasks. The Bucket Tasks are those things that are important, but for one reason or another aren’t necessary every sprint—usually because they don’t get updated that often. These are tasks like updating the threat model, designing or updating privacy and security documents, creating the incident response plan, and so forth. Now for each of these you can draft a specific set of steps, depending on your application, it’s intended use and audience, your customized Agile methodology, etc. In fact, doing so is one of the One-Time tasks I usually recommend.
- So: We’ve talked about why we do appsec, and discussed some approaches to implementing it. Let’s talk about some of the common types of tools that are used in the pursuit of secure software.
- SAST, DAST, IAST. That’s a lot of acronyms that all look very much alike. Let’s look at these a bit closer and see how they differentiate from each other and how they complement each other in an appsec program. First, SAST or Static Application Security Tool. This is your classic “source code scanner”. Typically this is a syntactic analysis tool that will review submitted code and run it against a list of known flaws, vulnerabilities, and best practices. It will then provide an indication of the sort of issue it finds, locate it within the code, and in some cases provide additional information on the nature of the issue and provide recommendations on how to resolve it. These tools tend to be heavily language specific, signature based, and a little on the resource heavy side. They’re usually pretty quick, however. The output of a SAST is a list of flaws and/or potential vulnerabilities, based on the source code in a vacuum. It does not know how your databases are set up, what kind of firewall is in front of the finished application, or even the operating system that will be used. For that reason the output needs to be triaged by the team before it can be acted on. Please note, however, that even if a flaw cannot be exploited at this time, that does not mean it isn’t a flaw in the code! This is why many SAST tools don’t have a way to mark issues as “false positive”; instead you mark them “not exploitable”. The flaw is real, it just doesn’t lead to a security finding. At least, not today.
- DAST, or Dynamic Application Security Tool, operates differently. A DAST runs against compiled code, looking for vulnerabilities in the APIs, web interfaces, SQL calls, etc that it can find. They get pointed at the application from the outside; for this reason they are also called “black box testing” tools. Their output is a list of potential vulnerabilities that typically comes from a known source such as CVS (Common Vulnerability System), and uses a common framework to rank them, such as OWASP Top 10. The accuracy of a DAST tool depends on where it’s placed. If you run it against a production system from outside your security perimeter, then anything it can see an attacker can see as well, which means it’s highly unlikely to be any sort of false positive. As with SAST however you will not want to just blindly accept the findings, as it may not be aware of other mitigations in place.
- Finally IAST is Interactive Application Security Tool. This runs on the application server, and monitors application activity in real time as it’s used. Because it’s part of your deployment infrastructure, it is aware of the underlying server, any application frameworks, backend databases, and so forth. What most IASTs look for is vulnerable behavior or results. These tools provide a comprehensive look at the application infrastructure and can help pinpoint any underlying vulnerabilities and how they may interact with flaws in the compiled code. Again as with all automated tools you want to triage the results to ensure that the detected issues are aligned with your risk model. If DAST is “black box” testing, then IAST can be considered “white box” testing.
- In order to maximize the effectiveness of these tools I usually recommend a layered approach: SAST running internally, at the very least performing regular scans on the repositories. Ideally the tool is able to be run by developers out of their IDE as well—this will provide them with near-real-time feedback on their code as they’re developing it. Failing that, the SAST should be triggered after a certain number of updates to the repository; how many depends on your internal processes.
- DAST should be running externally to your User Acceptance infrastructure, and should be run after every deployment. The purpose of this tool is largely to confirm that flaws have been identified and remediated, and that any proposed mitigations are in fact protecting the system as described.
- IAST should be running on your QA systems, and runs constantly. This will generate new data with every QA pass, so it should ideally be a part of that team’s output.
- Automated testing can only get you so far. In order to test completely a certain amount of more manual testing is necessary. This should be done by a team that is not associated with the development team or the application security team—either a dedicated Red Team within the organization or an external vendor. They will perform a manual security analysis using standard penetration testing tools and techniques. This process is usually time and labor intensive, and results in a comprehensive report of the overall security stance of the application and its infrastructure. Because of the time and intensity factor I rarely have this run more often than twice a year. As a rule of thumb, you want to have external testing performed with every major release iteration. Many people see red teams as confrontational. They shouldn’t be. You should be able to have the red team, whether internal or external contractors, working in close cooperation with the application development and project management teams to identify, prioritize, and remediate issues as they are found, and if you can’t? Find a different team. Remember that will all of these tools and approaches the final goal is secure, working software.
- I’ve given you a lot of information, and hopefully some of it has been enlightening. When I’m building a presentation like this one of the things I try to consider is this: If you were only going to take away three things from my time here with you, what would I want them to be? And in this case those three things are: 1. Application Security is not anti-Agile; in fact not being secure is anti-Agile. 2. Application security principles can be folded into your development processes, rather than bolted on to the end, and 3. No matter how many tools you deploy or tests you run, secure applications are developed by people, for people.