4/16/2009                                Maheshwar Kanitkar         Security Testing                            1Software ...
4/16/2009Awareness  What  Why  When  WhoDefects are reported late in sdlcSecurity engineering model is not well integrated...
4/16/2009High level Threat Model Define the application requirements:    Identify business objectives    Identify user rol...
4/16/2009 Scope of security testing Identify risks Prioritization on risks Regulatory Compliance Define threat model to be...
4/16/2009Application Security CenterA complete application lifecycle solution                                 DevInspect’s...
4/16/2009Before we close  Know the 5 Ws    The bare minimum is knowing the who, what, where, when, and    why for each fea...
4/16/2009Security Testing          13         Thank You    Maheshwar Kanitkar   mrkanitkar@gmail.comSecurity Testing      ...
Upcoming SlideShare
Loading in …5
×

Security testing

279
-1

Published on

Software security testing

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
279
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Security testing

  1. 1. 4/16/2009 Maheshwar Kanitkar Security Testing 1Software security stateSoftware security engineeringDefining test strategyRegulatory complianceQ&A Security Testing 2 1
  2. 2. 4/16/2009Awareness What Why When WhoDefects are reported late in sdlcSecurity engineering model is not well integratedwith standard sdlc Security Testing 3Formal security requirements to be identifiedSecurity compliance needs to taken in account indesign phaseProcess to be integrated in sdlcTest strategy for security testingQuality Time to be allocated for building securesoftware at all levels: requirement, design, coding,testing.Engineering teams, qa teams needs training Security Testing 4 2
  3. 3. 4/16/2009High 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. 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 7Tools Available HP Application security center Microsoft Visual studio team edition IBM Appscan Various small utilities. 4
  5. 5. 4/16/2009Application Security CenterA 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. 6. 4/16/2009Before 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 11Credits http://en.wikipedia.org/wiki/Wiki http://www.isecom.org/osstmm/ http://www.hp.com http://www.ibm.com http://www.microsoft.com 6
  7. 7. 4/16/2009Security Testing 13 Thank You Maheshwar Kanitkar mrkanitkar@gmail.comSecurity Testing 14 7

×