and may conflict if not well orchestrated. Because of
interactions, effective assurance requires that all levels
and roles consistently recognise and respond to risk.
assurance of an integrated product depends on
other people's assurance decisions and the level of
trust placed on these dependencies. The integrated
software inherits all of the assurance limitations of
each interacting component. In addition, unless specific
restrictions and controls are in place, every operational
component including infrastructure, security software
and other applications can be affected by the assurance
of every other component. There is a risk each time
an organisation must depend on others' assurance
decisions. organisations should decide how much
trust they place in dependencies based on a realistic
assessment of the threats, impacts and opportunities
represented by an interaction. dependencies
are not static, and trust relationships should be
regularly reviewed to identify changes that warrant
reconsideration. The following examples describe
assurance losses resulting from dependencies:
· defects in standardised pieces of infrastructure
firewalls, routers, etc.) can serve as widely available
threat entry points for applications.
assurance of the resulting software product.
vulnerabilities can be introduced into software
products by the tool builders.
technology capabilities are able to compromise
the confidentiality, integrity and availability of an
organisation's technology assets. There are no
perfect protections against attacks, and the attacker
profile is constantly changing. The attacker will use
technology, processes, standards and practices to craft
a compromise (known as a socio-technical response).
Attacks are crafted to take advantage of
the ways we normally use technology or
designed to contrive exceptional
situations where defences are circumvented.
all technology participants. Protection must be
applied broadly across the people, processes and
technology in an organisation because the attacker
will take advantage of all possible entry points.
authority and responsibility for assurance must
be clearly established at an appropriate level in
the organisation to ensure the
organisation effectively participates
in software assurance. This
assumes that all participants know
about assurance, and that is not
usually a reality. There is much to
be done to educate people on
software assurance.
governance, construction and operation of software
and systems and is highly sensitive to changes in each
of these areas. an adaptive response is required for
assurance because the applications, interconnections,
operational usage and threats are always changing.
assurance is not a once-and-done activity. it must
continue beyond the initial operational implementation
through operational sustainment. assurance cannot be
added later; it must be built to the level of acceptable
assurance that organisations need. no one has
resources to redesign systems every time the threats
change, and assurance cannot be readily adjusted
upward after the fact.
must be built in. That which is not measured cannot
be managed. Each stakeholder or technology user
will address only the assurance for which they
are held accountable. assurance will not compete
successfully with other competing needs unless
results are monitored and measured. all elements of
the socio-technical environment, including practices,
processes and procedures, must be tied together to
evaluate operational assurance. organisations with
more successful assurance measures react and recover
faster, learn from their reactive responses and that
of others and are more vigilant in anticipating and
detecting attacks. Defects per lines of code, a common
development measure, may be useful for code quality
but are not sufficient evidence for overall assurance
because they provide no perspective on how that
code behaves in an operational context. both focused
and systemic measures are needed to ensure the
components are engineered with sound security and
the interaction among components establishes effective
assurance.
increases the motivation to appropriately address the
necessary practices, standards and methods that must
be implemented to provide the desired assurance. The
principles help everyone involved in software assurance
understand its importance and value. Communicating
them across the software development community is
a critical next step.
by the department of defense under Contract no.
fa8721-05-C-0003 with Carnegie mellon University for the
operation of the software engineering institute, a federally
funded research and development center.
expressed in this material are those of the author(s) and
do not necessarily reflect the views of the United States
department of defense.
UniversiTY and sofTWare enGineerinG
insTiTUTe maTerial is fUrnished on an "as-is"
basis. CarneGie mellon UniversiTY makes no
WarranTies of anY kind, eiTher eXPressed
or imPlied, as To anY maTTer inClUdinG, bUT
noT limiTed To, WarranTY of fiTness for
PUrPose or merChanTabiliTY, eXClUsiviTY, or
resUlTs obTained from Use of The maTerial.
CarneGie mellon UniversiTY does noT make
anY WarranTY of anY kind WiTh resPeCT
To freedom from PaTenT, Trademark, or
CoPYriGhT infrinGemenT.
unlimited distribution.
Information in Computer Systems," Communications of the ACM,
vol. 17, issue 7, 1974.
http://en.wikipedia.org/wiki/Morris_worm. [Accessed June 2011].
http://en.wikipedia.org/wiki/System/370. [Accessed June 2011].
4009," National Information Assurance Glossary. Revised June
2009.