SWE2012-SOFTWARE

Dr. [Link] Devi

Professor

SECURITY
School of Information
Technology and Engineering
VIT, Vellore
WHY IS SECURITY A
SOFTWARE ISSUE?
Introduction
 Software Assurance and Software Security
 Identifies threats
 Shortcomings of software development

Executives/project managers/technical leaders

The problem
 Software intensive systems – to store, process & transmit most sensitive info in internet
 Ex: banks, shops, pay taxes, buy insurance, investment, social networks
 Are open and wide spread access to sensitive info.
Info warfare, cyber terrorism, computer crime
s/w defects with sec. ramifications(coding bugs) are ubiquitous
Malicious intruders  malicious code and botnetsunauth access launch
attackss/w defects
Internet enabled s/w appmore challenging
Global Security Survey– vulnerabilities reported by year87% of poor quality
App Sec: Sec code @ dev stage to prevent vulnerabilities
 Do vulnerability testing, app scanning, penetration testing during SDLC
S/W @ GREATER RISK
1. Growing internet connectivity of computers and networks & user dep on n/w
enabled services-email, web Tx
2. Degree to which sys accept updates and extensions
3. Unbridled growth in size and complexity of sys – windows OS
SYSTEM COMPLEXITY
The context within which s/w lives building trustworthy s/w
Dev Assumptions
1. Multiple indep control points instead of centralized control for large standalone sys
2. Maintained operational capabilities with sec services- upgraded and added new service
3. Heterogeneous collection of components, multiple imp of common interface, inconsistences
among sec policies
4. Errors and mistakes – failure in some form
SOFTWARE ASSURANCE
The ability to trust that s/w will remain dependable under all circumstances with
justified level of confidence
Becomes critical b’cas
 Dramatic increase in business
 Mission risks are known to be attributable to exploitable s/w

Risk exposure
 s/w is weakest link
 S/w size and complexity
 Outsourcing and use of unvetted s/w
 Sophistication & stealthy nature of attacks
 Reuse of legacy s/w with other apps
 Unwilling to make risk appropriate investment by business leaders
SOFTWARE ASSURANCE(SA)
Level of confidence
Freedom from vulnerabilities
Either intentionally designed/accidentally inserted
SAS/w Reliability + S/w Safety + S/w Security
S/w Reliability S/w fault tolerance
SOFTWARE SECURITY
Ability of s/w to resist, tolerate & recover from events that intentionally threaten its
dependability
Obj: - To build more robust, higher quality defect-free s/w that continues to fun
correctly under malicious attacks
To satisfy the following criteria:
1. Sys is vulnerability/defect-free as possible
2. Sys limits the damage from failures caused/ effects of attacks are not propagated/recovers as
quickly as from failures
3. Sys continues operating correctly
1. Either resisting the exploitation of weaknesses
2. Or tolerating the failures
SECURE S/W PROPERTIES
THROUGHOUT ITS SDLC
1. Predictable Execution
 Justifiable confidence- to reduce/eliminate malicious input to alter exe/ outcome favourable to the attacker

2. Trustworthiness
 No exploitable vulnerabilities or to be decreased

3. Conformance
 Planned, systematic & multidisciplinary activities to be ensured
 Conforms to requirements & stds & procedures

4. Attack resistant
5. Attack tolerant
6. Attack resilient
THREATS TO S/W SECURITY
Sources of danger – harm using malicious s/w
2 Categories
1. Threats during development(insider threats)
 [Link] can sabotage the s/w at any point of time in its SDLC through intentional exclusions from, inclusions in or
 Modifications of SRS
 Threat models
 Design docs
 Src code
 Assembly & integration of framework
 Test cases and test results
 Installation & config instr. Tools
2. Threats during operation (both insider & external threats)
Runs on a n/w connected platform
Vulnerabilities exposed to attackers
 Unpatched vulnerabilities
 Leading to memory corruption
 Exe. Of arbitrary exploit scripts
 Remote code exe
 Buffer overflows
