codebits 2014 - secure coding - gamification and automation for the win

Centralway

Secure CodingGamification and automation for the win

Rafael Matias@skylept

Tiago Henriques@balgan

www.centralway.com

$wut?

Objectives of this talk - Developers

● Top 10 risks to your web applications● What worries your security team● How you can write secure code● Secure your data, applications and test it● Automate

Objectives of this talk - Security● Stimulate your developers towards Security● Make it interesting, fun and rewarding for the developers● Make security work in a way that fits your developers● Automate

Objective

Security Developers

$who

Tiago Henriques@balgan

Head of SecurityCentralway

Rafael Matias@skylept

Software EngineerCentralway

How it all started...

Problem?● Too many areas

● Too many project

● Too much work

● 1 guy

Problem? Solutions!● Too many areas - Automation

● Too many project - Consistency

● Too much work - Focus.

● 1 guy - Recruiting.

Problem? Solutions!

“You cannot defend everything, take a step back, calm down and really FOCUS on your work”

Nicolas Ruflin - CTO Centralway, 2013.

Too many areas - automation

Application Security

Developer Education

Integration of security into SDLC

Code Reviews

Testing

Deployment

Design

Regular testing

Incident Handling

Too many areas - automation

Application Security

Developer Education

Integration of security into SDLC

Code Reviews

Testing

Deployment

Design

Incident Handling

Partial Automation

Partial Automation

FullAutomation

GuidelinesAssistance

Manual

Manual

Today we focus on...

Application Security

Developer Education

Integration of security into SDLC

Code Reviews

Testing

Partial Automation

Partial Automation

Manual

SDLCHow does Security fit the SDLC?

Excellent talk by Jeff Williams (@planetlevel) on where security comes in the SDLC got me thinking about this.

SDLC

AppSec at DevOps Speed and Portfolio Scale - Jeff Williamshttp://youtu.be/cIvOth0fxmI

SDLC - v1

This looks quite nice, there is a lot in there we don’t need at the moment though. Let me create my own version that can adapt to our needs

SDLC - V1

SDLC - V1Hey Mr Developer, here is a cool new diagram I made on how Security can fit our Software development life cycle! Check it out!

SDLC - V1What the hell is this crap?This is absolutely focused on waterfall which is nowhere near what we use. Dude. Seriously. What the hell. We use agile… blablablabla

*ARGHHHHH*

SDLC - V1

I can give u some explanation on how Agile works and how we work!

fineeeeee...

SDLC - V1

Blablabla… iterations...blablabla… inception...blablabla construction… blabla continuous deployment… blablablablabla

3 hours later

SDLC - V1

Cool dude, thanks! Time to go back to the whiteboard.

SDLC - v1

This looks quite nice, there is a lot in there we don’t need at the moment though. Let me create my own version that can adapt to our needs

Mistakes:1. Assumed I knew what we needed2. Didn’t consult the developers

SDLC - V2

SDLC - V2

Manual:

● Application catalog - Creation and maintenance of an application assets DB (application name; project team; technology; third party extensions; etc.)

● Risk analysis - Assess and rank how applications add risk● Data analysis - Value of data● Threat analysis - possible enemies and threats to product● Write down possible compliance issues● Check technologies and identify specific security measures, techniques and technologies that will apply to that project.● Create technology-specific best-practice secure development guidance● Cross project architecture against checklist of secure architecture principles. ● Identify the entry points (attack surface/defense perimeter) in software designs● Analyze software designs against the known security risks● Write which data will need to be logged from this project

SDLC - V2

Manual:

● Actively discuss and help developers with questions they might have● Find solutions for problems we might encounter● Create a log of all these issues so that in the future similar situations happen there is a record of solutions found and

that we can easily adapt to other projects - (example: Developer found Project XYZ didnt have SSL, SecurityDude sat down with him and discussed how to do SSL on IOS and use SSL pinning)

