Agile Appsec 2013 Building Real Software

Agile AppsecCAMUG 2013

Agile Appsec 2013 Building Real Software

Why we Suck at Building Secure Software…

CAMUG 2013

Agile Appsec 2013 Building Real Software

and what we can do about it…

CAMUG 2013

Agile Appsec 2013 Building Real Software

Or… CAMUG 2013

Agile Appsec 2013 Building Real Software

How Agile Development is a major Cause of today’s Insecure Software…

CAMUG 2013

Agile Appsec 2013 Building Real Software

and how Agile Development can be the Cure too

CAMUG 2013

Agile Appsec 2013 Building Real Software

◦ Jim Bird◦ A software guy that cares about security◦ Experience in software development, Ops, general

management, project management (PMP, CSM, PMI-ACP, SCPM)

◦ Worked with financial services organizations in more than 30 countries

◦ Consulted to IBM, Italian Banking Association, Deutsche Borse, Korea Exchanges, Australian Stock Exchange, …

◦ Currently co-founder and CTO of a major US-based institutional trading service

◦ Helps out at SANS and OWASP◦ “Building Real Software” blog◦ Find me on LinkedIn

About the Author

Agile Appsec 2013 Building Real Software

Lots of information to follow No pictures of puppies, kittens, babies or

Star Trek characters Stuff you can take away and use later

Warning

Agile Appsec 2013 Building Real Software

As an industry we suck at building secure software

Most developers don’t understand software security (take the test and see how you do) https://www.aspectsecurity.com/news/press/press-release-aspect-security-launches-free-tool-to-measure-gaps-in-developers-application-security-knowledge/

and we don’t include security in development ◦ Microsoft study 2012: Only 37% of developers follow

secure development practices ◦ Ponemon Institute study 2012: 79% of developers

followed no or only ad hoc secure development process

The Problem

Agile Appsec 2013 Building Real Software

Many security experts think that Agile is the problem◦ Agile Development = Security Fail, Adrian Lane, RSA

Conference 2011 http://vimeo.com/15505840◦ Agile development is seen in some big shops as being

undisciplined and unmanaged◦ 2010 Study: Agile teams did not take meaningful steps

to integrate security into development even when security was a mandated requirement http://www.igi-global.com/article/agile-software-development/46153

Agile development makes it easier to build more software faster. More software = more vulnerabilities

Agile AKA “the A Word”

Agile Appsec 2013 Building Real Software

Major security vulnerabilities are found in common desktop software each month: Windows, Java, Adobe, all of the browsers, Quicktime, …

InformationWeek 2013 Strategic Security Survey◦ 46% of breaches last year were due to software exploits

(OS, mobile or other application) New technologies like HTML 5 and node.JS

introduce new capabilities and new security risks http://www.darkreading.com/applications/beware-of-html5-development-risks/240156891 https://www.owasp.org/images/3/31/Node.js_Security_Old_vulnerabilities_in_new_bottles_-_Sven_Vetsch.pdf

We Suck at Building Secure Software

Agile Appsec 2013 Building Real Software

2013 Verizon Data Breach Investigations Report: ◦ 1/3 of all breaches are caused by attacks on Web apps◦ Probability of being hit by a Web app exploit: 75%

Cenzic Report 2013◦ 99% of apps tested had at least 1 serious vulnerability

WhiteHat Security Report 2013◦ Average Web app has 56 serious vulnerabilities◦ 25% of organizations had at least 1 security breach caused

by an application vulnerability Veracode State of Software Security April 2013

◦ Only 13% of Web apps passed OWASP Top 10 (the most common vulnerabilities)

◦ These are apps that people bothered to test…

We Suck at Building Secure Web Apps

Agile Appsec 2013 Building Real Software

viaForensics Mobile App Security Study 2011 Only 17% of apps passed basic tests 10% of apps stored passwords in plain text In 2/3 of apps, private or sensitive data was recoverable

