AIT 681 Secure Software Engineering

Topic #4. Seven Software Security Touchpoints (I)

Instructor: Dr. Kun Sun

Reading

• This lecture– McGraw: Ch. 3 Overview– McGraw: Ch. 4 Code Review– McGraw: Ch. 5 Architectural risk analysis

2

Software Security Touchpoints

• Best Practices– Economical consideration: earlier is better– Change “operational” view to secure software– Expounded by experts and adopted by practitioners

• System-wide activity: from design to testing and feedback

• Throughout the SDLC (Software Development Life Cycle)

• Both White Hat (constructive) and Black Hat (destructive) activities

3

Secure SDLC

• Secure SDLC adds security-related activities to the existing development process. – E.g., add security requirements to functional requirements – E.g., performing architecture risk analysis in design phase

• Many Secure SDLC models have been proposed, e.g., – MS Security Development Lifecycle (MS SDL): proposed by

Microsoft in association with the phases of a classic SDLC.– OWASP CLASP (Comprehensive, Lightweight Application

Security Process): Simple to implement and based on the MS SDL. It maps the security activities to roles in an organization.

– NIST 800-64: Provides security considerations within the SDLC.

4

When to Apply Security?

• Economical consideration: early is better• Effectiveness of touchpoints: – Economics– What software artifacts are available– What tools are available– Cultural changes

• Change from reactive strategy to proactive secure development

5

Seven Touchpoints

1. Code review2. Architectural risk analysis3. Penetration testing4. Risk-based security testing5. Abuse cases6. Security requirements7. Security operations

Plus External Analysis

Prioritize activities!

6

Application of Touchpoints

Requirement and Use cases

Architecture and Design Test Plans Code Tests and

Test ResultsFeedback from

the Field

6. Security Requirements

2. Risk Analysis

External Review

4. Risk-Based Security Tests

1. Code Review(Tools)

2. Risk Analysis7. Security Operations

5. Abuse Cases

3. Penetration Testing

7

1. Code Review

8

Code Review (Tool)

• Artifact: Code• Focus on detecting implementation bugs• Static Analysis tools• White Hat

Requirement and Use cases

Architecture and Design Test Plans Code Tests and

Test ResultsFeedback from

the Field

5. Abuse cases

6. Security Requirements

2. Risk Analysis

External Review

4. Risk-Based Security Tests

1. Code Review

2. Risk Analysis

3. Penetration Testing

7. Security Operations

9

Software Bugs

• Programming bugs: – Compiler catches error, developer corrects bug,

continue development

• Security relevant bug: – May be dormant for years– Potentially higher cost than programming error

• Who should be responsible for security bug?– Software developer?– Security expert?

10

Manual vs. Automated Code Review

• Manual Peer Code Review– Tedious, error prone, exhausting– Need expert with the mindset of an attacker!

• Static analysis tools– Identify many common coding problems– Faster than manual– Need developer with basic understanding of

security problems and how to fix detected ones

11

Best Practices on Peer Code Review

• Peer Code Review recommendations from SmartBear Software–Based on a Cisco code review study–Over 6000 programmers and 100

companies “lessons learned” results– Light weight code review

https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

12

Best Practices Recommendation 1

• Review fewer that 200-400 lines at a time– Optimizes number of detected vulnerabilities (70-90 %)

• Inspection rate less than 300-500 line of code/hour– Faster is not better!– Based on number of detected vulnerabilities

• Do not spend more than 60-90 minutes at a time– Efficiency drops after about an hour of intense work

• Make developers annotate their code– Encourage developers to “double-check” their work– Reduce the number of vulnerabilities in the code

13

Best Practices Recommendation 2

• Establish quantifiable goals for code review– External metrics: e.g., reduced # of support calls– Internal metrics: e.g., inspection rate, defect rate, detect density

• Maintain checklist– Prevent omissions of important security components, eliminate

frequently made errors

• Verify that defects are fixed– Need good collaborative review of software

• Managers must support code review– Support team building and acceptance of process

14

Best Practices Recommendation 3

• Positive code review culture– Use of metrics – role of manager

• The Ego effect– Use code review to encourage developers for good coding

habits– Review at least 20-33% of code

• Light weight style of review– Tool assisted– Just as efficient as formal, heavy weight review but 1/5 less

time required

15

Static Analysis in SDLC

16

http://blogs.grammatech.com/enhancing-code-reviews-with-static-analysis

Static Analysis

• Identify vulnerable constructs without code execution• What to check? Source Code or Binary Code?• Source Code: – See the logic, control, and data flow– See explicit code lines– Fixes can be carried out on the source code

• Compiled Code:– May need reverse engineering (disassemble, decompile)– Finding a few vulnerabilities is easy. Finding all is difficult – Fixes may be incorporated as binary modules or external

filters

17

Source Code vs. Binary Code Check

• Source code– Easy to identify

location of flaw– CPU independent– Language

dependent.– Environment

independent?– 1st party only

• Binary code– Hard to map back to

source– CPU dependent– Language

independent– Environment

independent– 3rd party utility

18

How Static Analysis Works?

• Look for fixed set of patterns or rules– Syntactic matches– Lexical analysis– Flow analysis (control flow, call chains, data flow)

• False negatives• False positives• Sound tool: given a set of assumptions, the static

analysis tool does not produce false negatives• Commercial tools (e.g., Veracode, Coverity):– unsound

19

Static Analysis Tools

• Easy to use – still need expert knowledge• Can process large code (millions of lines)

