Secure Development and Deployment

Baking security in – the earlier, the better

• The earlier in a project’s lifecycle you find a security vulnerability, the
easier—and therefore cheaper—it will be to fix (holistic approach)

• The later you find a problem, the greater the chance that you’ll have a
lot of work to undo and redo (penetrate-and-patch approach)
The Penetrate-and-Patch approach
• This approach works on security activities only at the end (bad approach)
• A penetration test, colloquially known as a pentest or ethical hacking, is an
authorized simulated cyberattack on the web application, performed to
evaluate the security of the application.
• The test is performed to identify weaknesses (or vulnerabilities) and the
possible attacks on the application.
• The test is done using tools that a hacker will use
• If there is no in-house expertise to perform the pentest, then you can
contract with a third party to perform the pentest.
• It is a costly approach as it involves many cycles of testing and fixing the
vulnerabilities
The Penetrate-and-Patch approach
• Fix any defects that the pentest turns up and also retest the
application
• If the retest reveal that the issues weren’t fixed completely correctly,
or if turns up any new issues, then you’ll need to start up yet another
round of fixing and retesting
The Penetrate-and-Patch approach
Holistic Approach to Web Application
Security
• This approach is opposite to the Penetrate-and-Patch approach
• Instead of testing the security of the web application at the very end,
start at the very beginning and work security activities into every
phase of the development lifecycle (good approach)
• For example, if your design review finds a problem now and saves the
development team 100 hours of rework later in the project cycle, the
time spent on that review will have paid for itself many times over
• This approach is followed by some of the world’s most security-
successful software companies including Symantec, EMC, and
Microsoft.
Holistic Approach to Web Application
Security
• Security training
• Threat modeling
• Secure coding libraries
• Manual and automated security code review
• Security testing and black-box application scanners
• Incident response planning
Security training
• Security training must be given before a project kicks off
• Security training doesn’t need to be restricted to just developers and
testers
Security training is mandatory for everyone in a technical role, including
project engineering managers and program managers
A program manager may write application requirements or design use cases
and the security flaw should not get introduced into the system at an earlier
point in the life cycle
Threat Modelling
Threat model
• Use threat model to find out vulnerabilities in the design phase
• (Identify Security Objectives in the requirement phase itself
Security objectives are goals and constraints related to the
confidentiality, integrity and availability of your application)
• For every component in the system and every interaction between those
components, you ask yourself :
What could possibly go wrong here?
How could someone break what we’re building?
And most importantly of all, how can we prevent them from doing
that? (Here, record the mitigations so that the coders can use them)
Approaches to Threat modelling
• Asset centric perspective
what do we have that’s worth defending?
• Attacker-centric perspective
who might want to attack us, and how might they do it?
• Software centric perspective
where are all the potential weaknesses within our application?
• Microsoft has developed a threat modeling tool—the SDL (Security
Development Lifecycle) Threat Modeling Tool
Microsoft Threat Modelling Tool
• Start using the tool by creating a high-level representation of your architecture
design in data flow diagram (DFD) format
 Represent processes in your application with circles, external entities with
rectangles, datastores with parallel lines, and connections between
components are represented with arrows
• The SDL Threat Modeling Tool will automatically generate some high-level
potential threats for the elements you’ve modeled. These threats are
categorized according to the STRIDE classification: spoofing, tampering,
information disclosure, denial of service, or elevation of privilege
• The tool will also come up with the suggestions for mitigation. For example, if
you’ve created a datastore object in your DFD, the tool might prompt you to
consider the potential information disclosure effects of any undo or recovery
functionality.
Sample DFD for an online shopping cart
Microsoft’s Elevation of Privilege : A
Threat Modelling Card Game
• Elevation of Privilege is a fun and very easy way to get started threat
modeling
• Elevation of Privilege gameplay is loosely based on the game Spades.
• Players are dealt with cards, which they then play in rounds of tricks
• Every player who can identify a potential threat in their application
corresponding to the card played earns a point, and the player who
wins the trick with the best card also earns a bonus point
Microsoft’s Elevation of Privilege : A
Threat Modelling Card Game
Mitigating Design Threats
• For example, a mitigation to the threat of an attacker gaining access
to the application database might be to encrypt all the columns in
the database containing users’ sensitive personal information.
Secure Coding libraries
• Secure coding libraries and software frameworks with embedded
security help software developers guard against security-related design
and implementation flaws
 A developer writing an application from scratch might not have
