Presentation at CAMUG Nov 2013 on the problems in secure application development, why Agile is sometimes blamed for being the cause of insecure software, and how Agile development can be the cure for insecure software.
7. ◦ Jim Bird
◦ A software guy that cares about security
◦ Experience in software development, Ops, general
management, project management (PMP, CSM, PMIACP, 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
Agile Appsec 2013
Building Real Software
8.
Lots of information to follow
No pictures of puppies, kittens, babies or Star
Trek characters
Stuff you can take away and use later
Agile Appsec 2013
Building Real Software
9.
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/pressrelease-aspect-security-launches-free-tool-to-measuregaps-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
Agile Appsec 2013
Building Real Software
10.
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-softwaredevelopment/46153
Agile development makes it easier to build
more software faster. More software = more
vulnerabilities
Agile Appsec 2013
Building Real Software
11.
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-ofhtml5-development-risks/240156891
https://www.owasp.org/images/3/31/Node.js_Security_Ol
d_vulnerabilities_in_new_bottles_-_Sven_Vetsch.pdf
Agile Appsec 2013
Building Real Software
12.
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…
Agile Appsec 2013
Building Real Software
13.
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
Agile Appsec 2013
Building Real Software
14.
Hacking Industrial Systems Turns out to be
Easy, MIT Technology Review, Aug 2013
http://www.technologyreview.com/news/517731/ha
cking-industrial-systems-turns-out-to-be-easy/
Backdoor in computer controls opens critical
infrastructure to hackers, Oct 2012
http://arstechnica.com/security/2012/10/backdoorin-computer-controls-opens-critical-infrastructureto-hackers/
Researchers expose flaws in popular industrial
control systems, InfoWorld, Jan 2012
http://www.infoworld.com/d/security/researchersexpose-flaws-in-popular-industrial-controlsystems-184629
Agile Appsec 2013
Building Real Software
15.
Smart toilet security flaw could result in nasty
surprise, Fox News Aug 2013
http://www.foxnews.com/tech/2013/08/05/smart-toiletsecurity-flaw/
The same security risks are in today’s
cars, smart homes, TVs, …
◦ http://arstechnica.com/security/2013/07/disabling-acars-brakes-and-speed-by-hacking-its-computers-anew-how-to/
Hacking airplanes in flight? I did that a year
ago…, April 2013
http://www.foxnews.com/tech/2013/04/12/hacking-inflight-airplane-did-that-year-ago-hacker-says/
Agile Appsec 2013
Building Real Software
16.
Lack of Knowledge and Skills – Developers
Don’t Understand Security
Fundamental Asymmetry – the Bad Guys
always Win
Quality – Bad Software is Easy to Hack
Agile Appsec 2013
Building Real Software
17.
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/platformspecific vulnerabilities and attacks and
exploits, secure configuration, context-sensitive
data encoding, race conditions (TOC/TOU),…
Agile Appsec 2013
Building Real Software
18.
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
Agile Appsec 2013
Building Real Software
19.
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/wpcontent/uploads/2012/09/7-Ways-to-Scale-WebSecurity-Jeremiah-Grossman.pdf
◦ 17 million developers worldwide
◦ BSIMM says 2% of developers need to be security
black belts = 340,000 need advanced appsec
training
Agile Appsec 2013
Building Real Software
20.
Software Security is an Asymmetric Problem
Michael Howard, 8 Simple Rules for Developing More
Secure Software http://msdn.microsoft.com/enus/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
Agile Appsec 2013
Building Real Software
21.
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
Agile Appsec 2013
Building Real Software
22.
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/greentech/computers/stories/450000-passwords-stolen-in-yahoodata-breach
◦ http://www.zdnet.com/over-21000-plain-text-passwordsstolen-from-billabong-7000000842/
Agile Appsec 2013
Building Real Software
23.
Security = C-I-A
All of these are also important factors to
Software Quality
◦ Confidentiality
◦ Integrity
◦ Availability
“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
Agile Appsec 2013
Building Real Software
25.
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 (1month, 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, …)
Agile Appsec 2013
Building Real Software
27.
“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-facebook-fixsecurity-failures-putting-kids-risk
◦ http://www.zdnet.com/facebook-admits-failure-in-bug-report7000019657/
◦ http://www.thetechherald.com/articles/More-security-failure-asPhishing-attacks-return-to-Facebook/6017/
◦ http://grahamcluley.com/2013/06/facebook-owns-privacybreach-tells-world-late-friday-night/
◦ http://www.dailymail.co.uk/news/article-2396628/MarkZuckerbergs-Facebook-page-hacked-Khalil-Shreateh-exposesite-vulnerability.html
◦ http://thehackernews.com/2013/09/vulnerability-allowedhacker-to-delete.html
◦ ….
Agile Appsec 2013
Building Real Software
28.
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….
Agile Appsec 2013
Building Real Software
29.
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
Agile Appsec 2013
Building Real Software
30.
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
Agile Appsec 2013
Building Real Software
31.
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
Agile Appsec 2013
Building Real Software
32.
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-doesnthave-or-need-testers/7191
Agile Appsec 2013
Building Real Software
33.
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…
Agile Appsec 2013
Building Real Software
34.
Work is defined through Stories
As a <type of user> I want <something> so
that <reason>
Most security requirements are nonfunctional (like maintainability, supportability)
http://www.infoq.com/articles/managing-securityrequirements-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”
Agile Appsec 2013
Building Real Software
35.
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?
Agile Appsec 2013
Building Real Software
37.
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_Devel
opment:_Don%27t_Forget_EVIL_User_Stories
◦ Cigital Abuse/Misuse Cases – think like a bad guy
http://cigital.com/papers/download/bsi2-misuse.pdf
Agile Appsec 2013
Building Real Software
38.
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
Agile Appsec 2013
Building Real Software
39.
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?
Agile Appsec 2013
Building Real Software
40.
Try following Microsoft: SDL Agile
◦ Available for free but expensive to follow
http://msdn.microsoft.com/enus/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)
Agile Appsec 2013
Building Real Software
41.
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”
Agile Appsec 2013
Building Real Software
42.
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!
Agile Appsec 2013
Building Real Software
43.
Design and Architecture
◦ Understand the security capabilities of your
framework
(.NET, Rails, Play, Spring, Django, Yii, iOS, Andr
oid, …)
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, …)
Agile Appsec 2013
Building Real Software
44.
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?
Agile Appsec 2013
Building Real Software
45.
Attack Surface
◦ How bad guys get in:
forms, fields, parms, cookies, files, URLs, APIs, runtime 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?
Agile Appsec 2013
Building Real Software
46.
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?
Agile Appsec 2013
Building Real Software
47.
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 checkin monitoring (Etsy, Zane Lackey)
http://www.slideshare.net/zanelackey/effectiveapproaches-to-web-application-security
Agile Appsec 2013
Building Real Software
48.
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_Codi
ng_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
◦
◦
◦
◦
Agile Appsec 2013
Building Real Software
49.
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
Agile Appsec 2013
Building Real Software
50.
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
Agile Appsec 2013
Building Real Software
51.
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
Agile Appsec 2013
Building Real Software
52.
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-SoftwarePractical-Testing/dp/0201796198
http://jpkc.sziit.edu.cn/software/www/st/courses/res/q
iyeziyuan/eng/how_to_break_software.pdf
Agile Appsec 2013
Building Real Software
53.
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
Agile Appsec 2013
Building Real Software
54.
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)
Agile Appsec 2013
Building Real Software
55.
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/introducingminion/
Agile Appsec 2013
Building Real Software
56.
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
Agile Appsec 2013
Building Real Software
57.
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
Agile Appsec 2013
Building Real Software
58.
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-securesoftware-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-simianarmy.html
Agile Appsec 2013
Building Real Software
59.
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
Agile Appsec 2013
Building Real Software
61. ◦ 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
Agile Appsec 2013
Building Real Software
62. ◦ 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)
Agile Appsec 2013
Building Real Software
63. ◦ 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
Agile Appsec 2013
Building Real Software
64. ◦ 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
Agile Appsec 2013
Building Real Software
65. ◦ 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)
Agile Appsec 2013
Building Real Software
66. ◦ 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
Agile Appsec 2013
Building Real Software
Editor's Notes
The number of security attacks on applications is increasing year over year. This is because developers suck at writing secure software – and the bad guys know it. Web applications are full of security holes. Mobile apps are worse. Real time industrial control systems are easily hacked, which could lead to potential disaster situations. And of course there are still lots of vulnerabilities found every week in personal software: Windows, Adobe Reader, Java, Quicktime…Many security experts believe that Agile development is making the problem worse – that Agile teams cannot build secure software. But just because we don’t write secure software doesn’t mean that we can’t. We’ll look at how serious the appsec problem is and why: what the problems are in building a secure app, how Agile development practices make it more difficult to build secure software, and what we need to change.