Starting your Software Security Assurance Program

May 21, 2015

ITARC, Stockholm, Sweden

Presenter

Max Poliashenko Chief Enterprise Architect Wolters Kluwer, Tax & Accounting

Max leads the Enterprise Architecture practice across 15 geographies of WK T&A Division and defines its Technology Strategy as well as oversees the architecture of its software products. He chairs the Architecture Review Board, which performs EA governance Max is active in the IT Architecture community. He has served on IASA Architect Education and Certification committees. Max is IASA Fellow, holds Microsoft Certified Architect and CITA-P certifications, and served on multiple CITA-P and MCA boards

Dramatic Changes in IT Security Environments

n  Security landscape has substantially changed in the recent years: the number of breaches and their financial and reputational impact.

n  Automated penetration tools are becoming more main stream and attacker’s barrier of entry is lower and lower

n  The corporate IT perimeter is rapidly eroding with data in the Cloud, hybrid deployments, BYOD devices, etc.

n  The attackers no longer doing it just for fun and bragging but to exploit the compromised assets for financial or political gains

n  The government agencies are also rapidly expanding security regulation and levels of responsibility of application providers

n  Average cost of dealing with a compromised record - $1.2K

n  Many companies are spending millions and billions to raise their security defenses

3

Holistic Security Ecosystem – Defense in Depth

n  Infrastructure and Perimeter –  Firewalls, anti-malware, Intrusion Detection and Prevention systems –  Secure settings on Routers, Switches

n  IT Controls –  User account management, password expiration policies –  Limitation on privileges and access, on-boarding and off-boarding

n  Human Behavior –  Clicking on links with unknown origins –  Bringing in personal device into workplace and plugging into company network –  Rogue employee

n  Physical Access and Devices –  Physical security of Data Centers –  Securing company user devices, including mobile, which may have customer data

n  Application Code – the focus of SSA –  Cross Site Scripting, SQL Injection, Path traversal , misconfigurations, many others… –  Security-conscious SDLC, roles and activities –  Bugs vs. design defects

4

Gartner Shifts Security Focus to Applications

Top 10 Strategic Technology Trends for 2015 report: “…Security-aware application design, dynamic and static application security testing, and runtime application self-protection combined with active context-aware and adaptive access controls are all needed in today's dangerous digital world. This will lead to new models of building security directly into applications. Perimeters and firewalls are no longer enough; every app needs to be self-aware and self-protecting.”

n  http://www.gartner.com/newsroom/id/2867917 Gartner Symposium

5

Typical Application Vulnerabilities

Broke Authentication and Session Management Ø  Included in 2013 - OWASP Top 10

Ø  Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users.

Ø  Scenario: “Insider or external attacker gains access to the passwords stored locally. User passwords are not properly encrypted, exposing them to the attacker. ”

Ø  Scenario: “Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and accesses user’s session and data.”

6

Typical Application Vulnerabilities

Insecure Direct Object Reference Ø  Included in 2013 - OWASP Top 10

Ø  An authorized attacker simply changes a parameter value in the request (filename, key, guid, ID, etc.) that directly refers to a system object which the user isn’t authorized to access. The system doesn’t properly validate the request parameters and doesn’t validate authorizations to access the data before sending it back to the user

Ø  Scenario: “An attacker is able to manipulate the file name or path of a file to a file they do not have permission to access. The file is owned by a different customer of the application. The vulnerability enables the attacker to access data in the file of a different customer.”

7

Typical Application Vulnerabilities

SQL Injection Ø  A top industry application vulnerability for over 10 years

Ø  Attack is able to access data in the database by sending SQL commands into the database through application interface. These command can access, modify or delete the data in the database.

Ø  Scenario: “Attacker exploits this vulnerability in an applications that stores PII information. The attacker sends in the SQL commands which cause the application to expose customer or their clients PII data or alter/delete other data in the database”

8

Most Frequent Application Vulnerabilities

Source – WhiteHat security report 2014

9

Answer: Software Security Assurance (SSA) Program

10

• Code Review • Security Testing • Architectural Analysis

• Vulnerability Management

• Environment Hardening

• Penetration Testing

• Secure Architecture • Security Standards and Requirements

• Training • Policies and Compliance

• Strategy and Metrics

Governance Construction

Verification Deployment

Enterprise Architecture team can perform stewardship and governance of SSA program, providing it with organizational context:

§  Maintain Security Policies, Standards, Guidelines adopting Industry standards and best practices such as Microsoft SDL, OWASP, etc.

