-
1.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
2
Contents
• Threats and Impacts of Insecurity
• Risks & Controls
• Secure Application Development Process: SSDLC
• Reducing Risks: Secure-SDLC & Testing
-
3.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
3
THE PROBLEM:
APPLICATION DATAATTACKS
-
4.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
13
THE TALE OF
3 LITTLE PIGS
-
14.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
18
APPLICATION SECURITY
RISKS
18
-
19.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
24
YEAH, BUT …
That’s all fine to identify the problems,
but how do we eliminate void them in the first place?
24
-
25.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
26
OWASP Top 10 Controls to Risks Mapping
-
27.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
27
ENTERPRISE METRICS
-
28.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
29
APPLICATION SECURITY
SCOPE
-
30.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
30
Open Systems Interconnection model
(OSI model)
-
31.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
31
SSDLC
-
32.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
33
Requirements
(Scoping)
Design
Implementation
(Development)
Verification
(Test)
Release
Secure Software Development Life Cycle
• 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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
34
Secure Software Development
Components
-
35.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
36
DevOps with Agile, CI, and CD
Plan Code Build Test Release Deploy Operate
Dev Ops
Continuous Delivery
Continuous Integration
Agile Development
-
37.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
42
APPLICATION RISK
ASSESSMENT
-
43.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
43
Requirements
(Scoping)
Design
Implementation
(Development)
Verification
(Test)
Release
Secure Software Development Life Cycle
• 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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
45
AppSec Risk Assessment Core Artifacts
-
46.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
46
Scope Definition
1 Context Diagram
(Functionality, Users, & External Entities)
-
47.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
48
Requirement Detailing
3 Feature Use Case Process Flow
Diagram
-
49.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
50
Architecture Design
5 Data Map
-
51.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
51
SUMMARY
-
52.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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.
Red7:|:applicationsecurity
© Copyright 2017 Robert Grupe. All rights reserved.
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
Every week there are new stories about information data breaches, hacker service disruptions, ransomware blackmailing, government spying, and disgruntled employee sabotage.
And yet most start-up software and mobile applications are rushed to market using the “Code, Release, and Hope” approach; which unfortunately leaves them vulnerable to malicious attackers and legal actions as a result of inadequate personal, financial, and health information protection.
This session will provide an overview of the Secure Software Development Life Cycle (SSDLC) process, along with some simple tools and techniques that can help improve application hardening and data protection.
Bio
From Fortune 100 to start-up companies, Robert Grupe is an international professional with practitioner, leader, and consultant experience in information security, market strategy, development, and support for global leaders in information technology, health care, high tech industries.
Robert is a registered Certified Information Security Professional (CISSP), Certified Secure Software Lifecycle Professional (CSSLP), and Project Management Professional (PMP).
2013 Cost of Data Breach Study: Global Analysis, Ponemon Institute
Source: Verizon 2013 Data Breach Investigations Report
Praetorian Study Attacks 2016-08-22
- http://www.theregister.co.uk/2016/08/22/hacker_playbook/
NIST 2002 study - http://www.abeacha.com/NIST_press_release_bugs_cost.htm
Source: IBM Global Business Services industry standards
Broken Auth and Session Management moved up, we believe, because more consulting organizations were included in this data set, and they can find this better than automated tools can. We don’t believe the actual prevalence of this issue increased, just the measured prevalence.
CSRF dropped we believe because organizations are getting a handle on this new issue that was first added to the Top 10 in 2007. The awareness the Top 10 raised, has helped reduce the prevalence of this issue (we believe).
https://www.owasp.org/index.php/OWASP_Proactive_Controls
https://www.owasp.org/index.php/OWASP_Proactive_Controls#Top_10_Mapping_2016
https://en.wikipedia.org/wiki/OSI_model
http://www.microsoft.com/en-us/sdl/default.aspx
Policy (objectives)
Principles to guide decisions and achieve acceptable outcomes.
Minimizing profit loss (government fines, customer trust, etc.)
SSDLC (Secure Software Development Life Cycle)
Protocol/procedure for implementing policy
Standards (ways of doing things)
Governments, industry organizations
Requirements (acceptance criteria: what and why)
Compliance with policy and standards
Training (how, what, why)
Check Lists (reminders)
Auditor
Government (HIPAA)
Industry (PCI)
Customer (DoD)
Legal (lawsuit discovery)
Internal (Quality Improvement)
https://en.wikipedia.org/wiki/Agile_software_development
https://en.wikipedia.org/wiki/Scrum_(software_development)
https://en.wikipedia.org/wiki/DevOps
https://en.wikipedia.org/wiki/DevOps_toolchain
Plan Tools: Atlassian (JIRA/Confluence), CA Technologies, iRise and Jama Software
Create Tools: Bitbucket, GitLab, GitHub, Electric Cloud, and CFEngine
Verify Tools: * Test automation (ThoughtWorks, IBM, HP), * Static analysis (Parasoft, Microsoft, SonarSource), * Test Lab (Skytap, Microsoft, Delphix), and * Security (HP, IBM, Trustwave, FlawCheck).
Packaging Tools: Jfrog’s Artifactory, SonaType Nexus repository, and Inedo’s ProGet.
Release Tools: Automic, Inedo, VMware, and XebiaLabs* application release automation* deployment automation* release management
Configure Tools: Ansible, Chef, Puppet, Otter, and Salt* Continuous Configuration Automation, * configuration management, and * Infrastructure as Code tools.
Monitoring Tools: BigPanda, Ganglia, New Relic, Wireshark
http://www.microsoft.com/en-us/sdl/default.aspx
enisa European Network and Information Security Agency Risk Management: Implementation principles and Inventories for Risk Management/Risk Assessment methods and tools June 2006. sec 3.1.1
From The Daily Drucker, 3/13