Developing Secure
Software
Secure UML
Security Planning
Susan Lincke
Security Planning: An Applied Approach | 6/21/2016 | 2
Objectives
The Student shall be able to:
Define command injection, cross-site scripting, cross-site request forgery.
Draw a Misuse Case Diagram and Security Use Case Diagram
Prepare a Misuse Case Description and Security Use Case Description
Define the five steps of the OCTAVE security requirements process
Describe the functionality of a Missequence diagram, Misuse Deployment
Diagram, state diagram
Describe how and why each of the following coding recommendations are
important: sanitize input and output; never expose internal data structures;
minimize access; use tried and true security algorithms; validate and control
the configuration; and manage exceptions.
Define BugBar, fuzz testing, reliability testing, sandbox, vulnerability scanner,
web spider.
Security Planning: An Applied Approach | 6/21/2016 | 3
Security Assures … CIA (Review)
Confidentiality: Limits access of
authorized users and prevents access
to unauthorized users
Integrity: The reliability of
information resources and data have
not been changed inappropriately
Availability: When something needs
to be accessed by the user, it is
available
Security Planning: An Applied Approach | 6/21/2016 | 4
Security Vocabulary (Review)
Asset: Diamonds
Threat: Theft
Vulnerability: Open door or
windows
Threat agent: Burglar
Owner: Those accountable
or who value the asset
Risk: Danger to assets
Security Planning: An Applied Approach | 6/21/2016 | 5
Registration System
Use Case Diagram
Register: Clients register to obtain
documentation by providing name,
email, job function
Provider: Send periodic updates to
Clients to indicate changes in
materials
Security Planning: An Applied Approach | 6/21/2016 | 6
OCTAVE Security Requirements Process
Risk: Threat and vulnerability(s) -> negative impact
1. Identify critical assets
2. Define security goals
3. Identify threats
4. Analyze risks
5. Define security requirements
Security Planning: An Applied Approach | 6/21/2016 | 7
Step 1. Identify Critical Assets
via Business Process Diagram
Contact Info: Name, email, job function
Materials: Course materials
Comments: Feedback, saved & sent as email
Security Planning: An Applied Approach | 6/21/2016 | 8
Step 2. Define Security Goals
Assets
Confidentiality
Integrity
Availability
Contact Info
**
No PII maintained
***
Require accurate
list of interested
persons
*
Weekly backup
Materials
*
Public with login
***
Accurate –
tamper-proof
**
24/7 preferred
Comments
**
Confidential pref.
***
Accurate – tamperproof
*
Weekly backup,
email
Impact Rating:
* Low Priority
** Medium Priority
*** High Priority
Security Planning: An Applied Approach | 6/21/2016 | 9
Step 3: Identify Threats
What it is
Spoof
Identity
STRIDE
General
Threats
Software Techniques Advanced Security
Assume identity
Encrypt passwords
Bypass protection
No backdoor entry
Secure Password
Digital Certificate
Sec. Awareness
Tamper w.
Data
Modify data
Repudiation
Hide activities
Info
Disclosure
Read data
Denial of
Service
Unreliable
execution, resource
consumption
Validate real user via
CAPTCHA
Test for Failures
Intrusion Prevention
System
Elevation of
Privilege
Gain privileges
Take care with error
messages
Access Control
Hide system files
Segregation of
Duties
Validate input
Execute
unauthorized
cmds/code
Authentication
Stop buffer overruns
Access Control
Close unused resources
Message Digest
Require passwords
Trans. Logging
Log user transactions
Digital Signature
Encrypt data
Encryption
Encrypt packets
Authentication
Minimal permissions
Secure Handling
Require approval
Firewall
Security Planning: An Applied Approach | 6/21/2016 | 10
Step 3. Identify Threats
via Misuse Case Diagram
Which misuse cases relate to:
•Confidentiality?
•Integrity?
•Availability?
Definitions:
DOS = Denial of Service
misuser
Misuse case
Security Planning: An Applied Approach | 6/21/2016 | 11
Step 3 (cont’d):
Expand DOS Misuse Case Diagram
Overflow DB: Fill disk with records
Send Continual Requests: (Distributed Denial of Service) No processor remains
Security Planning: An Applied Approach | 6/21/2016 | 12
Step 3 (optional)
Threat Tree
Security Planning: An Applied Approach | 6/21/2016 | 13
Step 3 cont’d: Intro to Misuse Case Description:
Change Valid Data
User Intention
System Response
Security Threat
User requests Reg. form
System provides form
Attacker enters form input
but appends additional SQL
commands
SQL injection
System processes input
Obtain (client) list
Change valid data
Security Planning: An Applied Approach | 6/21/2016 | 14
Step 3 Cont’d: Light-weight Misuse Case
Description
DOS
Misuse Case: Denial of Service
Summary: An attacker issues repeated Registrations, resulting in filling the database
with fake data, and depleting system and file resources.
Basic Path:
1. Do forever
2.
The attacker requests a Registration form
3.
The attacker sends random fake data in the form
4. Enddo
Alternative Paths:
AP1. Repeat data is entered
Mitigation Points:
MP1. At BP Step 2-3 use CAPTCHA in Registration form to avoid bot attack.
MP2. At BP Step 3 validate data: no duplicates, data type matching
Security Planning: An Applied Approach | 6/21/2016 | 15
Step 3 Cont’d: Mid-weight Misuse Case Description:
Circumvent Input
Misuse Case: Circumvent Input
Summary: Deviant Client bypasses registration by going directly to the download web
page.
PreCondition: Client does Google search and finds link to download web page OR
obtains link reference from a colleague
Basic Path:
1. DeviantClient obtains web reference from Google or friend.
2. DeviantClient uses web reference to download materials without registering.
Mitigation Points:
MP1: Web page has no other web references.
MP2: Create dynamic web page with unique reference. This web page is accessible
only if a key is provided during registration. Key expires in one week.
Related Business Rule: Users must register to obtain materials.
Mitigation Guarantee: MP1 and MP2 solves Google search problems. MP2 could be
used by friends for one week, which is acceptable.
Security Planning: An Applied Approach | 6/21/2016 | 16
Step 4: Analyze Risks
Threat
Impact
Likelihood
Priority = I*L
DOS
***
***
9
SQL Attack
(affects integrity,
confidentiality)
***
***
9
Invalid Input
*
***
3
Circumvent input
**
***
6
Security Planning: An Applied Approach | 6/21/2016 | 17
Step 5: Define Security Requirements
using Security Use Case Diagram
Definitions
Security Planning: An Applied Approach | 6/21/2016 | 18
Stage 5: Define Security Requirements
Modify Register
Use
Case
Desc.
Use Case: Register
Summary: Client registers to obtain access to download materials.
Preconditions: Client is at Welcome Web Page
Basic Path:
1. The client selects the Obtain Materials link.
2. The system asks the client for name, email address, job function, and CAPTCHA.
3. The client enters all three required information.
4. Include (Validate Registration)
5. The system displays the URL for the download materials.
Alternative Path:
AP1. If an attack is detected, no URL is displayed.
Postcondition:
The client has access to the download materials.
The database contains the client contact information.
Security Planning: An Applied Approach | 6/21/2016 | 19
Stage 5: Define Security Requirements:
Validate Registration Security Use Case Descr.
Security Use Case: Validate Registration
Summary: This include validates a registration.
Precondition: A name, email, job function, and Captcha are provided.
Basic Path:
1. The user enters a name, email, and job function in Step 3 of Register
2. Do until valid CAPTCHA.
3.
Rerequest form with new CAPTCHA
4. The system checks for valid characters, to prevent SQL injection.
5. The system checks for valid name, email and job function
6. If email is unique in database
7.
Save record to database
8. The system returns success.
Postconditions:
The input has been checked for bot attempt, SQL attempt, and validity.
Security Planning: An Applied Approach | 6/21/2016 | 20
Business Process Diagram
Enhancement
Loc
Loc
Local
Access
AD
AD
Attack
Detection
Pr
Pr
Privacy
Security Planning: An Applied Approach | 6/21/2016 | 21
Secure UML
SECURE DESIGN
Security Planning: An Applied Approach | 6/21/2016 | 22
Mis-Sequence Diagram
Security Planning: An Applied Approach | 6/21/2016 | 23
State Diagram
State Diagrams can ensure
software:
Retains proper order of
processing
Recognizes out-of-sequence
steps
Can change behavior based on
time or past history
Security Planning: An Applied Approach | 6/21/2016 | 24
Documenting Security Packages
Sanitizer
Registration
<<Security Package>> Sanitize Input
<<Risk Factor>> 9
<<Security Descriptor>> Injection Attack
Defense
<<protects>>
CAPTCHA
<<Security Package>>
<<Risk Factor>> 9
<<Security Descriptor>> DOS Defense
<<Security Descriptor>> 3rd Party S/W
Security Planning: An Applied Approach | 6/21/2016 | 25
Open Group’s Common Data Security
Architecture
Application
Common Security Services Manager Application Programming Interface
System Security Services
(Digital Certificate, key management, integrity services, security contexts)
Cryptographic
Services Mgr.
CS Library
Trust
Policy
Services
Mgr.
Trust
Library
Authorization
Certificate
Computation
Library Mgr.
Mgr.
AC Library
Cert. Library
Data
Storage
Library
Mgr.
DS Library
Elective
Module
Mgr
New
Services
Lib.
Security Planning: An Applied Approach | 6/21/2016 | 26
Security Diagrams:
Security Patterns
Authenticator Pattern
Authorization Pattern
Security Planning: An Applied Approach | 6/21/2016 | 27
Misuse Deployment Diagram
Shows attacks/defenses
Shows where attacks are
handled
Useful for:
• Security Planning
• Audit
• Test - QC
• S/W Development
Security Planning: An Applied Approach | 6/21/2016 | 28
Confidentiality
Integrity
Secure UML
SECURE PROGRAMMING
& SECURE TEST
Availability
Security Planning: An Applied Approach | 6/21/2016 | 29
Coding Safeguards
Sanitize input & output
• Overflows: strings, buffers, integers, float
• Suspect input: parameters or arguments, cookies, network packets, environment
variables, client request data, query/server results, URL components, e-mail, files
and databases
Never expose internal data structures:
• Protect database keys, object references or IDs, file references
• Structures may be modified to access other data
Security Planning: An Applied Approach | 6/21/2016 | 30
Coding Safeguards Cont’d
•
•
•
•
•
•
•
•
Minimize access:
Permissions: Only provide higher level access for shortest possible time
Resources: Keep resources such as files, devices and communications open
for the shortest time possible
Jail: OS can impose resource limits on programs: I/O, disk, network, files
Caching: Sensitive pages are not cached, use an active authorization token
Use tried & true security algorithms
Open Design uses algorithms created/shared by many users to withstand
the test of time
Critical algorithms include: input sanitization, encryption, integrity,
authentication, authorization, session management, logging, random
number generators
Nonce: an active authorization ticket that restricts the time a user may
respond
Do not trust 3rd party software without good inspection!
Security Planning: An Applied Approach | 6/21/2016 | 31
Coding Safeguards, Cont’d
Validate & control the configuration
Programs often require files to run properly: configuration or environmental
files.
• If an attacker changes them, a program can operate improperly
To safeguard:
• Store files in a location that prevents access to users.
• Use the full pathname to access the file
• Validate that the file does indeed have the required minimal access
permissions.
• If your program is on a website, establish certain paths with restricted
outside access
• Never hardcode configurations since the attacker can reverse engineer
code.
Security Planning: An Applied Approach | 6/21/2016 | 32
Coding Safeguards, Cont’d
Manage exceptions
The programmer can abort, continue or commit after an exception
• recovery is preferable
• recover at lower levels is best, where the specific condition is known.
• automatic exception handling is preferred
• Mission critical function requires recovery or manual intervention
Use Safe Coding Practices
Static analysis tools inspect code without execution
• Provides warnings beyond what a compiler normally provides.
• e.g., variable or environment contents not initialized, possibly leaking previous data
• Fix all warnings
Error messages should be helpful to the user, but not too explicit.
• Chatty error message: “Cannot find file: C:/users/Lincke/validation.txt”
• Error messages should avoid file, network configuration and personal info
• Remove debug information before release.
Security Planning: An Applied Approach | 6/21/2016 | 33
Test Tools
Fuzz and robustness testing generate a large number of inputs to find subtle flaws
Fuzz testing generates random input to test exception handling and input validation
Reliability testing ensures software can survive unusual conditions, e.g., faults or
unusual operating conditions.
• For mission critical code, functions shall not fail; failure rate must be known.
Vulnerability scanners test for web attacks: integer, float or string overflows, SQL
injection and cross-site scripting
Web spiders parse website(s) to find embedded links
• Follows all links recursively to determine full connectivity of a website.
• Finds cross-site scripting in websites
Manual penetration tests are tailored for specific applications
• Proxies and vulnerability scanners allow dynamic packet creation.
Security Planning: An Applied Approach | 6/21/2016 | 34
Vulnerability Testing
Buffer Overflow: Can long input affect service?
Script Injection: Can input with scripts execute?
Numeric Overflow: Can a large number become a negative or
small number?
Race Condition: Can multiple threads cause errors?
Configuration Issues: Can software be installed improperly,
causing abuse?
Programmer Backdoors: Have programmers left hooks providing
entry or information?
Security Planning: An Applied Approach | 6/21/2016 | 35
When to Release Software?
Attack Surface
Bug Bar
Knight: suit of armor protects
Security threshold that must be
attack surface by covering most achieved for release
of his body
Software: where are (new)
vulnerabilities that are not
mitigated?
Security Planning: An Applied Approach | 6/21/2016 | 36
BugBar
Bug Bar Standard for Tampering and Repudiation
Severity
Permanent modification of any user data in a common scenario that
High
persists after restarting the OS/application.
Permanent modification of any user data in a specific scenario, or
Moderate
temporary modification of user data in a common scenario.
Temporary modification of data in a specific scenario that does not
persist after restarting the OS/application.
Low
Security Planning: An Applied Approach | 6/21/2016 | 37
Mature Software Practices
Software Assurance Maturity Model
Building Security In Maturity Model
(SAMM)
(BSIMM)
Governance
Construction
Verification
Strategy & Metrics
Strategy & Metrics
Policy & Compliance
Compliance & Policy
Education & Guidance
Training
Threat Assessment
Intelligence
Attack Models
Security Requirements
Security Features & Design
Secure Architecture
Standards & Requirements
Design Review
Architectural Analysis
Security Testing
Secure
Software
Development
Life Cycle
Touchpoints
Vulnerability Mgmt
Deployment
Penetration Testing
Code Review
Deployment
Governance
Code Review
Security Testing
Environment Hardening
Software Environment
Operational Enablement
Configuration Mgmt. &
Vulnerability Mgmt.
Security Planning: An Applied Approach | 6/21/2016 | 38
Agile Development
Security training is important!
Include Evil User Stories in every Sprint
• "As a hacker, I send bad data in forms, so I can modify the database in
unauthorized ways."
Analyze risk at start of sprint, backlog change
Address Security features
• authentication, access control, input validation, output encoding,
error/exception handling, encryption, data integrity, logging and alarms,
and data communication security
Review code for security
Test using code analyzers, fuzz testing, auto/manual penetration
tests
Security Planning: An Applied Approach | 6/21/2016 | 39
Summary
Building Security Into Software
Designers and developers are trained in standard security practices
Security requirements are decided based on risk analysis and regulatory
compliance
High priority risks are mitigated and included in the schedule.
Secure designs ensure that the architecture is effective and efficient
When code is written, secure utilities are familiar to the coders and correctly
used the first time.
Knowledgeable testers perform competent penetration testing and use
automated test tools for faster, more accurate testing.
The code may still be released before all bugs are fixed, but the organization
knows and approves of any security flaws that remain.
Security Planning: An Applied Approach | 6/21/2016 | 40
Jamie Ramon MD
Doctor
Chris Ramon RD
Dietician
Terry
Medical Admin
HEALTH FIRST CASE STUDY
Security Requirements
Pat
Software Consultant
Security Planning: An Applied Approach | 6/21/2016 | 41
Step 1: Identify Critical Assets
All of this information is
protected by HIPAA
HIPAA protects:
Confidentiality: In
transmission, on disk, or
any other form.
Integrity: All
transactions are logged
as to who did them and
why. Hashing
(sophisticated
checksums) are also
required.
Security Planning: An Applied Approach | 6/21/2016 | 42
Step 2: Define security goals
Confidentiality
Integrity
Patient
Information:
Appointments,
Medical history,
Treatment,
Prescriptions,
Bills
Impact Rating:
* Low Priority
** Medium Priority
*** High Priority
Availability
Security Planning: An Applied Approach | 6/21/2016 | 43
Step 2: Define security goals
Patient
Information:
Appointments,
Medical history,
Treatment,
Prescriptions,
Bills
Confidentiality
Integrity
Availability
HIPAA Requirement
HIPAA
Requirement,
Malpractice law
suit if accidental
death
Malpractice law
suit if information
not available
***
***
Impact Rating:
* Low Priority
** Medium Priority
*** High Priority
***
Security Planning: An Applied Approach | 6/21/2016 | 44
Step 3: Identify Threats
Medical Admin use cases include:
Make appointment: Patient may
phone for an appt.
Create Patient Record To make an
appt, a minimal patient record must
exist or be created
Register for Appointment: When the
patient arrives for his/her appt.
Update Patient: Update patient
medical history
Determine Health Plan Eligibility: Ask
HMO/PPO what the patient is eligible
for in coverage – and conditions
Use Case Diagram
Security Planning: An Applied Approach | 6/21/2016 | 45
Step 3: Identify Threats
What it is
Spoof
Identity
STRIDE
General
Threats
Software Techniques Advanced Security
Assume identity
Encrypt passwords
Bypass protection
No backdoor entry
Secure Password
Digital Certificate
Sec. Awareness
Tamper w.
Data
Modify data
Repudiation
Hide activities
Info
Disclosure
Read data
Denial of
Service
Unreliable
execution, resource
consumption
Validate real user via
CAPTCHA
Test for Failures
Intrusion Prevention
System
Elevation of
Privilege
Gain privileges
Take care with error
messages
Access Control
Hide system files
Segregation of
Duties
Validate input
Execute
unauthorized
cmds/code
Authentication
Stop buffer overruns
Access Control
Close unused resources
Message Digest
Require passwords
Trans. Logging
Log user transactions
Digital Signature
Encrypt data
Encryption
Encrypt packets
Authentication
Minimal permissions
Secure Handling
Require approval
Firewall
Security Planning: An Applied Approach | 6/21/2016 | 46
Security Requirements Process
OCTAVE Security Requirements Process
 Identify critical assets
 Define security goals
3. Identify threats
Draw Misuse Diagram from Use Case Diagram
4. Analyze risks:
Priority = Impact * Likelihood
5. Define security requirements
Draw Misuse Diagram with Security Use Cases
Define one Misuse Description (Lightweight or Midweight)