Unit5

Unit5 Knowledge for
Software Security
Dr Mohammad Zunnun Khan

• Software developers place a high premium on knowledge.
• Experience is king, and expertise is very valuable.
• The software field is in a everlasting state of change, and keeping on
top of all possible new technologies is very difficult, if not impossible.
• Developers show great respect for those who master aspects of the
expanding field and are able to help bring others along.
• This is the kind of phenomenon that drives topnotch developer
conferences like SD West and SD Best Practices (called SD East by
most people)

• Similarly, software security practitioners place a premium on knowledge and
experience.
• In a field where most practitioners are still being exposed to the basics (think
checklists and basic coding rules), the value of master craftsmen who have
"been there and done that," learned a number of lessons the hard way, and
are able to transfer that experience to others is very high.
• The bad news is that there aren't enough master craftsmen in software
security to apprentice and train all software developers, software architects,
and software security newbies effectively.
• The good news is that critical software security knowledge and expertise can
be compiled from those in the know and then shared widely.

• This possibility yields a potentially higher return than the pervasive
one-to-one method of apprenticeship practiced today.
• Through the aggregation of knowledge from a number of
experienced craftsmen, knowledge management can provide a new
software security practitioner access to the knowledge and expertise
of all the masters, not just one or two.

• Software security knowledge is multifaceted and can be applied in diverse
ways.
• As the software lifecycle unfolds, security knowledge can be directly and
dynamically applied through the use of knowledge-intensive best practices
like the touchpoints in this book.
• During professional training and resource development, security knowledge
can be drawn on for pedagogical application, sparking stories and anecdotes.
• During academic training, security knowledge can inform basic coding and
design curricula.
• All of these activities are beginning to happen in software security. For this
reason, a sophisticated knowledge management approach is necessary.

Security Knowledge: A Unified View
• Security knowledge can be organized according to the taxonomy introduced
in the box Software Security Unified Knowledge Architecture.
• Seven knowledge catalogs
• principles,
• guidelines,
• rules,
• vulnerabilities,
• exploits,
• attack patterns,
• and historical risks

• are grouped into three knowledge categories
• prescriptive knowledge,
• diagnostic knowledge,
• and historical knowledge

• Two of the seven catalogs are likely to be familiar to software developers with
only a passing familiarity with software security vulnerabilities and exploits.
• These catalogs have been in common use for quite some time and have even
resulted in collection and cataloging efforts serving the security community.
• Similarly, principles stemming from the seminal work of Saltzer and Schroeder
[1975]and rulesidentified and captured in static analysis tools, such as ITS4 are
fairly well understood.
• Knowledge catalogs only more recently identified include guidelines (often
built into prescriptive frameworks for technologies such as .NET and J2EE),
attack patterns , and historical risks.
• Together, these various knowledge catalogs provide a basic foundation for a
unified knowledge architecture supporting software security.

