10. Secure Software
Secure Software
CITS3004
Alvaro Monsalve
1
1. Secure Software Development
1.1. MS SDL
2. Security Requirements
2.1. SQUARE
3. Secure Application Design
4. Security Testing
Agenda
2
• Many possible security vulnerabilities for a software system,
depending on:
– Requirements (missing, misunderstood, features not securely
implemented)
– Design
– Implementation language/library issues
– Subsystem interactions/issues
– Network environment issues
– (Lack of) testing/vulnerability analysis
– Other factors
3
1. Secure Application
Engineering Issues
• Common specifications of software development process
– ISO 12207 – Systems and software engineering – software life cycle processes
4
Software Development
Note: Security related tasks are not explicitly specified
• Business or mission analysis
• Stakeholder needs and
requirements definition
• Systems/Software
requirements definition
• Architecture definition
• Design definition
• System analysis
• Implementation
• Integration
• Verification
• Transition
• Validation
• Operation
• Maintenance
• Disposal
• Many different SLC methodologies:
– Waterfall – single series of steps
– Iterative – multiple iterations, one feature at a time
– Spiral – requirements or functions analysed for risks, developed as prototype,
integrated into whole
– MS SDL (MS Security Development Lifecycle) – Microsoft methodology
– Agile methodologies – e.g. Test-driven development (TDD): gather user stories,
generate reasonable and prioritized set of features, then cycle (per feature) of
develop tests, implement, refactor design if needed
5
Software Life Cycle (SLC)
• Practice since 2004 (public since 2008)
• Many iterations to improve its processes
6
1.1. MS SDL Methodology
“The Security Development Lifecycle (SDL)
consists of a set of practices that support
security assurance and compliance
requirements. The SDL helps developers build
more secure software by reducing the number
and severity of vulnerabilities in software,
while reducing development cost.”
• Twelve security practices to be completed.
7
MS SDL Methodology
• P1: Provide Training
• P2: Define Security Requirements
• P3: Define Metrics and Compliance Reporting
• P4: Perform Threat Modeling
• P5: Establish Design Requirements
• P6: Define and Use Cryptography Standards
• P7: Manage the Security Risk of Using Third-
Party Components
• P8: Use Approved Tools
• P9: Perform Static Analysis Security Testing
(SAST)
• P10: Perform Dynamic Analysis Security
Testing (DAST)
• P11: Perform Penetration Testing
• P12: Establish a Standard Incident Response
Process
https://www.microsoft.com/en-us/securityengineering/sdl/practices
https://www.microsoft.com/en-us/securityengineering/sdl/practices
Practice 1: Provide Training
– Such as:
• Secure design
• Threat modelling
• Secure coding
• Security testing
• Privacy
8
MS SDL Methodology
Practice 2: Define Security Requirements
– Consider items such as:
• Legal and industry requirements
• Internal standards and coding practices
• Review of previous incidents
• Known threats
9
MS SDL Methodology
See next topic (Security Requirements) for more details.
Practice 3: Define Metrics and Compliance Reporting
– To:
• Establish minimum acceptable levels of security and privacy
quality
• Hold engineering teams accountable to meeting criteria
• Track key performance indicators
• Accurate tracking and reporting of security work
10
MS SDL Methodology
Practice 4: Perform Threat Modeling
– Applied to:
• Component
• Application
• System
• Etc.
11
MS SDL Methodology
• To:
• Understand security implications
• Identify security vulnerabilities
• Determine risks from those threats
• Etc.
Practice 5: Establish Design Requirements
– To carry out:
• Create security and privacy design specifications
• Review specifications
• Minimal cryptographic design requirements
• Etc.
– Secure vs Security feature
12
MS SDL Methodology
Practice 6: Define and Use Cryptography Standards
– Use industry-vetted encryption libraries
– Develop clear encryption standards
• Let the experts do this
– Make correct choice in the use of cryptography and tools
13
MS SDL Methodology
Practice 7: Manage the Security Risk of Using Third-
Party Components
– Understand impact when using third-party components
– Have an accurate inventory of third-party components
– Plan to respond when new vulnerabilities are found
– Conduct validation (where feasible)
14
MS SDL Methodology
Practice 8: Use Approved Tools
– define and publish a list of approved tools and their
associated security checks
– Use latest version of approved tools
– Take advantage of new security analysis functionality and
protections
15
MS SDL Methodology
Practice 9: Perform Static Analysis Security Testing
(SAST)
– provides a scalable capability for security code review
– help ensure that secure coding policies are being followed
– There is no one size fits all solution for conducting SAST
16
MS SDL Methodology
Practice 10: Perform Dynamic Analysis Security Testing
(DAST)
– specify tools that monitor application behaviour for
memory corruption, user privilege issues, and other critical
security problems
17
MS SDL Methodology
Practice 11: Perform Penetration Testing
– performed by skilled security professionals
– uncover potential vulnerabilities resulting from
• coding errors
• system configuration faults
• other operational deployment weaknesses
– often performed in conjunction with automated and
manual code reviews
18
MS SDL Methodology
Practice 12: Establish a Standard Incident Response
Process
– to help address new threats that can emerge over time
– create in coordination with your organization’s dedicated
Product Security Incident Response Team (PSIRT)
19
MS SDL Methodology
• OWASP Software Assurance Maturity Model (SAMM)
• Building Security In Maturity Model (BSIMM)
20
Other Approaches
https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/
SAMM
BSIMM
• Better to prevent problems with application security than
to detect and respond to them after they happen
• This is primarily done through secure software
requirements engineering and design
– Secondarily through secure development and testing as
assurance
21
Timing of Security Efforts
Requirements
– define what a system is required to do and the constraints under which it
is required to operate
Requirements engineering
– all activities involved in discovering, documenting, and maintaining a set
of requirements for a computer-based system
• The term engineering implies that systematic and repeatable
techniques (based on best practices) should be used
• Requirements engineering is the first step in software system
development
22
2. Requirements Engineering
23
Engineering Requirements
• Software Engineering has historically considered security
requirements primarily as non-functional requirements
• Software developers have recognised the need to integrate
most of the non-functional requirements, such as reliability
and performance, into the software development processes
• Security too often remains an afterthought
24
Software Engineering and
Security – History (1)
• Historical View: A Variety of Non-Functional
Requirement Types
25
Software Engineering and
Security – History (2)
lAuditability
lExtensibility
lMaintainability
lPerformance
lPortability
lPercentage of target
dependent statements
lNumber of target systems
lReliability
lMean time to failure
(MTTF)
lSecurity
lTestability
lUsability
lEtc.
• Functional security requirement
– A condition or capability needed in the system to control or limit the
fulfilment of requirements
• Non-functional security requirement
– A property of the system required to ensure fulfilment of requirements in
the face of abuse or misuse
• Derived security requirements
– not explicitly stated in the set of Stakeholder requirements, but we still
need them
• From functional requirements
• From non-functional security requirements
26
Security Requirement Types
• Describe positive, functional behaviour related to security
• Can be directly tested
• Often related to security features like role-based access
control, data integrity, etc
• Examples:
– Back office users must authenticate with valid user ID and password
– 5 or more failed login attempts result in an account lockout
27
Functional Security
Requirements
• Related to generalised security needs
• Examples:
– Audit logs shall be verbose enough to support forensics
– All price modification events shall be logged
– Application shall achieve 99.7% uptime between 6:00am and 2am
local time
– Multiple database servers
– Transaction integrity, fall-back, retry, etc.
28
Non-Functional Security
Requirements
• Important to determine security requirements early on
• Some key requirements to identify are:
– What sensitive data (assets) will be worked with?
– What actor roles will need to be distinguished?
– What levels of access to classes of data should be given to each
actor role?
• Q: how to generate these?
– A variety of elicitation techniques can be used
29
Security In Requirements
Gathering
• Traditional Approaches
– Introspection
– Interview/survey
– Group elicitation
• Observational approaches
– Protocol analysis
– Participant Observation
30
Requirements Engineering
Elicitation Techniques
• Model-based approaches
– Scenarios: characterisations of the ways in which the system is
used
– Use Cases: specific instances of interaction with the system
– Goal-based: hierarchies of stakeholders’ goals
• Exploratory approaches
– Prototyping (try something, get feedback, throw away the
original)
31
Requirements Engineering
Elicitation Techniques
Example Process:
• Security Quality Requirements Engineering, or short
for SQUARE
• From Software Engineering Institute (SEI)
• https://www.cert.org/cybersecurity-
engineering/products-services/square.cfm
32
Requirements Gathering
https://www.cert.org/cybersecurity-engineering/products-services/square.cfm
1. Agree on definitions
2. Identify security goals
3. Develop artefacts to support security requirements definition
4. Assess risks
5. Select elicitation technique(s)
6. Elicit security requirements
7. Categorize requirements
8. Prioritize requirements
9. Inspect requirements
33
2.1. SQUARE Steps
• An arbitrary term may have multiple meanings due to the
differences in expertise, knowledge, and experience.
• Ambiguities may arise in the level of detail that is assumed.
– E.g., “access control” can be interpreted as…
• To avoid, public resources can be used to produce and reuse a
comprehensive set of security terms.
– E.g., IEEE 610.12 Standard Glossary of Software Engineering
Terminology
34
Step 1: Agree on Definitions
• Requirements Engineering Team Responsibilities
– Provide an initial set of terms.
– Provide a means for stakeholders to review and select a desired definition
for each term.
– Document and share the finalised set of terms and definitions.
• Stakeholder Responsibilities
– Select an existing or create a custom definition for each term provided by
the requirements engineering team.
– All stakeholders must come to a consensus on each term’s definition in a
timely manner and present their results.
35
Step 1: Agree on Definitions
• Different stakeholders will likely have different ideas about which assets are
important and the associated security goals.
• A single business goal and several security goals:
– “The system allows the client to make informed decisions based on which assets are
available.” (Business Goal)
– “The confidentiality, accuracy, and integrity of the system’s data shall be maintained.”
(Security Goal)
36
Step 2: Identify Security
Goals
• Establish security goals, not security requirements or security
recommendations
• Goals – state what shall be
– “Management shall exercise effective control over the system’s
configuration and usage.”
– “The confidentiality, accuracy, and integrity of the Asset Management
System shall be maintained.”
– “The system shall be available for use when needed.”
• i.e., not what a specific system must do, but future desirable
state
37
Step 2: Goals vs
Requirements
• Requirements – state what must be done
– “The system is required to have strong authentication measures
in place at all system gateways/entrance points.”
(maps to Goals 1 and 2)
– “A continuity of operations plan (COOP) must be in place to
assure system availability.”
(maps to Goal 3)
• Recommendations – state a general good idea
– “Invest in backup information technology hardware to ensure
business continuity.”
38
Step 2: Goals vs
Requirements
• collect a complete set of artefacts of the system:
– system architecture diagrams
– use case scenarios/diagrams
– misuse case scenarios/diagrams
– attack trees
– standardised templates and forms
• Verify the accuracy and completeness of all artefacts!
39
Step 3: Develop Artefacts
• To identify the vulnerabilities and threats that face the
system.
– What do we know about risk assessment?
• To prioritise the security requirements at a later stage in the
process.
• Responsibilities:
– Facilitate the completion of a structured risk assessment
– Review the results and share with stakeholders
40
Step 4: Perform Risk
Assessment
• a list of potential techniques
– Use/Misuse Cases [Jacobson 92]
– Soft Systems Methodology (SSM) [Checkland 90]
– Quality Function Deployment (QFD) [QFD 05]
– Controlled Requirements Expression (CORE) [SDS 86]
– Issue Based Information Systems (IBIS) [Kunz 70]
– Joint Application Development (JAD) [Wood 89]
– Feature-Oriented Domain Analysis (FODA) [Kang 90]
– Critical Discourse Analysis (CDA) [Schiffrin 94]
– Accelerated Requirements Method (ARM) [Hubbard 00]
– Structured/unstructured Interviews.
• Examples
– https://buildsecurityin.us-cert.gov/articles/best-practices/requirements-engineering/an-evaluation-of-cost-
benefit-using-security-requirements-prioritization-methods
41
Step 5: Elicitation
Techniques
https://buildsecurityin.us-cert.gov/articles/best-practices/requirements-engineering/an-evaluation-of-cost-benefit-using-security-requirements-prioritization-methods
• Even if the stakeholders are very knowledgeable about
the project and communicate effectively, it can be
challenging for the requirements engineering team to
elicit correct requirements
– E.g., non-verifiable or vague, ambiguous requirements
– “The system shall improve the availability of the existing
customer service centre” – rephrase this.
• Remember, requirements are concerned with what the
system should do, not how it should be done.
42
Step 6: Elicit Security
Requirements
• This step allow the requirements engineer and stakeholders to classify the
requirements:
• E.g., minimal set of categories for requirements categorisation
• Note: These categorise are a minimal set, likely to be much larger and customised
to the project.
43
Step 7: Categorise
Requirements
System
Level
Software Level
Architectural
Constraints
Essential
Non-essential
• Since the goal of SQUARE is to produce security requirements, the
requirements engineering team and stakeholders should avoid
producing architectural constraints.
• Architectural constraints are provided as a category here to serve as
an outlet for “requirements” that, upon categorisation, are
considered to be constraints.
• Ideally, such anomalies would be identified and corrected in the
previous steps of the process.
44
Step 7: Categorise
Requirements
• Often we will be unable to implement all of the security requirements due
to lack of time, resources, etc.
• Step 4, the risk assessment, and Step 7, categorisation, are crucial inputs
to this step.
• Can be unstructured deliberation.
• Some structured prioritisation techniques:
– Triage [Davis 03]
– Win-Win [Boehm 01]
– Analytical Hierarchy Process [Karlsson 97, Saaty 80]
• What to do with infeasible requirements?
45
Step 8: Prioritise
Requirements
• To create a set of accurate and verifiable security
requirements.
• The goal is to find any defects in the requirements such as
ambiguities, inconsistencies, or mistaken assumptions.
• Responsibility:
– Facilitate the inspection process by providing any orientation to the
structured inspection technique or informal inspection guides such as
checklists.
46
Step 9: Inspect
Requirements
• Security Architectural Patterns
– Single-Access Point Pattern
• single point of entry into system
– Check Point Pattern
• centralised enforcement of authentication and authorisation
– Role Pattern
• disassociation of users and privileges
47
3. Security in Design –
Architectural Level (1)
• Security Architectural Patterns
– Distrustful Composition
• decompose multi-function systems to reduce attack surface
– Privilege Separation
• Reduce the amount of code that works with increased privilege
level
– Defer to Kernel
• Use existing user verification functionality within kernel to avoid
reinventing decision control
48
Security in Design –
Architectural Level (2)
49
Our System
System
Sub-system1 Sub-system2
Sub-system3
• System should have single point of entry
– Common to all incoming requests
– All users must pass through it
– Any unauthorised requests of any other component of the
system are directed to this point
• Example: Java Enterprise Edition (EE) – supports with
declarative security implemented through web container
50
Single-Access Point Pattern
51
Single-Access Point Pattern
System
Sub-system1 Sub-system2
Sub-system3
• Centralises and enforces authentication and authorisation
• Single mechanism determines if access (or ability to grant access) to
particular resource is proper
• Matches user with level of security allowed
• May be multiple check points
• Java EE supports with Java Authentication and Authorisation Service
(JAAS)
• Pluggable Authentication Module (PAM) also supports this pattern
52
Check Point Pattern
53
Check Point Pattern
System
Sub-system1 Sub-system2
Sub-system3
• Disassociation of users and their privileges
• Avoid an un-manageable rats’ nest of combinations
• User assigned one or more roles
• Role assigned one or more privileges
• Supports easier management
• Java EE supports through declarative security model
– Can specify in XML deployment descriptors
• Found in other large software systems (e.g. Oracle)
54
Role Pattern
55
Role Pattern
System
Sub-system1 Sub-system2
Sub-system3
• Normally, functionality accumulates within modules,
leaving large modules with multiple functionality and
possibly multiple interfaces and/or attack surfaces
• Pattern: decompose multi-function systems to reduce
the attack surface
– Small cohesive units have less vulnerabilities by providing a
smaller attack surface
– Small, modular units can be better isolated and tested
56
Distrustful Composition
57
Distrustful Composition
Sub-system3
Resource files User credentials
• Reduce the amount of code that works with increased
privilege level
• Specific instance of Distrustful Composition
• Uses pre-authentication and post-authentication states
– Pre-authentication: before undergoing authentication, client or
responding server process are given no privilege
– Post-authentication, privilege is introduced, but not directly given to
the client
• Uses privileged parent process as monitor and less-privileged
child process as worker
58
Privilege Separation
59
Privilege Separation
Resource files
User credentials
1
2
OK!
1
NO!
• Use existing user verification functionalities within
kernel to avoid reinventing decision control
– Avoid re-implementing work that the kernel already can do
– The kernel has proven, existing security features and has
been analysed more thoroughly than new code
60
Defer to Kernel
61
Defer to Kernel
User credentials User credentials
Cryptography
Authentication
kernel
Cryptography
Authentication
Etc.
• Two Examples:
– Façade (fa-saad)
– Proxy
62
General Design Patterns
Relevant to Software Security
• Facade pattern provides an unified interface to a
complex subsystem
– Example: JDBC interface requires client to use three major Java
classes: Connection, Statement and ResultSet
– Could generate a single facade class, so that client can access
that class, and that class deals with the actual detail work
through the three classes, as well as providing an additional
point of security
63
Facade Design Pattern (1)
64
Facade Design Pattern (2)
JDBC
System 1
Connection
Statement
ResultSet
SUPERJDBC
Connection
Statement
ResultSet
• Not only simplifies class structure (from client view)
and guides user, but limits what client can do with
the complex subsystem
• Facade can help implement Single Access Point and
Check Point security patterns
65
Facade Design Pattern (3)
• Used to provide varying degrees of access and instantiation
on demand to varying clients
• Proxy acts as a reference to the real object
• Many networking systems use proxy classes to protect actual
server classes from direct contact and security issues
• Proxy controls access to object, may be responsible for
creating/deleting it
66
Proxy Design Pattern (1)
67
Proxy Design Pattern (2)
System 1 System 2
• Proxy can help implement a security layer:
– Authentication
– Authorisation
– Filtering requests
– Auditing/Logging
68
Proxy Design Pattern (3)
• Investigation of standard design patterns for security
issues, goal of modifying these patterns to support
secure design
• See SEI Secure Design Patterns Technical Report
– http://resources.sei.cmu.edu/library/asset-
view.cfm?assetID=9115
69
Secure Versions of Design
Patterns
http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9115
• Implementation Level Patterns
– Secure Logger
– Clear Sensitive Information
– Secure Directory
– Pathname Canonicalisation (normalisation)
– Input Validation
– Resource Acquisition is Initialisation.
70
Security Implementation
Patterns
• One approach
– Identifying threats, considering interfaces
– Considering design options for each threat
– Making a secure design decision for each threat
71
Designing for Security
• Involves good software engineering principles
regarding testing
• Involves security mindset, principles, and
consideration
72
4. Security Testing
• An integral part of software development
• Normally software development teams need to test several aspects of the
system, including:
– Correctness of the software
– Performance
– Reliability
– Etc.
• A testable design is a design that can be easily validated and maintained
• However, testing demands a rigorous effort and requires significant time
and cost
• Designing software that allows testability is also an important design
principle for software development
73
Software Testing – Background
• Two possible results of a test
– Positive test – no problem found
• Only validates that software works for specified test cases
• Doesn’t mean there aren’t defects lurking outside of the tested
areas/aspects
– Negative test – problem found
• One negative test result is sufficient to show that defects exist
74
Software Testing
• Levels of testing
– Unit testing
– Integration testing
– System testing
– Acceptance testing
• Good testing done by multiple testers that are not developers
for that code
– Often independent quality assurance (QA) group
– Exception: unit testing is done by developers
75
Software Testing
Unit Testing (Module testing)
• debuggers, tracers
• done by programmers as they develop (hopefully continuously)
• Advantages
– Tests are run very frequently – issues are identified quickly
– Most granular form of test – high test coverage
• Disadvantages
– Not many security vulnerabilities can be tested at this layer
76
Software Testing
Integration Testing
• communication between modules
• start with one module, then add incrementally
• Advantages
– Can test in the application server
– Many security vulnerabilities can be tested (e.g., Injection, Authentication flaws
and Authorisation flaws)
• Disadvantages
– Not executed as often as unit tests
– Overhead of starting an application server
– Some vulnerabilities may not be easily testable, e.g.: XSS, URL filtering performed
by a web server or application firewall.
77
Software Testing
System Testing
• manual procedures, restart and recovery, user interface
• real data is used
• users involved
• Advantages
– Can test the security of whole system
– All potential security vulnerabilities can be tested
• Disadvantages
– Overhead of starting an application server
– Some vulnerabilities may not be easily testable
78
Software Testing
Acceptance Testing
• user-prepared test data
• Verification Testing, Validation testing, Audit Testing
• Advantages
– Full testing of external API
– Security consultants can use tools to script vulnerabilities
– Documents vulnerabilities
– Easy retesting
• Disadvantages
– Low test coverage
– Developers aren’t involved in testing
79
Software Testing
• Two testing types
– White Box Testing
• Assume access to source code
• Performed by examining logic flow through code
– Black Box Testing
• Assume no access to source code
• Performed by testing with expected and unexpected input,
examining output and side effects
80
Software Testing
• In general:
1. Decide how much security is needed
2. Carry out automated testing
3. Test at every stage
4. Make a test plan
5. All system components are tested
81
Software Testing
• Two aspects of security testing:
– Testing security mechanisms in system to ensure that their functionality is properly
implemented
• Part of testing general system functionality
• Test authentication, authorization, access control, etc.
– Performing risk-based security testing, motivated by understanding and simulating
the approach of a likely attacker
• Not considered part of general functionality testing
• Testing misuse cases to see if they have been prevented
• Question: Who is qualified/best suited to do these two types of security
testing?
82
Software Testing
• Software vulnerability analysis
• Secure coding
• Security assurance
• Software/security maintenance
– E.g., emerging issues
83
Other things to consider
• Security has to be built into every phase of the
software development process
• Software security starts with secure requirements
and secure design
• Retrofitting security is expensive and less effective
84
Summary
• Agile
– MS SDL: https://www.blackhat.com/presentations/bh-dc-10/Sullivan_Bryan/BlackHat-
DC-2010-Sullivan-SDL-Agile-wp.pdf
– SAFECODE:
http://www.safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf
• US CERT: security requirements engineering
– https://www.us-cert.gov/bsi/articles/best-practices/requirements-engineering/security-
requirements-engineering
• OWASP SAMM: Software Assurance Maturity Model
– https://www.owasp.org/index.php/OWASP_SAMM_Project
85
Extra Items
https://www.blackhat.com/presentations/bh-dc-10/Sullivan_Bryan/BlackHat-DC-2010-Sullivan-SDL-Agile-wp.pdf
http://www.safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf
https://www.us-cert.gov/bsi/articles/best-practices/requirements-engineering/security-requirements-engineering
https://www.owasp.org/index.php/OWASP_SAMM_Project