Putting Security Into SDLC-OWASP v2

Case Study: An Evolution of
Putting Security into SDLC
Curtis Coleman, MSIA, CISSP, CISM

Director, Global IT Governance
Seagate Technology
SILICON
OWASP
VALLEY
CHAPTER
AppSec
MEETING
June 2004 NYC Copyright © 2004 – Seagate Technology
Permission is granted to copy and distribute for Fair Use Only
The OWASP
http://www.owasp.org
Foundation
G u ilty
G ets l eads raud
y P F
oda d ian Online
L I MT eek Ca na
l i on
AO ed W i l
60 Muters,
t e r IIS
a ck ompu o $ S
H ral C
ede iPl
t -- R e 200 2
, be e ervers
—F l 30 unn xploite can
7 , 2002 ane
tS Apri
r il 2 - Se otic d
Ap onl erver curi
t y W ed
ine ho at c
— b le a 200 h, Sep
The ank
ing ffects , 1 t6
Ap Re Go
ril gis
28,
2
te
001 r d as in v’t P
e s Re Ha Den ayr
e se f New ck ver oll
ers O Sy
tscap rns o pe st
r D isrupts Ne I wa ack 1
-M
SN n t em
Hac ke FB Att 200 o
i ty W ebsite g1
7 , BC
, Ju
Univers ept 6, 2001
u
s, A ly
10
— CN N
,S byte ,2
ews 00
—N
1
Code Red:Alive
Po
again and Kicking
we
rG — Zdnet Aug 1, 2001
b a nks
rid
V Milit so me rds
H u l a r c e c a
—
LA ack
e
n er a
b
y Hack
e ers for d ebit 2001
Tim r le t D efen r s k sa pt 5 ,
es, s o se o hit US Hac l V i e
Aug
13, — vn ffice ca nce terWorld , S
2 001 April u ne t.comto pu
om
2 6, 20
02
, —C
Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 2
Permission is granted to copy and distribute for Fair Use Only off
Application Security Is the Trend of the
Future
“The biggest vulnerability to a corporation’s network
is its widespread access to its applications. Security
has focused on anti-virus and network security –
but the most crucial part of business transaction is
the application and its core data.”
-- Curtis Coleman, CISSP,
Kick-off of new Application Assurance Department, 2001
3rd Age Age of Application Security

2nd Age Age of Network Security
1st Age Age of Anti-Virus

Web based technology simplifies attacks
 Everyone gets hacked, from large e-Commerce

sites, such as Yahoo!, to government agencies,
such as the FBI and CIA
 In the past a majority of security breaches occurred
at the network layer
 The next level of attacks will focus at manipulating
web applications inside the firewall
 Given a tiny hole in the application code
 Armed with only a browser
 Hackers will access and sabotage corporate and customer
data

Why isn’t the Web Environment secure?
 SSL and Data-encryption are not enough

 They protect the information during transmission,
but when this data is used by the system it must
be in a readable form
 Odds are the data is not stored in an encrypted
format
 It is surprisingly easy to retrieve data from many
Web-based applications
 Firewalls are not enough
 Ports 80 and 443 pass completely through the
firewall

But, I have a firewall . . .
Source: Jeremiah Grossman, BlackHat

2001
OK, but I use encryption . . .
Source: Jeremiah Grossman, BlackHat

2001
Why Application Security Defects
Matter  Frequent
• 3 out of 4 business websites are
21% Full vulnerable to attack (Gartner)
Control and
Access to
Information
 Pervasive
32% Hijack
Session/ 7% Modify • 75% of hacks occur at the
Identity Theft Information Application level (Gartner)
 Undetected
• QA testing tools not designed to
27% Privacy detect security defects in
11%
Breach
e-Shoplifting applications
2% Delete Web
Site • Manual patching - reactive, never
ending, time consuming and
expensive
 Dangerous
>1000 application ‘Healthchecks’ with AppScan – • When exploited, security defects