sufficient knowledge, time, or budget to properly implement or
maintain security features.
Secure Coding Libraries
Static Analysis tool for code review
• Code review can be done by humans (manual)
• Instead of manually reviewing every line of code in your application for
potential security issues, a better way to use your time is to run a tool
called the static analysis tool - also called white box scanner
• Cons
Static analysis tools work on one specific source code language or a
couple of different languages
If different modules of your application are written in different
languages, then any modules written in a language that the scanner
doesn’t understand won’t be analyzed.
Static Analysis tool for code review
Security Testing
• The very nature of security testing is different from functional testing
In functional testing, you’re checking that the application does
something it’s supposed to do.
But in security testing, you’re checking that the application doesn’t do
something it’s not supposed to do
• More number of tools are needed to perform security testing as hackers
use more tools
Automated black-box scanning tools
HTTP proxy tools like the Fiddler tool
Black-Box scanning
• Automated testing tool that detects vulnerabilities in target applications not by
analyzing its source code, but rather by analyzing its HTTP responses
• They’re called black-box scanners because, unlike a static analysis tool, they
don’t have access to the application’s underlying source code
 Pros - So, they don’t care what languages or frameworks you’re using.
Whether you’re using just vanilla PHP (for example) or a combination of F#,
Scala, and Go, a black-box scanner will happily analyze your application
either way
 Cons - Since there is no access to the source code, it’s possible for the
scanner to miss analyzing large portions of the application
• Two types
 Active scanners
 Passive scanners
Black-Box scanning
• Active scanners
Automatically generate and send their own HTTP request attacks
against the target application
Pros
 Works faster than a human tester
 Know how to construct SQL injection attacks and cross-site scripting
attacks whereas a human tester may lack this knowledge
Cons
 Sometimes difficult to be able to automatically traverse through
complex application workflows such as multistep login forms
 They may corrupt the application
Black-Box scanning
• Passive scanners
Watch HTTP traffic while a human tester interacts with the live application
• Note
Don’t run active black-box scanning tools against live, production web sites.
You could potentially corrupt your application’s databases or accidentally run
a denial of-service attack (DoS) on yourself. Run these kinds of tools against
test systems or staging servers.
Black box Analysis Tools
Security Incident Response Planning
• While you work to avoid getting hacked, you also have to make a plan
as to what you’ll do if the worst thing happen.
• Attackers can launch attacks at inconvenient times (like Christmas
morning) for you, since it’ll take you longer to respond. So, we need
to have a plan ahead of time.
Plan
• Security training for everyone at least once a year. This includes not only
coders and testers but also engineering and program managers as well.
• In-house training can be very effective. If in-house training is not possible,
then look into inexpensive or free alternatives such as local conferences,
security workshops, and blogs
• Use threat modelling to find out design-level vulnerabilities. Finding out
vulnerabilities in the design phase makes it less expensive to correct.
• Threat modeling is a waste of time unless you identify mitigations along
with the threats and you remember to record them, so that coders can use
them
• Use secure coding libraries (available for free download). It will save you
the time and frustration of trying to write your own defense code.
Plan
• Manually reviewing code for security defects is extremely time-
consuming. So, use an automated static source code or binary
analyzer.
• No tool is perfect. So, use third party service to weed out false
positives
• Along with static source code analyzer, use a black-box web
application scanner. These two types of tools has the potential to find
issues that the other can’t.
• Have a security incident response plan in place before your
application is pushed to production.
Industry Standard Secure Development
Methodologies and Maturity Models
• Microsoft’s Security Development Lifecycle (SDL)

• OWASP’s Comprehensive Lightweight Application Security Process (CLASP)

• Software Assurance Maturity Model (SAMM)

