Downloaded 15 times
Uploaded byDefconRussia
Alexey Sintsov- SDLC - try me to implement
This document discusses implementing security best practices within an agile software development lifecycle (SDLC). It recommends that security requirements and testing be integrated into each sprint or iteration. The security team would provide requirements, guides, tools, and training to development teams. They would conduct a final security review before software releases. DevOps practices could help automate security processes and configuration of cloud platforms. The overall approach is to distribute security responsibilities to development teams with support from the centralized security team.
More Related Content
![Eloi Sanfelix - Hardware security: Side Channel Attacks [RootedCON 2011]](https://cdn.slidesharecdn.com/ss_thumbnails/esanfelix-sidechannelattacks-110307125844-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DCG 25] Александр Большев - Never Trust Your Inputs or How To Fool an ADC](https://cdn.slidesharecdn.com/ss_thumbnails/presentationdefconrussia-160406215741-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Alexey Sintsov- SDLC - try me to implement
![[Defcon Russia #29] Михаил Клементьев - Обнаружение руткитов в GNU/Linux](https://cdn.slidesharecdn.com/ss_thumbnails/revealingrootkitsv5-170328122611-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Defcon Russia #29] Александр Ермолов - Safeguarding rootkits: Intel Boot Gua...](https://cdn.slidesharecdn.com/ss_thumbnails/intelbgpart2-170328124242-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Defcon Russia #29] Алексей Тюрин - Spring autobinding](https://cdn.slidesharecdn.com/ss_thumbnails/springautobinding-170328123002-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Defcon Russia #29] Борис Савков - Bare-metal programming на примере Raspber...](https://cdn.slidesharecdn.com/ss_thumbnails/preza-170328124723-thumbnail.jpg?width=640&height=640&fit=bounds)
![SHS_Core_CAE_Q3_LE1 FOR THIRD [FINAL].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/shscorecaeq3le1final-251116055110-e3081055-thumbnail.jpg?width=640&height=640&fit=bounds)
Alexey Sintsov- SDLC - try me to implement
- 1. Alexey Sintsov @asintsov DEFCON RUSSIA DC#7812 SDLC IMPLEMENT ME OR DIE
- 2. # SDLC… --History, introduction and blah-blah-blah skipped -- HOWTO: • Secure design • Secure code • Stable product • … QUALITY => Happy users/customers
- 3. # Stages (c)Microsoft Corp.
- 4. # But… •Agile • Agile • Agile • …. Every Sprint Bucket Once (c) Microsoft Corp.
- 5. # Agile WhySDLC? • Documentation • Testing • Tasks It’s already included! Just add ‘Security requirements/tests’. • Development through testing • Unit tests • Continues Integration • Acceptance tests
- 6. User wants toregister his account through web-form with login/password Task 1 Create DB structure Task 2 Add UI form Task 3 Add API for creating account Task X … Security Requirements Security Guides Retrospective Store passwords secure (crypto. Req.) CSRF protection ClickJacking protection CAPTCHA SQLi protection Password req. … etc … Security related tasks
- 7. Security Requirements SecurityGuides Retrospective User wants to register his account - investigation RISK ANLYSES User wants to register his account through web-form with login/password Task 1 Create DB structure Task 2 …. Task X Add second factor auth. mechanism Security “things” – tasks can be better than stories!
- 8. # Wow it’sso easy… Let’s do it… • Online services • API • Mobile Apps • Automotive • Many different teams • Different frameworks and languages • Different attack surfaces and threats and risks • Agile • DevOps
- 9. # Impossible ??? SDLC – not a strict “standard”, use it as pack of practices or what can be done, but HOW it can be done – it’s real state-of-art. So… • More security things goes to dev teams (responsibility) • Maximum automation • Manuals, guides and tools can be done by SecTeam • And etc: any fun can be done if it helps….
- 10. # Training •Internal events • External training sessions Impossible to cover all threats, bugs and etc, especially if you have different teams that work with different technologies • HERE Architecture and Technology camp • Typical issues, stories and best practices • HOWTO • CTF games • HERE security support: • WIKI • IRC • Personal team trainings
- 11. # Security Requirements General requirements: • Code style • SQL requests (Prepared statements) • Input/Output validation • Mobile App req. • etc • Data encryption • Algorithms • PKI and etc • Security mitigations and mechanisms • HTTPOnly, X-Frame-Options • PIE, StackCanaries, NS bit… … and etc Based on General requirements, each team produce own list of req. and then tasks!
- 12. # Guides Patterns/Guides: • Code Based on guides each team will code some general things with our security requirements. • How to do auth. with captcha • How to read/upload files (work with FileSystem) • etc • Sensitive data • How to do right logging • How to store personal data • What is personal data • DevOps • How to deploy product with secret keys/service passwords ….
- 13. # SelfCheck lists Based on requirements we can provide more detailed self-check lists to teams: • Have you done SAST? • What hash alg do you use for storing passwords? • Are you logging auth. tokens/passwords/credit card numbers? • Do you have SSL? • Do you have HTTPOnly/Secure? • Is your service scanned by security scanner? - Different check lists of Dev/DevOps, for design and architecture.
- 14. # Example ofModel SecTeam Project Team 1 Project Team 2 Requirements Guides Tools produce • Requirements • Documentation • Design • Code • Security Tests • Requirements • Documentation • Design • Code • Security Tests checks “SDLC” on AGILE Final Review Exploratory testing Anything else…
- 15. # HERE SecurityTeam • Requirements • Guides • Support for all Dev teams • Developing security tools and libs • Fuzzers • Input validation lib for common frameworks • Security Scripts, like platform audit • Providing SecService to teams and work with vendors: • WhiteHat • Retina • Veracode service • etc… • GoLive review • Incident Response
- 16. # GoLive (SDLCFinalSecurityReview) • Threat/Risk Analysis • Architecture security review • SAST • Encryption • Design, etc • Engineering security review • DAST • Configurations • Logs , etc • Privacy review • Personal data • Government requirements , etc • Business continue review
- 17. # GoLive (SDLCFinalSecurityReview) What we want • Teams understand our security requirements • Teams produce their own security requirements to their product • Teams follow our guides • Teams provides documentation, answered self-check lists Teams runs all security and can do self checks • Security knowledge stay in teams • After each GoLive review one team became more aware about security
- 18.
- 19. # DevOps +SDLC • Deployment as part of security process • Platform and configuration as a part of final product PRODUCT OS Services Code
- 20. # HERE PlatformSecurity as a part of SDLC With help of DevOps: Own Cloud platform with all security things • Box configured secure by default: • SSH • Apache • Iptables • Patch Management for packages • Monitoring system • WAF • etc • Latest Images • Control for security groups • MFA • Templates for all accounts • CloudTrail • Access Key rotation • Security scanning for all instances • etc + MAXIMUM AUTOMATION
- 21. # SoWhat •SDLC – not a kind of “standard” = just bunch of ideas and practices • You can’t download it and use, you need to understand your env., business requirements and implement what you want in any way it will work. • More checks and responsibilities for Dev. site. • Agile have enough places for implementing ‘security’, you do not need to change something, but it requires more knowledge from teams • SecTeam – control, hack, develop sec tools and support Devs • DevOps – can be a big help for security process!
- 22.
Editor's Notes
- #3 СДЛЦ это – блабла кратко. Майкрософт конечно молодец, но не вдаваясь в детали о том, кто первый додумался о том, что о безопасности продукта нужно беспокоится на всех стадиях разными методами, давайте посмотрим зачем нам вообще СДЛЦ, прежде чем идти дальше. Мы хотим, что бы наш продукт был крутым, безопасным, стабильным и при это пользователи были довольны, в общем и целом эти вопросы, включая вопросы безопасности – это вопрос КАЧЕСТВА. То есть безопасность это одна их характеристик качественного продукта. Это спорное утверждение, но оно становится справедливым, если безопасность является одним из критериев определения «качественный продукт»
- #4 Тут все понятно, в разработке есть шаги, на каждом шаге можно и нужно делать нечто крутое и полезное. Но…
- #5 Это круто в теории, но на практике очень сложно, в основном из того, что современные методологии они все такие Скам и аджаил.. Хотя теже МС выпустили доку, как можно это все прикрутить и к аджайлу… но опять же, все в теории. К тому же, код это одно, а если мы говорим про тех кто пишет сервисы, АПИ всякие причем много и разного… то есть сложности
- #9 Ну ок, раз МС говорит это просто и круто. Давайте прикинем… Опа, да у нас ж дофига всего и разного… а нас, секурити не так много…
- #10 Все не просто, но если подойти к СДЛЦ не как к бумажному стандарту набору практик, а как к идеи, то можно реализовать многие вещи и действительно повысить качество продуктов…