148 Core Software Security
been evaluated and tested by a large number of experts provides
a more secure authentication method than one that has not been
widely assessed.
8. Least common mechanism. This principle states that a minimum
number of protective mechanisms should be common to multiple
users, as shared access paths can be sources of unauthorized informa-
tion exchange. Shared access paths that provide unintentional data
transfers are known as covert channels. The least common mechanism
promotes the least possible sharing of common security mechanisms.
9. Psychological acceptability. This refers to the ease of use and intui-
tiveness of the user interface that controls and interacts with the
access control mechanisms. The user must be able to understand
the user interface and use it without having to interpret complex
instructions.
10. Weakest link. As in the old saying, “A chain is only as strong as its
weakest link,” the security of an information system is only as good
as its weakest component. It is important to identify the weakest
mechanisms in the security chain and layers of defense and improve
them so that risks to the system are mitigated to an acceptable level.
11. Leveraging existing components. In many instances, the security
mechanisms of an information system are not configured properly or
used to their maximum capability. Reviewing the state and settings
of the extant security mechanisms and ensuring that they are operat-
ing at their optimum design points will greatly improve the security
posture of an information system. Another approach that can be used
to increase system security by leveraging existing components is to
partition a system into defended subunits. Then, if a security mecha-
nism is penetrated for one subunit, it will not affect the other sub-
units and damage to the computing resources will be minimized.
15,16
Designing good software isn’t easy, and building security in makes it
even more difficult. Although some software flaws may not matter from
a user perspective, from a security perspective they may matter because
an attacker may be able induce failures by setting up the highly specific
conditions necessary to trigger a flaw. Something that may have had a
low probability of happening randomly and dismissed as irrelevant may
be significant if an attacker can take advantage of it. In the summary of
Saltzer and Schroeder’s design principles, the principles are stated clearly
but they lack the success criteria for security. We fortunately do have a
Design and Development (A3): SDL Activities and Best Practices 149
general idea of what security looks like and can avoid failure in this area
by incorporating the long-accepted properties of confidentiality, integrity,
and availability into the design principles. There are of course different
views of security, from that of a software developer, who may think of
security primarily in terms of quality; to that of a network administra-
tor, who may think of security in terms of firewalls, IDS/IPS systems,
incident response, and system management; or even those of managers
and academics, who may think of security mostly in terms of the classic
design principles described above or in terms of various security models.
All these viewpoints are important in building secure systems and relevant
to modeling the overall threat to your software. You must stay focused on
the ultimate prize when designing security in: the potential exploitation
of the software you are developing.
Detailed design artifacts are used to build each software component
needed to satisfy the use case requirements required to effectively design
your software for security. A thorough analysis of each software artifact
for possible vulnerabilities is conducted for every feature, property, and
service that exists in every component. As a result of analyzing each soft-
ware component for the use cases and in misuse case scenarios identified
through the processes described in Chapter 4, developers will be able to
design appropriate countermeasures up front and transparently, so that
the entire team is able to see how software security is being handled in the
application. As a result, the use case concepts can be converted to actual
software requirement specifications. As the developers review the specific
application software they are developing, they should also assess any vul-
nerabilities found in the associated ecosystem it will support, including
its network, architecture, and supporting software. It is also important
for the development security team to stay current with the latest vulner-
abilities that may affect your specific software and associated ecosystem,
both pre- and post-release, to prepare for new potential planes of attack
previously unknown or discovered, both internally and externally. It will
be much easier and less expensive to fix or develop a countermeasure to
an identified risk as the software is being designed and developed than
after it is released. Although the secure design of the code is critical and
of upmost importance, mistakes will be made, new attack methodologies
will be discovered and will continue to drive the need to research and
assess new methods of attack and vulnerabilities long after the product has
shipped and likely until it reaches end of life. This of course is why it is so
important to minimize the attack surface through the methods described
150 Core Software Security
in Chapter 4, combined with good design principles to maximize the
limitation of severity of any security flaws that may be missed in the code.
The design as organized framework will be a strategy breaking down the
problem into smaller parts that are more easily solved. Threat modeling
will be key to your success and process in this endeavor, as it will typi-
cally identify a secure design issue that might have gone un noticed until
much later. The data flow diagram results will be used next, along with
the brainstorming of attacks and review of known checklists. Apply what-
ever combined methodology works best for you, conduct all the necessary
research, and apply it early in your design to minimize any component
failing late in the development process.
5.5 Privacy Implementation Assessment
The authors believe that the most concise, clear, and field-tested privacy
implementation assessment processes, procedures, and guidelines for soft-
ware development are available from Microsoft and are contained in three
primary documents:
1. Microsoft’s Privacy Guidelines for Developing Software Products and
Services, Version 3.1; September 2008
17
2. Microsoft MSDN’s SDL—Process Guidance—Appendix C: SDL
Privacy Questionnaire
18
3. Microsoft’s Simplified Implementation of the Microsoft SDL
19
The process and guidance by which you determine your Privacy
Impact Rating and estimate the work required to be compliant is
described in Microsoft’s Privacy Guidelines for Developing Software
Products and Services, Version 3.1; September, 2008,
20
and their SDL—
Process Guidance—Appendix C: SDL Privacy Questionnaire.
21
The ratings
(P1, P2, or P3) represent the degree of risk your software presents from
a privacy perspective. You need to complete only the steps that apply to
your rating, based on the following guidelines:
• P1: High Privacy Risk. The feature, product, or service stores or
transfers personally identifiable information (PII), changes settings
or file type associations, or installs software.
Design and Development (A3): SDL Activities and Best Practices 151
• P2: Moderate Privacy Risk. The sole behavior that affects pri-
vacy in the feature, product, or service is a one-time, user-initiated,
anony mous data transfer (for example, the user clicks on a link and
the software goes out to a website).
• P3: Low Privacy Risk. No behaviors exist within the feature, pro-
duct, or service that affect privacy. No anonymous or personal data is
transferred, no PII is stored on the machine, no settings are changed
on the user’s behalf, and no software is installed.
22
The questions are designed to help you complete the privacy aspects of
the SDL, and you can complete some sections, such as the initial assess-
ment and a detailed analysis, on your own. It is recommended that you
complete other sections, such as the privacy review, together with your
privacy advisor.
23
One of the best ways to protect a customer’s privacy is not to collect
his or her user data in the first place. The questions that should constantly
be asked by architects, developers, and administrators of data collection
systems include:
• “Do I need to collect this data?”
• “Do I have a valid business purpose?”
• “Will customers support my business purpose?”
24
The development organization must keep in mind that for customers
to have control over their personal information, they need to know what
personal information will be collected, with whom it will be shared, and
how it will be used. In addition:
• Customers must provide consent before any personal information is
transferred from their computer; and
• If customers’ personal information is transferred over the Internet
and stored remotely, they must be offered a mechanism for accessing
and updating the information.
25
The guidelines developed in the Microsoft Privacy Guidelines for
Developing Software Products and Services, Version 3.1,
26
are based on
the core concepts of the Organization for Economic Co-operation and
Development (OECD) Fair Information Practices
27
and privacy laws
152 Core Software Security
such as the EU Data Protection Directive,
28
the U.S. Children’s Online
Privacy Protection Act of 1998 (COPPA),
29
and the U.S. Computer Fraud
and Abuse Act
30
and its amendments. The Microsoft Privacy Guidelines
for Developing Software Products and Services
31
document is divided into
two main sections. Section 1 provides an introduction to key privacy
concepts and definitions. Section 2 enumerates detailed guidelines for
specific software product and website development scenarios. The table
of contents for the Privacy Guidelines for Developing Software Products and
Services is provided below to show the breadth and scope of the guidance
in the document.
Table of Contents
Introduction
1 Basic Concepts and Definitions
1.1 User Data
1.1.1 User Data Categories
1.2 Data Minimization and Data Management
1.2.1 Minimizing Data Collected
1.2.2 Limiting Access to “Need to Know”
1.2.3 Reducing the Sensitivity of Data Retained
1.2.4 Reducing Duration of Data Retention
1.3 Notice, Choice, and Consent
1.3.1 Types of Notice
1.3.2 Types of Consent
1.4 Notice Mechanisms
1.4.1 Just-in-Time Notice
1.4.2 First Run Notice
1.4.3 Installation Time Notice
1.4.4 “Out of the Box” Notice
1.5 Security
1.6 Access
1.7 Data Integrity
1.8 Types of Privacy Controls
1.8.1 User Controls
1.8.2 Administrator Privacy Controls
1.9 Shared Computers
1.10 Children’s Privacy
1.11 Software Installation
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.