• Building Security In Maturity Model (BSIMM)

Microsoft’s Security Development Lifecycle (SDL)
• The SDL is based on a waterfall-style development methodology
(www.microsoft.com/sdl)
• The Microsoft SDL introduces security practices throughout all phases of
the development process. The SDL helps developers build more secure
software by reducing the number and severity of vulnerabilities.
• There are seven phases: training, requirements, design, implementation,
verification, release and response
Provide Training
• Security is everyone’s job
Developers, service engineers, and program and product managers
must understand security basics and know how to build security into
software and services to make products more secure while still
addressing business needs and delivering user value
• Everyone should understand the attacker’s perspective and their goals
• Effective training will reinforce security policies, SDL practices, standards,
and requirements of software security, and be guided by insights derived
through data or newly available technical capabilities.
Define Security Requirements
• Factors that influence security requirements include (but are not
limited to) the legal and industry requirements, internal standards
and coding practices, review of previous incidents, and known
threats. These requirements should be tracked through either a work-
tracking system or through telemetry derived from the engineering
pipeline.
Create Quality Gate/Bug bar
• A bug bar is a quality gate which is used to define the severity thresholds of
security vulnerabilities
For example, there should be no known vulnerabilities in the application
with a “critical” or “important” rating at time of release
• The bug bar, once set, should never be relaxed.
Establish Design Requirements

• Establish design requirements such as authentication, logging,

cryptography etc.
• Define cryptography standards
Perform Threat Modeling

• Threat modeling can be applied at the component, application, or system

level.
• Applying a structured approach to threat scenarios helps a team more
effectively and less expensively identify security vulnerabilities, determine
risks from those threats, and then make security feature selections and
establish appropriate mitigations
Use Approved Tools

• Define and publish a list of approved tools and their associated security
checks, such as compiler/linker options and warnings. Engineers should
strive to use the latest version of approved tools, such as compiler
versions, and to take advantage of new security analysis functionality and
protections.
Perform Static Analysis Security
Testing (SAST)
• Done
To identify security vulnerabilities in code
 To spot certain flaws such as the existence of unsafe or other banned
functions and replace those with safer alternatives
• Development teams should decide the optimal frequency for performing
SAST
Perform Dynamic Analysis Security
Testing (DAST)
• Black box tools are used to check memory corruption, user privilege issues,
and other critical security problems etc.
Fuzz testing
• Black box testing method
• An automated software testing method that injects invalid, malformed, or
unexpected inputs into a system to reveal software defects and
vulnerabilities. A fuzzing tool injects these inputs into the system and then
monitors for exceptions such as crashes or information leakage.
• Fuzzing is an automated process whereas the traditional pen testing is a
manual process
Establish a Standard Incident Response Process

• Incident Response Plan is crucial to address new threats that can emerge
over time
• It is a set of written instructions that outline your organization's response
to cyber attacks and security incidents
• It should be prepared in coordination with your organization’s dedicated
Product Security Incident Response Team (PSIRT)
• The plan should include
Who to contact in case of a security emergency
Protocol for security servicing
Plans for including code inherited from other groups within the
organization and for third-party code.
• The incident response plan should be tested
SDL-Agile
• To address the difficulty of completing SDL tasks in a short release cycle,
Microsoft developed an adaptation of the original SDL process called SDL-
Agile
• SDL categorizes the security activities by lifecycle phase and SDL-Agile
categorizes them by frequency
For example, static analysis is both relatively quick and easy to
perform, and is very useful in finding potential vulnerabilities, so it
should be performed during the course of every sprint. However, fuzz
testing takes much longer to perform, and finds fewer vulnerabilities (at
least for average web applications), so it only needs to be performed
once every six months
Classic Agile Methodology
OWASP Comprehensive Lightweight
Application Security Process (CLASP)
• Originally developed by Secure Software, but was donated to OWASP in
2006
• SDL categorizes the security practices by lifecycle phase (and SDL-Agile
categorizes them by frequency), whereas CLASP categorizes them by role
of project members
• Each contributor to a CLASP project fits into one or more of these seven
roles:
Project Manager
Requirements Specifier
Architect
Designer
Implementer
Test Analyst
Security Auditor
Software Assurance Maturity Model
(SAMM)
• SAMM is a prescriptive model, an open framework which is simple to use,
fully defined, and measurable
• The solution details are easy enough to follow even for non-security
personnel
• SAMM was defined with flexibility in mind so that small, medium, and
large organizations using any style of development can customize and
adopt it
• SAMM does not insist that all organizations achieve the maximum
maturity level in every category. Each organization can determine the
target maturity level for each Security Practice that is the best fit and adapt
the available templates for their specific needs
The resources provided by SAMM will aid in:
✦ Evaluating an organization’s existing software security practices
✦ Building a balanced software security assurance program in
well-defined iterations
✦ Demonstrating concrete improvements to a security assurance
program
✦ Defining and measuring security-related activities throughout
an organization.
• Software Assurance Maturity Model was developed by OWASP
• SAMM starts by defining four business functions:
 Governance, or the management of software development
 Construction, or the design and coding of software
 Verification, or the testing of software
 Deployment/Operations, or the shipping to end users and support of software
