Application security testing in the age of Agile development - by Julio Cesar Fort
•Download as PPTX, PDF•
1 like•135 views
Agile development methodologies have brought with them a myriad of challenges for security engineers. Old school application security testing no longer keeps pace with the rapid deployment of code, fast moving projects and change of requirements. This presentation aims to introduce how we security engineers are adapting to integrate application security testing and tools into the software development process and discuss the new role of QA engineer in taking ownership too of security of the product.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Application security testing in the age of Agile development - by Julio Cesar Fort
Similar to Application security testing in the age of Agile development - by Julio Cesar Fort (20)
Recently uploaded
Recently uploaded (20)
Application security testing in the age of Agile development - by Julio Cesar Fort
- 3. Application security testing in the age of Agile development
- 4. Director of Professional Services at Blaze Information Security INTRO
- 5. AGENDA
- 7. DEVELOPMENT METHODOLOGIESVS. SECURITY In the past decade or so there was a shift from waterfall to Agile development model. We went into Agile / DevOps but security was once again left out.
- 9. CURRENT SOFTWARE DEVELOPMENT PROCESS
- 10. CURRENT SOFTWARE DEVELOPMENT PROCESS
- 11. Think of your system as a cake: security is often brushed on top of the cake, instead of being baked in as layers. PROBLEMATIC APPROACHTO SECURITY
- 12. You push code continuously, but why aren’t security initiatives continuous too? PROBLEMATIC APPROACHTO SECURITY
- 13. TRADITIONAL SECURITYTESTING ○ Penetrate and patch approach: has been done since the 60’s, with an uptick in the late 90’s and the current momentum since 2000’s ○ Traditional security testing only occurs right in the end of the process: after everything has been built, you bring in a team to review / break things ○ Time-boxed engagements: usually a team gets hired for 1 or 2 weeks for an assessment Impossible to get acquainted with the inner workings of the system and get the best bugs out of it
- 14. DISAVANTAGES OFTHE CURRENT APPROACH #1 ○ Things are broken: some defects are easier to fix, some others will require more time - delays in the GO-LIVE date ○ Trying to bolt security onto software after it had been developed produces an insufficiently secure product ○ Cost of fixing issues gradually increases as the end of the development cycle approaches
- 16. DISAVANTAGES OFTHE CURRENT APPROACH #2 ○ Silo culture: breakers often lack the builders knowledge, edge cases and tricky bugs will be missed ○ Security becomes a bottleneck for faster releases
- 18. MODERN SECURITY ENGINEERING IN SOFTWARE DEVELOPMENT ○ Build security in – since the early days of the project until the day it launches ○ Make security activities as an active part of the project sprint ○ Teams: add “adversarial thinking” into your user stories
- 19. Security Code Review Introduce Security Oriented Tests Risk Analysis Threat Modeling Security Requirements Abuse Cases SECURITY ACTIVITIES INTHE DEVELOPMENT PROCESS
- 20. SECURITY ACTIVITIES INTHE DEVELOPMENT PROCESS Vulnerability Scanning Penetration Testing
- 21. SECURITY ACTIVITIES INTHE DEVELOPMENT PROCESS SecOPS Continuous Penetration Testing
- 22. MODERN SECURITY ENGINEERING IN SOFTWARE DEVELOPMENT: INTHE IDEAL WORLD
- 23. AND INTHE REAL WORLD…
- 24. How can QA testers help?
- 25. TOWARDS SOFTWARE ASSURANCE ON A SHOESTRING What can we do as QA’s to help an average development team with little resources to improve security maturity?
- 26. TOWARDS SOFTWARE ASSURANCE ON A SHOESTRING ○ Ops team: add open-source security controls into your DevOps pipeline ○ Security team: teach QA’s application security basics and how to identify easy bugs
- 27. QUICK WIN #1: CROSS-SITE SCRIPTING ○ Cross-site scripting (XSS) is an attack that can compromise users of a website ○ Often used to execute scripts on the user’s browser ○ One of the most common class of vulnerability affecting web applications ○ Sample payload – how to test: “><script>alert(1)</script><“
- 28. QUICK WIN #2:TEMPLATE INJECTION ○ Server-SideTemplate Injection (SSTI) happens when user input is injected into a template and rendered by a template engine ○ Template rendering is frequently executed in server-side ○ Sample payload – how to test: {{7*7}}
- 29. QUICK WIN #3: IDOR ○ Insecure Direct Object Reference (IDOR) occurs when user input is used to access objects directly ○ IDORs are a common access control problem ○ This type of issue is usually easy to find ○ How to test: Seen ?id=1 - so why not cycle through id=2, id=3, id=4…
- 30. QUICK WIN #4: SERVER-SIDE REQUEST FORGERY ○ SSRF allows an attacker to instruct the application to issue requests on his/her behalf ○ It can be used to connect to resources located in the organization’s internal network, interacting with otherwise inaccessible back-end systems ○ The result of a successful SSRF can range from leaking cloud secret keys and even code execution ○ How to test: A parameter taking a URL?Try: https://www.myip.is If the IP isn’t yours but the server’s, you may have a SSRF
- 31. QUICK WIN #5: MISCONFIGURED AUTHORIZATION ○ The idea of authorization is to allow or restrict access to a given resource to a user ○ Horizontal vs.Vertical privilege escalations ○ How to test: get two sessions from different users (A and B).Try to use A’s session tokens to access the same resources expected only to be available for B
- 32. Conclusion
- 33. CONCLUSION ○ Security is not always that complicated and thinking this way makes it harder ○ Code is being pushed into production faster than ever before, and security did not catch up – but this is changing
- 34. Introducing security into the DevOps pipeline and QA even on a budget may yield good results if your team can’t afford dedicated specialists. CONCLUSION
- 35. A lot of application security testing is just glorified QA with different tools and hacker-sounding names. Really. CONCLUSION
- 36. With Agile, security is now part of everyone’s job. CONCLUSION
Editor's Notes
- My name is Julio, I am currently a partner and director of services at Blaze Information Security. We are a cybersecurity consultancy company offering a range of technical services for customers in Europe and Latin America, mostly related to application security.
- Here’s the brief agenda. We start talking about the traditional penetration testing model, then speak about modern security engineering activities and move on to answer how QA testers can help and finally conclude the talk.
- So, we will now discuss briefly the current penetration test model applied by most organizations out there
- So as you guys know very well, waterfall software development process was the thing until a couple of years ago, maybe a decade or so. Now many modern organizations shifted into agile and all this paradigm of move fast and break things, and so on, but again security takes the back-seat and is rarely considered a priority.
- Now we have a brief overview of the regular activities that are performed in the waterfall software development process. As you can imagine, we can bring in a few security activities in each step.
- We now have agile and DevOps, which are more or less – at least my understanding as a non-software developer and QA tester, that it is fairly similar to waterfall, however that process happens much more often and in faster iterations.
- The current approach to security is, in my opinion, problematic. Think of your system as a cake: often security is brushed on, like cream or a cherry on top of the cake. Instead of baking it into the foundations of the cake, as layers. And this attempt to retro-fit security into a system that was never designed with it in the first place usually creates a system that is insufficiently insecure, and will bring a lot more costs in the end of the day, as we will see later.
- And in the age of agile, you push code continuously – is your security continuous too?
- Traditional security testing has been happening since maybe the 60’s, I guess it was the US Airforce who started it, commissioning penetration testing of their old old computer systems. This penetrate and patch approach has gained the shape and form it has since the 1990’s, when the first IT security companies started to appear in the market and to be honest, not much has changed since then. That is, it’s almost 30 years and we’re doing the same thing. Again, we try to bring security in a pretty late stage of the project and assessments are usually time-boxed: 1, 2, 3 weeks that in many cases makes it difficult to get acquainted with the inner workings of the system, fully understand the business logic, etc. These approaches have, obviously, some disadvantages as we will see later.
- What if things are broken and your go-live date is next week? What if it is a design error and not a simple implementation bug? As we will see in the upcoming slide, cost of fixing issues grows exponentially as the end of the development cycle approaches.
- So as we can see here, a research from IBM Rational says it can cost up to 30 times MORE to fix issues depending on the phase it is in the development, whereas in the very beginning it is like a lot lower than this.
- The current approach of testing in the end not only can cause costs to go higher, but it also does not leverage the internal knowledge and communication between teams, and the builder’s knowledge is important to find the edge cases and tricky bugs. On top of that, by testing only in the end security can become a bottleneck for faster releases.
- But all of this is in the ideal world, where we will have training, consultancy from experts, threat modeling, source code review, DevSecOps, etc. We know this is in many cases not feasible for most organizations.
- So in the real world, with a lot of luck you may get a penetration test once a year. And often because it was mandated by a customer or a partner. But remember, we push code out sometimes daily and might have a much wider security technical debt than we think. So how can QA testers help?
- What can you QA testers help a development team to improve security?
- Of course, we are talking about collaboration here and there must be the involvement of a few other teams too such as the Ops and Security team. In my opinion, what the security team can do best is to train QA testers the basics of application security and how to identify the quick wins.
- One of the first quick wins we can talk about is cross-site scripting. (Read the slides)
- Template injection happens when the user input is injected into a template and rendered as such by the template engine. It is frequently executed in server-side and we know template languages can be sometimes very powerful, to the point we can do introspection, read configuration objects of the application, and even execute code.