destroy company value and
98% vulnerable: all had firewalls and encryption customer trust
solutions in place…

Impact of Security Defects
Bad Business
• On average, there are 5 to 15 defects in
every 1,000 lines of code
 US Dept. of Defense and the Software
Engineering Institute
Slow Business
• It takes 75 minutes on average to track
down one defect. Fixing one of these
defects takes 2 to 9 hours each
 5 Year Pentagon Study
• Researching each of the 4,200
vulnerabilities published by CERT last year
for 10 minutes would have required 1
staffer to research for 17.5 full workweeks
or 700 hours
 Intel White paper, CERT, ICSA Labs
Loss of Business
• A company with 1,000 servers can spend
$300,000 to test & deploy a patch; most
companies deploy several patches a week
 Gartner Group

What then shall we do?

Kepner-Tregoe* Situation Appraisal
 Lack of resources for security test procedures/processes
 No means of measuring security testing processes
 Lack of consistent methodology/process for quality and testing
 Security test planning and execution is not uniform across IT
 No security testing standards/guidelines
 No information assurance test metrics
 No security test training process
 No clear definition of roles/responsibilities for security test activities
 No security acceptance testing standards for purchased products
 SDLC weak in security test guidelines
 No centralized process owner for security testing and standards
 Lack of rigorous security acceptance test processes
* The New Rational Manager, Kepner, H. & Tregoe, B.(1997)

System Development Lifecycle (SDLC) Security
Checkpoints

Using Six Sigma in Security
For Tool Selection and Improvement

Automating Application Vulnerability
Scanning

Key Variables - KPIVs and KPOVs

Fishbone Diagramming of Top Risks
KPIVs

Cause and Effect
Backdoor and debug options

Third party misconfiguration
1 2 3 4 5 6 7 8 9 10
Hidden field manipulation
Published vulnerabilities
Parameter tampering
Stealth commanding
Cross-site scripting
Forceful browsing
Cookie poisoning
Buffer overflow
EFFECTS
Developers
"Bugs" insert
Hidden Form fields Insecure
Application do URL More data and backdoors
Cookies can fields Forms accept default
not force a parameters than the security into
CAUSES be modified
browsing
used to
are
accept
application
upload of
holes in
settings in 3rd
applications
by client track metatags malicious party
order on client changed expects 3rd party and forget to
session code application
code remove for
production
Patches
Hacker can Hidden are
Null value Metatag Site
Return of jump directly fields delayed
causes characters Incoming defacement Unclear or
unarthorized to pages can be while
application are not data size is or server lack of Debugging is
information normally seen hackers
to enter filtered by not execution configuration turned on
to controlled by using have
undefined the checked of uploaded procedures
application authentication View published
state application code
mechanisms Source exploit
code
Previously
saved
Client Field Mis-
cookies are Parameters Patches
data is validation configurations Backdoors do
modified are not are not
not on server are published not require
and sent as checked by keep
validated are not on hacker passwords
current application updated
by server checked sites
cookies to
server
Database Error
statements messages and
Cookier are
(insert, comments in
not
delete) are the code
encrypted
not reveal
validated vulnerabilities

Measurement Systems Analysis – Design of
Experiment
Fully automated (without operator inference)
 Design:
– Test Site and scan tool on same machine
– 30 scan runs with randomized start time
– Classified for High-Medium-Low and Total Vulnerabilities
 Conclusion:
– Ability of Scan Tool to discriminate good from bad is suspect
– MSA feedback to Tool Maker results in observed improvements when
applying latest subscription.
Operator test
 Design:
– Same location, same machine, same Test Site
– Operator manually steps through application
– 3 operators, 3 sets of 10 scans
 Conclusion:
– Operator experience with Tool is key
– Knowledge of application logic is important
– New operators could run tool with minimum training and detect Red
Alerts

MSA: Measurement system is unreliable
 Tool was in its second patch release when Seagate adopted
 MSA showed the tool was not stable
 The MSA results were shared with the Sanctum’s CTO
