security culture from concept to maintenance: secure software development life cycle

HELPING YOU SECURE YOUR INFORMATION ASSETS

Security Culture from Concept to Maintenance:Secure Software Development Life Cycle

Dilum Bandara, PhDConsultant, 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


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


• Time gap between identification of vulnerability & attack decreasing

• Zero day attacks are increasing


Web Application Security Vulnerabilities

Source: HP Security Research Cyber Risk Report 2015


http://info.hpenterprisesecurity.com/LP_460192_Cross_CyberriskFullReport_0315_gate?src=hp.com

Costs


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


Secure SDLC


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


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


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


Secure SDLC


Security Development Lifecycle (SDL)• Introduced by Microsoft

• Software development process

• Helps developers build more secure software & address security compliance requirements

• Reduce development cost


Source: www.microsoft.com/en-us/sdl/

http://www.microsoft.com/en-us/sdl/

SDL Steps


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


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


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


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


SDL – Design (Cont.)

• Use Threat Modeling• Apply a structured approach to threat scenarios

• More effective & less expensively identification of vulnerabilities, risks, & mitigations


Source: https://technet.microsoft.com/en-us/security/dn140238.aspx

https://technet.microsoft.com/en-us/security/dn140238.aspx

Threat Modeling


Source: https://www.owasp.org/index.php/Application_Threat_Modeling

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


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 modelsCopyright © 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


SDL – Response

• Execute Incident Response Plan• Help protect customers from software security or

privacy vulnerabilities

• Practice, practice, practice


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


Training for All Steps

• Ensure Best Practices are integral to the development program & applied over lifecycle of Application


Req

uir

emen

ts Security Requirements

Compliance Analysis

Governance Definition

Des

ign Risk

Assessment

Secure Architecture

Imp

lem

enta

tio

n Code Reviews

Code Analysis

Ver

ific

atio

n Security Testing

Risk Assessment Review

Penetration Testing

Rel

ease Security

Review

Incident Response Plan R

esp

on

se Incident Forensics

Security Monitoring

Security Awareness Trainings


Remember – It’s a Cycle


Source: www.juniper.net/us/en/security/sdl/

http://www.juniper.net/us/en/security/sdl/

Agile Development

• Security better aligns to waterfall-like processes

• Can be used in Agile methods with proper care


Source: www.screenmedia.co.uk/blog/2014/08/what-is-agile-development-a-brief-introduction/

http://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


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


OpenSAMM


Source: www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model

https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model

Where to Begin


Secure Development

• Start with known/common vulnerabilities


Source: www.securityninja.co.uk/secure-development/the-principles-place/

http://www.securityninja.co.uk/secure-development/the-principles-place/

Top Vulnerabilities


Source: https://geekflare.com/online-scan-website-security-vulnerabilities/

https://geekflare.com/online-scan-website-security-vulnerabilities/

OWASP Top 10


Source: http://dunnesec.com

http://dunnesec.com/

A1: Injection

• SQL Injection

• OS Command Injection


SQL Injection – Solution


Source: www.owasp.org

http://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


http://www.w3schools.com/sql/sql_injection.asp

https://www.owasp.org/index.php/Command_Injection

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet

http://www.codeproject.com/Tips/586207/How-to-prevent-SQL-Injection-in-Stored-Procedures

A2: Broken Authentication & Session Management• http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

• Suppose a user e-mail this link to a friend

• Has session ID

• May include credit card nos, & other unique data


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


http://www.tutorialspoint.com/security_testing/testing_broken_authentication.htm

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

A3: Cross-Site Scripting (XSS)


Source: http://www.acunetix.com/blog/articles/blind-xss/

http://www.acunetix.com/blog/articles/blind-xss/

XSS Example


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_Prevention_Cheat_Sheet

• DOM based XSS Prevention Cheat Sheet• https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_S

heet


https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

https://crypto.stanford.edu/cs155/papers/CSS.pdf

http://www.w3schools.com/php/php_form_validation.asp

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

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


Insecure Direct Object References – Example


Source: http://lazarusalliance.com/test-your-owasp-knowledge/

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


• http://www.tutorialspoint.com/security_testing/insecure_direct_object_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_Object_References_%28OTG-AUTHZ-004%29


http://www.tutorialspoint.com/security_testing/insecure_direct_object_reference.htm

https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference

https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)

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


• http://www.tutorialspoint.com/security_testing/testing_security_misconfiguration.htm


http://www.tutorialspoint.com/security_testing/testing_security_misconfiguration.htm

A6: Sensitive Data Exposure

• Not using SSL

• Use of account & credit card numbers without hashing

• Unencrypted passwords & credit card numbers


Source: www.htbridge.com/vulnerability/common-web-weaknesses/

https://www.htbridge.com/vulnerability/common-web-weaknesses/

Sensitive Data Exposure –Solutions• Solutions

• Proper use of SSL 2.0• Hashing & encryption• PCD DSS & PA DSS


• http://www.tutorialspoint.com/security_testing/testing_sensitive_data_exposure.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


http://www.tutorialspoint.com/security_testing/testing_sensitive_data_exposure.htm

https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

A7: Missing Function Level Access Control• Due to in proper authorization


Source: www.slideshare.net/appsec/19-owasp-top-10-a7missing-function-level-access-control

http://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


• http://www.tutorialspoint.com/security_testing/missing_function_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


http://www.tutorialspoint.com/security_testing/missing_function_level_access_control.htm

https://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access

https://www.owasp.org/index.php/Guide_to_Authorization

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" />


Source: http://www.redteamsecure.com/labs/post/66/Demystifying-Cross-Site-Request-Forgery

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


• http://www.tutorialspoint.com/security_testing/cross_site_request_forgery.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


http://www.tutorialspoint.com/security_testing/cross_site_request_forgery.htm

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/CSRFGuard

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


• http://www.tutorialspoint.com/security_testing/components_with_vulnerabilities.htm

• OWASP Dependency Check• https://www.owasp.org/index.php/OWASP_Dependency_Check


http://www.tutorialspoint.com/security_testing/components_with_vulnerabilities.htm

https://www.owasp.org/index.php/OWASP_Dependency_Check

A10: Unvalidated Redirects & Forwards• Unvalidated forwarding & redirectionshttp://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

• Solutions• Avoid using redirects & forwards• Use without involving user parameters in redirecting the

destination


• http://www.tutorialspoint.com/security_testing/unvalidated_redirects_and_forwards.htm

• Unvalidated Redirects and Forwards Cheat Sheet• https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_

Cheat_Sheet


http://www.tutorialspoint.com/security_testing/unvalidated_redirects_and_forwards.htm

https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet

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/


https://www.owasp.org/index.php/.NET_Security_Cheat_Sheet

https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

https://www.owasp.org/index.php/PHP_Top_5

https://msdn.microsoft.com/en-us/library/ff648647.aspx

http://www.smashingmagazine.com/2010/10/common-security-mistakes-in-web-applications/

Tools

• Static Application Security Testing • HP Fortify

• Veracode

• SonarQube

• Dynamic analysis• Acunetix

• Burp Suite

• w3af


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


Q & [email protected]


security culture from concept to maintenance: secure software development life cycle

Engineering