Security-Review-Proc..

Jun 12, 2008 1/14

A Security Review Process for Existing Software Applications


DRAFT

Gabriele Garzoglio Computing Division, Fermilab

Jun 12, 2008 2/14


Overview

• Goal– Identify technical risks and their impact

• Involvement• Focus• Process to achieve the Goal

– Application Review– Abuse Cases Analysis– Architectural Risk Analysis– Code Review – Application Tests– Write Report

Gabriele Garzoglio

Jun 12, 2008 3/14


Goal

Identify technical risks associated with the application– Find vulnerabilities / flaws in application code /

architecture– Technical problems or complications

… and the impact of these technical risks– Unexpected system crashes– Avoidance of security control– Unauthorized data modification / disclosure

Optionally: generate application quality metrics– Number of defects– Number of critical risks

Gabriele Garzoglio

Jun 12, 2008 4/14


Who should be involved

• Application Developers

• Application Administrators

• Management

• Security team

• Security reviewers

Gabriele Garzoglio

Jun 12, 2008 5/14


Focus

• To achieve the goals, study the software application with the following in mind:– what it does / what it protects (business

context / risk)– threat / exploit community (what does an

exploiter gain) – potential vulnerabilities (what defects can be

exploited)– risks (vulnerabilities x threats)

Gabriele Garzoglio

Jun 12, 2008 6/14


Overview

Goal– Identify technical risks and their impact

Involvement Focus Process to achieve the Goal

– Application Review– Abuse Cases Analysis– Architectural Risk Analysis– Code Review – Application Tests– Write Report

Gabriele Garzoglio

Jun 12, 2008 7/14


How to identify technical risks and their impact

1. Application review (interviews, documentation, etc.)

2. Abuse Cases Analysis3. Architectural Risk Analysis4. Code Review 5. Application tests (Security/Penetration)6. Write report

Gabriele Garzoglio

Jun 12, 2008 8/14


How to conduct the "Application Review"

• Study:– General Functionalities– Environment (Users, Security Policies, etc.)– Use Cases– Specific Features– Architecture– Project management practices– Operation practices– Risk Analysis / Security Requirements / Security

Operations (if any)

Gabriele Garzoglio

Jun 12, 2008 9/14


How to conduct the "Abuse Cases Analysis“ *

• Misuse or abuse cases:– Prepare for abnormal behavior (attack)– Uncover exceptional cases

• Document what software will do in the face of illegitimate use

• Process:– Start with attack patterns (see later), requirements,

and use cases– Build an attack model– Determine misuses and abuse cases

• Talk to the developers: they might know possible system abuses

Gabriele Garzoglio

* “Software Security: Building Security in” by G. McGraw; Ed: Addison-Wesley* “Exploiting Software: How to break the code” by G. Hoglund and G. McGraw; Ed: Addison-Wesley

Jun 12, 2008 10/14


48 attack patterns*• Meta-characters in E-mail Header• File System Function Injection, Content Based• Client-side Injection, Buffer Overflow• Cause Web Server Misclassification• Alternate Encoding the Leading Ghost Characters• Using Slashes in Alternate Encoding• Using Escaped Slashes in Alternate Encoding• Unicode Encoding• UTF-8 Encoding• URL Encoding• Alternative IP Addresses• Slashes and URL.Encoding Combined• Web Logs• Overflow Binary Resource File• Overflow Variables and Tags• Overflow Symbolic Links• MIME Conversion• HTTP Cookies• Filter Failure through Buffer Overflow• Buffer Overflow with Environment Variables• Buffer Overflow in API Calls• Buffer Overflow in Local Command·-Line Utilities• Parameter Expansion• String Format Overflow in syslog()

• Make the Client invisible• Target Programs That Write to Privileged OS Resources• Use a User-Supplied Configuration File to Run• Commands That Elevate Privilege• Make Use of Configuration File Search Paths• Direct Access to Executable Files• Embedding Scripts within Scripts• Leverage Executable Code in Non-executable Files• Argument Injection• Command Delimiters• Multiple Parsers and Double Escapes• User-Supplied Variable Passed to File System Calls• Postfix NULL Terminator and Backslash• Relative Path Traversal• Client-Controlled Environment Variables• User-Supplied Global Variables (DEBUG=1, PHP Globals,

etc.)• Session ID, Resource 10, and Blind Trust• Analog In-Band Switching Signals (aka "Blue Boxing")• Attack Pattern Fragment: Manipulating Terminal Devices• Simple Script Injection• Embedding Script in Nonscript Elements• XSS in HTTP Headers• HTTP Query Strings• User-Controlled Filename• Passing Local Filenames to Functions That Expect a URL

Gabriele Garzoglio

* “Exploiting Software: How to break the code” by G. Hoglund and G. McGrawEd: Addison-Wesley

Jun 12, 2008 11/14


How to conduct the"Architectural Risk Analysis“ *

• Process:– Build a one page overview– Architectural analysis

• Attack resistance analysis (see attack patterns)• Ambiguity analysis• Weakness analysis

– Rank risks– Build mitigations

Gabriele Garzoglio

* “Software Security: Building Security in” by G. McGraw; Ed: Addison-Wesley* “Building Secure Software” by J. Viega & G. McGraw; Ed: Addison-Wesley

Jun 12, 2008 12/14


How to conduct the"Code review“ *

• Best if using automated tools• Look out for:

– Input validation and representation– API abuse– Security features– Time and state– Error handling– Code quality– Encapsulation– Environment

Gabriele Garzoglio

* “Software Security: Building Security in” by G. McGraw; Ed: Addison-Wesley* “Building Secure Software” by J. Viega & G. McGraw; Ed: Addison-Wesley

Jun 12, 2008 13/14


How to conduct the"Application tests“ *

• Security Testing: Risk-based testing, Functional Security testing, Penetration testing, …– Several Standards of compliance: CHECK,

OSSTMM, OWASP, …

– Most appropriate for web applications is OWASPhttp://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents

– Select tests according to outcomes of previous analyses

Gabriele Garzoglio

* “Software Security: Building Security in” by G. McGraw; Ed: Addison-Wesley

Jun 12, 2008 14/14


How to “write the report”• Write a summary of your findings for each of the process steps

– Application Review– Abuse Cases Analysis– Architectural Risk Analysis– Code Review – Application Tests

• Identify impact of technical risks– Remember your “focus”:

• what it does / what it protects• threat / exploit community• potential vulnerabilities• risks (vulnerabilities x threats)

– What are the business needs of the application?• Availability, confidentiality, integrity, authenticity/non-repudiation, …

– Link the risks with the business needs• Propose mitigation strategies for highest impact risks

Gabriele Garzoglio

Security-Review-Proc..

Documents

Transcript of Security-Review-Proc..