§  Maintain Security Training Curriculum (both online and in-person) specific to SDLC roles: Developers, DBAs, Architects and Security Champions, QA, Product Managers and Scrum Masters

§  Work with Development and PMO to incorporate SSA into Agile Development Process

§  Perform Security reviews of applications §  Provide reviewer, advisor, and auditor

resources

§  Dedicated Application Security Architects responsible for SSA tools and governance

§  Keep and report on SSA KPIs §  Maintain security assessment repository

Risk-based Approach to Application Security Management

Utilize resources effectively to identify and mitigate risk

Application Security Risk Management

Business Impact

Assessment Asset

Inventory Status and Progress

Measurement Enrollment into SSA Vulnerability Prioritization

•  Create an application profile template

•  Build an inventory of applications

•  Describe each application

•  Classify applications

•  Determine business impact

•  Prioritize assets

•  Perform Threat Analysis

• Perform Static and Dynamic Code scanning

• Perform Security Reviews of highest risk applications

• Perform external pen and prod tests

• Prioritize vulnerabilities and create remediation plans

• Enroll high risk applications into SSA program:

• Identify Security Champions

• Train in Security the entire team

• Incorporating Security into SDLC

• Budget for Training, Tools and periodic tests

• Track progress against remediation plan

• Perform periodic Security Reviews, Code Scanning and Vulnerability Prioritization

Context

• Industry and Strategic Context • Organizational Context • Develop risk management structure and risk criteria

Identify Risks

• What can happen? • How can it happen?

Analyze Risks

• Determine existing controls • Determine likelihood • Determine impact • Establish Business risk profile

Evaluate Risk

• Compare against criteria • Set risk priorities and tolerances

Accept Risks

• Are we accepting the risk? If yes, then treat/mitigate risk

Treat Risks

• Identify mitigation options • Evaluate mitigating options • Prepare/define treatment plans • Implement/execute treatment plans

Application & Data Context

• Current Application Portfolio context • (Customer) Data context • Determine application and data risk evaluation criteria (Threat models and Attack patterns)

Identify Risks

• What can happen? • How can it happen?

Analyze Risks

• Determine existing application controls and underlying IT general controls

• Determine likelihood • Determine impact • Establish Application risk profile for each application

Evaluate Risk

• Compare against criteria (threat models and attack patterns)

• Set data and software risk priorities and tolerances

Accept Risks

• Are we accepting the risk? If yes, then treat/mitigate risk

Treat Risks

• Identify mitigation options • Evaluate mitigating options • Prepare/define treatment plans • Implement/execute treatment plans

Business Risk Management Software & Data Risk Assessment

Mon

itor

ing

and

Revi

ews

thro

ugh

Ass

essm

ents

Portfolio Risk Assessment Framework (Business & Security)

12

Application Security Testing Strategy

13

•  Applications are evaluated to determine their risk

•  Based on the risk, different security work flows could apply.

•  Including a combination of Dynamic and Static Analysis techniques.

Catalogue Application Assets

Evaluate Application Risk RISK = F (Probability X Expected Loss )

Rank Applications

LOW MEDIUM HIGH CRITICAL

§  Dev Code Scanning §  Code Scan on Builds §  QA Dynamic Scan §  Pre Prod Scan §  Manual Pen test §  External Security Test §  Quarterly Prod Test

§  Dev Code Scanning §  Code Scan on Builds §  QA Dynamic Scan §  Pre Prod Scan §  Manual Pen test §  Bi-Annual Prod Test

§  Code Scan on Builds §  Pre Prod Scan §  Manual Pen test §  Annual Prod Test

§  Pre Prod Scan §  Annual Prod Test

Security Roles and Tools in Dev Teams

14

Security Champions

15

n  Part time role, filled by Architects or Sr. Developers from the product team

n  Receive more in-depth security training to become local Security expert

n  Responsible for reviewing product requirements from Security view point and identifying Security requirements

n  Responsible for coordinating and tracking security issues for the product and communication with EA SSA team

n  May perform Threat analysis, Security code scanning and triaging scanned issues

Security Training

n  Training is foundation of SSA and aligns with agile goal of contribution from every team member –  All members of a software development team must receive appropriate training to stay

informed about security basics and recent trends in security and privacy. This includes Developers, DBAs, Architects and Security Champions, QA, Product Managers and Scrum Masters

n  Annual training goals: –  Software development team members in technical roles must attend at least one unique

security training class each year or 4 hours of online/seminar training –  Development is required to complete online Pluralsight security training –  EA team will maintain Recommended Security Training Curriculum –  Online and in-person security classes for Security Champions

