Implementing Application Security Policy

Fred Pinkett VP Product Management Security Innovation, Inc.

Simplify Your Process with TeamMentor

(Part Three of our Three-Part Series)

Today’s Presenter

Fred Pinkett Vice President Product Management

Ø  Responsible for product strategy and roadmap

Ø  Extensive security industry experience (Core Security, RSA)

Ø  MBA, Boston College; BS, Computer Science & Engineering, MIT

Ø  Regular blogger and author

About Security Innovation

Application Security Experts • 10+ Years vulnerability research • Security Testing Methodology adopted by SAP, Microsoft, Symantec • Authors of 8+ books Products and Services • Standards - Best Practices • Education - CBT & Instructor-Led • Assessment - Software and SDLC Reducing Application Security Risk • Critical Vulnerability Discovery • Secure SDLC Rollout • Internal Competency Development

Agenda

Ø A Review of Part 1 & 2

•  Application Security Policies Defined

•  Attributes of an Effective Policy

•  Deploying Your Security Policy –  Importing into TeamMentor

–  Linking to Articles in TeamMentor

–  Creating Views

–  Customizing

Common Use Cases: A Review

1. Development teams don’t know where to go for best practices guidance on software vulnerabilities.

2. There’s a need to communicate and share intelligence around specific vulnerabilities with your team.

3. Teams need to fix vulnerabilities and map to internal policies.

4. There’s a market need for making more sense of static analysis results to get to full-circle remediation.

Common Use Cases: Security Teams

•  Use Case: Security team - Discovery –  Software vulnerability identified.

–  Need for verification & more information

–  Where do go for guidance?

•  Use Case: Security team - Communication –  Software vulnerability verified

–  Need to communicate to your team

–  What’s the most effective way to accomplish this?

Common Use Cases: Development Teams

•  Use Case: Development team - Prioritize –  Need to prioritize verified vulnerabilities.

–  Need to map against internal process or policies.

–  How can I simplify this process and integrate with what I already have?

•  Use Case: Development team with Tools –  Your tool(s) report findings.

–  Need to make more sense out of results.

–  Findings point to guidance specific to the findings.

–  Fix vulnerabilities and re-scan.

How do you define your process?

•  Determine your risk tolerance –  Inventory high-risk applications.

–  Determine business criticality of those applications.

–  What’s your attack probability? Attack surface?

–  Rank your applications.

•  Define your data: Classify and Prioritize –  How sensitive is your data?

–  Relevant to internal mandates/compliance initiatives?

–  Build a threat model.

–  Compile the most effective set of testing criteria & tools.

How do you define your process? (con’t.)

•  Select your tools for testing –  Apply your rankings to your tools

selection.

–  Determine your combination of automated vs manual tools.

–  Consider how many applications, how much code and time-to-result.

–  Do you need them to run on their own, or are they better for a singular, manual purpose?

–  Assume that automated tools cannot target business logic attacks.

–  Interpret your results with remediation in mind.

Now…Map Activity to Your Criteria

Threat Rating

Static Analysis

Dynamic Analysis

Manual Pen Test

Threat Modeling

Complete/ Frequency

Complete/ Frequency

Complete/ Frequency

Complete/ Frequency

Tier 1 Required/

Major code changes

Required/ Major code

changes

Required/Per Milestone

Required/Per Release

Tier 2 Suggested/ Monthly

Required/ Quarterly

Required/Per Release

Suggested/ Per Release

Tier 3 Optional/ Quarterly

Required/ Annually

Optional/As Needed

Optional/As Needed

Agenda

•  A Review of Parts 1 & 2

Ø Application Security Policies Defined

•  Attributes of an Effective Policy

•  Deploying Your Security Policy –  Importing into TeamMentor

–  Linking to Articles in TeamMentor

–  Creating Views

–  Customizing

Application Security Policies Defined

•  Information security policies focus primarily on infrastructure and how software is deployed

•  Application security policies focus primarily on how software is developed

•  Information security policies are far more common and sometimes will imply application security policies

Application Security Policy - Goal

•  The goal of an application security policy is to define the business’s security expectations for its development organization

•  That’s all.

Information Security Policy - Example

•  Agencies will establish procedures for the secure storage of all electronically stored information that is owned or controlled by such agency/department

•  Users with access to State of Vermont customer sensitive information are strictly prohibited from downloading any customer information onto laptops, disk, flash drives, etc. unless the portable device is encrypted

