Historically, companies have
focused on implementing security controls around physical infrastructure,
networks, servers and endpoints. This focus is potentially because many different
technological solutions exist to help to protect these assets which can be managed
in a centralized way using dashboards and remote consoles.
Examples of these kinds of
solutions include next generation firewalls, anti-virus and advanced threat
protection (ATP) tools, and Security Incident and Event Monitoring (SIEM) supported
by threat intelligence processes.
However, the maturity level of
security in the software development lifecycle (SDLC) remains some steps behind
and I believe there are a few reasons for this.
Lack of time and the need to meet
a deadline is always the first complaint when discussing implementing security
controls beyond those which are default features in development frameworks, (for
example).
The second complaint is around
budget, especially if the development team is outsourced and are billing by the
hour. Since security has not historically been considered a basic property of
software code in the same way that performance and readability would be, it is
still seen as an extra cost.
The third complaint is the lack
of knowledge of many developers about basic security controls and the impact of
the major security flaws already documented by security community. Hopefully all
developers know about attacks such as SQL Injection, Cross-Site Scripting, Session
Hijacking, etc. However, is quite clear that sometimes developers are missing
the deep knowledge about the real consequences of successful exploitation of
those flaws. For example, a developer may know that a SQL Injection attack may
lead to data being stolen from a database but not be aware of other risks posed
by the same attack such as getting a remote command shell on the server where
the vulnerable database is hosted.
There are other examples of barriers
to implementing a secure software development lifecycle, but with the increase
in data breaches related to application vulnerabilities and the rise of known
penalties such as those defined by GDPR, it is now easier to demonstrate the
business case for companies to increase the maturity level of their secure
development processes.
OWASP (the Open Web Application
Security Project) is an international non-profit organization dedicated to
application security. It provides very valuable resources ranging from tools to
frameworks to documentation, all developed by a dedicated network of volunteers
from around the world. Nowadays, it is the best repository where you can find
all the information needed to raise the level of knowledge and skill of your
technical and management teams.
The OWASP Top 10, for example, which
is updated roughly every three years, is an excellent document to build
awareness of the most common application vulnerabilities which have been noted
in the last few years and the right controls and mitigations which can be used to
avoid and fix them. However, it is clear that it is vital that security is
included as early in the SLDC as possible since the later that security is
introduced, the more expensive issues are to fix. The Top 10 project is
probably not the most ideal project for including security early on in the SDLC
nor is it comprehensive enough to help an organization reshape their SLDC to
include security at each stage.
As such, I would like to discuss
the OWASP Software Assurance Maturity Model (SAMM) project. This is an open
framework to help organizations formulate and implement a strategy for software
security that is tailored to the specific risks facing the organization. This
model defines four different Business Functions related to Software Development
Lifecycle which the organization needs to address: Governance, Construction,
Verification and Deployment.
These four Business Functions can
be divided in 12 different Security Practices:
·
Governance (Business
Function)
o
Strategy & Metrics
(Security Practices)
o
Policy & Compliance
(Security Practices)
o
Education & Guidance
(Security Practices)
·
Construction (Business
Function)
o
Threat Assessment (Security
Practices)
o
Security Requirements
(Security Practices)
o
Secure Architecture
(Security Practices)
·
Verification (Business
Function)
o
Design Review (Security
Practices)
o
Code Review (Security
Practices)
o
Security Testing (Security
Practices)
·
Deployment (Business
Function)
o
Vulnerability Management
(Security Practices)
o
Environment Hardening
(Security Practices)
o
Operational Enablement
(Security Practices)
These twelve security practices can
each help to increase the maturity level of the organization’s SDLC, in a
measurable way. Implementing these practices can be planned step by step and the
resulting changes and improvements can be monitored. Therefore, it represents a
complete process that can be integrated into the SDLC and ensures that security
is considered from the very first stages of the planning through to the
application being deployed to production and on through the post-deployment
phase as well, with ongoing vulnerability management as a continuous practice.
The activities related to each
security practice are listed below:
·
Governance
o
Strategy & Metrics
§
Estimate overall business
risk profile
§
Build and maintain assurance
program roadmap
§
Classify data and
applications based on business risk
§
Establish and measure
per-classification security goals
§
Conduct periodic
industry-wide cost comparisons
§
Collect metrics for
historic security spend
o
Policy & Compliance
§
Identify and monitor
external compliance drivers
§
Build and maintain
compliance guidelines
§
Build policies and
standards for security and compliance
§
Establish project audit
practice
§
Create compliance gates for
projects
§
Adopt solution for audit
data collection
o
Education & Guidance
§
Conduct technical security
awareness training
§
Build and maintain
technical guidelines
§
Conduct role-specific
application security training
§
Utilize security coaches to
enhance project teams
§
Create formal application
security support portal
§
Establish role-based
examination/certification
·
Construction
o
Threat Assessment
§
Build and maintain
application-specific threat models
§
Develop attacker profile
from software architecture
§
Build and maintain
abuse-care models per project
§
Adopt a weighting system
for measurement of threats
§
Explicitly evaluate risk
from third-party components
§
Elaborate threat models
with compensating controls
o
Security Requirements
§
Derive security
requirements from business functionality
§
Evaluate security and
compliance guidance for requirements
§
Build an access controls
matrix for resources and capabilities
§
Specify security
requirements based on known risks
§
Build security requirements
into supplier agreements
§
Expand audit program for
security requirements
o
Secure Architecture
§
Maintain list of
recommended software frameworks
§
Explicitly apply security
principles to design
§
Identify and promote
security services and infrastructure
§
Identify security design
patterns from architecture
§
Establish formal reference
architectures and platforms
§
Validate usage of
frameworks, patterns and platforms
·
Verification
o
Design Review
§
Identify software attack
surface
§
Analyze design against
known security requirements
§
Inspect for complete
provision of security mechanisms
§
Deploy design review
services for project teams
§
Develop data-flow diagrams
for sensitive resources
§
Establish releases gates
for design review
o
Code Review
§
Create review checklists
from known security requirements
§
Perform point-review of
high-risk code
§
Utilize automated code
analysis tools
§
Integrate code analysis
into development process
§
Customize code analysis for
application-specific concerns
§
Establish release gates for
code review
o
Security Testing
§
Derive test cases from
known security requirements
§
Conduct penetration testing
on software releases
§
Utilize automated security
testing tools
§
Integrate security testing
into development process
§
Employ application-specific
security testing automation
§
Establish release gates for
security testing
·
Deployment
o
Vulnerability Management
§
Identify point of contact
for security issues
§
Create informal security
response team
§
Establish consistent
incident response process
§
Adopt a security issue
disclosure process
§
Conduct root cause analysis
for incidents
§
Collect per-incident
metrics
o
Environment Hardening
§
Maintain operational
environment specification
§
Identify and install
critical security upgrades and patches
§
Establish routine patch
management process
§
Monitor baseline
environment configuration status
§
Identify and deploy
relevant operations protection tools
§
Expand audit program for
environment configuration
o
Operational Enablement
§
Capture critical security
information for deployment
§
Document procedures for
typical application alerts
§
Create per-release change
management procedures
§
Maintain formal operational
security guides
§
Expand audit program for
operational information
§
Perform code signing for
application components
Whilst there are a lot of activities
to implement here, it is important to execute at the correct pace. If
activities are implemented too fast without monitoring metrics to check if each
phase was successful and has been integrated into the organization’s processes,
the implementation will ultimately fail and the security and other value
benefits will not be realized.
It is particularly important to
note that the activities in each security practice are ordered based on
maturity meaning that an organization should initially focus on implementing
the first activities across all the different practices and then once these
initial activities are operating correctly, go back and start implementing the
next activities, again across each the twelve practices.
The SAMM project documentation
even provides metrics for each activity, staff needed and the estimated time
that will be required per year for each member of the team to help the end-user
ensure that they are implementing each activity in the correct way.
Note that SAMM isn’t the only
methodology that can be used to improve the maturity level of a secure
development process. Some examples of similar methodologies are BSIMM, ISMM
(for IoT environments) or DASMM, this last one representing the implementation a
combination of controls from both BSIMM and SAMM at the same time.
Independent of the methodology,
is important to understand that everything must be grounded in the solid
foundations of a good strategy, metrics to monitor performance and policies and
procedures sponsored by management to ensure compliance with the new processes.
Ultimately, the key to success will
be employee education to help everyone to understand the real need to improve
the maturity level of secure development and to keep everyone updated and aware
of their own role in the process.
Always remember to carefully
monitor the entire process and establish SMART (Specific, Measureable,
Achievable, Relevant, Timely) goals for each step. A good approach to adopt to
help with the transformation is the Objectives and key results (OKR)
methodology as this will make it easier to identify what needs to be achieved at
each stage and what result is expected. The information for this is already
provided by the SAMM methodology. There is a link to information on OKR in the
references section.
Increasing the maturity of your
Secure SDLC will be hard work, but the results should be worthwhile and be
shown by an improvement in penetration testing results and decrease reduction
in the risk of compromise via application vulnerabilities.
References:
OWASP – https://owasp.org
BSIMM - https://www.bsimm.com/
DASMM - https://duo.com/blog/rsac-2018-building-a-software-security-maturity-program
