Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
1
BUILDING SECURE
SOFTWARE APPLICATIONS
An introduction to SSDLC
for web and mobile applications
robertGrupe, CISSP, CSSLP, PE, PMP
version: 2017-06-21
Tags :: SSDLC, Application, Software, Security, Development, AppSec,
DevOps, DevSecOps OWASP, Agile, Kanban, Scrum, Best Practices, Feature
Driven Development, FDD, Test Driven Development , TDD

2
Contents
• Threats and Impacts of Insecurity
• Risks & Controls
• Secure Application Development Process: SSDLC
• Reducing Risks: Secure-SDLC & Testing

3
THE PROBLEM:
APPLICATION DATAATTACKS

4
US Data Breach Costs
per person/record
• Data Breaches Increasing Every Year
• Despite mature IDS & vulnerability prevention tools and techniques
• Increased spending on security
• Top Industries Cost (increasing remediation
consequences)
• 1. Healthcare $233
• 2. Finance $215
• 3. Pharmaceutical $207
• Top Causes
• 41% Malicious attack
• 33% Human Factor
• 26% System glitch

5
Critical Data Breaches Analysis
• Attack Types
• 76% weak or stolen credentials
• 29% social engineering
• 13% privilege use or misuse
• Other: 52% hacking, 40% malware, 35% physical
• Malicious Actors Types
• 14% insiders
• 7% multiple actors
• 1% business partners
• Other: 92% external (50% criminals,19% foreign states (e.g. NK, etc)
• Commonalities
• 75% are considered opportunistic attacks
• 78% of initial intrusions rated as low difficulty
• 66% took months or more to discover

6
Top Web Application Vulnerabilities
• Praetorian Study of Penetration Tests and
• 66% Weak domain user passwords (a root cause of compromise)
• 64% Broadcast name resolution poisoning (aka WPAD)
• 61% Local administrator attacks (aka Pass the Hash)
• 56% Cleartext passwords stored in memory (aka Mimikatz)
• 52% Insufficient network access controls

7
The Need for Secure Software
Development Life Cycle (SSDL)
• 40% of breaches occur due to hacking (i.e. successful
exploitation of a software vulnerability)
• Responsible for 90% of the compromised records
• Bad News: >half applications found with vulnerabilities
• applications fail to achieve compliance on 1st submission
(OWASP Top 10, list of critical web application errors)
• 56% of outsourced applications
• 54% of internal developed applications
• Good News
• >80% achieve an acceptable security quality within 1 month

8
Top Vulnerability Categories
Vendor Supplied Web Application
• 79% Information
Leakage
• 71% Cross-Site
Scripting (XSS)
• 67% Cryptographic
Issues
• 67% Directory Traversal
• 67% CRLF Injection
• 51% Time and State
• 48% Insufficient Input
Validation
• 40% SQL Injection
• 35% API Abuse
• 34% Credential
Management
• 23% Encapsulation
• 21% OS Command
Injection
• 19% Session Fixation
• 18% Race Conditions
• 11% Error Handling

9
Minimizing Data Exposure
• Users and credentials significant vulnerability that can’t be
addressed by technical protection solutions alone
• Protecting critical data access, privileges, and credentials
• Usability design to minimize unintended data exposure
• Administrative processes to minimize potential abuse

10
The Cost of Bad SW Testing
Introduced/
Detected
Rqmnts Design Dev Sys Test Prod.
Requirements 1× 3× 5–10× 10× 10–100×
Architecture - 1× 10× 15× 25–100×
Construction - - 1× 10× 10–25×
“Code Complete”, Steve McConnell, Microsoft Press
NIST US Study
Software bugs cost $59.5 billion annually
More than 1/3 of this cost could be avoided if better software testing was
performed.

11
Costs of Delayed Vulnerability Detection
Cost to Fix Defects
• Not to mention potential…
• Regulatory fines
• Legal Regress
• Reputation damage
• Business loss
• Therefore: Primary AppSec Objective Should Be
• to minimize vulnerabilities during design and coding (proactive)
• not just detect and fix prior to release in Testing (reactive)
• to minimize project impact costs
• to minimize production fix costs and liability exposure due from
‘should-have-known’
Coding
$80
94X savings
Build
$240
31X savings
Test
$960
7X savings
Production
$7,600
*

12
Why AppSec is important and need for
SSDLC
• Compliance: legal & regulatory requirements to provide
business services online
• Federal & states Laws: personal data privacy & business licensing
• PCI: Payment card transactions
• HIPAA: Heath Care Information
• SOX: Publicly traded companies (or plan for IPO)
• Trust: Customer Specific Requirements
(protecting their systems, data, and reputations):
• DoD, Federal agencies, etc.
• Commercial supplier/partner
• Business Continuity
• Minimize malicious disruptions
• Data loss protection
• 92% of organization vulnerabilities through Internet applications

13
THE TALE OF
3 LITTLE PIGS

14
The first little pig built his house out of
straw…
No S-SDLC: Code, Release, & Hope
• Project Execution without S-SDLC
• No IT-Security involvement in estimation, scheduling, or delivery.
• Potential Outcome after 1st production release
• Hacker discovers vulnerabilities and compromises application
• Data Breach with PII and PHI posted and sold
• Company impacts
• $600+MM fine compliance fines
• $$MM’s for remediation and communications
• Civil lawsuits to company and individuals
• Unknown lost new business opportunities
• Reduced customer renewals
• Company stock shares lost value (company bonuses)
• Personal impacts
• Project and Program managers and their managers termination
• Involved in subsequent legal proceedings
• Lost professional reputation

15
The second little pig built his house out of
wood…
Minimum Security: Final Phase Security Testing
• Risk Assessment at beginning of project
• Too little information to properly evaluate
• (Especially when using Agile)
• Relies on information provided by non-security experts
• End of Project: Pen Testing
• Delays caused by resolving found defects
• 2 weeks to run test, 1+ weeks to remediate
• Results in avoidable Risk Acceptances due to time and budget
constraints
• Potential Outcome
• Hacker discovers vulnerabilities and compromises system
• user management design flaw
• Accepted known risks
• Company impacts - same as #1
• Personal impacts
• IRM and Executives professional reputations

16
Can’t just rely on periodic spot checking
• Periodic Audit and Fix
• Few man-days of ethical hacking FOR man-years of dev coding
• Business logic flaws (can’t test of unknown by tester)
• Code flaws
• Security errors
• PEN Testing
• against known vulnerabilities (OWASP)
• 80-90%?? of app coverage
• Easily overlooks privileged data access validation
• Just before release
• but not enough time to address properly, not funding to resolve the
causing architecture issues
• Maybe a couple times throughout year in production
• But attackers have 24x7x365

17
But the third little pig built his house with
bricks…
S-SDLC with parallel security verifications
• Security involved throughout development
• Identified & estimate included security
• Design
• Coding
• Testing
• Outcomes
• More accurate project cost and schedule estimates
• Faster development (re-useable requirements, tools,
and processes)
• Final QA: Minimal release disruptions
• Hackers unable to find easily exploitable/known
vulnerabilities
• But if breach…
• No compliance fines
• Positive company PR: lessons learned -
prevention and response

18
APPLICATION SECURITY
RISKS
18

19
Regulatory Best Practice Requirements
PCI DSS Requirements Testing Procedures Guidance
6.5 Address common coding
vulnerabilities in software-development
processes as follows:
Train developers at least annually in
up-to-date secure coding techniques,
including how to avoid common coding
vulnerabilities.
Develop applications based on
secure coding guidelines.
Note: The vulnerabilities listed at 6.5.1
through 6.5.10 were current with industry
best practices when this version of PCI
DSS was published. However, as
industry best practices for vulnerability
management are updated (for example,
the OWASP Guide, SANS CWE Top 25,
CERT Secure Coding, etc.), the current
best practices must be used for these
requirements.
6.5.a Examine software-development
policies and procedures to verify that
up-to-date training in secure coding
techniques is required for developers
at least annually, based on industry
best practices and guidance.
The application layer is high-risk and may be targeted
by both internal and external threats.
Requirements 6.5.1 through 6.5.10 are the minimum
controls that should be in place, and organizations
should incorporate the relevant secure coding practices
as applicable to the particular technology in their
environment.
Application developers should be properly trained to
identify and resolve issues related to these (and other)
common coding vulnerabilities. Having staff
knowledgeable of secure coding guidelines should
minimize the number of security vulnerabilities
introduced through poor coding practices. Training for
developers may be provided in-house or by third parties
and should be applicable for technology used.
As industry-accepted secure coding practices change,
organizational coding practices and developer training
should likewise be updated to address new threats—for
example, memory scraping attacks.
The vulnerabilities identified in 6.5.1 through 6.5.10
provide a minimum baseline. It is up to the organization
to remain up to date with vulnerability trends and
incorporate appropriate measures into their secure
coding practices.
6.5.b Examine records of training to
verify that software developers
receive up-to-date training on secure
coding techniques at least annually,
including how to avoid common
coding vulnerabilities.
6.5.c Verify that processes are in
place to protect applications from, at
a minimum, the following
vulnerabilities:
• Example: Payment Card Industry (PCI)

20
Open Web Application Security Project
(OWASP)
• A 501c3 not-for-profit
• worldwide charitable organization focused on improving the
security of software.
• Mission is to make application security visible
• So that people and organizations can make informed decisions
about true application security risks
• Everyone is welcomed
• to participate, and
• all of materials are available under free and open software
licenses.

21
OWASP Top 10
• Not a standard…
OWASP Top 10 is an Awareness Document
• Was probably 3rd or 4th OWASP project, after
• Developers Guide
• WebGoat
• Maybe WebScarab ??
First developed in 2003
• 2003, 2004, 2007, 2010, 2013, 2017
Released

22
OWASP Risk Rating Methodology
Threat
Agent
Attack
Vector
Weakness
Prevalence
Weakness
Detectability
Technical
Impact
Business
Impact
?
Easy Widespread Easy Severe
?Average Common Average Moderate
Difficult Uncommon Difficult Minor
1 2 2 1
1.66 * 1
1.66 weighted risk rating
Injection
Example
1
2
3

23
OWASP Top 10: 2010 OWASP Top 10: 2013
2010-A1 – Injection 2013-A1 – Injection
2010-A2 – Cross Site Scripting (XSS)
2013-A2 – Broken Authentication and Session
Management
2010-A3 – Broken Authentication and Session
Management
2013-A3 – Cross Site Scripting (XSS)
2010-A4 – Insecure Direct Object References 2013-A4 – Insecure Direct Object References
2010-A5 – Cross Site Request Forgery (CSRF) 2013-A5 – Security Misconfiguration
2010-A6 – Security Misconfiguration 2013-A6 – Sensitive Data Exposure
2010-A7 – Insecure Cryptographic Storage 2013-A7 – Missing Function Level Access Control
2010-A8 – Failure to Restrict URL Access 2013-A8 – Cross-Site Request Forgery (CSRF)
2010-A9 – Insufficient Transport Layer Protection
2013-A9 – Using Known Vulnerable Components
(NEW)
2010-A10 – Unvalidated Redirects and Forwards
(NEW)
2013-A10 – Unvalidated Redirects and Forwards
3 Primary Changes:  Merged: 2010-A7 and 2010-A9 -> 2013-A6
 Added New 2013-A9: Using Known Vulnerable
Components
 2010-A8 broadened to 2013-A7
Changes over Time

24
YEAH, BUT …
That’s all fine to identify the problems,
but how do we eliminate void them in the first place?
24

25
OWASP Top Ten Proactive Controls 2016
C1: Verify for
Security Early
and Often
C2:
Parameterize
Queries
C3: Encode
Data
C4: Validate All
Inputs
C5: Implement
Identity and
Authentication
Controls
C6: Implement
Appropriate
Access Controls
C7: Protect Data C8: Implement
Logging and
Intrusion
Detection
C9: Leverage
Security
Frameworks and
Libraries
C10: Error and
Exception
Handling

26
OWASP Top 10 Controls to Risks Mapping

27
ENTERPRISE METRICS

28
Your Metrics
Pen Test Defect Tracking
• Metric Quality Problems
• Not all applications are tested
• Limited staffing, only test some of requests
• Each new/release is not tested
• Annual testing only for selected
• QA is not a mirror of production
• Result inconsistencies
• If improve rigor of testing (improve frequency and depth through
automation)
•Metrics will suffer (find more defects)
• Frequency of tests is not uniform
• If decrease frequency of testing, then metrics will improve (less defects
found)

29
APPLICATION SECURITY
SCOPE

30
Open Systems Interconnection model
(OSI model)

31
SSDLC

32
Secure Software Development Life Cycle
(SSDLC) Objectives & Benefits
• Regulatory:
• Reduce regulatory compliance auditing time and effort
• Common documented and logged process
• Risk
• Reduce risk and potential business disruptions from
• Malicious data breach
• Accidental misuse or malicious attacks
• Proficiency
• Reduce development time to find and fix vulnerabilities
• Improve secure application developer and testing skills

33
Requirements
(Scoping)
Design
Implementation
(Development)
Verification
(Test)
Release
• AppSec
Requirements
(User Stories
with
Acceptance
Criteria)
• Security &
Regulatory Risk
Assessment
• Frameworks
Patterns
• Analyze Attack
Surface
• Threat
Modeling
• Approved Tools
• Deprecate
Unsafe
Functions
• Static Analysis
• Unit Tests/
User Story
Acceptance
• Dynamic
Analysis
• Fuzz Testing
• Attack Surface
Review
• Penetration
Testing
• Deferred
Defects
Risk
Acceptance
• Go/No-Go
Response
• Security Incident
Response Plan
Retire
• Decommissioning
Plan
Select
Design
Develop
Verify
Release
Agile

34
Secure Software Development
Components

35
Agile: Scrumban FDD*
• Kanban workflow†
• Scrum development
Ideas Features
w/User
Stories
Design Dev Test
Static
Test
Dynamic
Final
Approval
Release
WIP Limit
* Feature Driven Development
† Adaptive Software Development

36
DevOps with Agile, CI, and CD
Plan Code Build Test Release Deploy Operate
Dev Ops
Continuous Delivery
Continuous Integration
Agile Development

37
DevOps
Dev
• Plan: Requirements, Architecture, Schedule
• Create: Design, Coding, Build
• Verify: Test
• Package: Pre-Production Staging
Ops
• Release: Coordinating, Deploying
• Configure: Infrastructure, Applications
• Monitor: Performance, Use, Metrics
DevOps
Collaboration of software delivery teams:
• Developers;
• Operations;
• Quality Assurance: Testers
• Management;
• ... etc.
Continuous Development
automate delivery, focuses on
• Bringing together different
processes;
• Executing them more quickly and
more frequently.

38
SSDLC with DevOps
Security Feature Driven Development
• User Stories
• Assess Risks
• Frameworks/Patterns
• Attack Analysis
• Threat Modeling
• Approved Tools
• Deprecate Functions
• Static Analysis
• Unit Tests
• Dynamic Analysis
• Fuzz Testing
• Attack Review
• Penetration Testing
• Risk Acceptance
• Go/No-Go
• Logs
• Alerts
• Management
• Usage
• Changes
• Vulnerabilities
• Dashboards & Reports

39
Agile: Features Program Management
• Backlog: Product(s) Program Management
• Development: Scrum (or could be Kanban)
Ideas Business
Case
Approval
& Priority
Features
Detailing
Features
Completed
Security
Evaluation
Features
Ready
Features
In Work
WIP Limit
Initial draft Rational for
prioritization
Approval
to proceed
US
detailing
US’ done Sec Rqmnts
& Pen Test ?
Y/N
Ready for
team(s)
In team
backlogs

40
Automation AppSec Test Harness
Security
Code
Reviews
STAT: Static
AppSec
Testing
Defect and
Task Tracker
DAST:
Dynamic
AppSec
Testing
Manual
Interactive
AppSec
Testing
Vulnerability
Test Manager
Security
Penetration
(Pen) Testing
App Svr
RASP:
Responsive
Application
Security
Protection
AppSec
Rqmnts
QA Tests

41
DevSecOps
Security Test Driven Development
• Threat Analysis
• CI Training
• SAST in IDE
• SAST in build mgmt
• Automated Security
Requirements QA
• DAST
• RASP
• SIEM
• Secure Code Review
• Fuzzing (PenT)
• Bug Bounty

42
APPLICATION RISK
ASSESSMENT

43
Requirements
(Scoping)
Design
Implementation
(Development)
Verification
(Test)
Release
• AppSec
Requirements
(User Stories
with
Acceptance
Criteria)
• Security &
Regulatory Risk
Assessment
• Frameworks
Patterns
• Analyze Attack
Surface
• Threat
Modeling
• Approved Tools
• Deprecate
Unsafe
Functions
• Static Analysis
• Unit Tests/
User Story
Acceptance
• Dynamic
Analysis
• Fuzz Testing
• Attack Surface
Review
• Penetration
Testing
• Deferred
Defects
Risk
Acceptance
• Go/No-Go
Response
• Security Incident
Response Plan
Retire
• Decommissioning
Plan
Select
Design
Develop
Verify
Release
Agile

44
AppSec Risk Assessment Core Artifacts
• Risk Assessment Inputs
1. Context Diagram
• User Roles
• Features (Epic User Stories)
• Main interactive systems
2. User Roles & Privileges/Permissions Matrix
3. Feature Use Case Process Flow Diagrams
• Feature Use Cases of Users for each Feature
• Notifications & Messages (with errors information)
4. Data Flow Diagram
• Application communications/services: authentication & encryption
5. Data Map
• From UI to storage: sensitivity & encryption
• Threat Modeling Risk Assessment Output:
Security Requirement User Stories
• From AppSec Requirements Library (compliance & standards)
• From SSDLC based on sensitivity of data and application complexity

45
AppSec Risk Assessment Core Artifacts

46
Scope Definition
1 Context Diagram
(Functionality, Users, & External Entities)

47
Scope & Design
2 Access Roles & Permissions Matrix
Role Name Description Permissions
Product Requirements
External Regular User Default external user X X
External Group Manager SAM primary contact X X X
Internal User Default internal user X X X X
Support User Help Desk, administrate
user accounts and change
user settings
X X X X
Application Administrator Administrate all users and
settings
X X X X X
Per Design
Service 1, ... Connector for XyZ
functionality
X X X X X X

48
Requirement Detailing
3 Feature Use Case Process Flow
Diagram

49
Architecture Design
4 Data Flow Diagram
• Note: Consider all APIs and Content Delivery Networks (CDNs)
+ For all connections add:
• Communication protocol &
• Security used

50
Architecture Design
5 Data Map

51
SUMMARY

52
Calculating How Much You Should Invest
Business Risk Exposure & Mitigation
• Application Attractiveness (AA=$BMRV*Records)
• Black Market Resell Value of Your Data Records
• Number of Records
• Breach Cost Exposure
• Multi-Jurisdiction Fines per Record
• Incident Response & Recovery Costs
• Lost Business
• Your Security Confidence (use as annual probability)
• Testing Methodology Coverage (types used in each phase)
• NOTE: The problem with AppSec is that its costs aren’t
factored into the Solution ROI. Analysis needs to be done as
part of Business Case to Identify Exposure, and Mitigation
Investment Required (tools, processes, staffing)

53
Improving Your Application Security
• Keep in mind
• Periodic Penetration isn’t enough
• AppSec isn’t quick, easy, or free
• Prerequisites
• Select an ISMS framework
• Understand your legal & regulatory data protection requirements
• Create a Threat Agent and Mis-Use Library
• Establish your standard security requirements list
• Define your security requirement test cases
• Define your S-SDLC: Waterfall, Agile, CI/CD
• Design Phase
• UI critical data work-flow-diagramming
• Critical data storage and communications diagramming
• Threat Assessments with Business Team
• QA Test Case Scripts
• User Acceptance Testing
• Secure administration and mis-use UI testing

54
S-SDLC Dev & Testing
• Develop Secure Code
• Follow the best practices in OWASP’s Guide to Building Secure Web
Applications
• https://www.owasp.org/index.php/Guide
• And the cheat sheets: https://www.owasp.org/index.php/Cheat_Sheets
• Use OWASP’s Application Security Verification Standard as a guide to what an
application needs to be secure
• https://www.owasp.org/index.php/ASVS
• Use standard security components that are a fit for your organization
• Use OWASP’s ESAPI as a basis for your standard components
• https://www.owasp.org/index.php/ESAPI
• Review Your Applications
• Have expert SMEs/Mavens review your applications
• Leverage OWASP Guidelines
• OWASP Code Review Guide:
https://www.owasp.org/index.php/Code_Review_Guide
• OWASP Testing Guide:
https://www.owasp.org/index.php/Testing_Guide

55
enisa: AppSec Is More People Than tech
• Information technology security administrators should expect to
devote approximately one-third of their time addressing technical
aspects.
• The remaining two-thirds should be spent developing policies and procedures,
performing security reviews and analyzing risk, addressing contingency
planning and promoting security awareness;
• Security depends on people more than on technology;
• Employees are a far greater threat to information security than
outsiders;
• Security is like a chain. It is as strong as its weakest link;
• The degree of security depends on three factors:
• the risk you are willing to take, the
• functionality of the system and
• the costs you are prepared to pay;
• Security is not a status or a snapshot but a running process.
• Conclusion
• Security administration is a management and NOT a purely technical issue

56
Recommendations for
Your AppSec SSDLC Implementation
1. Evaluate where you are
• Start Small: Recognize that this is a journey
• OWASP SSAM
2. Make a prioritized plan
3. Microsoft SSDL: stripped down to what you can realistically
do
4. Identify your business security requirements
5. Specify your controls (encryption)
6. Make sure you are building with clean tools
7. Document your designs (intake documents)
8. Understand your threats and their motivations
• Risk Assessments: think like a malicious attacker
9. Get a Dynamic Testing tool and start to use it

57
And Finally: Implementation
Progress Tracking
• OWASP SAMM
(Software Assurance Maturity Model)
• ~12 month implementation
• Additional resourcing staffing and skills (QA for compliance)
• OWASP Top 10
• Threat Modeling
• Risk Management
• Assessment Tools

58
Finis
• Robert Grupe, CSSLP PMP CISSP
robert@rgrupe.com
+1.314.278.7901
• References
• This presentation @ http://rgrupe.com
• Microsoft Secure Development Lifecycle
@ https://www.microsoft.com/en-us/sdl/
• OWASP
@ https://www.owasp.org
• Software Assurance Maturity Model (SAMM)
• Best Practices: Web & Mobile Applications
• Testing Guidance
• Reference Sheets
• Much more

Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

More Related Content

What's hot

Similar to Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

More from Robert Grupe, CSSLP CISSP PE PMP

Recently uploaded

Red7 SSDLC Introduction: Building Secure Web and Mobile Applications

Editor's Notes