Measurement system is suspect:

30 scans of single site should reveal the
same number of High, Medium, and Low
risk alerts each time scan is run

MSA: Tool Improves After Feedback
Using Auto Mode, AppScan correctly identified the number of
highs, mediums, and low vulnerabilities of the Hack-Me Web
site. Test was repeated 30 times.
Measurement system stablized:
Over a period of 2 months and three
generations of the tool code, the tool was
calibrated and improved.

MSA: Demonstrates Tool Training is Important!
The operators used the tool in “manual” mode. Total number
of possible High vulnerabilities detected by manual mode is
99.
 Anil – Most advanced operator, formal training with scan tool, knows
application logic, clustered at 98/99
 David – Very experienced with tool, clustered around 92
 Curtis – Never used tool before MSA test, clustered around 79

Pareto (80/20) Rule
Pareto for Vulnerabilities
9000 100
8000
7000 80
6000
Percent
60
Count
5000
4000
40
3000
2000 20
1000
0 0
g
ing ing g ng er in ning
m per m per c ript in ro ws i ta mp ois o
t a t a s l b e r p rs
Defect met e
r
m et e
r
s s s it e
or c ef
u
r a me
t
Co oki
e
Ot he
ar a ar a C ro m- F -P a um
-
-P h- P gh - ediu dium edi
Low 3901 Hig Hi e M
Count 2180 2064 M 184M 181 123 383
Percent 43.3 24.2 22.9 2.0 2.0 1.4 4.2
Cum % 43.3 67.4 90.3 92.4 94.4 95.8 100.0

What Then Shall We Test For?
 These Categories Are of Most Importance…

 Hidden Field Manipulation
 Parameter Tampering
 Cross-site Scripting
 Buffer Overflow
 Backdoor and Debug Options
 Cookie Poisoning
 Forceful Browsing
 Published Vulnerabilities
 Stealth Commanding
 Third Party Misconfigurations
A Tool For Tracking Test Results
Vulnerability Categorty Vs Severity
1
No. Of Vulnerabilities Open
3 2
Red
Yellow
1 3
1 2 2
1
1 1 1 1
0
Parameter Data Flow Forceful Cross-site Buffer overflow Stealth Published Hidden field
tampering browsing scripting commanding / vulnerabilities manipulation
SQL Injection
Vulnerability Category
Source: TestDirector

Provide Detail Report to Customer

Sample of Prioritizing Findings
High Threat
V1
V5
Forceful Browsing
V6
V3 Hidden Field Manipulation
4 V8 1
V7
Cookie Poisoning
Parameter Tampering
V4
Low High
Vulnerability Vulnerability
3 V2 2
Low Threat
2004 Statistical Analysis of Application
Vulnerabilities Discovered
Discovered Vulnerabilities by Categoryand Resolved
Discovered Vulnerabilities Resolved and Open Vulnerabilities

Stealth commanding/
SQL Injection
6%
Hidden field manipulation
Parameter tampering
9%
26%
Published vulnerabilities
5%
Data Flow
4%
Third party
misconfigurations
10%
Cross-site scripting
26%
Forceful browsing
14%
Total: 176 Total: 89

R/Y: 65/111 R/Y: 2/87
Having the Tool is Nice,
Having A Report is Good,
But I Need A Process – Just How Do You Conduct An
Application Assurance Assessment?
Prepared by
Kris Kahn, Anil Ghanta, & David Viveiros
Seagate Application Assurance Team

Our Approach
 Target areas to get the most bang for the buck
 Review process in conceptual phase of project to
identify risks to the company, e.g. financial
transactions, client data, personal information, etc.
 Risk based approach – high risk applications have
more requirements and more budget allocated for
security.
 Security Architecture review to identify design flaws
 Application Assurance Review before promotion to
production
 Build Secure Enterprise Application Infrastructure

