Princess Sumaya University for Technology

The King Hussein School for Computing Sciences

13434 Secure Software Development

Topic 3: Software Security Models

Dr. Ahmad Altamimi

Outline
o Microsoft Security Development Lifecycle
o National Institute of Standards and Technology (NIST)
o OWASP Software Assurance Maturity Model (SAMM)
o Software Assurance Forum for Excellence in Code (SAFECode)
Microsoft Security Development Lifecycle
Microsoft Security Development Lifecycle
o Microsoft proposed sixteen mandatory security practices that have been
acknowledged as effective by security and privacy experts.
o These practices are constantly reviewed for effectiveness as part of an annual
evaluation process.

Requirements Design Implementation Verification Release Response

o Pre-SDL Requirements: Security Training

 SDL Practice 1: Training Requirements
 All members of a software development team must receive appropriate training to stay
informed about security basics and recent trends in security and privacy.

See https://www.microsoft.com/en-us/securityengineering/sdl/practices
SDL Practice 1: Training Requirements
Basic software security training should cover foundational concepts such as:
o Secure design, including the following topics:
 Attack surface reduction
 Principle of least privilege
 Secure defaults

o Threat modeling, including the following topics:

 Overview of threat modeling
 Coding constraints based on a threat model

o Security testing, including the following topics:

 Differences between security testing and functional testing
 Risk assessment
 Security testing methods
SDL Practice 1: Training Requirements
Basic software security training should cover foundational concepts such as:
o Secure coding, including the following topics:
 Buffer overruns (for applications using C and C++)
 Integer arithmetic errors (for applications using C and C++)
 Cross-site scripting (for managed code and Web applications)
 SQL injection (for managed code and Web applications)
 Weak cryptography

o Privacy, including the following topics:

 Types of privacy-sensitive data (Identifiable Information, Protected Health Information, Regulated,
Business, Confidential, and High-Risk Data)
 Privacy design best practices (embed use encryption and authentication and regularly test vulnerabilities)
 Privacy development and testing best practices
Microsoft Security Development Lifecycle
o Phase One: Requirements
 SDL Practice 2: Security Requirements
 Security and privacy requirements analysis is performed at project inception (during the
initial planning stages) and includes specification of minimum-security requirements.

 SDL Practice 3: Quality Gates/Bug Bars

 A bug bar is a quality gate that applies to the entire software development project. It is
used to define the severity thresholds of security vulnerabilities—for example, no known
vulnerabilities in the application with a “critical” or “important” rating at time of release.
 For example, all compiler warnings must be triaged and fixed prior to code check-in.
 Defining these criteria at the start enables teams to identify and fix security bugs during
development.
Microsoft Security Development Lifecycle
 SDL Practice 4: Security and Privacy Risk Assessment
 This requires deep review such as:
• (Security) Which portions of the project will require threat models before release?
• (Security) Which portions of the project will require security design reviews before
release?
• (Security) Which portions of the project (if any) will require penetration testing by a
mutually agreed upon group that is external to the project team?
• (Security) What is the specific scope of the fuzz testing requirements?
• (Privacy) What is the Privacy Impact Rating? The answer will be (High, Moderate, or
Low Privacy Risk) .
Microsoft Security Development Lifecycle
o Phase Two: Design
 SDL Practice 5: Design Requirements
Consider Secure features and Security features in this phase.
 Secure features describes features including validation of all data before processing or
cryptographically robust implementation of libraries for cryptographic services.
 Security features describes program functionality with security implications, such as
Kerberos authentication or a firewall.

In addition, security or privacy features are described here such as user authentication to
access specific data.
Microsoft Security Development Lifecycle
 SDL Practice 6: Attack Surface Reduction
 Attack surface reduction is a means of reducing risk by giving attackers less opportunity to
exploit a potential weak spot or vulnerability.
 Attack surface reduction encompasses shutting off or restricting access to system
services, applying the principle of least privilege, and employing layered defenses
wherever possible.

 SDL Practice 7: Threat Modeling

 Threat modeling is used in environments where there is meaningful security risk. It is a
practice that allows development teams to consider, document, and discuss the security
implications of designs in their planned operational environment and in a structured
fashion.
 Threat modeling also allows consideration of security issues at the component or
application level.
Microsoft Security Development Lifecycle
o Phase Three: Implementation
 SDL Practice 8: Use Approved Tools
Used the latest version of approved tools to take advantage of new security analysis
functionality and protections such as compiler/linker options and warnings.

 SDL Practice 9: Deprecate Unsafe Functions

Project teams should analyze all functions and APIs that will be used in conjunction with a
software development project and prohibit those that are determined to be unsafe.
For example, use header files (such as banned.h and strsafe.h), newer compilers, or code
scanning tools to check code for the existence of banned functions.
Microsoft Security Development Lifecycle
 SDL Practice 10: Static Analysis
 Static analysis of source code provides a scalable capability for security code review and
