Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Making Security Agile - Oleg Gryb
Similar a Making Security Agile - Oleg Gryb (20)
Más de SeniorStoryteller
Más de SeniorStoryteller (18)
Último
Último (20)
Making Security Agile - Oleg Gryb
- 1. Getting security up to speed (with CI/CD) Oleg Gryb – Visa Inc.
- 2. DevOps Look at Security 2Making Security Agile
- 3. DevOps Look at Security 3Making Security Agile The only thing more dangerous than a developer is a developer conspiring with Security. The two working together gives us means, motive, and opportunity. Information Security is always flashing their badges at people and making urgent demands, regardless of the consequences to the rest of the organization, which is why we don’t invite them to many meetings. The best way to make sure something doesn’t get done is to have them in the room. They’re always coming up with a million reasons why anything we do will create a security hole that alien space-hackers will exploit to pillage our entire organization and steal all our code, intellectual property, credit card numbers, and pictures of our loved ones. These are potentially valid risks, but I often can’t connect the dots between their shrill, hysterical, and self- righteous demands and actually improving the defensibility of our environment.
- 4. From a real survey 4Making Security Agile “Stop pretending that you’re the only one in the room occupying a higher moral ground” Credits: http://www.looppng.com/
- 5. That Love between Sec & DevOps Goes both Ways 5Making Security Agile From @RSnake Post at Twitter Difficult to understand Won’t fix attitude
- 6. Retrospective – Waterfall 6 http://brentmailphotography.com Making Security Agile
- 7. 7 DREAD • Damage potential: How great is the damage if the vulnerability is exploited? • Reproducibility: How easy it is to reproduce the attack? • Exploitability: How easy it is to successfully exploit this condition? • Affected users: As a rough percentage, how many users are affected? • Discoverability: How easy it is to find the vulnerability? Making Security Agile
- 8. 8 STRIDE • Spoofing • Tampering • Repudiation • Information disclosure • Denial of service • Elevation of privileges Making Security Agile
- 9. Old Waterfall AppSec Summary We’ve generated huge *doc and *xls with Threat Models and pen test results. We wrote nice exec summaries and we presented details to Dev/OPS/DB teams We had a cool heat map to visualize the risk allocation for execs. Then we worked on remediation with developers – informal name “nagging” We supported a security dashboard and reported/escalated to CTO weekly 9Making Security Agile
- 10. DevOps + Agile = Big Bang for Security 10Making Security Agile
- 11. We had no choice 11Making Security Agile Credits to Pierre de Rauglaudre
- 12. New Agile Reality aka Reqs No 2-4 weeks for security purposes Nobody cares about (or understand) formalities such as STRIDE, DREAD or heat maps Forget about 2 full days of interviews, not possible Nobody gives Environment for 2-3 weeks solely for pen testing. Need to share. Need to do security as Dev process goes and in parallel Need to be integrated better with the DevOps and QA teams 12Making Security Agile
- 13. Other Challenges for API products You *can* pass an API URL to a scanner and tell “do automatic scanning” , but it’s not going to crawl. No Spidering is available. You can manually call each and every API while on a scan proxy and then do scanning, but if you have too many ever changing API’s, you’ll die doing that 13Making Security Agile
- 14. Differences – QA/DevOps and Security Ops: run_script(input) $? (0, non-zero) QA: assert(condition) {true,false} Security: scan(app) {HML…,false positive} where HML and FP is really a human’s decision 14Making Security Agile
- 15. QA and security differences You can’t dump all app scanner’s “findings” to a bug tracking system You usually need to triage each finding and verify a severity before submitting it to a bug tracking system In many cases you still need to explain your finding and remediation to developers 15Making Security Agile
- 16. Coming to a Solution Since Security does require a manual review, our hypothesis was that we need a dashboard with a broad import/export capabilities Import from scanners, export to bug tracking systems All scanners should be automated to run regression Should also allow manual testing and import for new features and products 16Making Security Agile
- 17. Making Security Agile 17 Scheduled Job Scheduled Job Manual testing Custom Tools Security Artists DevOps Team Notifications
- 19. Why use QA regression Over the years, QA team has built hundreds or even thousands of functional test scripts. They continue to add new scripts everyday. Security team can reuse the work done by QA team to do security testing. They can use a proxy such as BURP or ZAP to analyze requests & responses to find any security vulnerabilities. 19Making Security Agile
- 20. Automation with ZAP Proxy Use command such as following to start ZAP in headless mode on port 8085: java -Xmx2048m -jar /home/user/zap/ZAP_2.4.2/zap-2.4.2.jar -cmd -daemon -installdir /home/user/zap/ZAP_2.4.2 -config api.key=12345 -port 8085 Making Security Agile 20
- 21. Configure and start QA regression Configure QA regression properties to use proxy running on port 8085. Use command such as following to start QA regression (will vary depending on scripts used for your QA regression) mvn clean test -Dcategory=api - Dtarget.environment=qa -DexcludedGroups=in- progress,sdr,email,logs,cleanup - DuseProxy=true -DlocalProxy=true 21Making Security Agile
- 22. Save security findings from regression in XML form At the end of regression, save findings in XML form: curl "http://localhost:8085/OTHER/core/other/xmlre port/?apikey=12345" > /home/user/temp/newpaymentregression.xml Upload the findings to Threadfix using (app id for regression # 32 found earlier) java -jar /home/user/tfcli.jar --upload 32 /home/user/temp/newpaymentregression.xml Note: Above commands are part of automated script. 22Making Security Agile
- 23. ThreadFix supports these scanners Making Security Agile 23
- 24. BScan – Automation with Burp Making Security Agile 24 • Automates burp using Ruby extensions • Allows adding custom tests to the same scan • Can be run as simple as: jruby –S bscan –c config • Will generate report automatically when completed • Can work in auto proxy mode • Configurable – can overwrite any Burp and custom settings • Version 3.0 has been released on 10/2015 ! https://rubygems.org/gems/bscan/versions/3.0.0
- 25. BScan – Simple Config Making Security Agile 25 # BScan settings bscan.inactivity_to=20 bscan.issues=issues bscan.run_proxy=true bscan.report_url_prefix=https://www.google.com|google.xml bscan.report_url_prefix=https://www.whitehatsec.com|wh.xml bscan.report_def_name=report_all.xml bscan.ignore_info=false bscan.ignore_low=false # Burp Settings scanner.numthreads=10 proxy.interceptrequests=false #listen on port 8083 instead of standard 8080 proxy.listener0=1.8083.1.0..0.0.1.0..0..0..0.
- 26. BScan – Simple Run & Test with QA Regression Making Security Agile 26 jruby -J-Xmx1024m -J-Djava.awt.headless=true -S bscan -c bscan.conf -L 2 -l bscan.log & Aka QA regression: curl -k -x http://localhost:8083 https://www.google.com curl -k -x http://localhost:8083 https://www.whitehatsec.com
- 27. Security Transformation Cheat Sheet 27 From TO Two full days TM meetings with many people involved Participating in arch/design discussions through Confluence or other collab tools Very formal, “scientific” TM with DREAD, STRIDE residual risks, etc. Recommendations in JIRA coming from arch/design discussions DREAD, residual risks, etc. HML (High, Medium, Low) STRIDE CVE (usually automatically assigned by a tool) Manual pen testing for everything Selective pen testing for new features and products Expensive commercial scanners To OWASP ZAP, Burp, custom tools Docs and PDF reports, manual export to Dev bug tracking systems Exporting tickets directly to JIRA from Threadfix Running/uploading scans manually Automated batch jobs w auto-upload to Threadfix Making Security Agile
- 28. Returning to “Phoenix Project”- DevOps Implemented “I’m amazed at how quickly the Unicorn security fixes are being integrated,” he says. “Compared to the rest of Phoenix, fixing Unicorn security issues is a breeze. The cycle time is so short, we once put in a fix within an hour. More typically, we can get fixes in within a day or two. Compared to this, remediating Phoenix issues is like pulling our own teeth out, without any anesthesia. Normally, we’ d have to wait for a quarter for any meaningful changes to be made, and jumping through all the hoops required to get an emergency change order through was almost not worth the trouble. 28Making Security Agile
- 29. Summary: STOP wiring buttons that nobody will ever push © Lean Startup Conference - 2013 There is no “one size fits all” solution, which depends on your org and its culture. Try to change the mentality and remove quotes in “Love” between security, DevOps and others. Remember: coding along is not going to solve all your security problems Don’t forget about Security Artists, because security is just as politics – an art of possibilities and tools are very much useless without them. 29Making Security Agile
- 30. THANKS FOR COMING! Oleg Gryb A Human in Chief, Interested in Security Twitter: @oleggryb Linkedin: https://www.linkedin.com/in/ogryb 30Making Security Agile
Notas del editor
- I’m Oleg Gryb. I worked a couple of decades as a s/w developer before switching to pure security roles approximately ten 10 ago. I worked in 4 different countries in different kind of companies: well established technology, research and finance organizations, s/w development organizations in startup like environments. I’ve even created a couple of my own startups, but it was long time ago and in a different country. I work in Visa now, but I’ve been there for 4 months only and whatever I present today is not related to what I do at Visa. All thoughts are mine, so please treat them as such and don’t associate whatever I tell you today my current employer.
- I did this presentation a couple of time at pure OWASP security conferences, Lascon 2015 and AppSec California 2016, but today is a very special moment – I’m talking to DevOps people at RSA conference and feel obliged to talk a bit about DevOps movement from a security point of view. Before I start, I want to know how many of you are security engineers? How many of you consider themselves as DevOps engineers? How many of you consider themselves as both security and DevOps engineers? I’m sure, everyone read this book and wanted to remind you one quote related to security
- I will make it shorter, but the theme here is – DevOps look at security is mostly negative That “self-righteous demands” reminded me of a real feedback that our security team got from their peers once
- Aren’t we arrogant sometimes? Yes, we are, but the thing is – arrogance is not always bad as shown at the next slide All of that has a valid ground and can take extreme forms if instead of partnering with peers in their organization, security will try to police them only. Partnering is not such a simple things either. Sometimes rules need to be enforced fast, no matter how unhappy the peers are (think of compliance, critical issues or breaches that need to be stopped ASAP). Actually breaches, doesn’t matter how stressful and painful they are for the organization can be used efficiently by security. This is the moment of truth when everybody is willing to listen and to co-operate.
- Speaking of breaches, this is how DevOps looks sometimes from security point of view, so we’re very much even in settling our scores. The last status is what I call “the moment of truth” – this is when you get all their undivided attention and cooperation. I just wanted to demonstrate that it’s not only about technology and automation. Mentality and hostility between teams need to be changed before you can orchestrate DevOps and security in such a way that all work together and security is not a bottleneck anymore. Automation has a role to play in it. It has two parts: You need to implement it to catch up with a DevOps process, You won’t be able to implement it without working closely with DevOps teams. I will show how these two goals can be achieved
- I want to talk about security automation today and how to transform an old approach to security in such a way that it fits well to a contemporary agile SDLC, because your security process is just as good as its integration with the SDLC used by your DevOps team. Going back 5 to 7 years our SDLC model was still very much Waterfall and our security process was adjusted well to it: We had 2 full days for onsite interviews Business owners, s/w and DB architects, Dev, OPS, QA were available to sit with us for those two days and talk about security and threats We were buttoned up and very formal We’ve created our own scoring system based on DREAD We created Threat Models based on interviews, We categorized findings based on STRIDE, After TM was completed we would start our pen testing. We had 2-4 weeks to complete it! We used heavy commercial tools to do static and dynamic analysis
- I won’t talk much about DREAD, it’s very much dead and it’s dead because of a good reason. You were required to score each dread category, and it was a pure guestimate anyway. It looks scientific because it has categories, but is essence it’s worth than just assigning a score in simple HML terms, because HML is very intuitive and can be easily understood by everyone.
- STRIDE – again, looks scientific and cool, but that categorization is very abstract and it’s difficult to practically apply it, because some vulnerabilities will fall into several categories, while for others will be difficult to find a match for. When you use CVE, it’s actually something that has a match in real world, easy to understand and most importantly it will be automatically created by many scanners and understood by dashboard such as Threadfix. Maybe helpful for beginners but as you grow in security, see more real threats, you categorization model should change as well
- It was very much like a waterfall model, where we had a “security gateway” clearly defined. There was no way to by-pass It was clearly “us” and “them” model, meaning that our involvement to Dev matters or Dev involvement to our matters was limited. It required a significant time and money to support all that There was an essential lag between a sec assessment and a release date, which could result in big differences between production and what we’ve tested and reviewed. Fixing was not easy, “nagging” didn’t always work
- And then Big Bang has happened. It happened because everybody has moved to Agile SDLC and new projects started flying over our head with a huge velocity. We’ve realized at this point that we could not do all those cool things that we did in the waterfall model.
- We had no choice. We’ve started looking around trying to understand what tools and methodologies we can find to upgrade the security process and make it more agile. There were a lot of speculations and new ideas about how security can be transformed. An extreme point of view was that we just need to write a lot of code and all security problems will be solved. While I definitely see a lot of value in writing code to automate security and I’ll show it later, I don’t believe that it alone will solve all security problems. I’ll show you I think so in a moment.
- “Us” and “them” model didn’t work anymore. We need to move with the team at their pace. That’s a perfect example where you need to work closer with DevOps and QA to make sure that you orchestrate deployment and testing well, doesn’t matter if this is security or QA/Dev testing.
- On the top of this general requirements there could be others, platform and product specific, since many companies shifting their focus from building apps and UI’s to API’s, requirements coming from API becomes very important. You can write security test for each API and parameter combination using tools like GAUNTLT , but considering the number of API and different parameter’s combination it might not be feasible since security team is usually not that big.
- This is how we’d come to our solution. This is our reasoning.
- Explain diagram. Security team is not usually big, definitely ,much smaller than DevOps . QA team usually has thousands of QA unit tests that cover functionality well. Remember Security Challenges related to security API testing? Since QA has already resolved them partially, security can jump on this train and utilize for security testing.
- The most important thing here is port, which is used by QA regression tests to run their test cases
- You can scan several URL’s/applications an put results to different xml files You can provide different level of debug information Speed up testing by allocating more threads Assign a port number that Burp will listen to
- I did real time demo at other presentations, but don’t have time today. It works though and even for just this single request to a home page, it would find something and store in the configuration files. What it finds though would be most likely – false positives, which only confirms my point about necessity of security artists.
- This is my own security transformation cheat sheet. As you see the major items are not about writing the code, it’s more about changing the process and mentality. What remained unchanged here is a necessity to review the results and start working with developers on remediation. What we try to avoid are tools that generate a lot of false positives, because it creates road block for automation
- I’m not completely buying this. In general, the picture is not that rosy, yes short cycle makes security guys to jump through the hoops with the rest of the DevOps team, but it’s probably true only about simple, routine security bugs like XSS and such. When there is a need to stop the DevOps pipeline and do something fundamental like redesigning the whole authentication and authorization system, it’s still very difficult to get attention and time, so the approach here to continue “pinging” sponsors to get money/resources for fundamental security things and … wait for the next security breach at which point you will have their undivided attention
- I took it from a Lean Startup conference and I think it’s very appropriate for our sec transformation process. Sec as code is overstatement. You can’t solve all your security problems just by writing code. You need to do more than that. That sec automation job does include writing code, creating sec services and an agile security process, but don’t forget about “security artists” who can make sense of tons of data generated by scanners and other tools, because security is still very much like politics, which is an art of possibilities I’m still missing the old process a bit and ask myself often: did we through out any babies with bath waters during this transformation? The answer is probably “yes”, but this is the nature of any agile approach, it usually bears bigger risks, not only in security domain and we’ll have to live with it. Security artists are people who can make sense of ravings generated by security tools.