In the agile, lean, devops communities people talk about improving security by "shifting left". Patterns and tools are emerging, or re-emerging, that make security less of a pain in the development process while also making applications more secure.
1. <<
Shift Left Security
What the funk does that mean?!
DevOps & Cloud Meetup 2018-11-28
Gérard de Vos
gerard@deplica.com
@gerardthefox
2. @gerardthefox
/me
Gérard de Vos
gerard@deplica.com
Systems Engineer ( DevOps Engineer :/ )
Wearing the security hat: security engineer, security lead, team lead.
or just running stuff on the internet...
Online & regulated environments
DevOpsDays Amsterdam community
Employers/clients: ING, Rabobank, Travix, LeasePlan, Schuberg Philis, Shell
5. @gerardthefox
Why shift left? What is wrong on the right?
● Unnecessary work and rework because of late discovery of defects
● Testing is far removed from design and build and things get obfuscated
○ Designs without adequate security considerations
○ Defects slipping through
● The further along, the costlier it gets to change anything
● Because of these higher costs cuts are made:
○ Less thorough testing. Even more defects slip through
○ "Accepted" risks that don't react well on contact with the real world
● And this happens when everyone is still sharing the same goals
○ Never mind what happens when varying departmental, team, and personal objectives kick in
9. @gerardthefox
Two worlds:
1. Security is a quality attribute
and as such an integral part of requirements, design, development, QA,
deployment, operations, production, etc.
2. Security is a speciality
and as such the domain of the Chief (Information) Security Officer, security
department, security testers, risk managers, auditors, etc.
10. @gerardthefox
World #1 - Security as quality
1. Everyone's job
○ Maybe a little more of leads, seniors and managers than of juniors but still everyone
2. Every day
13. @gerardthefox
Version Control. X-as-code
Everything in VCS, merge with approvals:
● Application code
● Infrastructure code
○ Terraform, CloudFormation
Ansible, Chef, Puppet
● Tests
● Documentation
● Designs
14. @gerardthefox
Static code analysis
Scan your code for known vulnerabilities / weak patterns
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
CWE https://cwe.mitre.org/
SANS Top 25 (of CWE weaknesses) https://www.sans.org/top25-software-errors
OWASP Top 10 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
16. @gerardthefox
Dependency checker
Check for known vulnerable (3rd party) libraries
OWASP Dependency Check
https://www.owasp.org/index.php/OWASP_Dependency_Check
Loads of language specific tools
$ npm audit
17. @gerardthefox
Web application scanner
Scan your application as it runs in test/acc/prod, where test/acc closely resembles prod
Cross site scripting (XSS)
SQL injection (SQLi)
Security misconfigurations
Basically OWASP Top 10 again
OWASP Zed Attack Proxy, ZAP
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Burp Suite, Arachni, nmap, etc.
https://en.wikipedia.org/wiki/Web_application_security_scanner#Listing_of_Vulnerability_Scanners
18. @gerardthefox
Functional tests / Unit tests
Not just happy path testing
● Sad path
● Bad path, aka evil path. Anti-personas
https://github.com/minimaxir/big-list-of-naughty-strings
https://www.cypress.io/
21. @gerardthefox
Security as stakeholder
● Security officer and security department are customers and stakeholders
○ Security requirements are product requirements
○ Security items are put in product backlogs, planning, demo
○ Security dept use the same tools and processes as "normal" stakeholders
Same ticketing system, not own risk mgt tool
○ New items are specific
ie. not a ticket with "security scan result, please check this 1200 page PDF and reply"
more like "https://endpoint123/ tests vulnerable to CVE-2014-160 (Heartbleed)"
22. @gerardthefox
Security as facilitator
● Security officer and security department are facilitators
○ Teams are responsible for their own security, and like some help
○ Help teams embed security in daily activities
○ Make the secure way the path of least resistance
23. @gerardthefox
Risk management through change management
● Changes & Change Advisory Board
○ Standard
Pre-approved, no CAB when ...
○ Normal
Approval through CAB
○ Emergency
Move mostly to Standard
24. @gerardthefox
Security as speciality
● Security dept delivers expertise, tools and services to other teams
○ Requirement and design help
○ CI/CD tools & services
○ Secrets management (certificates, keys, credentials)
○ Infrastructure scanning
○ Application scanning
○ Logging
○ Metrics
○ Incident detection
25. @gerardthefox
Requirements and design
OWASP Security Knowledge Framework
https://www.securityknowledgeframework.org/
OWASP Cheat Sheets
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
Help teams with the context specifics
26. @gerardthefox
Secrets management
For the things you definitely do not want in Git
Credentials, certificates, keys
AWS Systems Manager Parameter Store
KMS
Hashicorp Vault
Keywhiz
27. @gerardthefox
Infrastructure and application scanning
"Lightweight": ZAP, Nessus
Heavyweight:
● Metasploit
https://www.metasploit.com/
● Pentesting
● Blue team / Red team
● Stuff you learn at HXX, SHA, CCC, EMF
28. @gerardthefox
Logging & metrics
Make production logs and metrics available to developers.
Dashboards, screens
Interesting security wise:
● 500 internal server error. Can be vulnerability scanning
● Database error. SQL injection / scanning
● "UNION ALL" input. SQLi
● Logins, successful vs failed
● User passwd resets
● User email address resets
29. @gerardthefox
Auditing
● Use the output, logs, of the everyday tooling as much as possible
Git change logs, CI/CD, app logging
● Add to or change the logging of the tooling to satisfy audit requirements
32. @gerardthefox
Would you like to know more?
On the web:
- Rugged DevOps
- DevSecOps / SecDevOps
- Plain old DevOps
https://devopsdays.org
https://devopsdays.org/events/2019-amsterdam
https://www.owasp.org/
https://continuousdelivery.com/
33. @gerardthefox
Challenges
● How do we make security part of daily activities?
The software tools are the easy bit
When not appreciated / rewarded / goal?
When features always get priority? (and security is not seen as a feature)
● How can security folk / dept turn into facilitators?
Being more hands-on after years of spreadsheet management
Gain know-how on CI/CD, automation, or even just able to read code
Create self-service tooling & expert knowledge delivery
Run services like code analysis, scanners, logging, metrics
Help build and run secure-platform-as-a-service
34. @gerardthefox
What did I miss?
What tool / process / way of working?
What do we do with the security department? Or the developers?
<<
Should I put something in on how on little-endian cpu architectures a shift left doubles the value?
<<