n  Some training sites: —  http://www.microsoft.com/security/sdl/process/training.aspx  —  http://www.pluralsight.com/training/Products/Individual

16

Example of Security Training Curriculum

17

Course/Module Name   Hours   Target audience in order of relevance  

Level   Evaluation notes  

OWASP Top 10 Web Application Security Risks for ASP.NET  

8   Development, QA, Design, PM  

Medium   Recommended as base course for Development. With web concentration of this course we recommend additional modules  

Hack Yourself First: How to go on the Cyber-Offense  

9   QA, Design, Development, PM  

Medium   Basic course from the position of penetration test. Highly recommended  

Microsoft MTA: Security Fundamentals   5   PM, Design, QA   Basic   Describes basic security concepts with mostly network, than app security. Prepare for Microsoft Security fundamentals MCP exam  

Web Security and the OWASP Top 10: The Big Picture  

2   Design, PM, QA, Development  

Basic   Foundation course on base concepts of application security.  

What's New in the OWASP Top 10 for 2013  

1   Development, Design, QA   Basic   Short very recent (2014) course with information on latest changes in app security  

Introduction to Cryptography in .NET     2   Development, Design   Advanced      

Developing and Deploying SQL Server ISV Applications. Modules – Security, Testing  

1   Development, Design, QA   Medium   Recommended course for Axcess developers  

Enterprise Library Security and Cryptography Application Blocks  

1   Development   Medium   While this module is not actively used in Axcess there are many relevant points  

CompTIA Security+. Modules - Incident Response, User Education, Social Engineering, PKI, Cryptography  

2   PMO, PM   Medium   Describes security processes  

WCF Design concepts. Module Security   1.5   Development, Design   Advanced   Required course for Axcess developers  

SQL Server Fundamentals. Modules – Security 1, 2  

2   Development, Design, DBA   Medium   SQL Security  

Security Review Process

18

n  1.      Kick-off meeting. The dates for the in-person Security Review are agreed upon. —  The Dev team sends to the Review Team architecture documentation about the product —  ZIP’d source code or read-only access to the source repository

n  2.      Step 2: (approx. Week 2) Review Team sends Product team a customized Security questionnaire —  Product team sends answers to Review Team —  Call between Review team and Product team in order to review answers and plan visit       

n  3.      Step 3:  (approx. Week 2-3) Static and Dynamic code scanning —  Review team performs Static code vulnerability scan of the source code. —  Product team gives external authenticated access to their application Test or Staging environment to the Review

team. —  Review team performs Dynamic code vulnerability scan on the environment above.

n  4 Step 4:  (approx. Week 4) In person review of the product —  Demo of the latest product release —  Review of the architecture and important quality attributes —  Identification of threats and attack vectors —  Deep dive into potential vulnerabilities found during code scanning and inspections —  Recap of confirmed vulnerabilities and remediation recommendation with the team —  Review of Software Security Assurance process that they may want to adopt

n  5.      Step 5: (approx. Week 5) Report —  The Review team writes a report identifying the main threats identified and the remediation strategy —  Product team reviews the report and creates remediation plan for each high and medium risk vulnerability

n  6.      Step 6: Review Remediation Plan

Application Security Testing

n  Static code analysis – Static Application Security Testing (SAST) – White Box Testing, “Inside Out”

n  Dynamic Application Security Testing (DAST) – Black Box, “Outside In”

n  Interactive Application Security Testing (IAST) – Gray Box, combines static and dynamic testing

Vulnerability Remediation and Tracking Process

20

n  Create internal tracking record describing vulnerability with some required detail information. This document is sensitive and distribution should be limited and controlled.

n  Mitigation and remediation process is triggered by multiple points in incident response plan and executed separately for each vulnerability identified internally or externally.

n  Dev team provides remediation approach, dates for vulnerabilities or deferral dates in format specified by EA and infrastructure security.

n  Dev team report completion of remediation and provide verifiable prove.

n  EA tracks status of the remediation and updates executive Security dashboard

SSA Safe Harbor Principles

SSA will adhere to Safe Harbor principles in conducting Software Assurance Program to minimize risk of legal exposure due to Security incidents.

Those principles are:

n  Establish Security Policies, Standards and Guidelines

n  Establish Communication plan

n  Establish Training plan for all involved personnel

n  Audit and Monitor compliance

21

SSA ROADMAP

Capability Maturity Model

23

Veracode AppSec Maturity Model

Source: https://www.veracode.com/blog/2013/10/the-appsec-program-maturity-curve-1-of-4 24

