6. Security As Code: A New Frontier
→ RuggedSoftware.org
→ DevSecOps.org
[@/+]toddgrotenhuis
7. Rugged Manifesto
I am rugged and, more importantly, my code is rugged.
I recognize that software has become a foundation of our modern world.
I recognize the awesome responsibility that comes with this foundational role.
I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security.
I recognize these things – and I choose to be rugged.
I am rugged because I refuse to be a source of vulnerability or weakness.
I am rugged because I assure my code will support its mission.
I am rugged because my code can face these challenges and persist in spite of them.
I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.
[@/+]toddgrotenhuis
8. DevSecOps
→ Leaning in over Always Saying “No”
→ Data & Security Science over Fear, Uncertainty
and Doubt
→ Open Contribution & Collaboration over Security-
Only Requirements
→ Consumable Security Services with APIs over
Mandated Security Controls & Paperwork
[@/+]toddgrotenhuis
9. Security as Code
→ what all can you define in software?
→ what can you automate?
→ even "traditional" stuff?
→ even "non-boring" stuff?
[@/+]toddgrotenhuis
10. Rant Time
Do you like to talk about how old attacks continue
to work on customers?
This says at least as much about your effectiveness
as a consultant as it does about your clients'
effectiveness as an organization
(note: you are the common denominator)
[@/+]toddgrotenhuis
11. Strengthening the Weakest Link:
How to manage security vulnerabilities in 3rd party libraries used by your application
→ OWASP Dependency Check
→ Sonatype Nexus
→ Palamida
→ Black Duck Hub
→ Others
[@/+]toddgrotenhuis
12. → Use fewer and better suppliers
→ Use only the highest quality parts
→ Track what is used and where
→ Use repository managers over direct downloads
[@/+]toddgrotenhuis
13. Practical Application Security
Management:
How to Win an Economically One-Side War
→ costs are not just money, but time, people,
complexity
→ the business will always come first
[@/+]toddgrotenhuis
14. → actual sign-off from product owners on issues
reduces those that go through
→ satisfy people’s creative urges to make
→ security days: employees shadow for a day
→ reward reporting/submissions
[@/+]toddgrotenhuis
15. Delayed launch is a denial
of service
— Dheeraj Bhat
[@/+]toddgrotenhuis
16. The End of Security as We Know It:
why this might be a good thing
→ sometimes security is the only group with an
overall view
→ avoid “perfection complex”
→ MTTRemediate -> MTTRestore
→ “fuzz” non-technical things (e.g. processes)
[@/+]toddgrotenhuis
17. → Data Driven Decisions
→ Smaller Changes
→ Faster Failure
→ If It Hurts, Do It More
[@/+]toddgrotenhuis
18. Tool Requirements
→ sufficient logging
→ appropriate encryption
→ APIs / software definable / scriptable
→ test & abuse before purchase
→ take the bluecoat pledge
[@/+]toddgrotenhuis
20. Future Banks Live in the Cloud:
building a usable cloud with uncompromising security
→ security around money used to be physical
→ “extract value” as a better way of thinking about
attackers
→ empower engineers and help them choose
[@/+]toddgrotenhuis
21. Consensus-Based Deployment
1. anyone can propose a change
2. a non-involved party must approve the change
3. anyone can apply the change
[@/+]toddgrotenhuis
22. No one person should be
able to “accidentally the
company”
— Rob Witoff
[@/+]toddgrotenhuis
24. Doing AppSec at Scale:
taking the best of DevOps, Agile, and CI/CD into AppSec
→ AppSec Pipeline
→ Gauntlt
→ Threadfix
→ Bag of Holding
[@/+]toddgrotenhuis