can help ensure that secure coding policies are being followed.
 Static analysis tools look for a fixed set of patterns or rules in the code in a manner similar
to virus-checking programs.
• However, Static code analysis by itself is generally insufficient to replace a manual code review.
• Static analysis tools cannot evaluate implementation bugs created by developer errors such as
improperly selected cryptographic algorithms or passwords embedded in code.
• Development teams should decide the optimal frequency for performing static analysis – to
balance productivity with adequate security coverage.
Microsoft Security Development Lifecycle
o Phase Four: Verification
 SDL Practice 11: Dynamic Analysis
This run-time verification uses real or virtual processor tools like AppVerifier to monitor
application behavior for memory corruption, user privilege issues, and other critical
security problems.

 SDL Practice 12: Fuzz Testing

Is a specialized form of dynamic analysis used to induce program failure by deliberately
introducing malformed or random data to an application.

 SDL Practice 13: Threat Model and Attack Surface Review

A re-review threat models and attack surface measurement of a given application when it
is code complete. This review ensures that any design or implementation changes to the
system have been accounted for, and any new attack have been reviewed and mitigated.
Microsoft Security Development Lifecycle
o Phase Five: Release
 SDL Practice 14: Incident Response Plan
Every software must include an incident response plan as it can be subject to new threats
that emerge over time.
The incident response plan should include:
 An identified sustained engineering (SE) team, or an emergency response plan (ERP)
that identifies communications, and management staff to act as points of first contact
in a security emergency.
 On-call contacts with decision-making authority that are available 24 hours a day.
 Security servicing plans for code inherited from other groups within the organization.
 Security servicing plans for licensed third-party code, including file names, versions,
source code, third-party contact information.
Microsoft Security Development Lifecycle
 SDL Practice 15: Final Security Review (FSR)
 Examination of all the security activities performed prior to release. It includes an
examination of threat models, exception requests, tool output, and performance against
the previously determined quality gates or bug bars.
 The FSR results in one of three different outcomes: Passed FSR, Passed FSR with
exceptions, or FSR with escalation if a team does not meet all SDL requirements.

 SDL Practice 16: Release/Archive

 To release a software the security advisor must certify (using the FSR and other data) that
the project team has satisfied security requirements.
 In addition, all information and data must be archived to allow for post-release servicing.
This includes all specifications, source code, binaries, threat models, documentation,
emergency response plans, license and servicing terms for any third-party software...
Optional Security Activities
o Optional security activities are generally performed when a software application is likely to be used in
critical environments or scenarios to ensure a greater level of security analysis.
 Manual Code Review:
Performed by highly skilled individuals on the application security team and/or the security advisor
to focus on the “critical” components such as personally identifiable information, cryptographic
implementations, and alike.
 Penetration Testing:
Is a white box security analysis performed by skilled security professionals simulating the actions of
a hacker. The objective of a penetration test is to uncover potential vulnerabilities resulting from
coding errors, system configuration faults, or other operational deployment weaknesses.
Penetration tests are often performed in conjunction with automated and manual code reviews to
provide a greater level of analysis than would ordinarily be possible.
 Vulnerability Analysis of Similar Applications
Many software vulnerabilities can be found on the Internet that are potentially in software under
development.
National Institute of Standards
and Technology (NIST)
National Institute of Standards and Technology (NIST)
o NIST developed SAMATE (Software Assurance Metrics And Tool Evaluation) project
that is dedicated to improving software assurance.
o SAMATE develops methods to enable software tool evaluations, measuring the
effectiveness, and identifying gaps in methods.
o The scope of the SAMATE project is broad, ranging from operating systems to
firewalls, SCADA to web applications, source code security analyzers to correct-by-
construction methods.
o NIST developed Security Considerations in the System Development Life Cycle SP
800-64 to assist the integrating of the essential information technology security
steps into established IT system development lifecycle.
OWASP Software Assurance
Maturity Model (SAMM)
OWASP Software Assurance Maturity Model (SAMM)
o It is a flexible and prescriptive framework for building security into a software
development organization.
o SAMM enables organizations to self-assess their security assurance program and
then use recommended roadmaps to improve in a way that is aligned to the specific
risks facing the organization.
o It enables creation of scorecards for an organization’s effectiveness at secure
software development throughout the typical governance, development, and
deployment business functions.
Software Assurance Forum for
Excellence in Code (SAFECode)
Software Assurance Forum for Excellence in Code
(SAFECode)
o SAFECode is a nonprofit organization dedicated to increasing trust in information
and communications technology products and services through the advancement
of effective software assurance methods.
o It identifies and promotes best practices for developing and delivering more secure
and reliable software, hardware, and services.
o These are the “practiced practices”, which we identified through an ongoing
analysis of members’ individual software security efforts.