4. # But…
• Agile
• Agile
• Agile
• ….
Every Sprint Bucket Once
(c) Microsoft Corp.
5. # Agile
Why SDLC?
• Documentation
• Testing
• Tasks
It’s already included! Just add ‘Security requirements/tests’.
• Development through testing
• Unit tests
• Continues Integration
• Acceptance tests
6. User wants to register
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
Security Guides
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’s so 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 of Model
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 Security Team
• 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
17. # GoLive (SDLC FinalSecurityReview)
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
19. # DevOps + SDLC
• Deployment as part of security process
• Platform and configuration as a part of final product
PRODUCT OS Services Code
20. # HERE Platform Security 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!
СДЛЦ это – блабла кратко. Майкрософт конечно молодец, но не вдаваясь в детали о том, кто первый додумался о том, что о безопасности продукта нужно беспокоится на всех стадиях разными методами, давайте посмотрим зачем нам вообще СДЛЦ, прежде чем идти дальше.Мы хотим, что бы наш продукт был крутым, безопасным, стабильным и при это пользователи были довольны, в общем и целом эти вопросы, включая вопросы безопасности – это вопрос КАЧЕСТВА. То есть безопасность это одна их характеристик качественного продукта. Это спорное утверждение, но оно становится справедливым, если безопасность является одним из критериев определения «качественный продукт»
Тут все понятно, в разработке есть шаги, на каждом шаге можно и нужно делать нечто крутое и полезное. Но…
Это круто в теории, но на практике очень сложно, в основном из того, что современные методологии они все такие Скам и аджаил.. Хотя теже МС выпустили доку, как можно это все прикрутить и к аджайлу… но опять же, все в теории.
К тому же, код это одно, а если мы говорим про тех кто пишет сервисы, АПИ всякие причем много и разного… то есть сложности
Ну ок, раз МС говорит это просто и круто. Давайте прикинем…Опа, да у нас ж дофига всего и разного… а нас, секурити не так много…
Все не просто, но если подойти к СДЛЦ не как к бумажному стандарту набору практик, а как к идеи, то можно реализовать многие вещи и действительно повысить качество продуктов…