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
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

16. # GoLive (SDLC FinalSecurityReview)
• 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 (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

18. # DevOps

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!

22. #FIN
alexey.sintsov@here.com @asintsov