HELPING YOU SECURE YOUR INFORMATION ASSETS
Security Culture from Concept to
Maintenance:
Secure Software Development Life Cycle
Dilum Bandara, PhD
Consultant, TechCERT
Senior Lecturer, University of Moratuwa

SDLC
Copyright © TechCERT 2016 2

Reality
• High-level security requirements
• Password policy, HTTPS
• Secure design is almost none existent
• Implementation
• Password policy, HTTPS, etc.,
• Based on a code found in Stack Overflow
• Limited developer-level testing
• Focus on bugs, not flaws
• Rarely test interfaces & on actual server/environment
• No concern for security during evolution
Copyright © TechCERT 2016 3

Result
• 75% of vulnerabilities are application related –
Gartner
• Web is the #1 target
• 95% of web applications have some sort of a
vulnerability – Imperva
• 99% of mobile apps have some sort of a vulnerability –
IViZ
• 82% fail initial PCI-DSS assessment –
Computerworld
• Only 11% able to maintain compliance across
assessments – Computerworld
Copyright © TechCERT 2016 4

• Time gap between
identification of vulnerability &
attack decreasing
• Zero day attacks are increasing
Copyright © TechCERT 2016 5

Web Application Security Vulnerabilities
Source: HP Security Research Cyber Risk Report 2015
Copyright © TechCERT 2016 6

Costs
Copyright © TechCERT 2016 7

Solutions
• Secure Software Development Life Cycle (SDLC)
• SDL – Secure Development Lifecycle
• Organizations with a secure SDLC will experience
80% decrease in critical vulnerabilities – Gartner
• 50% reduction in vulnerabilities could reduce
configuration management & incident response
costs by 75% each – Gartner
Copyright © TechCERT 2016 8

Secure SDLC
Copyright © TechCERT 2016 9

Benefits
• Minimize costs due to security-related issues
• Avoid reputation damage
• Decrease number of security issues
• Minimize future security issues
• Improve security expertise/practices of
development team
• Reduce 3rd party testing/validation costs
Copyright © TechCERT 2016 10

Challenges
• Team pushback
• Not in their blood
• Security ownership
• You develop, we test
• “Security is Special” problem
• Official/actual adoption dilemma
• Measurement & justification of benefits
• Disruption due to Big-Bang adoption
Copyright © TechCERT 2016 11

Ways to Build a Security Culture
• You must invest in a security culture
• Make sure it sustains through:
• Understanding that security belongs to everyone
• Awareness & beyond
• Adopt a Secure Development Lifecycle (SDL)
• Reward & recognize people that do the right thing for
security
• Build security community
• Make security fun & engaging
Copyright © TechCERT 2016 12

Secure SDLC
Copyright © TechCERT 2016 13

Security Development Lifecycle
(SDL)
• Introduced by Microsoft
• Software development process
• Helps developers build more secure software &
address security compliance requirements
• Reduce development cost
Copyright © TechCERT 2016 14
Source: www.microsoft.com/en-us/sdl/

SDL Steps
Copyright © TechCERT 2016 15

SDL – Training
• Core Security Training
• Educate designers & developers on fundamentals
of building better software
• Secure design
• Threat modeling
• Secure coding
• Security testing
• Privacy
• Best practices
Copyright © TechCERT 2016 16

SDL – Requirements
• Establish Security & Privacy Requirements
• Define security & privacy requirements
• Make it easier to identify key milestones & deliverables
• Minimize disruptions to plans & schedules
• Create Quality Gates/Bug Bars
• Define minimum acceptable levels of security & privacy
• Helps team understand risks associated with security
issues, identify & fix security bugs
• Apply standards throughout the entire project
Copyright © TechCERT 2016 17

SDL – Requirements (Cont.)
• Perform Security & Privacy Risk Assessments
• Examine design based on costs & regulatory
requirements
• Team can identify which portions of project require
threat modeling & security design
• Determine privacy Impact rating of a product
Copyright © TechCERT 2016 18

SDL – Design
• Establish Design Requirements
• Consider security & privacy concerns
• Minimize risk of schedule disruptions & reduce cost
• Attack Surface Analysis/Reduction
• Reduce potential weak spots or vulnerabilities
• Require thoroughly analysis of overall attack surface
• Restrict access to system services
• Apply the principle of least privilege
• Employ layered defenses
Copyright © TechCERT 2016 19

