BEST PRACTICES FOR SECURITY TESTING TOP 10 RECOMMENDED PRACTICES
Disclaimer!! Best Practices are Not rules or rigid standards General solutions to common problems Guidelines and common reference that can be shared, further developed, and can give rise to new Best practices 2
Agenda Security Testing Myths Vs Realities The 10 Recommended Security Practices Summary 3
Security Testing Security Testing is the process to determine that an information system protects data and maintains functionality as intended. A few lines of code can wreak more havoc than a bomb - Tom Ridge (Former) Secretary of the U.S. Department of Homeland Security Need of Security Testing: Technical and Business Perspectives Validates system s conformance to security requirements Identify potential security vulnerabilities Improve project costs Reduce Litigation Conform to regulatory requirements Protect reputation or brand 4 Source: Avert Labs
Myths Vs Realities Some Myths of Software Security My applications do not have any security problem Network defense mechanism will protect an organization from any application based security breach Magic bullet theory Security implementation in an organization is costly Security testing is time consuming 5
Changing the Old Paradigm Creating a better, more secure application development process Software security testing is different from software functionality testing Integrate security best practices into the software development lifecycle (SDLC), instead of hastily adding it at the end. This increases efficiency, reduces overall costs and improves customer satisfaction 6
Integration of Security Testing throughout SDLC Maintain ( 500 X ) Test & Deploy ( 50 X 200 X) Implementation ( 20 X) Design ( 5 X ) Requirements Definition ( 3 X ) Project Initiation & Planning ( X ) 7 Parallel Security Activities
Information Gathering Software Components and Their Environment Collecting as much information as possible about the target application Understanding the software and it s environment is important to evaluate the attack surface 8
Information Gathering Evaluation of the Software Attack Surface 9
Threat Evaluation Data Flow Diagram (DFD) helps understand how the system works and the threats it faces A good way to get started in this space is the Microsoft s STRIDE model 10
STRIDE Spoofing Can an attacker gain access using a false identity? Tampering Can an attacker modify data as it flows through the application? Repudiation If an attacker denies doing something, can we prove he did it? Information disclosure Can an attacker gain access to private or potentially injurious data? Denial of service Can an attacker crash or reduce the availability of the system? Elevation of privilege Can an attacker assume the identity of a privileged user? 11
Every Asset is Subject to Attack Asset Request Data Files Requested File(s) External Entity User Response Service Process Data Store Dataflow 12 12 Authn Info Get Credentials Authn Engine Credentials Authn Request
Threat Types by Asset Type Asset S Spoofing T Tamperin g R Repudiation I Information Disclosure D Denial of Service E Elevation of Privilege External Entity Process Data Store Dataflow 13
Prioritizing Security Testing Focus testing on areas where difficulty of attack is least and the impact is highest - Chris Wysopal Why analyze and prioritize? What is Threat Modeling? 14
Why Analyze and Prioritize Security Testing? Put appropriate defenses in products Because attackers 15 Want to attack Your application
Threat Modeling and Its Benefits Threat modeling is.. A security-based analysis that helps understand where the product is most vulnerable Find assets, evaluates threats and uncovers vulnerabilities Helps reduce overall security risks Prioritizes security tests Forms the basis of security design specifications Determines the threat mitigation techniques to employ Benefits Helps understand an application better Helps find bugs and flaws in complex designs Drives well-designed security test plans 16
Threat Modeling Process Threat Modeling Process 1 2 Identify Assets Create an Architecture Overview 5 Document the Threats 17
Identifying Vulnerabilities In Source Code Well-tested code that includes security tests results in an end product that is more robust, easier to maintain and more secure Can be detected through Security code reviews Source code analysis Automating the code review process is a good approach 18
Testing with Known Intrusions No security testing regime is complete until the product is tested with known intrusions It verifies that the application cannot be breached by known means. If it can, then fix and verify before the application goes into production 19
Source: CERT 99% of network intrusions occurred based on known vulnerabilities that could have been prevented with proactive vulnerability management. Automate attack simulation whereby software pretends to attack the application with known paths of intrusion. Tools like Metasploit can help. 20
Creating a Security Test Plan The Security Test Plan should incorporate a highlevel outline of the artifacts to be tested and the methodologies to be used 21
Security Test Plan 22
Choosing the Right Tools for Security Testing Know your attacker and know yourself Test an application under the following conditions to determine the vulnerabilities a non-authenticated user an authenticated user an administrative user 23
Metrics & Reporting Both the quantity and quality of testing needs to be measured to assess the efficiency of the testing performed on the software Defect metrics are vital All time-oriented metrics should be measured regular Maintain a common problem database 24
25
Recap Security is a Process and not a Product Break the traditional approach. Integrate security testing throughout SDLC Evaluate the attack surface and threats Develop security testing strategy Analyze and prioritize test strategies Think Evil. Be Evil. Test Evil Perform code reviews Know your enemy and know yourself Attack!!! 26
References Risk-Based and Functional Security Testing: C. C. Michael and Will Radosevich Building Secure Web Applications: Peter Varhol, Technology Strategy Research, LLC Threat Modeling-Improving the Application Life cycle: Dan Sellers Myths of Software Security by People Security Secure Coding: Principles and Practices. Graff, Mark G. & Van Wyk, Kenneth R. Sebastopol, CA: O Reilly, 2003 (ISBN: 0596002424). Security Considerations in the Information System Development Life Cycle: Grance, T.; Myers, M.; & Stevens, M (NIST Special Publication 800-64), 2004 Risk Based Security Testing: TechRepublic Publication http://www.cert.org/stats/ http://web.nvd.nist.gov/view 27
THANK YOU!! Aarti_Agarwal@mcafee.com Aarti.Agarwal@gmail.com +91 9980851530 28