(private communications, personal data, acct numbers) Veracode State of Software Security Report 2013

64% of Android apps have crypto problems 42% of iOS apps have information leakage problems 31% of iOS apps have SQL injection bugs

Ponemon Survey 2012 65% of mobile apps aren’t tested at all

We Suck at Building Secure Mobile Apps

Agile Appsec 2013 Building Real Software

Hacking Industrial Systems Turns out to be Easy, MIT Technology Review, Aug 2013 http://www.technologyreview.com/news/517731/hacking-industrial-systems-turns-out-to-be-easy/

Backdoor in computer controls opens critical infrastructure to hackers, Oct 2012 http://arstechnica.com/security/2012/10/backdoor-in-computer-controls-opens-critical-infrastructure-to-hackers/

Researchers expose flaws in popular industrial control systems, InfoWorld, Jan 2012 http://www.infoworld.com/d/security/researchers-expose-flaws-in-popular-industrial-control-systems-184629

We Suck at Building Secure Industrial Control Systems

Agile Appsec 2013 Building Real Software

Smart toilet security flaw could result in nasty surprise, Fox News Aug 2013 http://www.foxnews.com/tech/2013/08/05/smart-toilet-security-flaw/

The same security risks are in today’s cars, smart homes, TVs, …◦ http://arstechnica.com/security/2013/07/disabling

-a-cars-brakes-and-speed-by-hacking-its-computers-a-new-how-to/

Hacking airplanes in flight? I did that a year ago…, April 2013 http://www.foxnews.com/tech/2013/04/12/hacking-in-flight-airplane-did-that-year-ago-hacker-says/

Cars, TVs, Toilets, Airplanes…

Agile Appsec 2013 Building Real Software

Lack of Knowledge and Skills – Developers Don’t Understand Security

Fundamental Asymmetry – the Bad Guys always Win

Quality – Bad Software is Easy to Hack

The Root Causes

Agile Appsec 2013 Building Real Software

Not firewalls, DMZs and patching Not just security features: authentication, access

control, auditing Thinking through workflows and exceptions like a bad

guy (abuse cases not use cases) Understanding security risks and weaknesses in your

language and platform stack Technical details that must be understood and

executed perfectly: ◦ crypto, session management, language/platform-specific

vulnerabilities and attacks and exploits, secure configuration, context-sensitive data encoding, race conditions (TOC/TOU),…

Developers don’t Understand Security

Agile Appsec 2013 Building Real Software

Education and Knowledge Gap◦ Almost no universities teach software security◦ Most developers don’t get enough – or any – on

the job security training (Ponemon Study, 2012)◦ Leading books/blogs/conferences on software

development and design do not touch on security◦ Agile 2013 conference example:

1800 people, 200+ sessions 1 session on application security (attended by 30 people) Agile 2013 Eventifier was hacked

Developers don’t Understand Security

Agile Appsec 2013 Building Real Software

Most security people are network infosec (CISSP), or auditing/compliance/risk

They can’t help developers with appsec Critical worldwide shortage of appsec

expertise: Breakers and especially Builders http://www.appsecireland.org/wp-content/uploads/2012/09/7-Ways-to-Scale-Web-Security-Jeremiah-Grossman.pdf◦ 17 million developers worldwide◦ BSIMM says 2% of developers need to be security

black belts = 340,000 need advanced appsec training

Security don’t Understand Development

Agile Appsec 2013 Building Real Software

Software Security is an Asymmetric Problem Michael Howard, 8 Simple Rules for Developing More Secure Software http://msdn.microsoft.com/en-us/magazine/cc163518.aspx

Developers must make sure that design and code are perfect

Attackers get in through mistakes and bugs that nobody understands or realizes are important (eg. C/C++ bounds violation)

1 Bug is all that the bad guys need

Attacker’s Advantage, and the Defender’s Dilemma

Agile Appsec 2013 Building Real Software

Ensuring that there are no critical security problems in software is very very hard

With enough money, time and talent (e.g., nation-state backed) targeted attackers can get into any system