Process Flow
 SDLC
 Design
 Include Security Principles
 Develop
 Include Application Security Recommendations (OWASP)
 Include System hardening standards
 Include Oracle Security Best Practices
 Test
 Submit request for Security Assessment (2-3 weeks advance notice)
 Staging
 Security Assessment is performed to include DB configuration audit
 Production
 Include e-Security as part of your code change control process for
significant application changes
 Future Compliance Audits

6-Layers Assessment Process
Physical
 Access control, fire protection, disaster recovery, data storage, etc.
Network
 Risks and vulnerabilities over the network
System
 Risks and vulnerabilities in system configuration
Application
 Weaknesses in web-based applications, Oracle applications (using
AppScan and ESM for Oracle)
Data Flow
 Weaknesses in the data flow (lack of encryption for confidential
information, etc.)
Process
 Data backup, disaster recovery, patch updates, user management,
change management, etc.

Assessment Process
Phase 1: Initiate
 E-Security Manager assigns resource(s) to project
 E-Security Manager passes football to lead assessor
Phase 2: Kick-Off
 E-Security and project team review assessment process and synchronize
timelines
 Assessor(s) meets project team
Phase 3: Gather Information

 Assessor interviews project team using checklist
 E-Security reviews all layers to determine assessment scope
 Project team provide a demonstration of the application to the assessor
Phase 4: Generate Plan

 E-Security create an assessment plan based on information gathered and
provides it to the project team for validation of scope
Phase 5: Perform Assessment

 Assessor performs vulnerability scans with appropriate tools and manual testing
 Assessor notify e-Security Management and project team if critical vulnerabilities
are discovered during testing

Assessment Process
Phase 6: Generate Report
 Assessor analyzes scan results to determine threat and probability of
identified vulnerabilities
 Assessor documents recommendations and findings from analysis in
Assessment Report (football)
 E-Security Management reviews report and passes football to project
team
Phase 7: Close-Out
 E-Security and project meet to review assessment report, open items are
identified and action plans are established
Phase 8: Resolution and Support

 Project team reviews and implements recommendations
 Project team reports actions in report
 Project team passes football back to e-Security
 Assessor validates fixes applied (go to Phase 5: Perform Assessment)
Process Exit: E-Security Certification for Production Deployment

 Provided for application when all critical vulnerabilities have been
Copyrightconfirmed toTechnology
© 2004 – Seagate be resolved OWASP San Jose Chapter Kick- 34
Assessment Process Map
Assess Risk
Risk
Discovery Assessment Cycle
Yes
E-Security Review Perform Generate Critical No
Assessment
Request Assessment Report Vulnerabilities? Project Approved
Approved?
No Yes
Project
Owner Request Apply
IT Staff Deferred or Fixes
Submits
Request Rejected
Review Report Review Report
Bus. Units
Fix Go live
Fix or
go live?
Policy Exception
SVPs Risk Acceptance

Assessment Deliverables
Assessment Plan
 Details of assessment scope and tool configuration
Assessment Report
 Detailed analysis of findings
 Recommendations for fixing or mitigating issues
Certification
 No red flags means project is certified to go live!
 Yellow flags will be reviewed by Electronic Security and
project team for overall risk.
 Cannot go live with red flags.

Compliance Audit
Confined Scope Assessment

 Re-Assessment integrated as part of Application
Change Control Process for significant changes
 Significant changes includes
– User interface
– Back-end processing
– New features for enhanced functionality
– Does not include hot-fixes or most incremental patches
for security updates
 Validates certification to ensure security and
determines if new vulnerabilities have been
introduced

Have You May Any Changes For Sarbanes-Oxley?
IT Governance & SDLC

COBIT Application Development Controls
PO 4 – Define the Information Technology Organization &
Relationships
 PO 4.4, Roles & Responsibilities
 PO 4.7, Ownership & Custodianship
 PO 4.10, Segregation of Duty (SOD)