SDL – Design (Cont.)
• Use Threat Modeling
• Apply a structured approach to threat scenarios
• More effective & less expensively identification of
vulnerabilities, risks, & mitigations
Copyright © TechCERT 2016 20
Source: https://technet.microsoft.com/en-us/security/dn140238.aspx

Threat Modeling
Copyright © TechCERT 2016 21
Source: https://www.owasp.org/index.php/Application_Threat_Modeling

SDL – Implementation
• Use Approved Tools
• Identify list of approved tools & associated security checks
• Compiler/linker options and warnings
• Automate & enforce security practices easily at a low cost
• Use latest tool versions
• Deprecate Unsafe Functions
• Analyzing all functions & APIs, & ban those that are unsafe
• Replacing them with safer alternatives
• Perform Static Analysis
• Analyze source code prior to compile
• Security code review
• Ensure secure coding policies are being followed
Copyright © TechCERT 2016 22

SDL – Verification
• Perform Dynamic Analysis
• Run-time verification
• Use tools that monitor application behavior for memory
corruption, user privilege issues, etc.
• Fuzz Testing
• Deliberately introducing malformed or random data to
break application
• Attack Surface Review
• Review attack surface
• Can identify any design or implementation changes
• Review changes and threat models
Copyright © TechCERT 2016 23

SDL – Release
• Create an Incident Response Plan
• Help address new threats that can emerge over time
• Identify security emergency contacts
• Establish security servicing plans for code inherited from
3rd parties
• Conduct Final Security Review
• Review all security activities
• Review against threat models, tools outputs, &
performance against quality gates & bug bars
• Certify Release & Archive
• Certify software
• Archive all pertinent data/code
Copyright © TechCERT 2016 24

SDL – Response
• Execute Incident Response Plan
• Help protect customers from software security or
privacy vulnerabilities
• Practice, practice, practice
Copyright © TechCERT 2016 25

Proactive vs. Reactive SDLC
Source: Tjylen Veselyj, SoftServe
Security
requirements / risk
and threat analysis
Coding guidelines
/code reviews/
static analysis
Security testing /
dynamic analysis
Vulnerability
scanning / WAF
Reactive ApproachProactive Approach
Secure SDLC
Copyright © TechCERT 2016 26

Training for All Steps
• Ensure Best Practices are integral to the development
program & applied over lifecycle of Application
Copyright © TechCERT 2016 27
Requirements
Security
Requirements
Compliance
Analysis
Governance
Definition
Design
Risk
Assessment
Secure
Architecture
Implementation
Code Reviews
Code Analysis
Verification
Security
Testing
Risk
Assessment
Review
Penetration
Testing
Release
Security
Review
Incident
Response Plan
Response
Incident
Forensics
Security
Monitoring
Security Awareness Trainings
Source: Tjylen Veselyj, SoftServe

Remember – It’s a Cycle
Copyright © TechCERT 2016 28
Source: www.juniper.net/us/en/security/sdl/

Copyright © TechCERT 2016 29
Source: Tjylen Veselyj, SoftServe

Agile Development
• Security better aligns to waterfall-like processes
• Can be used in Agile methods with proper care
Copyright © TechCERT 2016 30
Source: www.screenmedia.co.uk/blog/2014/08/what-is-agile-development-a-brief-introduction/

In the Long Run…
• Organization’s behavior changes slowly over time
• Changes must be iterative while working toward
long-term goals
• No single recipe works for all organizations
• Adopt a Maturity Model
• Must provide enough details for non-security people
• Must be simple, well-defined, & measurable
Copyright © TechCERT 2016 31

OpenSAMM – Software Assurance
Maturity Model
• Open framework to help organizations formulate &
implement a strategy for software security
• Tailored to specific risks facing the organization
• Helps to
• Valuate an organization’s existing software security
practices
• Build a balanced software security program in well-
defined iterations
• Demonstrate concrete improvements to a security
assurance program
• Define & measure security-related activities within an
organization
Copyright © TechCERT 2016 32

OpenSAMM
Copyright © TechCERT 2016 33
Source: www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model

Where to Begin
Copyright © TechCERT 2016 34