SOURCES OF SOFTWARE
INSECURITY
Complexities, inadequacies, changes in the s/w processing model
Incorrect assumptions about the capabilities, outputs and behavioural states of the
s/w exe environment
Flawed spec or design or defective imp
Unintended interactions between s/w components
SOFTWARE SECURITY
It is about
 Understanding software-induced security risks and how to manage them
 Leveraging software engineering practice,
 thinking security early in the software lifecycle
 Knowing and understanding common problems
 Designing for security
 Subjecting all software artifacts to thorough objective risk analyses and testing

It is a knowledge intensive field

TRINITY OF TROUBLE
Three trends
 Connectivity
Bigger problem today .. And growing
 Inter networked
 Include SCADA (supervisory control and
data acquisition systems)
 Automated attacks, botnets
 Extensibility
 Mobile code – functionality evolves
incrementally
 Web/Os Extensibility
 Complexity
 XP is at least 40 M lines of code
 Add to that use of unsafe languages (C/C+
+)
IT BOILS DOWN TO …
more code,
more bugs,
more security problems
SECURITY PROBLEMS IN
SOFTWARE
Defect
 implementation and design
vulnerabilities
 Can remain dormant
Bug
 An implementation level
software problem
Flaw Bug Flaw
 A problem at a deeper level Buffer overflow: stack smashing Method over-riding problems
Buffer overflow: one-stage attacks (subclass issues)
Buffer overflow: string format attacks Compartmentalization problems in

Bugs + Flaws Race conditions: TOCTOU