• Within each critical business function, SAMM defines three distinct security
practices that are key to improving software security assurance for that function.
These practices vary between business functions; for example, the governance
function is concerned with setting policy and ensuring regulatory compliance,
where the deployment function is concerned with hardening the environment that
the application is deployed into.
SAMM V1 Model
• For each security practice, SAMM defines four maturity levels,
starting at level zero (unfulfilled) and moving towards level three
(mastery). Each maturity level is defined by an objective and a set of
activities to accomplish this objective. For example, the objective to
attain the level one maturity stage of the design review practice is for
the organization to “support ad-hoc reviews of software design to
ensure baseline mitigations for known risks.” In order to accomplish
this, the team must identify the potential attack surface of their
application and check their application’s design against a set of
predefined security requirements
Maturity levels of the security practice
• The details for each level differs between the practices, but they generally
represent:
• 0 - represent the activities in the practice being unfulfilled
• 1 - Initial understanding of security practice
• 2 - Increased efficiency and/or effectiveness of the security practice
• 3 - Mastery of security practice
Security Practices in Governance
• Strategy & Metrics involves the overall strategic direction of the
software assurance program and instrumentation of processes and
activities to collect metrics about an organization’s security posture.
• Policy & Compliance involves setting up security policy, compliance,
and audit control framework to achieve increased assurance
• Education & Guidance involves training and guidance on security
topics relevant to individual job functions.
Security Practice in Construction
• Threat Assessment involves accurately identifying and characterizing
potential attacks in order to better understand the risks and facilitate
risk management
• Security Requirements involves promoting the inclusion of security-
related requirements during the software development process in
order to specify correct functionality from inception.
• Secure Architecture - Promote secure-by-default designs and control
over technologies and frameworks upon which software is built.
Security Practices in Verification
• Design Review involves inspection of the artifacts created from the
design process
• Implementation Review involves assessment of an organization’s
source code to aid vulnerability discovery and related mitigation
activities
• Security Testing involves testing the organization’s software
Security Practices in Operations
• Issue Management - Managing internal and external vulnerability
reports
• Environment Hardening involves implementing controls for the
operating environment to strengthen the security posture of
applications that have been deployed.
• Operational Enablement – identify security-relevant information to
properly configure, deploy and run an organization’s software.
The Building Security In Maturity Model
(BSIMM)
• BSIMM is somewhat similar to SAMM in that it’s a maturity model with
four high-level domains (governance, intelligence, secure software
development lifecycle [SSDL] touchpoints, and deployment) with three
practices defined for each domain.
• Like SAMM, BSIMM defines maturity levels for each practice and sets of
activities to take you from one level to the next.
• Difference between SAMM and BSIMM
• SAMM is prescriptive whereas BSIMM is descriptive
SAMM provides prescriptive advice on how to implement particular
activities
BSIMM doesn't say what you should be doing, rather what other
firms out there are doing