Secure Development
• Start with known/common vulnerabilities
Copyright © TechCERT 2016 35
Source: www.securityninja.co.uk/secure-development/the-principles-place/

Top Vulnerabilities
Copyright © TechCERT 2016 36
Source: https://geekflare.com/online-scan-website-security-vulnerabilities/

OWASP Top 10
Copyright © TechCERT 2016 37
Source: http://dunnesec.com

A1: Injection
• SQL Injection
• OS Command Injection
Copyright © TechCERT 2016 38

SQL Injection – Solution
Copyright © TechCERT 2016 39
Source: www.owasp.org

Injection – Solutions
• Validate
• Prepare query
• CAPTCHA for open forms
• Resources
• SQL Injection
• http://www.w3schools.com/sql/sql_injection.asp
• OS Command Injection
• https://www.owasp.org/index.php/Command_Injection
• SQL Injection Prevention Cheat Sheet
• https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
• Query Parameterization Cheat Sheet
• https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
• TSQL
• http://www.codeproject.com/Tips/586207/How-to-prevent-SQL-Injection-in-
Stored-Procedures
Copyright © TechCERT 2016 40

A2: Broken Authentication &
Session Management
• http://example.com/sale/saleitems/jsessi
onid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop
• Suppose a user e-mail this link to a friend
• Has session ID
• May include credit card nos, & other unique data
Copyright © TechCERT 2016 41

Broken Authentication & Session
Management – Solutions
• Store session ID in a cookie & use with HTTP payload
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/testing_broken_a
uthentication.htm
• Session Management Cheat Sheet
• https://www.owasp.org/index.php/Session_Management_Cheat_
Sheet
• Authentication Cheat Sheet
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
• Forgot Password Cheat Sheet
• https://www.owasp.org/index.php/Forgot_Password_Cheat_Shee
t
Copyright © TechCERT 2016 42

A3: Cross-Site Scripting (XSS)
Copyright © TechCERT 2016 43
Source: http://www.acunetix.com/blog/articles/blind-xss/

XSS Example
Copyright © TechCERT 2016 44
Source: Amit Klein, Sanctum Security Group

XSS Solutions
• Validate and filter out everything
• CAPTCHA for open forms
• Resources
• Cross-site Scripting (XSS)
• https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
• Cross Site Scripting Explained
• https://crypto.stanford.edu/cs155/papers/CSS.pdf
• PHP 5 Form Validation
• http://www.w3schools.com/php/php_form_validation.asp
• XSS (Cross Site Scripting) Prevention Cheat Sheet
• https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prev
ention_Cheat_Sheet
• DOM based XSS Prevention Cheat Sheet
• https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_S
heet
Copyright © TechCERT 2016 45

A4: Insecure Direct Object
References
http://webapp.com/app/accountInfo?acct=admin
String sqlquery = "SELECT * FROM useraccounts
WHERE account = ?";
PreparedStatement st =
connection.prepareStatement(sqlquery , � );
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );
When developer exposes a reference to an internal implementation
object, such as a file, account no, directory, or database key without any
validation
Copyright © TechCERT 2016 46

Insecure Direct Object References
– Example
Copyright © TechCERT 2016 47
Source: http://lazarusalliance.com/test-your-owasp-knowledge/

Insecure Direct Object References
– Solution
• Check access control
• Use only one user or session for indirect object
references
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/insecure_direct_o
bject_reference.htm
• Top 10 2007-Insecure Direct Object Reference
• https://www.owasp.org/index.php/Top_10_2007-
Insecure_Direct_Object_Reference
• Testing for Insecure Direct Object References
• https://www.owasp.org/index.php/Testing_for_Insecure_Direct_O
bject_References_%28OTG-AUTHZ-004%29
Copyright © TechCERT 2016 48

A5: Security Misconfiguration
• When security settings are defined, implemented, &
maintained as defaults
• Not disabling directory listing
• Show debug information
• Default settings
• Sample apps that came with tool
• Solution
• Address above issues
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/testing_security_
misconfiguration.htm
Copyright © TechCERT 2016 49

A6: Sensitive Data Exposure
• Not using SSL
• Use of account & credit card numbers without
hashing
• Unencrypted passwords & credit card numbers
Copyright © TechCERT 2016 50
Source: www.htbridge.com/vulnerability/common-web-weaknesses/