efficiently• Need competence of reviewer on results• Encapsulates knowledge (known

vulnerabilities) and efficient flow analysis• Encourages efficient and secure coding

We will cover more details in Topic 19.

20

Static Analysis Tools for Security

• Be designed for security• Be extensible• Be useful for both security analyst and

developer• Support existing development process• Make sense for multiple stakeholders

21

Why Manual Reviews Are Still Required?

• Find defects that tools miss– Better understanding the intention of what the code is

meant to do (limitation of AI?)• Inspection is more than just code– Software review includes requirements, design, test plans,

and source.• Provide important context to tool reports– Better understanding the requirements of the system and

the expected outcomes• Validate tool findings – unsound of static analysis

• Intangible benefits– mentoring new developers, consistency in design and

implementation, team cohesion, project management

22

2. Architectural Risk Analysis

23

Architectural Risk Analysis

• Artifact: design and specification• Design flaws account for 50% of security problems, and

design flaws cannot be identified by code review.• A higher-level understanding of the software is required.

– Document assumptions and identify possible attacks– At both specification-based architecture stage and class-

hierarchy design stage• White hat method

Requirement and Use cases

Architecture and Design Test Plans Code Tests and

Test ResultsFeedback from

the Field

5. Abuse cases

6. Security Requirements

2. Risk Analysis

External Review

4. Risk-Based Security Tests

1. Code Review

2. Risk Analysis

3. Penetration Testing

7. Security Operations

Risk Management in Software Security

• Risk analysis: the activity of identifying and ranking risks at some particular stage in the software development lifecycle.– Popular when applied to architecture and design-

level artifacts

• Risk management: the activity of performing a number of discrete risk analysis exercises, tracking risks throughout development, and strategically mitigating risks.

25

Software Risks

• Project risks: threaten the project plan.– Identifying potential resource, schedule, scope, and

stakeholder problems. – Technical risks: Threaten the quality and schedule.– Identifying potential design, implementation, interface,

and maintenance problems.

• Business risks: threaten the viability of the SW. – An excellent SW that no one wants– A SW that no longer fit the business need– A SW that people don’t know how to sell– A SW that no longer supported by the management– A SW that lose its resource

26

Common Themes on Risk Analysis

• Risk = probability * impact• Risk identification, ranking, and mitigation is a continuous

process.• Risk analysis results and risk categories drive both into

requirements and into testing (to define and plan particular tests for risks).

• Rigorous risk analysis relies heavily on an understanding of business impact.– May require an understanding of laws and regulations as much as the

business model supported by the software.– E.g., Lawsuit between Google and Oracle on Java API

• Human Factors, assumptions

27

A Prototypical Risk Analysis Approach

1. Learn as much as possible about the target of analysis .

2. Discuss security issues surrounding the software.

3. Determine probability of compromise.4. Perform impact analysis.5. Rank risks.6. Develop a mitigation strategy.7. Report findings.

28

Microsoft STRIDE Threat Model

• Question: what can go wrong in this system we're working on?

• STRIDE is an acronym for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.

• To build a model of the system using both data flow diagrams, use cases, and a simple process for creating attack hypotheses using both lists of vulnerabilities and lists of system assets as starting points.

• Threat modeling should really refer to the activity of describing and cataloging threats those actors or agents who want to attack your system.

29

Knowledge Requirement in Architectural Risk Analysis

• Results are deeply constrained by the expertise and experience of the team doing the analysis.

• Three major aspects– Attack resistance analysis– Ambiguity analysis– Weakness analysis

30

Attack Resistance Analysis

• To capture the checklist-like approach to risk analysis– Use information about known attacks, attack patterns, and

vulnerabilities.– Not good at capturing new attacks

• Four steps:– Identify general flaws using secure design literature and

checklists (e.g., STRIDE).– Map attack patterns using either the results of abuse case

development or a list of attack patterns. – Identify risks in the architecture based on the use of

checklists.– Understand and demonstrate the viability of these known

attacks.31

Ambiguity Analysis

• To capture the creative activity required to discover new risks.– Requires at least two analysts and some amount

of experience to carry out separate analysis activities in parallel.

• It takes advantage of the multiple points of view on software architecture.– Disagreements and misunderstandings usually

reveal the potential security risks.

32

Ambiguity Analysis (cont.)

• It helps to – Uncover ambiguity and inconsistency– Identify downstream difficulty (through a process

of traceability analysis)– Unravel convolution.

• Unfortunately, it requires a team of experienced analysts.

33

Weakness Analysis

• To understand the impact of external software dependencies.– Modern software is usually built on top of complex

middleware frameworks.– Distributed code once the interesting architectural

exception has become the norm• To consider:– COTS (e.g. OpenSSL library)– Frameworks (e.g., Android, J2EE)– Network topology (e.g., DNS hijacking)– Platform (e.g., Touch ID)– Physical environment (e.g., Square 1.0)– Build environment (e.g., XcodeGhost)

34

Weakness Analysis (cont.)

• Cloud computing:– Need to understand which services your code is

counting on and exactly what your code expects those services to deliver is critical.

• The basic idea:– Understand what kind of assumptions you are

making about outside software– What will happen when those assumptions fail (or

are coerced into failing).

35

Knowledge is Most Useful in All 3 Steps

• Attack patterns and exploit graphs for understanding attack resistance analysis

• Design principles for use in ambiguity analysis • Security issues in commonly used frameworks

and other third-party components

36

Newbies should not be tasked with architectural risk analysis!!!