7/17/13 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
1 7/17/13 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
2 7/17/13 How to build Security in Software*!
Touch Point Model: Incorporate security considerations
throughout the Software Development Life Cycle!
Abuse
cases
Security
requirements
Requirements
and use
cases
Risk
analysis
Design
External
review
Test Plan
Penetration
testing
Static
analysis
Security
breaks
Risk
analysis
Risk-based
security
tests
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 performance vs. usability and risks!
•  No longer a single concern of securing codes!
• Cultivate awareness of software security practice in
organizations!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
9
3 7/17/13 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 !
4 7/17/13 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
5 7/17/13 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
6 7/17/13 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!
!
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!
•  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
20
Current security engineering
Software Development Life Cycle
Requirements
Elicitation!
Security breaks"
Security
Upgraded
Penetration testing"
Requirements
Feedback
Deployment &
Design &
Maintenance
Analysis
Risk Analysis"
Product
Penetration testing"
Risk Analysis" Design
Risk Analysis"
Review"
Verification &
External
Implementation! Software
Validation!
Security Tests"
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
21
7 7/17/13 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!
Web Application
Design Model!
C
me ount
as er
ure
s!
Risk!
High-Risk
Counter
Mitigation! Components!
measures!
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
22
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
23
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
24
8 7/17/13 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
25
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
26
High-level Software Design
Customer order products scenario
Browse
product!
Place!
Product
Order!
Verify Order
and Charge!
yes!
Login!
yes!
CI!
Record Billing to
Orders ! Customer!
Validate!
Login!
no!
no!
Customer Interface!
Cancel!
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
27
9 7/17/13 Estimate Exposure Degrees
Customer order products scenario
Place!
Product
Order!
Browse
product!
Login!
no!
CI!
Cancel!
Record Billing to
Order ! Customer!
Validate!
Login!
Schedule
Product Plan!
Determine Parts
Requirements!
MPS!
Record
Material
Order!
Place
Material
Order!
BOM!
Record
Finished
Products!
Simulate Parts/
Products!
Manufacturing!
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!
Update Demands &
Input Parameters!
yes!
no!
Estimating component
exposure based on its
likelihood of usage
Verify Order
and Charge!
yes!
JOB!
Center for Science & Engineering of Cyber Security
!
Whitacre College of Engineering
28
Component Dependency Graph
S!
0.4!
!
0.4!
!
0.5!
!
0.2!
!
0.5!
!
!
T! !
0.25! 0.33!
0.46!
SI!
0.2!
!
CI!
!
MI!
0.75! 0.1! 0.67!
!
! ! 0.07!
MRP!
!
!
0.17!
0.7!
! MPS!
!
1!
!
BOM!
0.3!
!
JOB!
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
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
!
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
29
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"
Application Servers!
Center for Science & Engineering of Cyber Security
and
D4! Product
Material orders
A3!
Database Servers"
Whitacre College of Engineering
30
10 7/17/13 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
!2!
!4!
!3!
!1!
!2!
!2!
!2!
!2
Whitacre College of Engineering
31
Vulnerability Ratios
Application Servers!
MI, MRP"
Manager!
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
!
Database Servers"
D1!
2"
"1
"A3
!
!
!
!
!
!
!1
Center for Science & Engineering of Cyber Security
"2
"D1
!
!
!
!1
!
!
!
D4!
1"
"2
"D2
!1
!
!1
!1
!1
!
!
"2
"D3
!
!1
!
!1
!1
!1
!
2"
2"
MRP"
Product and SI, MI, MRP, BOM"
Material orders
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
32
Component Dependency Graph
Annotate each component
with its vulnerability ratio!
0"
S!!
0.4!
!
0.2!
0.4!
!
1"
!
0.14"
!
0.5!
SI!
The chances of CI being attacked !
(via S→CI) is estimated by !
T!!
0.46! 0.09"0.25! 0.33!
!
!
! CI!
!
MI!
0.2"
0.75! 0.1! 0.67!
!
! ! 0.07! !
0.2! 0.23"MRP!
!
!
! 0.17!
0.7!
0.5!
!
0.16"MPS!
!
!
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
33
11 7/17/13 Component Dependency Graph
Annotate each component
with its vulnerability ratio!
0"
S!!
0.4!
!
0.2!
0.4!
!
!
1"
T!!
0.14"
0.46! 0.09"0.25! 0.33!
!
0.5!
SI!
!
!
! CI!
!
The chances of MRP being attacked !
via CI is estimated by !
MI!
0.2"
0.75! 0.1! 0.67!
!
! ! 0.07! !
0.2! 0.23"MRP!
!
!
! 0.17!
0.7!
0.5!
! MPS!
0.16"
!
!
1!
!
!
0.16"
!
BOM!
1!
0.3!
!
!
!
0.02" JOB!
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"
!= 0.02"
!= 0.04"
!= 0.01"
Chances via MI
Chances via SI
Chances via JOB
!
Chance of MRP being attacked = 0.14 !
!
!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
34
Likelihood Estimates
0"
Component! Likelihood!
S!!
0.4!
!
0.2!
0.4!
!
1"
0.04!
SI!
0.06!
MI!
0.04!
MRP!
0.14!
MPS!
0.07!
BOM!
0.08!
T!!
0.14"
0.46! 0.09"0.25! 0.33!
!
0.5!
SI!
CI!
!
!
!
! CI!
!
MI!
0.2"
0.75! 0.1! 0.67!
!
! ! 0.07! !
0.2! 0.23"MRP!
!
!
! 0.17!
0.7!
0.5!
! MPS!
0.16"
!
!
1!
!
!
0.16"
!
!
BOM!
0.3!
!
0.02" JOB!
JOB!
0.13!
T!
0.665!
1!
!
!
Center for Science & Engineering of Cyber Security
Whitacre College of Engineering
35
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
36
12 7/17/13 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
ß Highest risk
Must protect or
mitigation plan
Whitacre College of Engineering
37
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
38
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
39
13 7/17/13 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
40
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
41
14