PO 10 - Manage Projects
 PO 10.01, Project Management Framework
 PO 10.02, User Participation in Project Initiation
 PO 10.03, Project Team Membership & Responsibilities
 PO 10.04, Project Definition
 PO 10.05, Project Approval
 PO 10.06, Project Phase Approval
 PO 10.07, Project Master Plan
 PO 10.08, System Quality Assurance Plan
 PO 10.09, Planning of Assurance Methods
 PO 10.10, Formal Project Risk Management
 PO 10.11, Test Plan
 PO 10.12, Training Plan
 PO 10.13, Post-Implementation Review Plan
PO 11 - Manage Quality
 PO 11.05, Systems Development Life Cycle Methodology
 PO 11.08, Coordination and Communication

COBIT Application Development Controls
AI 2 - Acquire & Maintain Application Software
 AI 2.01, Design Methods
 AI 2.02, Major Changes to Existing Systems
 AI 2.03, Design Approval
 AI 2.04, File Requirements Definition & Documentation
 AI 2.05, Program Specifications
 AI 2.06, Source Data Collection Design
 AI 2.07, Input Requirements Definition & Documentation
 AI 2.08, Definition of Interfaces
 AI 2.09, User-Machine Interface
 AI 2.10, Processing Requirements Definition & Documentation
 AI 2.11, Output Requirements Definition & Documentation
 AI 2.12, Controllability
 AI 2.13, Availability as a Key Design Factor
 AI 2.14, Integrity Provisions in Application Program Software
 AI 2.15, Application Software Testing
 AI 2.16, User Reference and Support Materials
 AI 2.17, Reassessment of System Design
AI 6 - Manage Change
 AI 6.01, Change Request Initiation & Control
 AI 6.02, Impact Assessment
 AI 6.03, Control of Changes
 AI 6.04, Emergency Changes
 AI 6.05, Documentation & Procedures
 AI 6.06, Authorized Maintenance
 AI 6.07, Software Release Policy
 AI 6.08, Distribution of Software
Summary of Key Controls for Sarbanes-
Oxley

Web Application Assurance Checklist
& e-Security Academy Course

Questions?


Putting Security Into SDLC-OWASP v2

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Putting Security Into SDLC-OWASP v2

Cargado por

Copyright:

Formatos disponibles

Case Study: An Evolution of

Putting Security into SDLC

Curtis Coleman, MSIA, CISSP, CISM

3rd Age Age of Application Security

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 3

 Everyone gets hacked, from large e-Commerce

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 4

 SSL and Data-encryption are not enough

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 5

Source: Jeremiah Grossman, BlackHat

Source: Jeremiah Grossman, BlackHat

>1000 application ‘Healthchecks’ with AppScan – • When exploited, security defects

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 8

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 9

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 10

 Lack of consistent methodology/process for quality and testing

 Security test planning and execution is not uniform across IT

 No security testing standards/guidelines

 No information assurance test metrics

 No security test training process

 No clear definition of roles/responsibilities for security test activities

 No security acceptance testing standards for purchased products

 SDLC weak in security test guidelines

 No centralized process owner for security testing and standards

 Lack of rigorous security acceptance test processes

* The New Rational Manager, Kepner, H. & Tregoe, B.(1997)

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 11

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 12

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 13

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 14

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 15

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 16

Backdoor and debug options

Hidden field manipulation

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 17

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 18

Measurement system is suspect:

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 19

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 20

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 21

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 23

 These Categories Are of Most Importance…

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 25

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 26

Discovered Vulnerabilities Resolved and Open Vulnerabilities

Total: 176 Total: 89

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 29

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 30

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 31

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 32

Phase 3: Gather Information

Phase 4: Generate Plan

Phase 5: Perform Assessment

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 33

Phase 8: Resolution and Support

Process Exit: E-Security Certification for Production Deployment

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 35

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 36

Confined Scope Assessment

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 37

IT Governance & SDLC

Copyright © 2004 – Seagate Technology OWASP San Jose Chapter Kick- 38