But we are making it too easy for the lazy bad guys (opportunistic hackers)

Too many security bugs are too easy to find and exploit… even bugs that are easy to fix and prevent

Attacker’s Advantage, and the Defender’s Dilemma

Agile Appsec 2013 Building Real Software

The most common attacks stay the same year over year (XSS, CSRF, Directory Traversal ../, SQL Injection)

SQL injection ◦ The most dangerous security vulnerability for the past

5+ years http://cwe.mitre.org/top25/index.html◦ Easy to fix – use prepared statements and bind variables◦ NOSQL databases have injection vulnerabilities too

http://blog.fortify.com/blog/2011/04/27/ Bad guys use SQLi to steal data like email addresses

and passwords – which programmers don’t store safely◦ http://www.mnn.com/green-tech/computers/stories/450000-p

asswords-stolen-in-yahoo-data-breach◦ http://www.zdnet.com/over-21000-plain-text-passwords-stolen

-from-billabong-7000000842/

Attacker’s Advantage, and the Defender’s Dilemma

Agile Appsec 2013 Building Real Software

Security = C-I-A ◦ Confidentiality◦ Integrity◦ Availability

All of these are also important factors to Software Quality

“Software security relates entirely and completely to quality. “ Dr. Gary McGraw

A poor quality system cannot be secure Security vulnerabilities are bugs that need to be

eradicated like all the other bugs

Security <> Quality, but…

Agile Appsec 2013 Building Real Software

Agile: the Security Problems

CAMUG 2013

Agile Appsec 2013 Building Real Software

Agile is about building software quickly◦ Move fast and iterate, respond to feedback ◦ Emphasis on Velocity: how much Business Value

is delivered every 1 or 2 weeks◦ Short time boxes keep getting shorter (1-month,

2-weeks, 1-week, …)◦ Deliver software to customer before it is finished◦ Taken to extreme by teams following Continuous

Deployment pushing changes 10-100+ times per day (Facebook, Twitter, Linkedin, …)

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

When is “Fast” too Fast?

Agile Appsec 2013 Building Real Software

“Move fast and break things. The idea is that if you never break anything, you’re probably not moving fast enough.” Mark Zuckerberg, Facebook ◦ http://www.straight.com/life/carol-todd-asks-facebo

ok-fix-security-failures-putting-kids-risk◦ http://www.zdnet.com/facebook-admits-failure-in-b

ug-report-7000019657/◦ http://www.thetechherald.com/articles/More-securit

y-failure-as-Phishing-attacks-return-to-Facebook/6017/

◦ http://grahamcluley.com/2013/06/facebook-owns-privacy-breach-tells-world-late-friday-night/

◦ http://www.dailymail.co.uk/news/article-2396628/Mark-Zuckerbergs-Facebook-page-hacked-Khalil-Shreateh-expose-site-vulnerability.html

◦ http://thehackernews.com/2013/09/vulnerability-allowed-hacker-to-delete.html

◦ ….

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Emergent Design◦ 50% of security problems are caused in design (Gary

McGraw, Cigital)◦ De-emphasis on architecture definition in Agile

(BDUF is B-A-D)◦ Only design and build what you need (Simple

Design, YAGNI, Minimum Marketable Feature)◦ Refactor and react to feedback – design on the fly

◦ The Code is the Design - so how do you see design mistakes and oversights? You wait to get feedback from the customer… or from hackers….

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

The Product Owner is King/Queen◦ Defines requirements, decides what gets done when◦ Under pressure (and pressures team) to deliver

Business Value, Time-to-Market◦ The Product Owner has too much Responsibility:

Doesn’t always understand what they are supposed to do, or have the time to do it properly

Doesn’t understand security beyond mandated compliance requirements in regulated environments

Doesn’t always understand the risks and threats facing the organization

Doesn’t understand software development

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Security is a Chicken, not a Pig◦ Only Pigs have a voice – Product Owner, the Team◦ Pigs decide how software is going to be developed◦ Security is on the outside looking in – a Chicken, a

