81
Chapter 4
Architecture (A2):
SDL Activities and
Best Practices
During the second phase of the security development lifecycle, security
considerations are brought into the software development lifecycle to
ensure that all threats, requirements, and potential constraints on func-
tionality and integration are considered (see Figure 4.1). At this stage of
the SDL, security is looked at more in terms of business risks, with inputs
from the software security group and discussions with key stakeholders
in the SDLC. Business requirements are defined in the security terms
of confidentiality, integrity, and availability, and needed privacy con-
trols are discussed for creation, transmission, and personally identifiable
information (PII). SDL policy and other security or privacy compliance
requirements are also identified at this stage of the SDL. This ensures
that security and privacy discussions are performed as part of, rather than
separate from, the SDLC, so that there are solid understandings among
project personnel about business decisions and their risk implications for
the overall development project. A cost analysis for development and sup-
port costs required for security and privacy consistent with business needs
is also done as part of the requirements analysis. As discussed previously,
Figure 4.1 Architecture (A2): SDL activities and best practices.
Architecture (A2): SDL Activities and Best Practices 83
the planning and awareness of security, privacy, and risk management
early in the SDLC through the proper used of an SDL will result in sig-
nificant cost and time savings.
Perhaps the most important, complex, and difficult part of the SDL
starts during this phase of the SDL. As discussed previously, threat
modeling and architectural security analysis typically fall into the domain
of the senior software security architects and requires the most experience
and expertise of any of the tasks within the SDL. Fortunately, tools are
currently available and in the process of being developed that can assist
this phase, and help leverage and scale a skill set that is typically a limited
resource in a software security group.
Additional security training that may be needed for key developers
to understand the current threats and potential exploitations of their
products, as well as training for secure design and coding techniques
specific to the software being developed and for the systems with which
the software will be interacting, are identified at this stage of the SDL.
This enables the developers to work more efficiently with the software
security architects and others from the software security group to create
more secure designs and empower them to address key issues early in the
development processes.
4.1 A2 Policy Compliance Analysis
The purpose of a software security policy is to define what needs to be pro-
tected and how it will be protected, including reviewing and incor porating
policies from outside the SDL that may impact the development process.
These might include policies governing software or applications developed
or applied anywhere in the organization.During this phase, any policy
that exists outside the domain of the SDL policy is reviewed. Corporate
security and privacy policies will likely instruct designers and developers
on what the security and privacy features need to be and how they must
be implemented. Other policies may include those that govern the use
of third-party and open-source software or the protections and control
of source code and other intellectual property within and outside the
organization. Assuming the software security group is separate from the
centralized information security group, it is important that both groups
collaborate on all policies and guidelines related to the development and
84 Core Software Security
post-release security support and response of software from that organiza-
tion. It is also important to collaborate with the privacy function of the
company, whether it is a centralized group or outside legal counsel.
4.2 SDL Policy Assessment and Scoping
The SDL also provides an invaluable guide for software developers setting
a security standard for their organization and should offer a roadmap for
implementation without disrupting the core business of producing qual-
ity software applications. Unless the senior leadership of the development
organization and the management team support this model, the SDL will
likely fail. It must be driven by a policy that is signed off, promulgated,
and provides support by the software development management team
and ideally by the CEO. An organization should have a documented and
repeatable SDL policy and guideline that supports the SDLC including
its business needs and as a complement to the engineering and develop-
ment culture that it supports. The culture and maturity of the organiza-
tion is very important to consider in the development of the SDL policy,
so that you ensure it will be both feasible and practical to implement. The
management style, complexity of people, process, and technology needs,
including the overall architecture of the product, will help determine
how granular or objective in focus the guidelines will be. The amount
of outsourced development, if any, will need to be assessed as part of this
process as well. An internal development team will require more detailed
procedures, while an outsourced function will require more contractual
objects, service levels, and detailed deliverables. The vulnerabilities and
risk of using outsourced development resources will be covered later in
the book.
4.3 Threat Modeling/Architecture
Security Analysis
4.3.1 Threat Modeling
As discussed previously, threat modeling requires a special set of skills,
experience, and mindset: The people on the team who do this must be
Architecture (A2): SDL Activities and Best Practices 85
able to think like an adversary. A senior software security architect or
one of the more seasoned software security champions typically runs this
aspect. The developers and team members who are pulled into this pro-
cess must know not only how to develop or build software, but also how
to deconstruct or take apart the software and its architecture while think-
ing like an adversary.
Microsoft first documented its threat modeling methodology in
1999, and its method has evolved into an industry standard since that
time.
1
This was not the first time anyone threat-modeled at Microsoft,
of course, but rather the first time the methodology was formalized or
considered as an abstracted engineering activity. The threat risk model-
ing process has five steps, enumerated below and shown graphically in
Figure4.2. They are
1. Identify security objectives.
2. Survey the application.
3. Decompose it.
4. Identify threats.
5. Identify vulnerabilities.
Following these five steps will help you understand what assets you need
to protect, from whom you need to protect them, how you can protect
them, what is the implementation priority, and what risk you will have
to live with if a few of the threats are not included in the implementa-
tion scope.
The focus of threat modeling should not be simply on the software
product itself, but include the context of the business and the user. The
implementation priorities can be limited to the software product itself
after the threat modeling, analysis, and architectural security risk analysis
are completed. Besides the cost savings achieved by building security in
early in the process, another advantage is to take into account the busi-
ness and user needs and requirements so you can balance out and make
security decisions that are cost-efficient and relevant to the competiveness
of the product in addition to facilitating expected and required security
and privacy controls.
The user context influences not only the scope of threats and vul-
nerabilities, it may also strongly affect priorities for implementation. For
example, if you are storing customers’ credit card data in your hosting
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.