Example of SSA Capability Maturity Roadmap

Capability Year 1 Year 2 Year 3

Product risk assessment including security and privacy

1 – ad-hoc 2 – reactive 3 – proactive

Attack surface reduction 1 – ad-hoc 2 – reactive 3 – proactive

Threat modeling 1 – ad-hoc 2 – reactive 3 – proactive

Approved tools and components 2 – reactive, catalog

3 – proactive

4 – measured

Fuzz testing 1 – ad-hoc 2 – reactive 3 – proactive

Release certification None 1 – ad-hoc 2 – reactive

Including OP applications 2 – reactive 3 - proactive 4 - measured

Not-weighted average 2.2 3.2 4

25

Example of SSA Capability Maturity Roadmap (continued)

Capability Year 2 Year 3 Year 4

Core Security Training 4 – measured 5 - optimizing 5 – optimizing

Annual Security Review 4 – measured 5 – optimizing 5 – optimizing

Security Champions 4 – measured 5 – optimizing 5 – optimizing

Security Design Requirements’ validation

2- reactive, catch up with existing

3 – defined, proactive

4 - measured, controlled

Static code security review

2 – reactive, self-service

4 – proactive, validated, measured

5 – optimized, automated

Dynamic product scanning 2 - reactive 3- proactive, pre-release

4 – measured, controlled

Incident response 2 – reactive, RCA 3 – defined, policy driven

4 – measured, controlled

SSA Program planning 3 – proactive 4 – measured, predictable

5 - optimizing

26

27

Questions?

28

Appendix

CODE SCANNING TOOLS

Requirements

Design

Code & Unit Test

Integration

System Test

The “Waterfall” Approach

STATIC ANALYSIS (Dev) AppScan Source

DYNAMIC ANALYSIS (QA) AppScan Standard AppScan Enterprise

PENETRATION TEST (Security) AppScan Standard Manual Testing

Product Backlog Sprint Backlog Iteration Product Shipping

SPRINT 2 - 3 weeks

Daily Review

The “Agile” Approach

PENETRATION TEST (Security) AppScan Standard Manual Testing

AppScan Source (Filtering on High Confidence)

AppScan Source AppScan Enterprise/ Standard

Requirements

Design

The “Agile-Fall” Approach

Integration

System Test

DYNAMIC ANALYSIS (QA) AppScan Standard AppScan Enterprise

PENETRATION TEST (Security) AppScan Standard Manual Testing

AppScan Source AppScan Enterprise/ Standard

Manual Static Code Analysis

n  Manual code testing —  Proven —  Expensive, difficult, hard to cover all flows, no guarantee —  Coverage is critical for security – single failure fails system —  To scale - Automated to automated unit tests

n  Code review —  Humans can generalize beyond rules —  Human time is expensive —  Not consistent between iterations/releases —  To scale - Automated to static code analysis

Automated Static Code Analysis

n Strong points of static code analysis: —  Scales better — Can detect vulnerabilities proactively — Can focus on a few key properties with big payoffs — Can reuse security specifications across programs — Eliminate categories of error vs single error — Encourage better development practices

n Domains: — Inference (program understanding, bug-finding)

n  Appropriate for legacy code — Enforcement (proving absence of bugs)

n  Most useful when building new systems

35

AppScan Source •  For Remediation •  For Development

Enterprise Reporting User

Administration

AppScan Enterprise Server

AppScan Source DB

AppScan Enterprise

DB

AppScan Enterprise •  Reporting

AppScan Source §  For Analysis

(Security Policy)

Create Shared configuration Files Create Shared filters (Security Policy)

Administration (Source/Reporting)

View enterprise level metrics, trending and compliance reports

AppScan Source •  For Analysis

Open Published Assessments

Build Server AppScan Source §  For Automation

Developers

Lead Developer “Champion” ** One Champion per Development team

Managers

Reports & dashboards

Security Team

Open Defects

Triage scan results Assessment Data (Bundles)

Source Code & Dependencies

Build Team

Markup Management •  Resolve lost sinks •  Identify lost sources •  Create custom rules

Review triage & assessments

Static Analysis Security Work Flows

Scan for “High Confidence” Findings using Security Policy (configuration files and filters) Conduct Scans

Integration with Build Process (Ant, Make, Maven, TFS, Jenkins, CLI) Scan (Auto)

Conduct Scans

Scan (full coverage) Onboard Applications Conduct

Scans

AUTO Publish Assessments

Publish Assessments

Managers AppScan Enterprise Reporting

Security Team AppScan Standard & AppScan Enterprise Dynamic User