Sensitive Data Exposure –
Solutions
• Solutions
• Proper use of SSL 2.0
• Hashing & encryption
• PCD DSS & PA DSS
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/testing_sensitive_data_ex
posure.htm
• Cryptographic Storage Cheat Sheet
• https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
• Password Storage Cheat Sheet
• https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
• Transport Layer Protection Cheat Sheet
• https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sh
eet
Copyright © TechCERT 2016 51

A7: Missing Function Level
Access Control
• Due to in proper authorization
Copyright © TechCERT 2016 52
Source: www.slideshare.net/appsec/19-owasp-top-10-a7missing-function-level-access-control

Missing Function Level Access
Control – Solutions
• Authenticate & authorize every form/request
• Deny everything else
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/missing_functi
on_level_access_control.htm
• Failure to Restrict URL Access
• https://www.owasp.org/index.php/Top_10_2007-
Failure_to_Restrict_URL_Access
• Guide to Authorization
• https://www.owasp.org/index.php/Guide_to_Authorization
Copyright © TechCERT 2016 53

A8: Cross Site Request Forgery
(CSRF)
http://bankx.com/app?action=transferFund&amount=35
00&destinationAccount=4673243243
<img
src="http://bankx.com/app?action=transferFunds&amo
unt=14000&destinationAccount=attackersAcct#"
width="0" height="0" />
Copyright © TechCERT 2016 54
Source: http://www.redteamsecure.com/labs/post/66/Demystifying-Cross-Site-Request-Forgery

Cross Site Request Forgery –
Solutions
• Unique token in a hidden field - sent in body of HTTP
request rather than in an URL
• Re-authentication before a transaction
• Captcha
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/cross_site_request_forger
y.htm
• Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
• https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
• OWASP CSRFGuard Project
• https://www.owasp.org/index.php/CSRFGuard
Copyright © TechCERT 2016 55

A9: Using Known Vulnerable
Components
• 3rd party libraries, frameworks, etc.
• Solutions
• Identify all components & versions used
• Keep all components such as public databases, project
mailing lists upto date
• Add security wrappers
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/components_wit
h_vulnerabilities.htm
• OWASP Dependency Check
• https://www.owasp.org/index.php/OWASP_Dependency_Check
Copyright © TechCERT 2016 56

A10: Unvalidated Redirects &
Forwards
• Unvalidated forwarding & redirections
http://www.mywebapp.com/redirect.jsp?redirectrul=hack
er.com
http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.
jsp
• Solutions
• Avoid using redirects & forwards
• Use without involving user parameters in redirecting the
destination
• Resources
• Example
• http://www.tutorialspoint.com/security_testing/unvalidated_redirects_an
d_forwards.htm
• Unvalidated Redirects and Forwards Cheat Sheet
• https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_
Cheat_Sheet
Copyright © TechCERT 2016 57

More
• .NET Security Cheat Sheet
• https://www.owasp.org/index.php/.NET_Security_Cheat_She
et
• PHP Security Cheat Sheet
• https://www.owasp.org/index.php/PHP_Security_Cheat_She
et
• PHP Top 5
• https://www.owasp.org/index.php/PHP_Top_5
• Design Guidelines for Secure Web Applications
• https://msdn.microsoft.com/en-us/library/ff648647.aspx
• Common Security Mistakes in Web Applications
• http://www.smashingmagazine.com/2010/10/common-
security-mistakes-in-web-applications/
Copyright © TechCERT 2016 58

Tools
• Static Application Security Testing
• HP Fortify
• Veracode
• SonarQube
• Dynamic analysis
• Acunetix
• Burp Suite
• w3af
Copyright © TechCERT 2016 59

How TechCERT Can Support
• Application Functionality Assessment & Certification
• Mobile App Assessment
• Secure communication
• Secure storage & memory
• OWAPS Top 10
• Secure Code Review
• Tool-based & manual
• OWAPS Top 10
• Backdoors, login issues, cryptography implementation
• Best practices
• Tool-Based Vulnerability Assessment
• Penetration Testing
• Consulting Secure SDLC Initiatives
Copyright © TechCERT 2016 60

Q & A
dilumb@techcert.lk
Copyright © TechCERT 2016 61