SDLC - V2

Dynamic:

● Developer submits his code by himself to Source radar and does self check for warnings.● Source radar should log (this will give an overview to the security team about the evolution of a project and the quality

of the developers):● Amount of reviews developer X did on project Y● Amount of errors or warnings found on code by developer X on project Y● Types of errors found on code by developer X on project Y

● Use tools similar to O2 - automatic code fix - automatic code warn integrated into IDE● Security team does source code review using source radar and specific tools for technology in case they exist

(example: Brakeman for Ruby)● At the end compare his results with results found by developers from Sourceradar● If previous analysis have been done compare current review with previous and do an analysis for changes. (More bugs

of type X, less bugs of type Y, more bugs in entire project)

SDLC - V2

Interactive:

● Security team will try to break project by simply interacting and using it. No use of security tools allowed on this phase.● Log bugs with as much detail as possible in a spreadsheet and pass them over to developers● Create an entry, mark them as non-fixed, write date of vulnerability found● Retest on next iteration - if fixed mark it on spreadsheet and write date of vulnerability fixed

SDLC - V2Deploy - Staging

Manual:

● Test application manually - using security tools such as BURP Proxy and others.● When vulnerability is found create a ticket for project without and assign it to head of project who will then assign it to

the correct developer● Write down on a log this vulnerability with the following: id, title, type, HTTP request / network request (if needed),

screenshots of abuse, notes, date found, name of person who found issue● Mark it for retest● On next iteration retest, if fixed write down on log its fixed and date it was confirmed as fixed and who retested. if it's

not fixed re-open ticket and write comment explaining.

SDLC - V2Deploy - Staging

Dynamic:

● Automated application test - run some automated tools such as: Acunetix, websecurify scanner, BURP Scanner, nikto against application

● Save reports on project folder● When vulnerability is found create a ticket for project without and assign it to head of project who will then assign it to

the correct developer● Write down on a log this vulnerability with the following: id, title, type, HTTP request / network request (if needed),

screenshots of abuse, notes, date found, name of person who found issue● Mark it for retest● On next iteration retest, if fixed write down on log its fixed and date it was confirmed as fixed and who retested. if it's

not fixed re-open ticket and write comment explaining.

SDLC - V2

Deploy - Staging

Static:

● Using static analysis tools debug and test the application● Save reports on project folder● When vulnerability is found create a ticket for project without and assign it to head of project who will then assign it to

the correct developer● Write down on a log this vulnerability with the following: id, title, type, HTTP request / network request (if needed),

screenshots of abuse, notes, date found, name of person who found issue● Mark it for retest● On next iteration retest, if fixed write down on log its fixed and date it was confirmed as fixed and who retested. if it's

not fixed re-open ticket and write comment explaining.

SDLC - V2Deploy - Production

Manual:

● Go through all data about the project● Make sure no critical vulnerabilities are being passed to production● Guarantee all retest has been done● Using checklist on Source radar guarantee everything has been checked and passed● Pair code review of critical code only● Guarantee all important information is being saved to logs● Verify logging is working against complex manual attacks● Verify warnings are working against complex manual attacks● If it is a critical application or one that contains important data - create a audit environment (copy of production)● Book external audit and have them do testing on that environment.● When results arrive get them fixed ASAP

SDLC - V2

Deploy - Production

Static:

● Verify and re-test all critical static issues found

Dynamic:

● Verify and re-test all critical dynamic issues found● Verify logging is working against automated tool attacks● Verify warnings are working against automated tool attacks

Interactive:

● Write a set of edge cases for the application and interactively test them

SDLC - V2

Post Production Deployment

Manual:

● Monitor project and attend to warnings and alerts● Create bug bounty for project if its public facing● Verify the existence of new exploits in case new vulnerabilities show up for technologies used - if it exists get them

fixed ASAP.

SDLC - V2

Post Production Deployment

Static:

