overview of secure engineering

8/2/2019 Overview of Secure Engineering

1/41

IBM Rational

2009 IBM Corporation

Ory Segal, Security Products ArchitectRational, Application Security


2/41

IBM Rational Application Security


Quick recap of session #1

What is secure engineering

Security & SDLC

Requirements Security requirements, Abuse cases & Protection Poker

Design Secure design principles, Architectural risk analysis

Code Secure coding, Code review tools

Test Security testing

Deploy Secure deployment, Enablement & Vulnerability management

Security education & Guidance


3/41



Security Products Architect, Rational (Application Security)

Member of the IBM Security Architecture Board technical team

Member of the IBM SAB Secure Development workgroup

Web application security evangelist

Web Application Security Consortium (WASC) Officer

Contributor to projects such as: MITRE CWE, OWASP, WASC, NIST SAMATE, etc.

Author of numerous web application security articles, research papers and

advisories

Renowned web application security expert


4/41



Session #1


5/41



We are trying to secure software, because:

Continued growth in software vulnerabilities (connectivity,

extensibility, complexity)

Its much cheaper to fix security defects during design/code phase(x1 vs. x30-100)

Security flaws have a high PR cost (IBM ranked #4 in 2008)

Customers are encouraging vendors to deliver safer systems

Security as a competitive differentiator

Regulations & laws

Cybercrime big money is being made out of software

compromise


6/41



A set of concepts, principles, and best practices that ensure

security is properly reflected and implemented in software

Used by architects, designers, developers, and testers

Covers:

Requirements gathering

Design (architecting)

Code (implementation) Test (unit, function, system, integration)

Deploy

Post deployment (documentation, serviceability)


7/41



Secure Development

Secure-By-Design

Trustworthy Computing Security Development Life Cycle (MS)

Defense-in-Depth Development

Security only at the implementation stage is not SE.SE is

an end-to-end development approach


8/41



Requirements

Securityrequirements

Abuse cases& anti

requirements

Design

Secure designprinciples

Architecturalrisk analysis

Code

Secure coding

Code review

Test

Risk analysis

Securitytesting

Deploy

Vulnerabilitymanagement

Securedeployment

Operational

enablement

Securitytesting

Security education & guidance

Security strategy & metrics


9/41




10/41



Security requirements are needed to ensure security is built

into the application from the start

Proactively specify the expected behavior of software with

respect to security Define what new security features are required and how

should existing features be changed

Covers both functional security (e.g. use of cryptography), as

well as emergent characteristics (i.e. abuse cases)

Gathered based on the high-level business purpose of the

software and known risks


11/41



Identification process does not include all relevant stakeholders and doesnt

use most modern/efficient techniques

Often describe architectural constraints or implementation mechanisms

rather than describe what the system must do (or must not do)

Requirements are often specified without analysis or modeling

Arbitrary, requirements being ambiguous, incomplete, inconsistent, not

cohesive, infeasible, obsolete, neither testable nor capable of being

validated

Requirements management is typically weak, with ineffective forms of datacapture

Attention is given to the functionality of the system, from the users

perspective, but little attention is given to what the system should notdo


12/41



Suggested activityRelated Project Roles

Owner Key Contributor

Identify global security policy Requirements specifier ---

Identify resources and trust boundaries Architect Requirements specifier

Identify user roles and resource capabilities Architect Requirements specifier

Specify operational environment Requirements specifier Architect

Detail abuse cases Requirements specifier Stakeholder

Identify attack surface Designer ---

Document security-relevant requirements Requirements specifier Architect


13/41



Auditing &logging

Input validation& outputencoding

Data at rest Data in motion

Exceptionmanagement

Authentication& authorization

Sessionmanagement

Cryptography &integrity

Configurationmanagement


14/41



Software builders tend to describe what the software will do in a normative

environment (UML, use cases, etc.)

If software is used, its going to be abused

Abnormal behavior must be anticipated, but theres no UML and use cases

for software abuse

Abuse cases enable you to think about your software the way an attacker

would

Clever attackers always try to undermine the assumptions a system is built

on

We are in a great position to know our system better than potential

attackers do, we should leverage this knowledge to benefit security

You may want to hire an external person to help you


15/41



Our system is made of a client & server components

Users must authenticate on the client, in order to submit

requests to the server

The server allows users to view their account details

No authentication is done on the server, since we assume that

only users using our client can talk to the server

Abuse case: a potential malicious user could sniff the network,or reverse engineer our client, in order to submit manual

requests to the server, and perform actions such as extraction

of user details, without performing any authentication


16/41




17/41




18/41




19/41



Design flaws account for ~50% of security problems

You cant find design flaws by staring at code - a higher-level

understanding is required (forest-level view)

Risk analysis helps to identify and understand project levelrisks, and to effectively prioritize security initiatives

By identifying risk, we can create a good measure of software

security

Good risk analysis links system-level concerns to probability

and impact measures

Approaches: threat modeling, protection poker, etc.

l l


20/41



Learn as much as possible about the target of analysis

Discuss security issues surrounding the software

Determine probability of compromise

Perform impact analysis

Rank risks

Develop mitigation strategy

Report findings

IBM R i l A li i S i


21/41



IBM R ti l A li ti S it


22/41



Similar in concept to Agile Planning Poker wideband Delphi estimation

Leverages a diversity of ideas, experience, and knowledge related to

software security

Goals:

Structure a collaborative, interactive, and informal practice for abuse

case development and/or threat modeling

It also spreads software security knowledge throughout a team

Output: list of the overall relative security risks for each potential

requirement for the iteration

This list of relative risks can be used to guide the prioritization of security

engineering resources towards the areas of the software with the highest

risk of attack

IBM R ti l A li ti S it


23/41



Game Rules: Protection Poker is played during an iteration planning-type meeting

Requirement is presented to the players and informal discussions of abuse

cases and threat models ensue

We use unit-less measures to compute risk

Security risk = (ease of attack)*(value of asset that could be exploited with a

successful attack)

Unit points are 1, 5, 8, 13, 20, 40 and 100 (you can use your own values)

Team members reveal their estimates first for ease points and then for value

points for each requirement

Team members with the lowest and highest estimates explain their estimates to

the group

More estimation rounds take place until the team can come to a consensus on a

quantity of ease and value points for the requirement



24/41





25/41



Software security flaws, are caused by one of the following three problems:

Requirements and design failed to include proper security

During implementation, vulnerabilities were inadvertently introduced

in the code

During deployment a configuration setting did not match the

deployment environment

Secure coding deals with problem #2 how do we avoid common coding

errors, which lead to security vulnerabilities in the code

Remember - you cant blame developers, if nobody ever told them what toavoid

Lets discuss what to avoid (very high level)



26/41



Improper Input Validation

Improper Encoding or Escaping

of Output

Failure to Preserve SQL QueryStructure (aka 'SQL Injection')

Failure to Preserve Web Page

Structure (aka XSS)

Failure to Preserve OS

Command Structure

Clear text Transmission of

Sensitive Information

Cross-Site Request Forgery (CSRF)

Race Condition

Error Message Information Leak

Failure to Constrain Operations

within the Bounds of a Memory

Buffer

External Control of Critical State Data

External Control of File Name or Path

Untrusted Search Path



27/41



Failure to Control Generation of

Code (aka 'Code Injection')

Download of Code Without

Integrity Check

Improper Resource Shutdown

or Release

Improper Initialization

Incorrect Calculation

Improper Access Control

(Authorization)

Use of a Broken or Risky

Cryptographic Algorithm

Hard-Coded Password

Insecure Permission Assignment for

Critical Resource

Use of Insufficiently Random Values

Execution with Unnecessary

Privileges

Client-Side Enforcement of Server-

Side Security



28/41





29/41



Code review can uncover up to 50% of security issues

Fixing problems at the code reduces fix-cost (session #1)

While important, code review is also:

Boring (ever tried reviewing 500K LoC?)

Requires deep security knowledge

Time consuming

Automated tools can assist code reviewers

Static analysis tools

Dynamic analysis tools



30/41



Total PotentialSecurity Issues

DynamicAnalysis

StaticAnalysis

Environment Configuration Issues Patch Level Issues Runtime Privileges Issues Authentication Issues Protocol Parser/Serializer Issues Issues in external 3rd partycomponents

Null Pointer Dereference Threading Issues Code Quality Issues Issues in Dead Code Insecure Crypto Functions Issues in Back-End ApplicationCode (Multi-Tier Applications)

SQL Injection Cross Site Scripting HTTP Response Splitting OS Commanding LDAP Injection(Taint propagation issues)

Application Logic Issues /Insecure Design Issues

Runtime Analysis

Runtime Analysis serves asthe glue between Static &Dynamic Analysis. It helpscorrelate results andimprove overall accuracy &actionability



31/41




32/41



33/41





34/41

pp y


Ensure that security requirements have been implemented and that the application

is free of vulnerabilities

Involves using manual techniques and automated tools*

Web application scanners, Fuzzers, Fault Injectors, Protocol Fuzzers, Code

analyzers

What do we test for? There are several resources with lists of common weaknesses:

MITRE CWE, OWASP Testing Guide, Top 10, Top 25, etc.

MITRE CVE, National vulnerability database,

Create security test plans

Use threat models, abuse cases, security requirements, documentation to locate

weak points to test

Use external audit teams



35/41

pp y


Careful configuration and customization of software deployment environment can

greatly enhance security posture

Secure deployment tips:

Only retain services and features necessary to meet system requirements

Replace services that are known to be insecure

Deploy relevant system patches

Access control eliminate default accounts & passwords. Restrict access appropriately

Fine tune access controls at the network and OS level

Protect sensitive data (stored, on the wire)

Configure event logging and monitoring (for incident response operations)

Remember attacks will happen! Be prepared



36/41

pp y


Security enablement:

Gathering security critical information from dev teams and

communicating it to the users and operators of the software

Without this information, even the most securely designed

software carries undue risks since important security

characteristics and choices will not be known at a deployment site

(documentation!)

Vulnerability Management:

Security incident response process

Metrics & analysis of root-causes



37/41




38/41


Building secure software requires knowledge and skills

Security awareness programs for dev teams is a must

Knowledge level required from the different team members:

Product managers: need to understand the level of security that is

necessary for the product and ensure that it is described in their

requirements documents. Fundamentals of software security and

specifically the impact of security issues. Knowledge of industry

standards & government regulations

Development managers: need to understand the impact of securityissues. Learn secure development frameworks & methodologies, threat

modeling & risk assessment



39/41


Software architects: understanding of security issues & impacts. Training

in secure coding practices, know security features and controls in

specific platforms, threat modeling & risk assessment

Developers: understand the coding mistakes that lead to security issues,

understand the principles for secure coding and be able to test their own

code

QA: understand the security issues they have to watch out for. They

would also benefit from training on application security testing

techniques and methodologies as well as training on different security

testing tools



40/41


An internal IBM document

A set of recommended guidelines and best practices to help

IBMers build secure software

The purpose of the SEF is to help you build security into thedevelopment process from the beginning and ensure products

will meet or exceed IBMs security requirements and industry

best practices

Scope: to educate the reader on what activities should beperformed, and not on the details of how to perform them

Provides further reference to training and education materials

that will provide deeper information



41/41

SEF document:

https://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdf

IBM Secure Engineering Community:

http://w3.tap.ibm.com/w3ki2/display/seceng/Home

Build Security In (DHS) web site:

https://buildsecurityin.us-cert.gov/daisy/bsi/home.html

Protection Poker:

ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdf

MITRE CWE (common weaknesses enumeration) :

http://cwe.mitre.org/

SANS Top 25 most dangerous programming errors:

http://www.sans.org/top25errors/

Open Software Assurance Maturity Model (OpenSAMM):

http://www.opensamm.org/
https://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttps://buildsecurityin.us-cert.gov/daisy/bsi/home.htmlftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfhttp://cwe.mitre.org/http://www.sans.org/top25errors/http://www.opensamm.org/http://www.opensamm.org/http://www.sans.org/top25errors/http://www.sans.org/top25errors/http://www.sans.org/top25errors/http://cwe.mitre.org/ftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfftp://ftp.ncsu.edu/pub/unity/lockers/ftp/csc_anon/tech/2008/TR-2008-21.pdfhttps://buildsecurityin.us-cert.gov/daisy/bsi/home.htmlhttps://buildsecurityin.us-cert.gov/daisy/bsi/home.htmlhttps://buildsecurityin.us-cert.gov/daisy/bsi/home.htmlhttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttp://w3.tap.ibm.com/w3ki2/display/seceng/Homehttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdfhttps://w3.tap.ibm.com/w3ki2/download/attachments/233955/SEF+whitepaper+-+20081113.pdf

overview of secure engineering

Documents