Conduct Scans

View enterprise level metrics, Application Management and compliance reports

Publish AppScan Standard Results

Conduct Scans

Scan results

Triage findings & Results Verification

Run on-demand or Scheduled Scans

Conduct Scans, ASE Administration, Create enterprise level metrics, trending and compliance reports “Complete Full Coverage Test Policy”

Web Application(s)

Development Teams AppScan Enterprise Dynamic User Run Quick Scans, manage issues, review findings “Limited / Input Control Test Policy”

QA Teams AppScan Enterprise Dynamic User Configure & Conduct Scans, manage issues, review findings “Application Test Policy”

Run Quick Scans

Dynamic Analysis Scanners

Conduct Scans Run on-demand or Scheduled Scans

Scan results

Manage Issues

Review Results

Dynamic Analysis Scanners

Headless & Automated Scans

Desktop Client

AppScan Standard

Enterprise Reporting User

Administration

AppScan Enterprise Server

AppScan Enterprise

DB

Review Results

Manage Issues

Manual Pen Test

Publish manual findings (CSV file)

Dashboards & Reports

Application Management

Dynamic Analysis Security Work Flows

37

Example of Risk Assessment Analysis Business Risk Analysis:

1.  Product Name 2.  Business Importance Ranking 3.  Is Internet Accessible 4.  Revenue or # of customers 5.  Assets to be protected 6.  Business Goals 7.  Data Center 8.  High Availability solution 9.  Backup solution 10.  Disaster Recovery solution 11.  Do Dev/Test environment

contain PII data? 12.  PII data encrypted? 13.  Has Intellectual Property? 14.  Business Risk Ranking

Product Threat Analysis:

1.  Security Attack Vector/Method 2.  Threat Actor 3.  Event type (CIA) 4.  Asset at risk 5.  What is Impacted 6.  Likelihood of event 7.  Severity of Impact 8.   Threat Severity 9.  Monitoring Process 10.  Mitigations 11.  Gaps 12.  Remediation Plan

SSA Activities for Each Enrolled Product/Dev Team n  All steps require active involvement of product leadership

n  Assign Team Security Champions –  Security champion roles should be filled by SMEs from the project team. –  Responsible for the negotiation, acceptance, and tracking of security and privacy requirements

and maintaining clear lines of communication with SSA governance –  Establish communication and training plan

n  Conduct Security Training for team and additional training for Champion

n  Perform Product Business Risk Assessment

n  Catalog software dependencies, especially Open Source

n  Run static code analysis scan, triage found issues

n  Run dynamic code analysis scan, triage found issues

n  Perform Security Risk Assessment &Threat Modeling (incl. IT Ops). Identify risks w/mitigations. As a result, create backlog of Security stories, Security bugs & IT Ops gaps

n  Document results in Security Assessment document

n  Budget for annual penetration test, training, tools and other SSA activities

n  Create Incident Response Plan (review it with Legal)

38

Security Activities for Each Product Release

At Release planning: n  Perform Security Threat Surface analysis and plan its reduction:

–  Review and prioritize security backlog, create new stories if needed –  Review other requirements for security impact –  Review and prioritize security bugs

n  QA creates test plans and updates automation scripts to test Security stories & bugs

For each Sprint: n  Incorporate security standards and guidelines into code reviews

n  Review security threat vectors

n  Perform static code analysis

n  Identify and prioritize security bugs

At the end of Release (during Hardening Sprint): n  Perform Dynamic security analysis and Fuzz Testing by QA

n  Conduct and submit security Assessment Survey by security champion

n  Perform Final Release Security Review (including IT Operations) and certify the Release

n  Update Security Assessment document and SSA governance repository

n  Perform external penetration test (at least annually)

39

Microsoft Security Development Lifecycle Framework n  The Security Development Lifecycle (SDL) is a security assurance process that is

focused on software product development.

n  As a company-wide initiative and a mandatory policy since 2004, the SDL has played a critical role in embedding security and privacy in software and culture at Microsoft.

n  Combining a holistic and practical approach, the SDL aims to reduce the number and severity of vulnerabilities in software.

n  The SDL introduces security and privacy throughout all phases of the development process.

n  The Microsoft SDL is based on three core concepts—education, continuous process improvement, and accountability.

n  Microsoft publish SDL best practices at http://www.microsoft.com/security/sdl

40

Best industry practices - Microsoft SDL

n  Team has reviewed best industry practices, consulted with internal and external experts

n  Microsoft SDL program was selected as battle-tested industry best practice model for TAA Software Security Assurance

41