witness, a nag who can be ignored or pushed off to later

◦ Without explicit security gates/approvals, Security has no control over how work gets done or over priorities or outcomes

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Whole Team and Collective Code Ownership Everybody shares all the work and all the code The Team decides how work will be done – will

they decide to include secure development practices?

Security work requires special knowledge and a Hacker’s/Breaker’s mindset

Remember the Defender’s Dilemma – even small mistakes have serious consequences

You need your best (technically strongest) people working on security – not everybody will “get it” or will be careful enough

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

XP has reinforced the value of testing, but…◦ TDD, automated unit testing (JUnit) and functional

acceptance testing (FIT, FITNesse) – “the feature passes the automated tests, so it must work”

◦ Security is a system testing problem, not a unit testing problem

◦ Many teams don’t have testers, or testers who do anything more than follow acceptance checklists – so who will do security testing? “Why Facebook doesn’t have or need testers” http://www.zdnet.com/blog/facebook/why-facebook-doesnt-have-or-need-testers/7191

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Sprints and Time Boxes Work needs to be done in little pieces and

time-boxed (smaller = better) Where do you fit security reviews and testing

in Scrum or iterationless Kanban or Continuous Deployment?

E.g. Penetration Testing doesn’t fit nicely into a short Sprint – need time to understand the app, explore, hack, assess risk and understand findings, fix and test again…

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Work is defined through Stories As a <type of user> I want <something> so

that <reason> Most security requirements are non-functional

(like maintainability, supportability) http://www.infoq.com/articles/managing-security-requirements-in-agile-projects

Security risks and activities cut across many stories (constraints on design and implementation)

Cannot always be tested (same as other NFRs) Security is never “Done”

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Traceability and Assurance◦ Waterfall has natural gates (requirements, design,

code, test, deploy) and hand-off documents for security experts to review and assess risk

◦ But Agile: “working software over comprehensive documentation”

◦ Story cards, white boarding, … “barely sufficient” and discarded when work is done

◦ Code and automated tests are the documentation How do you prove traceability in Agile? How do you

know (and show) that you’ve done a responsible job?

The Security Problems in Agile

Agile Appsec 2013 Building Real Software

Agile: the Security Solution

CAMUG 2013

Agile Appsec 2013 Building Real Software

Security Stories and Abuse Cases◦ Make security activities/risks part of the backlog◦ SAFECode Security Stories – common non-

functional stories and SDLC tasks for security http://www.safecode.org/publications/SAFECode_Agile_Dev_Security0712.pdf

◦ OWASP Evil User Stories: “As a hacker, I can send bad data in URLs, so I can access data and functions for which I’m not authorized” https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories

◦ Cigital Abuse/Misuse Cases – think like a bad guy http://cigital.com/papers/download/bsi2-misuse.pdf

Adding Security to Agile

Agile Appsec 2013 Building Real Software

Abuser Stories◦ Judy Neher, Agile 2013◦ As part of working on / elaborating a story, take

some time to explore negative cases◦ Don’t just think about what the user can do and

wants to do◦ Think about what the user can’t do and doesn’t

want to do◦ Write up negative cases/scenarios and include

them in scenarios or add them to the backlog

Adding Security to Agile

Agile Appsec 2013 Building Real Software

Security Sprint / Security Push◦ Test and fix security problems in high-risk areas (as

much as you can in a time box)◦ Train the team, then have them look for and fix

security vulnerabilities◦ Evaluate a static analysis tool, run it for the first time

and triage the results◦ Pen test and then fix what you can before you go live

Band aid: won’t solve your security problems Like a “Hardening Sprint” - difficult to build a

business case for – what value is the customer getting?

Adding Security to Agile

Agile Appsec 2013 Building Real Software

Try following Microsoft: SDL Agile◦ Available for free but expensive to follow