● Have auto-throttling on possible DoS functions working correctly (create account, login bruteforce etc...)

Dynamic:

● Have automated tools ran against these projects at least once a week to see if they are able to identify anything new and simple

Interactive:

● Make normal use of all functionality of the app to detect possible problems.

SDLC - V2

Follow these steps for each version of your application / software

Technology Ecosystem

Checklists - Developers

● Checklists for both Security team and Developers.● Best way to make sure you don’t forget anything● Makes your security team life easier● Faster to fix things● Technology catalog list - make a list of the technologies you use, hand

them over to your security team and have them create checklists for you to follow.

Checklists - Security

● Checklists for both Security team and Developers.● Best way to make sure you don’t forget anything● Makes your life easier as your developers can follow the checklists and you

don’t need to worry about the basics!

Principles of Secure Development

● Created by David Rook● Allows you to understand easily

the basic principles of writing secure code

● Based on the KISS (Keep It Short and Simple) principle

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 1 and 2 - Input and Output Validation

● Injection attacks● Cross Site Scripting● Security Misconfiguration● Unvalidated Redirects and Forwards● Content Spoofing● Unrestricted Upload of File with Dangerous Type● Failure to Preserve SQL Query Structure, Web Page Structure, OS Command

Structure● URL Redirection to Untrusted Site● Buffer Copy without Checking Size on Input● Improper Limitation of a Pathname to a Restricted Directory● Improper Control of Filename for Include or Require Statement in PHP

Program● Buffer Access with Incorrect Length Value● Improper Validation of Array Index● Integer Overflow or Wraparound● Incorrect Calculation of Buffer Size.

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 3 - Error Handling

● Information Leakage● Information Exposure Through an Error Message● Improper Check for Unusual or Exceptional Conditions

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 4 - Authentication

● Broken Authentication and Session Management● Security Misconfiguration● Unvalidated Redirects and Forwards● Insufficient Authorisation● Insufficient Authentication● Abuse of Functionality● Use of Hard-coded Credentials● Incorrect Permission Assignment for Critical Resource● Reliance on Untrusted Inputs in a Security Decision● Missing Authentication for Critical Function● Improper Access Control

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 4 - Authorization

● Authorisation● Insufficient Authentication● Abuse of Functionality● Use of Hard-coded Credentials● Incorrect Permission Assignment for Critical Resource● Reliance on Untrusted Inputs in a Security Decision● Missing Authentication for Critical Function● Improper Access Control

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 5 - Session Management

● Broken Authentication and Session Management● Cross Site Request Forgery

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 6 - Secure Communications

● Insufficient Transport Layer Protection● Use of a Broken or Risky Cryptographic Algorithm● Missing Encryption of Sensitive Data

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 7 - Secure Resource Access

● Insecure Direct Object Reference● Failure to Restrict URL Access● Security Misconfiguration● Unvalidated Redirects and Forwards● Predictable Resource Location● Improper Limitation of a Pathname to a Restricted Directory● Improper Control of Filename for Include/Require Statement in PHP Program● Allocation of Resource Without Limits or Throttling

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Principle 8 - Secure Storage

● Insecure Cryptographic Storage● Use of a Broken or Risky Cryptographic Algorithm● Missing Encryption of Sensitive Data

Input Validation

Output Validation

Error Handling

Authentication and Authorization

Session Management

Secure CommunicationsSecure Resource

Access

Secure Storage

Automation - Open Source and Free tools

● Agnitio● Brakeman● OWASP Zap● Codesake Dawn● Gauntlet● Source Radar

Agnitio

● Developed by David Rook● Source Code analysis● Rule based● Windows only● Open Source

Brakeman

● Only for Ruby on Rails● http://brakemanscanner.org/● Easily integrated into Jenkins and other CI software so

that you get automated reports each time a new build is done

● Open Source● Awesome Dev team

OWASP Zap

