Swe2012-Software Security: Dr. G.Usha Devi Professor School of Information Technology and Engineering VIT, Vellore
Swe2012-Software Security: Dr. G.Usha Devi Professor School of Information Technology and Engineering VIT, Vellore
Swe2012-Software Security: Dr. G.Usha Devi Professor School of Information Technology and Engineering VIT, Vellore
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
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
SAS/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)
S.Er 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
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.)
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
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
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
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
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
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