Unsafe environment variables
design
Privileged block protection failure

 leads to Risk Unsafe system calls (fork(), exec(),

system())
(DoPrivilege())
Error-handling problems (fails open)
Incorrect input validation (black list vs. Type safety confusion error
white list Insecure audit log design
Broken or illogical access control
(role-based access control [RBAC]
over tiers)
Signing too much code
SOLUTION …
THREE PILLARS OF SECURITY
PILLAR I:
APPLIED RISK MANAGEMENT

Architectural risk analysis

 Sometimes called threat modeling or security design analysis
 Is a best practice and is a touchpoint

Risk management framework

 Considers risk analysis and mitigation as a full life cycle activity
PILLAR II:
SOFTWARE SECURITY TOUCHPOINTS
“Software security is not security software”
 Software security
 is system-wide issues (security mechanisms and design security)
 Emergent property

Touchpoints in order of effectiveness (based on experience)

 Code review (bugs)
 Architectural risk analysis (flaws)
 These two can be swapped
 Penetration testing
 Risk-based security tests
 Abuse cases
 Security requirements
 Security operations
PILLAR II: (CONTD.)

Many organization
 Penetration first
 Is a reactive approach

CR and ARA can be switched however skipping one solves only half of the problem
Big organization may adopt these touchpoints simultaneously
PILLAR II: (CONTD.)

Software security best practices applied to various software artifacts

PILLAR II: (CONTD.)
MICROSOFT’S MOVE ..
 iCMM- intellectual Capital Maturity Model
CMMI – Capability Maturity Model Integration

PILLAR II: (CONTD.) RUP-Rational Unified Process

XP-Extreme Programming

Apply Security Touchpoints

(Process-Agnostic)

Process models

Software Security
CMMI
iCMM
System-wide Emergent
Issue Property

XP
RUP account for
Security Mechanisms
Design for Security
PILLAR III:
KNOWLEDGE
Involves
 Gathering, encapsulating, and sharing security knowledge

Software security knowledge catalogs

 Principles
 Guidelines
Can be put into three categories
 Rules
 Vulnerabilities Prescriptive knowledge
Diagnostic knowledge
 Exploits Historical knowledge
 Attack patterns
 Historical risks
PILLAR III: KNOWLEDGE
CATALOGS TO S/W ARTIFACTS
RISK MANAGEMENT FRAMEWORK:
FIVE STAGES
RMF occurs in parallel with SDLC activities

Measurement and reporting

1 2 Identify 3 4
Understand the Business Define the Risk
Synthesize and
the Business and Technical Mitigation
Rank the Risks
context Risk Strategy
Artifact Analysis

Business
Context
5
Carry out fixes
And validate
STAGE 1:
UNDERSTAND BUSINESS CONTEXT
Risk management
 Occurs in a business context
 Affected by business motivation

Key activity of an analyst

 Extract and describe business goals – clearly
 Increasing revenue; reducing dev cost; meeting SLAs; generating high return on investment
(ROI)
 Set priorities
 Understand circumstances

Bottomline – answer the question

 who cares?
STAGE 2: IDENTIFY THE BUSINESS
& TECHNICAL RISKS
Business risks have impact
 Direct financial loss; loss of reputation; violation of customer or regulatory requirements; increase in
development cost

Severity of risks
 Should be capture in financial or project management terms

Key is –
 tie technical risks to business context
STAGE 3: SYNTHESIZE AND
RANK THE RISKS
Prioritize the risks alongside the business goals
Assign risks appropriate weights for resolution
Risk metrics
 Risk likelihood
 Risk impact
 Number of risks mitigated over time
STAGE 4: RISK MITIGATION
STRATEGY
Develop a coherent strategy
 For mitigating risks
 In cost effective manner; account for
 Cost Implementation time
 Completeness Impact
 Likelihood of success

A mitigation strategy should

 Be developed within the business context
 Be based on what the organization can afford, integrate and understand
 Must directly identify validation techniques
STAGE 5: CARRY OUT FIXES
AND VALIDATE
Execute the chosen mitigation strategy
 Rectify the artifacts
 Measure completeness
 Estimate
 Progress, residual risks

Validate that risks have been mitigated

 Testing can be used to demonstrate
 Develop confidence that unacceptable risk does not remain
RMF - A MULTI-LOOP
Risk management is a continuous process
 Five stages may need to be applied many times
 Ordering may be interleaved in different ways
 Risk can emerge at any time in SDLC
 One way – apply in each phase of SDLC
 Risk can be found between stages

Level of application
 Primary – project level
 Each stage must capture complete project
 SDLC phase level
 Artifact level
It is important to know that RM is
 Cumulative
 At times arbitrary and difficult to predict
SEVEN TOUCHPOINTS
COST OF FIXING DEFECT AT
EACH STAGE
CODE REVIEW
Focus is on implementation bugs
 Essentially those that static analysis can find
 Security bugs are real problems – but architectural flaws are just as big a problem
 Code review can capture only half of the problems
 E.g.
 Buffer overflow bug in a particular line of code
 Architectural problems are very difficult to find by looking at the code
 Specially true for today’s large software
CODE REVIEW
Taxonomy of coding errors
 Input validation and representation
 Some source of problems
 Metacharacters, alternate encodings, numeric representations
 Forgetting input validation
 Trusting input too much
 Example: buffer overflow; integer overflow
 API abuse
 API represents contract between caller and callee
 E.g., failure to enforce principle of least privilege
 Security features
 Getting right security features is difficult
 E.g., insecure randomness, password management, authentication,
access control, cryptography, privilege management, etc.
CODE REVIEW
Taxonomy of coding errors
 Time and state
 Typical race condition issues
 E.g., TOCTOU; deadlock
 Error handling
 Security defects related to error handling are very common
 Two ways
 Forget to handle errors or handling them roughly
 Produce errors that either give out way too much information or so radioactive no one wants to handle them
 E.g., unchecked error value; empty catch block
CODE REVIEW
Taxonomy of coding errors
 Code quality
 Poor code quality leads to unpredictable behavior
 Poor usability
 Allows attacker to stress the system in unexpected ways
 E.g., Double free; memory leak
 Encapsulation
 Object oriented approach
 Include boundaries
 E.g., comparing classes by name
 Environment
 Everything outside of the code but is important for the security of the software
 E.g., password in configuration file (hardwired)
CODE REVIEW
Static analysis tools
 False negative (wrong sense of security)
 A sound tool does not generate false negatives
 False positives
 Some examples
 ITS4 (It’s The Software Stupid Security Scanner);
 RATS; Flawfinder
CIGITAL STATIC ANALYSIS PROCESS
ARCHITECTURAL RISK ANALYSIS

Design flaws
 about 50% of security problem
 Can’t be found by looking at code
 A higher level of understanding required

Risk analysis
 Track risk over time
 Quantify impact
 Link system-level concerns to probability and impact measures
 Fits with the RMF
ARA WITHIN RMF
2 Measurement and reporting
Identify
the Business Technical
Risk expertise
Artifact Analysis
1 4 5
Understand Business Define the Risk
Synthesize and
the Business Context Mitigation
Rank the Risks
context Strategy
3 Identify
the Technical
Risk
Artifact Analysis
7 6
Validate the
Initiate process Fix the artifacts
artifacts
improvement Validation loop
ARA PROCESS
Figure 5-4
ARA PROCESS
Attack resistance analysis
 Steps
 Identify general flaws using secure design literature and checklists
 Knowledge base of historical risks useful
 Map attack patterns using either the results of abuse case or a list
of attack patterns
 Identify risk based on checklist
 Understand and demonstrate the viability of these known attacks
 Use exploit graph or attack graph

- Note: particularly good for finding known problems

ARA PROCESS
Ambiguity analysis
 Discover new risks – creativity requried
 A group of analyst and experience helps – use multiple points of view
 Unify understanding after independent analysis
 Uncover ambiguity and inconsistencies

Weakness analysis
 Assess the impact of external software dependencies
 Modern software
 is built on top of middleware such as .NET and J2EE
 Use DLLs or common libraries
 Need to consider
 COTS
 Framework
 Network topology
 Platform
 Physical environment
 Build environment
SOFTWARE PENETRATION TESTING

Most commonly used today

Currently
 Outside->in approach
 Better to do after code review and ARA
 As part of final preparation acceptance regimen
 One major limitation
 Almost always a too-little-too-late attempt at the end of a development cycle
 Fixing things at this stage
 May be very expensive
 Reactive and defensive
SOFTWARE PENETRATION TESTING

A better approach
 Penetration testing from the beginning and throughout the life cycle
 Penetration test should be driven by perceived risk
 Best suited for finding configuration problems and other environmental factors
 Make use of tools
 Takes care of majority of grunt work
 Tool output lends itself to metrics
 Eg.,
 fault injection tools;
 attacker’s toolkit: disassemblers and decompilers; coverage tools monitors
RISK BASED SECURITY TESTING

Testing must be
 Risk-based
 grounded in both the system’s architectural reality and the attacker’s mindset
 Better than classical black box testing
 Different from penetration testing
 Level of approach
 Timing of testing
 Penetration testing is primarily on completed software in operating environment; outside->in
RISK BASED SECURITY TESTING

Security testing
 Should start at feature or component/unit level testing
 Must involve two diverse approaches
 Functional security testing
 Testing security mechanisms to ensure that their functionality is properly implemented
 Adversarial security testing
 Performing risk-based security testing motivated by understanding and simulating the attacker’s approach
ABUSE CASES
Creating anti-requirements
 Important to think about
 Things that you don’t want your software to do
 Requires: security analysis + requirement analysis
 Anti-requirements
 Provide insight into how a malicious user, attacker, thrill seeker, competitor can abuse your system
 Considered throughout the lifecyle
 indicate what happens when a required security function is not included
ABUSE CASES
Creating an attack model
 Based on known attacks and attack types
 Do the following
 Select attack patterns relevant to your system – build abuse case around the attack patterns
 Include anyone who can gain access to the system because threats must encompass all potential sources
 Also need to model attacker
ABUSE CASES
Figure 8-1
SECURITY REQUIREMENTS AND
OPERATIONS

Security requirements
 Difficult tasks
 Should cover both overt functional security and emergent characteristics
 Use requirements engineering approach

Security operations
 Integrate security operations
 E.g., software security should be integrated with network security
REFERENCE
SOFTWARE SECURITY ENGINEERING
BY
JULIAH ALLEN, SEAN BARNUM, ROBERT J ELLISON, GARY MCGRAW,
NANCY R MEAD
PEARSON EDUCATION