● Proxy used to intercept request and has a built in vulnerability scanner for web applications.

● Really good scripting engine (Python)● Grab all your developers tests and run using Zap as a

proxy with active scanner mode on.● Will detect basic stuff like XSS and some really 1-0-1

SQLi for free. (in case you can’t afford hiring a security member or just want a really basic automated check)

Codesake Dawn● Codesake::Dawn is a gem providing a security source code

analyzer for web applications written in ruby● When you run Codesake::Dawn on your code it parses your

project Gemfile.lock looking for the gems used and it tries to detect the ruby interpreter version you are using or you declared in your ruby version management tool you like most (RVM, rbenv, ...).

● Then the tool tries to detect the MVC framework your web application uses and it applies the security check accordingly.

● There checks designed to match rails application or checks that are applicable to any ruby code.

● https://github.com/codesake/codesake-dawn

Gauntlet● An always attacking environment for Developers● Easy syntax to write attack use cases● Can use lots of tools as you can invoke

direct command line commands

@slow @announce

Feature: Run sqlmap against a target

Scenario: Identify SQL injection vulnerabilities

Given "sqlmap" is installed

And the following profile:

| name | value |

| target_url | http://localhost:9292/sql-injection?

number_id=1 |

When I launch a "sqlmap" attack with:

"""

python <sqlmap_path> -u <target_url> --dbms sqlite --

batch -v 0 --tables

"""

Then the output should contain:

"""

sqlmap identified the following injection points

"""

And the output should contain:

"""

[2 tables]

+-----------------+

| passwords |

| sqlite_sequence |

+-----------------+

"""

Source Radar

Source Radar● Alpha● Very Alpha● More a proof of concept than anything else● Rule based● Can take any language - for the languages it has a

parser it will generate an AST and then do the analysis if not it will go with pure text parsing

● Can be used by developers and Security teams● Dream team generator● Reward based - Gamification

Source Radar - Example

● CVE-2011-0446● Potential XSS Problem with mail_to :encode => :javascript● All that you need to do on source radar is create a rule and it will go through all projects and

automatically look for projects that use this function

Source Radar - Rewards

● Gamification● Badges

Gamification

Gamification

Gamification

● People like games● Devs do hard work● And on top of that we want them to do Security● why not at least try to make it fun and rewarding

for them ?

Gamification - In security - Objectives

● Make devs want to do security● Make them want to do it often● Reward them correctly● Because they do it more often we get more data

(helps security team, more on this in a little)

Source Radar - DEMO

Data - Metrics - KPIs

● If you notice Sourceradar has some extra fields on the vulnerability fields

● On top of that it isn’t just an open web application it has a user management system associated with it

● Why?

Data - Metrics - KPIs

● Measuring Security.● Does security do anything?● How Secure are we?● How secure were we yesterday?● Have we been improving?

Vulnerability classification

Vulnerability classification

Data - Metrics - KPIs

● Weighted Risk Trend (WRT)● Defect Remediation Window (DRW)● Rate of defect recurrence (RDR)● Security to Quality defect Ratio (SQR)

Data - Metrics - KPIs

Developer training

Hey Boss, I need the team of developers from project X for 2 days for the application security training.

Developer training

HAHA! Nop. That would stop the project for too long. U get 1 hour with each developer

Developer training

● Tailored training - if developer X has only been having problems related to a Specific category like Cryptography why am I gonna make him listen to me ramble about user inputs and output filtering again?

● Teach each developer only what he needs = faster security training.

● Metrics - Developer improvement over-time - pre training vs after

Kudos

● Centralway● SAPO● David Rook

THANK YOU

www.centralway.com/careers

References

● https://www.owasp.org/images/7/77/Magic_Numbers_-_5_KPIs_for_Measuring_WebAppSec_Program_Success_v3.2.pdf

● www.securityninja.co.uk● http://owasp.blogspot.co.uk● http://vimeo.com/appsecusa