http://msdn.microsoft.com/en-us/library/windows/desktop/ee790621.aspx

◦ Integrate security activities and controls Start of project – understand security and privacy

requirements, training, assign security lead Each Sprint – using safe libraries, static analysis in

CI, threat/risk modeling on new features Bucket – code reviews, design reviews, incident

response planning (do one of these activities each Sprint)

Build Security In

Agile Appsec 2013 Building Real Software

Upfront, Iteration 0 stuff◦ Understand major risks and threats◦ Understand requirements for security and privacy,

compliance – don’t depend only on Product Owner◦ Include security in coding guidelines and

tools/technology selection◦ If you’re playing Pigs and Chickens, security must

be a Pig – make someone the Security Lead◦ Include time for security tasks in planning,

retrospectives/reviews and “Definition of Done”

Build Security In

Agile Appsec 2013 Building Real Software

Training◦ WhiteHat study: teams with training have 40% fewer

vulnerabilities, resolve them 59% faster◦ Train all developers and testers in basics

SAFECode free training https://training.safecode.org/courses

Coursera free MOOCs in Crypto https://www.coursera.org/instructor/~85

OWASP Cheat Sheet series https://www.owasp.org/index.php/Cheat_Sheets

◦ Security Lead needs extra training: Denim Group, SANS, Cigital

◦ Don’t forget to train the Product Owner!

Build Security In

Agile Appsec 2013 Building Real Software

Design and Architecture◦Understand the security capabilities of your

framework (.NET, Rails, Play, Spring, Django, Yii, iOS, Android, …) Authentication and Identity Management Access Control (deny by default) Auditing (including log injection protection) Session Management (including CSRF protection) Data access layer (SQL injection)

◦Keep frameworks patched and up to date and monitor for vulnerabilities (serious Rails vulnerabilities in 2013, …)

Build Security In

Agile Appsec 2013 Building Real Software

Design and Architecture◦Use a security library to fill in security gaps:

OWASP ESAPI (for enterprise apps, especially Java) Apache Shiro (Java general security toolkit) JASYPT (Java encryption) Microsoft’s Anti-Cross Site Scripting library (.NET) IronBox AntiSQLi (.NET) OWASP Java HTML Sanitizer (XSS protection)

◦If you really know enough to write your own crypto, why are you here reading this slide?

Build Security In

Agile Appsec 2013 Building Real Software

Attack Surface◦ How bad guys get in: forms, fields, parms, cookies, files,

URLs, APIs, run-time args, configs, sockets, databases… and the code behind this

◦ As you add features, attack surface increases: Just changing the same code again, adding another field

or form…? Adding a new API, or a mobile interface, or hooking up to

a new service? Introducing a new piece of confidential/secret data? Changing the stack or plumbing (web server, security

library, back-end data store…)?◦ What additional testing/reviews should be done?

Build Security In

Agile Appsec 2013 Building Real Software

Follow the Data◦ Identify critical data

Private/confidential data (PII, credit card, medical, anything to do with children, financial, …), tokens/passwords/session ids and other credentials, secrets, config, …

◦ Follow this data through the system What is the source (is the source authenticated, can you tell if

the data is being replayed)? Where is it validated and sanitized? Where is it stored (does it have to be stored)? Should it be encrypted or masked? Where is it displayed and used, are the users authorized? Who can change it, is this access audited? Do I need to protect it with a checksum/digital signature?

Build Security In

Agile Appsec 2013 Building Real Software

Focus on High-Risk Code◦ Security plumbing, network-facing APIs, file

handling, command and control (root) functions, data validation, error handling, database access layer, auto-update, …

◦ If any High-Risk code is changed: review and testing must be done

◦ Team Ground Rule, or automatically through check-in monitoring (Etsy, Zane Lackey) http://www.slideshare.net/zanelackey/effective-approaches-to-web-application-security

Build Security In

Agile Appsec 2013 Building Real Software

Be Careful with High-Risk Code◦ Code in pairs (always at least one senior developer)◦ Use OWASP Secure Coding Checklist

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