–  Examples of sensitive information may be a combination of any of the following but not limited to this list:

•  Credit card information •  Social Security Number •  Health information

•  Customer name •  Mailing address •  Email address •  Phone number

Application Security Policy - Example

•  During the project design phase, the business needs for security must be integrated into the system design

•  The project’s technology and processes for using the system should be examined for their ability to support the confidentiality, integrity, authorization and availability objectives identified in Project Concept Phase

•  Security considerations and recommended control measures shall be documented in the project specifications and approved by the agency

•  Security goals of the system should include: –  Confidentiality of the data –  Authentication of the data –  Integrity of the data –  Non-repudiation of the data –  Availability of the data –  Auditing of the data

Agenda

•  Application Security Policies Defined

Ø Attributes of an Effective Policy

•  Deploying Your Security Policy –  Importing into TeamMentor

–  Linking to Articles in TeamMentor

–  Creating Views

–  Customizing

An Effective Application Security Policy

There are things we can do to make it easier

An effective application security policy has the following attributes:

•  Clearly states what must be done

•  Clearly states why it matters

•  Technology agnostic, widely applicable

•  Tied to a real business objective

•  Deployed in such a way that it is easy to access and maintain

An Effective Application Security Policy - Example

•  Cross Site Scripting must be prevented by escaping all user input before it is used on a web page

•  Cross Site Scripting vulnerabilities allow attackers to execute scripts in the victim’s browser.

–  This attack can be used by an attacker to hijack user sessions, deface your web site, or redirect your user to malicious sites

•  Use standard libraries, do not write custom escaping code

Anatomy of an Effective Policy

This is an effective policy

•  Clearly states why it matters –  Cross site scripting can result in hijacking of user sessions, web site

defacement, or redirection to malicious sites.

•  Clearly states what must be done, very little interpretation needed

–  Escape all user input before echoing back to a web page

An Effective Application Security Policy

There are additional steps you can take:

•  Tie the policy to role or SDLC phase

•  Map to compliance or customer requirements

•  Consider criticality of application and data –  requirements, activities and level of detail needed will differ

•  Provide an exception policy –  What if minimum standards can’t be met? What is considered

acceptable? Who approves?

Agenda

•  Application Security Policies Defined

•  Attributes of an Effective Policy

Ø Deploying Your Security Policy –  Importing into TeamMentor

–  Linking to Articles in TeamMentor

–  Creating Views

–  Customizing

Use Case: SQL Injection

✔  EFFECTIVE POLICY STATEMENT –  If your application connects to a SQL database, you must defend

against SQL injection attacks

–  A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands in the database. It can be used by an attacker to steal sensitive data, modify existing data or log in as a user with higher privileges

–  Usage of parameterize queries is strongly recommended

Interpret the Policy

•  This is a well written policy and is easy to interpret –  Any application that connects to a SQL database must protect

against SQL Injection attacks

–  Parameterized queries are the recommended solution

Find SQL Injection – ASP.NET 4.0

Open the Article to View Best Practices

Coding Best Practices

•  We can do the same thing for implementation best practices

•  We look in TeamMentor and find: –  Use Parameterized APIs for Database Access

Best Practice - Details

Our Application Security Solutions

Computer Based Training –  48 Technical & Awareness courses –  Secure Design, Coding, Testing –  .NET, Java, C/C++, C#, PHP, Mobile, OWASP, PCI, Database

Secure Development Standards –  Aligns development activities to policies –  3,500 secure development best practices for OWASP, PCI, Web Services –  Create dedicated guidance views for your security policies –  Meets PCI requirements 6.3, 6.5 and 6.6 out of the box

–  Application Assessment –  SDLC Optimization & Compliance

Professional Services

Thank you!! Evaluate TeamMentor:

•  OWASP Guidance Library (Creative Commons content) •  Install locally or use web •  Watch a video: http://bit.ly/Vra3OS •  OWASP: https://owasp.teammentor.net/teamMentor •  SI Library: https://teammentor.net/teamMentor

Enterprise & Partner Versions: •  Full set of guidance libraries (4500+ articles) •  Single user, cloud instnace, business unit, & enterprise

licensing •  Partner organization pricing •  Contact Sales: getsecure@securityinnovation.com •  Contact Fred: fpinkett@securityinnovation.com