2. 4/16/2009
Awareness
What
Why
When
Who
Defects are reported late in sdlc
Security engineering model is not well integrated
with standard sdlc
Security Testing 3
Formal security requirements to be identified
Security compliance needs to taken in account in
design phase
Process to be integrated in sdlc
Test strategy for security testing
Quality Time to be allocated for building secure
software at all levels: requirement, design, coding,
testing.
Engineering teams, qa teams needs training
Security Testing 4
2
3. 4/16/2009
High level Threat Model
Define the application requirements:
Identify business objectives
Identify user roles that will interact with the application
Identify the data the application will manipulate
Identify the use cases for operating on that data that the application will facilitate
Model the application architecture
Model the components of the application
Model the service roles that the components will act under
Model any external dependencies
Model the calls from roles, to components and eventually to the data store for each use case
as identified above
Identify any threats to the confidentiality, availability and integrity of the data and the
application based on the data access control matrix that your application should be
enforcing
Assign risk values and determine the risk responses
Determine the countermeasures to implement based on your chosen risk responses
Continually update the threat model based on the emerging security landscape.
One can build threat model using STRIDE, an acronym for Spoofing, Tampering,
Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
Company policies / Security features
documents Authentication
Privacy policy Authorization
Coding standards Administrative interfaces
Patching policy User management
Data classification policy
Infosec policies
Acceptable use policies
Export control
Results from previous
security audits
Security Testing 6
3
4. 4/16/2009
Scope of security testing
Identify risks
Prioritization on risks
Regulatory Compliance
Define threat model to be used (can be based on
MS security threat model, OSSTMM)
Training requirements
Testing during Sustenance
Available tools, solutions, cost, time
Security Testing 7
Tools Available
HP Application security center
Microsoft Visual studio team edition
IBM Appscan
Various small utilities.
4
5. 4/16/2009
Application Security Center
A complete application lifecycle solution
DevInspect’s hybrid analysis ensures code under
development is secure
QAInspect verifies the security of the entire
application during QA
WebInspect provides pre- and post-
production application and environment
security analysis
Assessment Management Platform enforces
security policies and manages activities across
the lifecycle
Security Testing 9
Regulatory compliance Industry regulations and
SOX 404 standards
HIPAA FFIEC
PCI OWASP Top 10 / Guides
GLBA SCADA Security
CA SB1386 / State OASIS
Notification Laws ISO 17799
BASEL II
FISMA
EU Data Protection
Directive
Security Testing 10
5
6. 4/16/2009
Before we close
Know the 5 Ws
The bare minimum is knowing the who, what, where, when, and
why for each feature
Design & Validate Security into the Product
Several legal requirements should be considered in
testing, such as the Health Insurance Portability and
Accountability Act of 1996 (HIPAA), Computer Fraud and
Abuse Act (CFAA), and California (CA) SB1386.
Never Run Tests as an Administrator/ Root
Understand limitations of tools
Keep updating methodology, tools
Not all software security programs are identical, build a
program to Security Testing
meet your needs 11
Credits
http://en.wikipedia.org/wiki/Wiki
http://www.isecom.org/osstmm/
http://www.hp.com
http://www.ibm.com
http://www.microsoft.com
6
