1. Centralway
Secure Coding
Gamification and automation for the win
Rafael Matias
@skylept
Tiago Henriques
@balgan
www.centralway.com

2. $wut?

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. Objective
Security Developers

5. $who
Tiago Henriques
@balgan
Head of Security
Centralway
Rafael Matias
@skylept
Software Engineer
Centralway

6. How it all started...

9. Problem?
● Too many areas
● Too many project
● Too much work
● 1 guy

10. Problem? Solutions!
● Too many areas - Automation
● Too many project - Consistency
● Too much work - Focus.
● 1 guy - Recruiting.

11. Problem? Solutions!
“You cannot defend everything, take a step back,
calm down and really FOCUS on your work”
Nicolas Ruflin - CTO Centralway, 2013.

12. Too many areas - automation
Application Security
Developer
Education
Integration
of security
into SDLC
Code
Reviews
Testing
Deployment
Design
Regular
testing
Incident
Handling

13. 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

14. Today we focus on...
Application Security
Developer
Education
Integration
of security
into SDLC
Code
Reviews
Testing
Partial
Automation
Partial
Automation
Manual

15. 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.

16. SDLC
AppSec at DevOps Speed and Portfolio Scale - Jeff Williams
http://youtu.be/cIvOth0fxmI

17. 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

18. SDLC - V1

19. 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!

20. 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*

21. SDLC - V1
I can give u some explanation on
how Agile works and how we work!
fineeeeee...

22. SDLC - V1
Blablabla… iterations...blablabla…
inception...blablabla construction…
blabla continuous deployment…
blablablablabla
3 hours later

23. SDLC - V1
Cool dude, thanks! Time to go
back to the whiteboard.

24. 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

25. SDLC - V2

26. 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

27. 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)

28. 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)

29. 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

30. 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.

31. 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.

32. 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.

33. 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

34. 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

35. 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.

36. 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.

37. SDLC - V2
Follow these steps for each version of your application / software

38. Technology Ecosystem

39. 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.

40. 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!

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. Automation - Open Source and Free tools
● Agnitio
● Brakeman
● OWASP Zap
● Codesake Dawn
● Gauntlet
● Source Radar

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

52. 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

53. 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)

54. 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

55. 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 |
+-----------------+
"""

56. Source Radar

57. 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

58. 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

59. Source Radar - Rewards
● Gamification
● Badges

60. Gamification

61. Gamification

62. 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 ?

63. 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)

64. Source Radar - DEMO

65. 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?

66. Data - Metrics - KPIs
● Measuring Security.
● Does security do anything?
● How Secure are we?
● How secure were we yesterday?
● Have we been improving?

67. Vulnerability classification

68. Vulnerability classification

69. Data - Metrics - KPIs
● Weighted Risk Trend (WRT)
● Defect Remediation Window (DRW)
● Rate of defect recurrence (RDR)
● Security to Quality defect Ratio (SQR)

70. Data - Metrics - KPIs

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

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

73. 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

74. Kudos
● Centralway
● SAPO
● David Rook

75. THANK YOU
www.centralway.com/careers

76. 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