Software Security (Part II):
Practices, Trends, Risks
Rattikorn Hewett"
!
NSF SFS Workshop!
August 12-16, 2013!
Outline
•  Software security: interpretation & issues!
•  Software security practices!
•  In software development!
•  New trends!
•  Software security in Information System Design!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
2
Software security: Interpretations
•  Software security refers to ….?!
•  Software that provides security (e.g., anti-virus software)!
•  Security in any software!
Goal: "
To build software that protects !
•  confidentiality,!
•  integrity, and !
•  availability !
of resources under the control of authorized users even
under malicious attacks
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
3
Software security: Issues
•  Software is highly connected and exposed!
àdiverse & large sets of users/attackers!
•  Software is highly complex!
à software defects!
à security ramifications, e.g.,!
•  Implementation bugs leading to buffer overflow!
•  Design security flaws !
•  Software is highly extensible to large-scale !
à infeasibility of defect-free software!
•  Software defects with security ramifications are likely to
remain …… regardless how well we learn to develop
secure software!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
!
4
Outline
•  Software security: meaning & issues!
•  Software security practices!
•  In software development!
•  New trends!
•  Software security in Information System Design!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
5
Current principles!
•  No longer non-functional add-on security features!
•  Deal with the whole life-cycle of software development!
•  No longer secure components by isolation!
•  Deal with the whole system and not just software!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
6
How to build Security in Software*!
Touch Point Model: Incorporate security considerations
throughout the Software Development Life Cycle!
Abuse
cases
Requirements
and use
cases
Security
requirements
Risk
analysis
Design
External
review
Security
breaks
Risk
analysis
Risk-based
security
tests
Test Plan
Penetration
testing
Static
analysis
Code
Test Results
Field
Feedback
Lightweight - Good for experts but hard for non-security
people to practice because of insufficient details!
* Gary McGraw, 2006. Software Security: Building Security In, Addison-Wesley Software Security Series
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
7
Outline
•  Software security: meaning & issues!
•  Software security practices!
•  In software development!
•  New trends!
•  Software security in Information System Design!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
8
Additional principles!
•  No longer non-functional add-on security features!
•  Deal with the whole life-cycle of software development!
•  No longer secure components by isolation!
•  Deal with the whole system and not just software!
•  No longer one perspective!
• Deal with multiple perspectives: performance, usability
and risks!
•  No longer a single concern of securing codes!
• Cultivate awareness of software security practice in a
whole organization"
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
9
Security practices must ….!
•  Be iterative à building blocks !
•  Enable risk-based customized to the organization!
•  Provide enough details for non-security-people!
•  Be simple, well-defined, and measurable!
SAMM: Software Assurance Maturity Model*
* Pravir Chandra, OpenSAMM Project, http://www.opensamm.org
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
10
SAMM Security Practices
•  Each business function has three security practices
covering areas relevant to software security assurance!
•  Each practice is a silo for improvement!
* Pravir Chandra, OpenSAMM Project, http://www.opensamm.org
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
11
Each Security Practice!
•  Defines elements: objectives, activities, results,
metrics, cost etc.!
•  Each element has three successive levels of practices
(for improvement over time):!
1.  Initial understanding/ad hoc provision!
2.  Increase efficiency and/or effectiveness!
3.  Comprehensive mastery of the practice at scale !
SAMM Security Practices
•  Each business function has three security practices
covering areas relevant to software security assurance!
•  Each practice is a silo for improvement!
* Pravir Chandra, OpenSAMM Project, http://www.opensamm.org
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
13
Example of security practice level 1!
Overview!
Software Development!
Business Function!
Governance!
Security Practice!
Education & Guidance (EG)!
Center for Science & Engineering of Cyber Security
EG1 – Objective "
Offer development staff access to resources around the
topics of secure programming and deployment!
EG1 – Activities "
•  Conduct technical security awareness training!
•  Build and maintain technical guidelines
EG1 – Results"
§  Increased developer awareness on the most common
problems at the code level !
§  …!
EG1 – Success Metric"
§  >50% development staff briefed on security issues within
past 1 year!
§  …!
EG1 – Costs"
§  Training course build out or license!
§  …!
EG1 – Personnel"
§  Developers (1-2 days/yr)!
§  Architects (1-2 days/yr)!
EG1 – Related Levels"
Whitacre College of Engineering
14
Conducting assessments!
•  SAMM includes assessment worksheets for each
Security Practice
* Pravir Chandra, OpenSAMM Project, http://www.opensamm.org
SAMM !
Provides a model for security practices that help:!
•  Build a balanced software security assurance program
in well-defined iterations!
•  Define and measure security-related activities
throughout an organization!
•  Demonstrate concrete improvements !
•  Evaluate an organizationʼs software security practices!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
16
Outline
•  Software security: meaning & issues!
•  Software security practices!
•  Development!
•  New trends!
•  Software security in Information System Design!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
17
Motivations
•  Today s modern organizations increasingly rely on
web-based information systems to provide:!
•  critical functions (e.g., power grid control)!
•  day-to-day operations and business services
(e.g., banking transactions)!
!
!
!•  Security breaches in such applications could have
devastating consequences
à Security has become a necessary requirements
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
18
Challenges
•  Advances in Communication & IT have made web-based
systems more vulnerable !
•  pervasive, ubiquitous (e.g., distributed, mobile, wireless)
computing!
⇒ High exposure & huge diverse users!
•  Distinctive features of web-based development:!
⇒ Uncertainty!
•  Rapid change and growth!
⇒ Long term effects!
•  Living with long life cycles!
•  Increase scope & complexity! ⇒  Impossible for large-scale!
applications to be defect-free!
!
Risk-based Assessment!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
19
Issues
•  Design flaws are estimated to cost about 50% of security
problems [Verdon & McGraw, 04]!
•  Fixing security after a system was built can be costly,
unprincipled, or infeasible!
!!
Risk-based Assessment !
at a Design Level"
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
20
Issues
•  Design flaws are estimated to cost about 50% of security
problems [Verdon & McGraw, 04]!
•  Fixing security after a system was built can be costly,
unprincipled, or infeasible!
•  Existing security risk methodologies and tools at the design
level mostly rely on!
•  Best practice standards (e.g., checklists and guidelines)!
⇒ not robust to custom designs
! ⇒ vulnerable to unforeseen threats
•  Subjective expert judgments!
!! ⇒ tend to be ad-hoc & unstructured
⇒ results are inconsistent, unrepeatable & hard to scale
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
21
Current security engineering
Software Development Life Cycle
Requirements
Elicitation!
Security breaks"
Security
Upgraded
Risk Analysis"
Penetration testing"
Requirements
Feedback
Deployment &
Design &
Maintenance
Analysis
Product
Risk Analysis" Design
Review"
External
Security Tests"
Implementation! Software
Penetration testing"
Risk Analysis"
Verification &
Validation!
Static Analysis (Tool)
•  Existing risk methodologies at design levels:!
•  standard-based e.g., NIST s ASSET, SEI s OCTAVE
•  tool-based e.g., Insight s CRAMM, Microsoft s STRIDE
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
22
Our research objectives
•  To develop an analytical framework for building security
into web-based information system design!
New component/!
Modified design!
Risk
management!
decision!
Cost/Benefit!
Tradeoff!
Counter
measures!
Web Application
Design Model!
Risk!
Mitigation!
High-Risk
Components!
Risk
Quantification!
Risk Analysis"
!
•  To enhance risk quantification in high-level design to
alleviate current deficiencies!
Model-based risk quantification
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
23
Risk concepts
•  Risk refers the possibility of some undesirable event
along with the likelihood of its occurrence. !
•  Traditional risk quantification: Given an undesirable
event (hazard), !
!
Risk = Hazard Likelihood × Subsequent Severity!
Security Risk = Exposure × Vulnerability
Asset Values
•  Security risk quantification: Given a threat !
(attackerʼs goal), we can quantify security risk above.
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
24
Proposed Risk Quantification
High-level web-based
information system design
High-level
software design
Use case
scenarios
Hardware
deployment
Activity/Workflow/!
Process Diagrams
Scanned known
vulnerability of each
HW component
Failure
Likelihood of
consequences component usage
Exposure Degree
Quantified Severity
Number of vulnerabilties
Vulnerability Ratio
Quantified attack Likelihoods
Security Risk
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
25
Case study
•  A web-based system for material requirements planning
(MRP) for manufacturing enterprise (to minimize delay in
production and product delivery):!
•  takes customer orders through the B2B web front!
•  updates and predicts the daily planned orders (can be
overwritten by the manager) !
•  simulates real-time scheduling and production!
•  determines materials required !
•  sends material orders to supplier!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
26
Use case scenarios & Assumptions
!We assume a simplified B2B!
•  Three use cases!
•  customer orders products!
•  manager adjusts demands/requirements!
•  supplier acknowledges material order!
•  All payments are off-line transactions!
•  Access policy: !
•  customers & suppliers must login via a web front!
•  a manager can do remote login to the MRP system!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
27
High-level Software Design
Customer order products scenario
Browse
product!
Place!
Product
Order!
Verify Order
and Charge!
yes!
Login!
yes!
CI!
Customer Interface!
Cancel!
Record Billing to
Orders ! Customer!
Validate!
Login!
no!
no!
Update Demands &
Input Parameters!
Schedule
Product Plan!
Determine Parts
Requirements!
Simulate Parts/
Products!
Manufacturing!
Place
Material
Order!
Record
Finished
Products!
Center for Science & Engineering of Cyber Security
Record
Material
Order!
MRP!
Material Requirements!
Planning !
MPS!
Master Production
Schedule!
BOM!
Bill of Material!
JOB!
Job shop simulator!
Whitacre College of Engineering
28
Estimate Exposure Degrees
Customer order products scenario
Browse
product!
Place!
Product
Order!
yes!
Login!
yes!
no!
CI!
Cancel!
Record Billing to
Order ! Customer!
Validate!
Login!
no!
Estimating component
exposure based on its
likelihood of usage
Verify Order
and Charge!
Update Demands &
Input Parameters!
Schedule
Product Plan!
Determine Parts
Requirements!
Simulate Parts/
Products!
Manufacturing!
Place
Material
Order!
Record
Finished
Products!
Center for Science & Engineering of Cyber Security
M1 CI MRP MPS BOM JOB T
CI 0 3 4 0 0 0 14
MRP 14 0 14 0 0 12
MPS 0 0 0 1 0 0
BOM 0 0 0 0 12 12
JOB 0 1 0 0 0 0
MRP!
MPS!
Record
Material
Order!
BOM!
JOB!
!
Whitacre College of Engineering
29
Component Dependency Graph
S!
0.4!
!
!
0.5!
!
0.2!
!
0.5!
!
!
T! !
0.25! 0.33!
0.46!
SI!
0.2!
0.4!
!
CI!
!
MI!
0.75! 0.1! 0.67!
!
! ! 0.07!
MRP!
!
!
0.17!
0.7!
! MPS!
!
1!
!
BOM!
0.3!
!
JOB!
1!
!
!
M1 CI MRP MPS BOM JOB T
CI 0 3 4 0 0 0 14
MRP 14 0 14 0 0 12
MPS 0 0 0 1 0 0
BOM 0 0 0 0 12 12
JOB 0 1 0 0 0 0
customer orders
products (0.4)
M 2 MI MRP MPS BOM JOB T
MI 0 2 3 0 0 0 13
MRP 13 0 13 0 0 13
MPS 0 0 0 1 0 0
BOM 0 0 0 0 12 12
JOB 0 1 0 0 0 0
manager adjusts
demands/
requirements (0.2)
M3 SI MRP BOM T
SI 0 12 12 0
MRP 12 0 0 12
BOM 0 0 0 1
0.5×0.4 = 0.2
0.33×0.2 = 0.06
supplier
acknowledges
material order (0.4)
0.5×0.4 = 0.2
Center for Science & Engineering of Cyber Security
!
Whitacre College of Engineering
30
Hardware Deployment
Manager!
D1! Password Data
A1!
Info,
D2! Product
Production Plan!
Customer!
A2!
Customer &
D3! Supplier Info!
Internet"
Supplier!
W!
Web Server!
Client Servers"
A3!
Application Servers!
Center for Science & Engineering of Cyber Security
and
D4! Product
Material orders
Database Servers"
Whitacre College of Engineering
31
Estimate Component Vulnerability
Assess known vulnerabilities from public databases !
(e.g., Bugtraq) or running a security scanner (e.g., Nessus)
Host
Vulnerability Sources
Vulnerability Count"
!
W
A1
A2
A3
D1
D2
D3
D4
!Apache-Chunk, PHP 4.2
"Jboss, JRE 1.4.2, Windows, Tomcat-3.2.1
"Jboss, JRE 1.4.2, Windows
"Telnetd
"Oracle, TNS Listener
"Oracle, TNS Listener
"Oracle, TNS Listener
"Oracle, TNS Listener
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
!2!
!4!
!3!
!1!
!2!
!2!
!2!
!2
32
Vulnerability Ratios
Application Servers!
MI, MRP"
Manager!
D1!
2"
Password
Data
MPS, BOM!
D2! 2"
Product Info, CI, MI, MRP, MPS"
Production Plan!
A2!
D3!
Customer & SI, MRP, MPS, BOM"
Supplier Info!
A1!
Customer!
CI, SI"
Internet"
Supplier!
W! 2"
4"
3"
JOB"
Web Server!
A3!
Client Servers"
#Vuls ! 2
!W
CI
!1
SI
!1
MI
!
MRP !
MPS !
BOM !
JOB !
"4
!A1
!
!
!1
!1
!
!
!
"3
"A2
!
!
!
!
!1
!1
!
Center for Science & Engineering of Cyber Security
Database Servers"
"1
"A3
!
!
!
!
!
!
!1
"2
"D1
!
!
!
!1
!
!
!
D4!
1"
"2
"D2
!1
!
!1
!1
!1
!
!
"2
"D3
!
!1
!
!1
!1
!1
!
2"
MRP"
Product and SI, MI, MRP, BOM"
Material orders
2"
Vulnerability counts
"2
!!
"D4 Total #Vuls Vul. Ratio"
!
!4
!0.09"
!1
!6
!0.14!
!1
!8
!0.2!
!1
!10
!0.23"
!
!7
!0.16"
!1
!7
!0.16!
!
!1
!0.02
Whitacre College of Engineering
33
Component Dependency Graph
Annotate each component
with its vulnerability ratio!
0"
S!!
0.4!
!
0.14"
!
SI!
0.2!
0.4!
!
1"
!
The chances of CI being attacked !
(via S→CI) is estimated by !
T!!
0.46! 0.09"0.25! 0.33!
!
0.5!
!
! CI!
!
MI!
0.2"
0.75! 0.1! 0.67!
!
! ! 0.07! !
MRP!
0.2! 0.23"
!
!
! 0.17!
0.7!
0.5!
! MPS!
0.16"
!
!
1!
!
!
0.16"
!
!
BOM!
0.3!
!
0.02" JOB!
S is secured & !
!1−0!
S transits to CI safely & !0.4!
CI s vulnerability !
!0.09!
Chance = 1× 0.4 × 0.09 = !0.04"
Ignore cycle since it gives lower chance!
1!
!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
34
Component Dependency Graph
Annotate each component
with its vulnerability ratio!
0"
S!!
0.4!
!
0.14"
!
SI!
0.2!
0.4!
!
1"
!
The chances of MRP being attacked !
via CI is estimated by !
T!!
0.46! 0.09"0.25! 0.33!
!
0.5!
!
! CI!
!
MI!
0.2"
0.75! 0.1! 0.67!
!
! ! 0.07! !
MRP!
0.2! 0.23"
!
!
! 0.17!
0.7!
0.5!
! MPS!
0.16"
!
!
1!
!
!
0.16"
!
!
BOM!
0.3!
!
0.02" JOB!
1!
!
!
Center for Science & Engineering of Cyber Security
S is secured & !
!
S transits to CI safely & !
CI is secured
!
CI transits to MRP safely &!
Vulnerability of MRP
!
!1−0!
!0.4!
!1− 0.09!
!0.75!
!0.23!
Chance = 1× 0.4 × 0.91× 0.75× 0.23 !
= 0.06"
Chances via MI
!= 0.02"
Chances via SI
!= 0.04"
Chances via JOB != 0.01"
!
Chance of MRP being attacked = 0.14 !
!
!
Whitacre College of Engineering
35
Likelihood Estimates
0"
Component! Likelihood!
S!!
0.4!
!
0.2!
0.4!
!
1"
!
T!!
0.14"
0.46! 0.09"0.25! 0.33!
!
0.5!
SI!
!
!
! CI!
!
MI!
0.2"
0.75! 0.1! 0.67!
!
! ! 0.07! !
MRP!
0.2! 0.23"
!
!
! 0.17!
0.7!
0.5!
! MPS!
0.16"
!
!
1!
!
!
0.16"
!
!
BOM!
0.3!
!
0.02" JOB!
CI!
0.04!
SI!
0.06!
MI!
0.04!
MRP!
0.14!
MPS!
0.07!
BOM!
0.08!
JOB!
0.13!
T!
0.665!
1!
!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
36
Severity Analysis
SW
units
CI
MRP
MPS
BOM
JOB
MI
SI
Malicious actions
Consequences
change product order
increase access level
change product order
change demands
change charges
access customer info
access product info
change schedule
access product info
access supplier info
change parts
increase access level
access product info
access supplier info
change finished time
access product info
change prod. status
increase access level
increase access level
order unverified
increase vulnerabilities
incorrect charge, plan
over/under stock
lose profits
lose financial info
lose product info
incorrect plans
lose product info
lose supplier info
incorrect product plan
increase vulnerabilities
lose product info
lose supplier info
late delivery, lose cust.
lose product info
wrong update
increase vulnerabilities
increase vulnerabilities
Center for Science & Engineering of Cyber Security
Severity
MN
CR
MG
MG
CT
CT
MG
CR
MG
MG
CR
MG
MG
MG
MG
MG
MN
MN
MG
CT (catastrophic: 0.95)
CR (critical: 0.75)
MG (marginal: 0.5)
MN (minor: 0.25)
[ISO, 2002].
Whitacre College of Engineering
37
Security Risks
Component! Likelihood! Severity!
Risks!
CI!
0.04!
0.75!
0.03!
SI!
0.06!
0.5!
0.03!
MI!
0.04!
0.25!
0.01!
MRP!
0.14!
0.95!
0.13!
MPS!
0.07!
0.75!
0.05!
BOM!
0.08!
0.75!
0.06!
JOB!
0.13!
0.5!
0.07!
T!
0.665!
0.75!
0.499!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
ß Highest risk
Must protect or
mitigation plan
38
Exercise
You are to assess security risk of a high level design
of a simple online shopping system with given three
components with corresponding functions as follow:!
•  Product Browser (B): browse items and add/update
customerʼs basket!
•  Payment Manager (P): checks customerʼs financial
credentials and allows submission accordingly. A
customer may change his mind to quit or go back to
shopping again !
•  Record Manager (R): records shipping information
and purchase order. A customer may continue
shopping after this!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
39
Exercise (cont)
•  Step 1 – Design a workflow diagram of the eshopping process as described!
•  Step 2 – Construct component dependency model
from transitions in one use case!
•  Step 3 – Compute vulnerability ratio of each
component from a given hardware deployment and
the number of vulnerabilities resulted from a scanner
(in green) below!
B"
!
Customer!
A1"
B"
!
2"
Product Info! B, P"
D1!
Internet"
W! 3"
Web Server!
A2!
3"
P, R"
Application Servers!
Center for Science & Engineering of Cyber Security
D2!
2"
Payment
Record!
P, R"
2"
Database Servers"
Whitacre College of Engineering
40
Exercise (cont)
•  Step 4 – Compute attack likelihood of each
component based on vulnerability ratio and
transitions!
•  Step 5 – Assess severity, i.e., damages of attack of
each component (using standard ISO 2002)!
•  Step 6 – Compute security risk of each component !
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
41
Conclusions
•  Provide concepts of software security practices!
•  Present one aspect of research in software
security!
à How to evaluate software design with respect
to security risks!
à Can be used to determine which components
need to be protected from attack risks!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
42