Centralway
Secure Coding
Gamification and automation for the win
Rafael Matias
@skylept
Tiago Henriques
@balgan
www.centra...
$wut?
Objectives of this talk - Developers
● Top 10 risks to your web applications
● What worries your security team
● How you c...
Objective
Security Developers
$who
Tiago Henriques
@balgan
Head of Security
Centralway
Rafael Matias
@skylept
Software Engineer
Centralway
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 - Recr...
Problem? Solutions!
“You cannot defend everything, take a step back,
calm down and really FOCUS on your work”
Nicolas Rufl...
Too many areas - automation
Application Security
Developer
Education
Integration
of security
into SDLC
Code
Reviews
Testin...
Too many areas - automation
Application Security
Developer
Education
Integration
of security
into SDLC
Code
Reviews
Testin...
Today we focus on...
Application Security
Developer
Education
Integration
of security
into SDLC
Code
Reviews
Testing
Parti...
SDLC
How does Security fit the SDLC?
Excellent talk by Jeff Williams (@planetlevel) on where
security comes in the SDLC go...
SDLC
AppSec at DevOps Speed and Portfolio Scale - Jeff Williams
http://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
...
SDLC - V1
SDLC - V1
Hey Mr Developer, here is a cool
new diagram I made on how
Security can fit our Software
development life cycle!...
SDLC - V1
What the hell is this crap?
This is absolutely focused on
waterfall which is nowhere near
what we use. Dude. Ser...
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…
blablablabl...
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
...
SDLC - V2
SDLC - V2
Manual:
● Application catalog - Creation and maintenance of an application assets DB (application name; project ...
SDLC - V2
Manual:
● Actively discuss and help developers with questions they might have
● Find solutions for problems we m...
SDLC - V2
Dynamic:
● Developer submits his code by himself to Source radar and does self check for warnings.
● Source rada...
SDLC - V2
Interactive:
● Security team will try to break project by simply interacting and using it. No use of security to...
SDLC - V2
Deploy - Staging
Manual:
● Test application manually - using security tools such as BURP Proxy and others.
● Whe...
SDLC - V2
Deploy - Staging
Dynamic:
● Automated application test - run some automated tools such as: Acunetix, websecurify...
SDLC - V2
Deploy - Staging
Static:
● Using static analysis tools debug and test the application
● Save reports on project ...
SDLC - V2
Deploy - Production
Manual:
● Go through all data about the project
● Make sure no critical vulnerabilities are ...
SDLC - V2
Deploy - Production
Static:
● Verify and re-test all critical static issues found
Dynamic:
● Verify and re-test ...
SDLC - V2
Post Production Deployment
Manual:
● Monitor project and attend to warnings and alerts
● Create bug bounty for p...
SDLC - V2
Post Production Deployment
Static:
● Have auto-throttling on possible DoS functions working correctly (create ac...
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 anyth...
Checklists - Security
● Checklists for both Security team and Developers.
● Best way to make sure you don’t forget anythin...
Principles of Secure Development
● Created by David Rook
● Allows you to understand easily
the basic principles of writing...
Principle 1 and 2 - Input and Output Validation
● Injection attacks
● Cross Site Scripting
● Security Misconfiguration
● U...
Principle 3 - Error Handling
● Information Leakage
● Information Exposure Through an Error Message
● Improper Check for Un...
Principle 4 - Authentication
● Broken Authentication and Session Management
● Security Misconfiguration
● Unvalidated Redi...
Principle 4 - Authorization
● Authorisation
● Insufficient Authentication
● Abuse of Functionality
● Use of Hard-coded Cre...
Principle 5 - Session Management
● Broken Authentication and Session Management
● Cross Site Request Forgery
Input Validat...
Principle 6 - Secure Communications
● Insufficient Transport Layer Protection
● Use of a Broken or Risky Cryptographic Alg...
Principle 7 - Secure Resource Access
● Insecure Direct Object Reference
● Failure to Restrict URL Access
● Security Miscon...
Principle 8 - Secure Storage
● Insecure Cryptographic Storage
● Use of a Broken or Risky Cryptographic Algorithm
● Missing...
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
...
OWASP Zap
● Proxy used to intercept request and has a built in
vulnerability scanner for web applications.
● Really good s...
Codesake Dawn
● Codesake::Dawn is a gem providing a security source code
analyzer for web applications written in ruby
● W...
Gauntlet
● An always attacking environment for Developers
● Easy syntax to write attack use cases
● Can use lots of tools ...
Source Radar
Source Radar
● Alpha
● Very Alpha
● More a proof of concept than anything else
● Rule based
● Can take any language - for ...
Source Radar - Example
● CVE-2011-0446
● Potential XSS Problem with mail_to :encode => :javascript
● All that you need to ...
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 t...
Gamification - In security - Objectives
● Make devs want to do security
● Make them want to do it often
● Reward them corr...
Source Radar - DEMO
Data - Metrics - KPIs
● If you notice Sourceradar has some extra fields
on the vulnerability fields
● On top of that it is...
Data - Metrics - KPIs
● Measuring Security.
● Does security do anything?
● How Secure are we?
● How secure were we yesterd...
Vulnerability classification
Vulnerability classification
Data - Metrics - KPIs
● Weighted Risk Trend (WRT)
● Defect Remediation Window (DRW)
● Rate of defect recurrence (RDR)
● Se...
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
...
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
●...
Codebits 2014 - Secure Coding - Gamification and automation for the win
Codebits 2014 - Secure Coding - Gamification and automation for the win
Upcoming SlideShare
Loading in …5
×

Codebits 2014 - Secure Coding - Gamification and automation for the win

1,196 views

Published on

Published in: Technology
2 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total views
1,196
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
39
Comments
2
Likes
6
Embeds 0
No embeds

No notes for slide

Codebits 2014 - Secure Coding - Gamification and automation for the win

  1. 1. Centralway Secure Coding Gamification and automation for the win Rafael Matias @skylept Tiago Henriques @balgan www.centralway.com
  2. 2. $wut?
  3. 3. 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
  4. 4. Objective Security Developers
  5. 5. $who Tiago Henriques @balgan Head of Security Centralway Rafael Matias @skylept Software Engineer Centralway
  6. 6. How it all started...
  7. 7. Problem? ● Too many areas ● Too many project ● Too much work ● 1 guy
  8. 8. Problem? Solutions! ● Too many areas - Automation ● Too many project - Consistency ● Too much work - Focus. ● 1 guy - Recruiting.
  9. 9. Problem? Solutions! “You cannot defend everything, take a step back, calm down and really FOCUS on your work” Nicolas Ruflin - CTO Centralway, 2013.
  10. 10. Too many areas - automation Application Security Developer Education Integration of security into SDLC Code Reviews Testing Deployment Design Regular testing Incident Handling
  11. 11. Too many areas - automation Application Security Developer Education Integration of security into SDLC Code Reviews Testing Deployment Design Incident Handling Partial Automation Partial Automation Full Automation Guidelines Assistance Manual Manual
  12. 12. Today we focus on... Application Security Developer Education Integration of security into SDLC Code Reviews Testing Partial Automation Partial Automation Manual
  13. 13. SDLC How does Security fit the SDLC? Excellent talk by Jeff Williams (@planetlevel) on where security comes in the SDLC got me thinking about this.
  14. 14. SDLC AppSec at DevOps Speed and Portfolio Scale - Jeff Williams http://youtu.be/cIvOth0fxmI
  15. 15. 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
  16. 16. SDLC - V1
  17. 17. SDLC - V1 Hey Mr Developer, here is a cool new diagram I made on how Security can fit our Software development life cycle! Check it out!
  18. 18. SDLC - V1 What 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*
  19. 19. SDLC - V1 I can give u some explanation on how Agile works and how we work! fineeeeee...
  20. 20. SDLC - V1 Blablabla… iterations...blablabla… inception...blablabla construction… blabla continuous deployment… blablablablabla 3 hours later
  21. 21. SDLC - V1 Cool dude, thanks! Time to go back to the whiteboard.
  22. 22. 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 needed 2. Didn’t consult the developers
  23. 23. SDLC - V2
  24. 24. 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
  25. 25. 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)
  26. 26. 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)
  27. 27. 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
  28. 28. SDLC - V2 Deploy - 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.
  29. 29. SDLC - V2 Deploy - 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.
  30. 30. 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.
  31. 31. SDLC - V2 Deploy - 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
  32. 32. 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
  33. 33. 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.
  34. 34. 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.
  35. 35. SDLC - V2 Follow these steps for each version of your application / software
  36. 36. Technology Ecosystem
  37. 37. 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.
  38. 38. 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!
  39. 39. 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 Communications Secure Resource Access Secure Storage
  40. 40. 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 Communications Secure Resource Access Secure Storage
  41. 41. 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 Communications Secure Resource Access Secure Storage
  42. 42. 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 Communications Secure Resource Access Secure Storage
  43. 43. 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 Communications Secure Resource Access Secure Storage
  44. 44. 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 Communications Secure Resource Access Secure Storage
  45. 45. 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 Communications Secure Resource Access Secure Storage
  46. 46. 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 Communications Secure Resource Access Secure Storage
  47. 47. 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 Communications Secure Resource Access Secure Storage
  48. 48. Automation - Open Source and Free tools ● Agnitio ● Brakeman ● OWASP Zap ● Codesake Dawn ● Gauntlet ● Source Radar
  49. 49. Agnitio ● Developed by David Rook ● Source Code analysis ● Rule based ● Windows only ● Open Source
  50. 50. 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
  51. 51. 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)
  52. 52. 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
  53. 53. 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 | +-----------------+ """
  54. 54. Source Radar
  55. 55. 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
  56. 56. 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
  57. 57. Source Radar - Rewards ● Gamification ● Badges
  58. 58. Gamification
  59. 59. Gamification
  60. 60. 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 ?
  61. 61. 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)
  62. 62. Source Radar - DEMO
  63. 63. 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?
  64. 64. Data - Metrics - KPIs ● Measuring Security. ● Does security do anything? ● How Secure are we? ● How secure were we yesterday? ● Have we been improving?
  65. 65. Vulnerability classification
  66. 66. Vulnerability classification
  67. 67. Data - Metrics - KPIs ● Weighted Risk Trend (WRT) ● Defect Remediation Window (DRW) ● Rate of defect recurrence (RDR) ● Security to Quality defect Ratio (SQR)
  68. 68. Data - Metrics - KPIs
  69. 69. Developer training Hey Boss, I need the team of developers from project X for 2 days for the application security training.
  70. 70. Developer training HAHA! Nop. That would stop the project for too long. U get 1 hour with each developer
  71. 71. 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
  72. 72. Kudos ● Centralway ● SAPO ● David Rook
  73. 73. THANK YOU www.centralway.com/careers
  74. 74. 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

×