• The category prescriptive knowledge includes three knowledge
catalogs: principles, guidelines, and rules.
• These sets span a continuum of abstraction from high-level
architectural principles at the level of philosophy (e.g., the principle
of least privilege to very specific and tactical code-level rules (e.g.,
avoid the use of the library function gets() in C).
• Guidelines fall somewhere in the middle of this continuum (e.g.,
make all Java objects and classes final(), unless there's a good reason
not to.
• As a whole, the prescriptive knowledge category offers advice for
what to do and what to avoid when building secure software.

• The category diagnostic knowledge includes three knowledge catalogs: attack patterns,
exploits, and vulnerabilities.
• Rather than prescriptive statements of practice, diagnostic knowledge helps
practitioners (including operations people) recognize and deal with common problems
that lead to security attack.
• Vulnerability knowledge includes descriptions of software vulnerabilities experienced
and reported in real systems (often with a bias toward operations).
• Exploits describe how instances of vulnerabilities are leveraged into particular security
compromise for particular systems.
• Attack patterns describe common sets of exploits in a more abstract form that can be
applied across multiple systems.
• Such diagnostic knowledge is particularly useful in the hands of a security analyst,
though its value as a resource to be applied during development is considerable (e.g.,
consider the utility of attack patterns to abuse case development).

• The category historical knowledge includes the knowledge catalog
historical risks and, in some cases, vulnerabilities.
• Rather than derivations or abstractions, this catalog represents
detailed descriptions of specific issues uncovered in real-world
software development efforts and must include a statement of
impact on the business or mission proposition.
• As a resource, this knowledge offers tremendous value in helping to
identify similar issues in new software efforts without starting from
scratch.
• It also provides a continuing source for identifying new instances of
other knowledge catalogs described here: principles, guidelines,
rules, vulnerabilities, and attack patterns.

Security Knowledge and the Touchpoints
• Software security knowledge can be successfully applied at various stages throughout the entire
SDLC.
• One effective way to apply such knowledge is through the use of software security best practices
such as the touchpoints.
• For example, rules are extremely useful for static analysis and code inspection activities.
• Software security best practices and their associated knowledge catalogs can be applied
regardless of the base software process being followed.
• Software development processes as diverse as the waterfall model, RUP, XP, Agile, spiral
development, and CMMi (and any number of other processes) involve the creation of a common
set of software artifacts (the most common artifact being code).
• Figure shows an enhanced version of the touchpoints diagram that serves as the backbone. The
figure has identify those activities and artifacts most clearly impacted by the knowledge catalogs
described here.

• The box Two Example Catalog Entries:
• A Principle and a Rule and the preceding Table provide an overview of each
of the knowledge catalogs.
• Principles, given their philosophical level of abstraction,
• bring significant value to early-lifecycle activities including the
• definition of security requirements,
• performance of software architecture risk analysis,
• and design reviews.
• Rules, given their tactical, specific, syntactic nature, are primarily applicable
during implementation of code review and are particularly well suited for
inclusion in a static analysis tool.
• This opportunity for automation means that rules have an implicit
requirement for encapsulation in a deterministic definition language so that
they can be consumed by automated code scanning software.
• As you can see, this set of software security knowledge catalogs offers an
excellent foundation for integrating security knowledge into the full SDLC.

• The Department of Homeland Security Build Security In Portal
• The U.S. Department of Homeland Security is developing a software security
portal (along with the Carnegie Mellon Software Engineering Institute and
Cigital).
• This portal aims to provide a common, accessible, well-organized set of
information for practitioners wishing to practice software security.
• The portal effort is expressly aimed at the problem of encapsulating,
expanding, and spreading software security knowledge.

Knowledge Catalog: Principle Item: Principle of
Least Privilege
• Two Example Catalog Entries: A Principle and a Rule
• Description:
• Every program and every user of the system should operate using the least set of privileges necessary to complete
the job.
• Primarily, this principle limits the damage that can result from an accident or error.
• It also reduces the number of potential interactions among privileged programs to the minimum for correct
operation so that unintentional, unwanted, or improper uses of privilege are less likely to occur.
• Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is
minimized.
• Put another way, if a mechanism can provide "firewalls," the principle of least prationale rivilege provides a for
where to install the firewalls.
• The military security rule of "need-to-know" is an example of this principle.

• Concrete example:
• A good software specific example is a mail server which
• accepts mail from the Internet,
• and copies the messages into a spool directory;
• a local server will complete delivery.
• It needs rights to access the appropriate network port, to create files in the
spool directory, and to alter those files (so it can copy the message into the
file, rewrite the delivery address if needed, and add the appropriate
"Received" lines).
• It should surrender the right to access the file as soon as it has completed
writing the file into the spool directory, because it does not need to access
that file again.
• The server should not be able to access any user's files, or any files other than
its own configuration files.

• Knowledge Catalog: Rule
• Item: Use of creat()
• Context: C/C++
• Attack Category: TOCTOU-time of checktime of use

• Description:
• The creat(char *pathname,mode_t theMode) function either creates
a new file or prepares to rewrite using pathname as the filename.
• The call creat(theName,theMode) is equivalent to
• open(theName,O_WRONLY | O_CREAT | O_TRUNC, theMode)
• If the file exists, the length is truncated to zero and the mode and
owner are unchanged.
• This function is a problem because it is possible to unintentionally
delete a file or enter a potentially unstable race condition.
• creat() is vulnerable to TOCTOU attacks.
• Using automated scanning tools, the existence of a call to this
function should be flagged regardless of whether a "check" function
precedes it.

• Method of Attack:
• The creat() call is a "use" category call that when preceded by a "check" category call can indicate
a TOCTOU vulnerability.
• Solution:
• Consider using a safer set of steps for opening and creating files as outlined in Building Secure
Software [Viega and McGraw 2001, p. 220]. If this call must be used, create a directory only
accessible by the UID of the running program, and only manipulate files in that directory.
• Signature: Presence of the creat() function.
• Code Example:
• char filename[] = "rightFile.txt"; strcpy(filename,"wrongfile.txt"); creat(filename,theMode);
• In this case, the contents of the file passed into the creat() function are destroyed.If the results of
the function call are used before completion, then the results can also be unstable.

Knowledge Management Is Ongoing
• Efforts to identify and define knowledge constructs for software security are
in their infancy.
• Our hope is that a wider population of thought leaders and key practitioners
of software security will help to refine and validate this knowledge
architecture in an effort to build consensus and move toward standardization.
• Such discussion and collaboration are critical to the success of software
security as a unified practice.
• As work continues to gain consensus, my colleagues and I will continue to
collect real-world examples of content to build out the breadth and depth of
catalogs.
• We will also work to identify further opportunities for directly applying these
catalogs in the SDLC.

• Figure, dentifies aspects of software assurance currently covered in
the catalog.
• Material is divided into three major categories:
• best practices, tools, and foundational knowledge.
• This is an alternative way of organizing software security content with
reference to artifacts.

• The portal includes several types of information, categorized for efficient search and utility as follows.
• Best practices:
• A significant portion of the BSI effort is devoted to best practices that can provide the biggest return considering the current best
thinking, available technology, and industry practice.
• This list will grow as more resources become available, more practices are proven, changes occur in the industry environment, and
technology progresses. This book covers a number of critical best practices in some detail.
• Knowledge:
• Software defects with security ramificationsincluding implementation bugs such as buffer overflows and design flaws such as
inconsistent error handlingpromise to be with us for years.
• Recurring patterns of software defects leading to vulnerabilities have been identified by long-time software security practitioners,
and the BSI team is documenting detailed instructions on how to produce software without these defects.
• This work shows up in Figure as "Guidelines" and "Coding rules."
• The BSI team has also identified principles that provide high-level direction for avoiding security problems in
design, such as the principle of least privilege and the principle of compartmentalization.
• The BSI team is collaborating with the National Institute of Standards and Technology (NIST), the International
Organization for Standardization (ISO), and the Institute of Electrical and Electronics Engineers (IEEE) on standards
activities focused on developing safe and secure subsets of languages and software assurance style guides.

• Tools:
• The BSI portal includes information about which tools developers and security
analysts can use to detect and/or remove common vulnerabilities.
• Of particular interest are static analysis tools that help developers look for
common security-critical problems in source code.
• The best current commercial tools support languages like Java, CLR, C++, C,
and PHP.
• Business case:
• Even with extensive technical content, a business case is required to convince
industry to adopt secure software development best practices and educate
consumers about the need for software assurance.
• Therefore, each documented best practice addresses the business case for
use of that practice.
• In addition, we've included an overall business case framework.

• Dynamic navigation:
• The extent to which users will find the content accessible as well as useful
will determine how this portal will impact real-world development
practices and, thus, overall systems security.
• The BSI team is making the content approachable in several different ways.
• For example, a software engineer might use the catalog to determine
applicable security guidelines, an architect might use security principles to
determine how to design an n-tier application in a secure fashion, and a
development team leader might use the information to justify software
assurance techniques to management by building a business case. Because
the repository will be structured and designed to evolve as well as support
usage by a variety of user types, it includes a dynamic navigation interface.

• Once practical guidance and reference materials are available for the
day-to-day work most development organizations do, the BSI team
plans to identify and organize content for practical guidance and
reference materials for enterprise-level security concerns.
• Although the portal is currently in a nascent stage, the BSI team
welcomes feedback on this effort.
• Information on providing feedback can be found on the portal itself;
community involvement and use is crucial to its success.

Unit5

More Related Content

What's hot (20)

Similar to Unit5 (20)

More from Integral university, India (14)

Recently uploaded (20)

Unit5