Expert Security Code Review ◦ Bring in an outside expert/consultant◦ Help them to understand the code and design◦ Time-box their review◦ Make sure you understand what they found, why it is a

problem, and how to fix it◦ Maybe get them to review your fixes too

Build Security In

Agile Appsec 2013 Building Real Software

Write Code that “doesn’t boink”◦ Correctness and usability isn’t enough◦ Clean code isn’t enough – although it helps (security

and quality problems are correlated with complexity)◦ Use safe functions and APIs (understand your

language and platform and use them properly)◦ Pay attention to data validation (client-side isn’t

enough, strong white-list vs weak black-list)◦ Error handling and exception handling (check return

codes, fail closed, watch for information leakage)◦ Manage threads and memory carefully◦ Log and trace – but don’t log confidential/private data

Build Security In

Agile Appsec 2013 Building Real Software

Static Analysis Checkers (Source/Binary)◦ Start with picky Compiler options and flags, and IDE◦ Continuous Integration: Fail build on serious bugs◦ Java

Free: Findbugs and PMD (or SonarQube) – superficial but common security bugs

Expensive: Coverity, Fortify, Klocwork, Appscan, Checkmarx – deeper, interprocedural data flow and control flow analysis

◦ .NET Microsoft FxCop, CAT.NET, MS Source Code Analyzer for SQL

Injection, BinScope◦ PHP: RIPS◦ Ruby: Brakeman◦ Binary analysis (if you don’t have source): Veracode SaaS

Build Security In

Agile Appsec 2013 Building Real Software

Unit testing is not enough◦High unit test coverage for high-risk code to

ensure correctness – especially security features

◦Need negative tests for error handling and for input checking – tedious to do, maybe try fuzzing instead

◦Fuzzing files is easy (dumb), fuzzing APIs is hard (smart)

Also need end-to-end system testing

Build Security In

Agile Appsec 2013 Building Real Software

Manual exploratory testing◦Do some basic hacking on your own◦Test boundaries, negative cases◦Try injecting attack strings into fields◦Try to break things, be creative◦How to Break Software [and How to Break

Software Security], James Whittaker http://www.amazon.com/How-Break-Software-Practical-Testing/dp/0201796198 http://jpkc.sziit.edu.cn/software/www/st/courses/res/qiyeziyuan/eng/how_to_break_software.pdf

Build Security In

Agile Appsec 2013 Building Real Software

Application Pen Testing Hire an expert to hack into your app

◦Before go live◦Periodic Regression Sweep (1-2x per year,

or when you make a major change)◦Give pen tester whatever information and

access they need◦Learn from what they find – treat serious

bugs as Sev 1 or 2 But… Expensive and doesn’t Scale

Build Security In

Agile Appsec 2013 Building Real Software

Dynamic Web App Scanning – “Pen Tester in a Can”◦Arachni, Acunetix, Appscan, Webinspect, …

http://sectoolmarket.com/◦OWASP ZAP (Attack Proxy)

https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

◦Hassle to setup, train, review and triage◦Most developers don’t like using these tools, but QA

usually doesn’t have the technical skills

◦Consider Cloud-based service like WhiteHat◦Or Contrast Security (Java real-time bug tracing)

Build Security In

Agile Appsec 2013 Building Real Software

Gauntlt “Be Mean to Your Code” http://gauntlt.org/ ◦ Scriptable attacks against a system using

different security tools – built on Cucumber◦ Include in Continuous Integration or Continuous

Delivery pipeline◦ Limited number of tests available today

Mozilla Minion◦ Plug-in platform for automated testing web apps

https://blog.mozilla.org/security/2013/07/30/introducing-minion/

Build Security In

Agile Appsec 2013 Building Real Software

Remediation◦ WhiteHat study: only 61% of security bugs are

fixed, and it takes 193 days to fix them◦ Remember the Attacker’s Advantage – we’re

leaving holes open for a long time ◦ Treat security vulnerabilities like other bugs

Add them to the backlog Fix critical bugs Fix bugs you understand

◦ Use Agile to your Advantage: Agile teams can get fixes into production much faster than Waterfall

Build Security In

Agile Appsec 2013 Building Real Software

Secure Operations◦ Your responsibility doesn’t end with releasing

code◦ Secure the run-time – CIS and vendor lockdowns,

Nessus scanning, check SSL config (ssllabs)◦ WAF or IDS (mod_security, Snort)◦ Always be patching◦ Detective change control – OSSEC◦ Infrastructure as Code (Puppet, Chef) so you know

everything is setup consistently◦ Make sure somebody is actually reading the logs

Build Security In

Agile Appsec 2013 Building Real Software

Secure Devops – Learn from Etsy and Netflix◦ Understand what normal looks like, identify

anomalies/attacks, and respond◦ Fast, repeatable deployment capability so you can

fix problems immediately http://www.client9.com/2013/05/24/faster-secure-software-development-with-continuous-deployment/

◦ Automated health checks, self-tests, run-time asserts

◦ NetFlix Simian Army – Security Monkey, Conformity Monkey, Doctor Monkey, and Chaos Monkey/Gorilla http://techblog.netflix.com/2011/07/netflix-simian-army.html

Build Security In

Agile Appsec 2013 Building Real Software

Prepare to be Attacked◦ Leverage what you have for handling Sev 1 incidents◦ Escalate to outside security experts and legal◦ Contain and recover, capture data for forensics and

legal purposes if you can◦ Root Cause Analysis once you are stabilized ◦ SANS training on security incident management◦ ISO 30111 standard for vulnerability handling and

remediation (including root cause analysis)◦ ISO 21947 vulnerability disclosure - how to deal with

your friendly neighbourhood security researcher

Build Security In

Agile Appsec 2013 Building Real Software

Rinse and RepeatCAMUG 2013

Agile Appsec 2013 Building Real Software

◦Agile Development can be the Cure for Insecure Software Replace big, Waterfall gates with

continuous, iterative checks Always do something, always be

improving Smaller changes = less to review, less to

test, less risk Do what works for your team Automate everything that you can

Rinse and Repeat

Agile Appsec 2013 Building Real Software

◦Include Security Upfront Understand important security and

privacy compliance requirements and risks

Budget tools and time Training and OWASP Cheat Sheets on

basics

Make somebody on the team responsible for Security (the team’s Conscience)

Rinse and Repeat

Agile Appsec 2013 Building Real Software

◦Secure Design (the first 50%) Understand and use security capabilities

of your language(s) and framework(s) Plug any holes with a security library

Think about Trust when you cross Layers Think about security when you choose

Open Source / Commercial Software

Rinse and Repeat

Agile Appsec 2013 Building Real Software

◦Build Security into Sprints Defensive coding – code that is more

robust and more secure Michael Howard “all input data is evil

until proven otherwise” (the other 50%) Understand critical data and attack

surface – when you change it, evaluate risks

Security Stories/Abuser Stories Think about Ops and the run-time

Rinse and Repeat

Agile Appsec 2013 Building Real Software

◦Build Security on top of Quality Think – and test – like a bad guy Do some kind of security testing (static

analysis, dynamic scanning, pen test) Fix the bugs that you find – like any other bug Make sure that you can deploy bug fixes

quickly and safely – Continuous Delivery pipeline, regression testing

Include Security in Retrospectives (learn and prevent)

Rinse and Repeat

Agile Appsec 2013 Building Real Software

◦Join OWASP https://www.owasp.org/index.php/Membership

◦Setup an OWASP Chapter◦Contribute to an OWASP project◦Go to a security conference or at least attend

security sessions at other conferences (UberConf and JavaOne have security tracks)

◦Read more about appsec and security◦Talk to security people, make friends◦Get appsec training, mentor others◦Write good software

Be Part of the Solution