Design and Development (A3): SDL Activities and Best Practices 143
implements protective measures, such as code obfuscation, to pre-
vent reverse engineering. In this case, traditional debugging is not
possible. It should be noted that if the focus of debugging effort is
on the software interaction with an external component, the binary
may be all that is needed.
• Vulnerability scanning (black box). Automated vulnerability scan-
ning of operating system and application-level software involves use
of commercial or open-source scanning tools that observe execut-
ing software systems for behaviors associated with attack patterns
that target specific known vulnerabilities. Like virus scanners,
vulnerability scanners rely on a repository of “signatures,” in this
case indicating recognizable vulnerabilities. Like automated code
review tools, although many vulnerability scanners attempt to pro-
vide some mechanism for aggregating vulnerabilities, they are still
unable to detect complex vulnerabilities or vulnerabilities exposed
only as a result of unpredictable (combinations of) attack patterns.
In addition to signature-based scanning, most vulnerability scan-
ners attempt to simulate the reconnaissance attack patterns used by
attackers to “probe” software for exposed, exploitable vulnerabilities.
• Penetration testing (black box). The portion of security testing in
which the evaluators attempt to circumvent the security features of
a system. The evaluators might be assumed to use all systems design
and implementation documentation, which can include listings of
system source code, manuals, and circuit diagrams. The evaluators
work under the same conditions as are applied to ordinary users.
9–12
The test plan organizes the security testing process and outlines which
components of the software system are to be tested and what test proce-
dure is to be used on each one. The outline is more than just a list of high-
level tasks to be completed; it should also include which artifacts are to
be tested, what methodologies are to be used, and a general description of
the tests themselves, including prerequisites, setup, execution, and what
to look for in the test results. The risk analysis described previously is
typically used to prioritize the tests, since it is usually not possible, given
time and budget constraints, to test every component of the software.
Security test planning is an ongoing process, and the details of the test
process are fleshed out as additional information becomes available.
The developing organization may modify software because problems
have been uncovered and then send the software back to be retested.
144 Core Software Security
Therefore it is often inefficient for begin testing only after development
is complete, so one component may be in testing while other compo-
nents of the same system are still being developed. For larger projects, the
test plan is typically broken down into test cycles. Given the examples
above, test cycles may be created because of the need to retest software
that was already tested once before; or test cycles may be created because
the nature of the development effort requires that different modules be
tested at different times.
Intercomponent dependencies, including those elements or software
components in a SaaS or cloud environment that may interact with the
software being developed, must be taken into account so that the poten-
tial need for retesting is minimized. A development organization typically
has a very regimented development process, so the security team needs
to be involved from the beginning of the SDLC process. The security
team needs to specify early the order in which components should be
tested, to ensure that each module is tested before other modules that
might depend on it are developed and tested. The concept of “building
security in” should be used not just to promote the security program; it
must be strictly adhered to if the SDL is to be successful. This means the
security team needs to be included in the general test plan discussions
to ensure that the elements of security are included in the validation of
the test environment and the test data, and how the test cases define the
test condition. The test condition is what is actually going to be tested to
see how the software is actually going to respond. Test cases are created
during the test execution process and include information about the test
pre-conditions and post-conditions, how it will be set up and terminated,
and how the results will be evaluated.
Automation will be key to making the process run smoothly and most
importantly, repeatable and should be used wherever possible. As men-
tioned, previously, this will not always be possible and the human element
will be absolutely necessary, particularly the skills of senior software secu-
rity architects. The test plan will be expected to provide as much guidance
as possible to let the tester definitely know what they are looking for in
each test and what the specific test preparations are
Michael and Radosevich, of Cigital, listed the following typical ele-
ments of a security test plan that can be used as a guideline for develop ing
your own plan in their 2005 white paper titled “Risk-Based and Functional
Security Testing”:
Design and Development (A3): SDL Activities and Best Practices 145
• Purpose
• Software Under Test Overview
o
Software and Components
o
Test Boundaries
o
Test Limitations
• Risk Analysis
o
Synopsis of Risk Analysis
• Test Strategy
o
Assumptions
o
Test Approach
o
Items Not to Be Tested
• Test Requirements
o
Functionality Test Requirements
o
Security Test Requirements
o
Installation/Configuration Test Requirements
o
Stress and Load Test Requirements
o
User Documentation
o
Personnel Requirements
o
Facility and Hardware Requirements
• Test Environment
• Test Case Specifications
o
Unique Test Identifier
o
Requirement Traceability (what requirement number from
requirement document does test case validate)
o
Input Specifications
o
Output Specifications/Expected Results
o
Environmental Needs
o
Special Procedural Requirements
o
Dependencies Among Test Cases
• Test Automation and Testware
o
Testware Architecture
o
Test Tools
o
Testware
• Test Execution
o
Test Entry Criteria
o
QA Acceptance Tests
o
Regression Testing
o
Test Procedures, Special Requirements, Procedure Steps
146 Core Software Security
o
Test Schedule
o
Test Exit Criteria
• Test Management Plan
• Definitions and Acronyms
13
5.3 Threat Model Updating
After working through the threat modeling process described in Chapter4,
it is important to know when you are done with the process. This will
involve answering a few questions such as the following, whose answers
will likely depend on competing business and security risk interests and
may require some trade-offs:
1. Have you accounted for all the policies, laws, or regulations rele-
vant to the software that you are developing, and accounted for and
gained approval for the level of effort for each of these requirements?
2. Have all your stakeholders reviewed the security assessment and
risks identified as a result of the threat modeling process? The appro-
priate architects, developers, testers, program managers, and others
who understand the software should have been asked to contri-
bute to threat models and to review them. Broad input and reviews
should have been solicited to ensure that the threat models are as
comprehensive as possible. It is also important that all stakeholders
agree on the threats and risks that have been identified. If this is not
the case, implementing appropriate counter-measures may prove to
be difficult.
3. Have you accounted for and have your stakeholders agreed to the
availability of time and resources required as both a result of the
threat modeling process and any resulting mitigation and testing?
4. Have you ranked your threats and risks according to consensus from
stakeholders? If you were a buy of this software, would you agree
with this ranking?
5.4 Design Security Analysis and Review
In a 1974 paper, Saltzer and Schroeder of the University of Virginia
addressed the protection of information stored in a computer system by
Design and Development (A3): SDL Activities and Best Practices 147
focusing on hardware and software issues that are necessary to support
information protection.
14
The paper presented the following 11 security
design principles:
1. Least privilege. The principle of least privilege maintains that an
individual, process, or other type of entity should be given the
minimum privileges and resources for the minimum period of time
required to complete a task. This approach eliminates the opportu-
nity for unauthorized access to sensitive information.
2. Separation of duties. This principle requires that completion of
a specified sensitive activity or access to sensitive objects is depen-
dent on the satisfaction of multiple conditions. Separation of duties
forces collusion among entities in order to compromise the system.
3. Defense in depth. This is the application of multiple layers of pro-
tection, such that a subsequent layer will provide protection if a pre-
vious layer is breached.
4. Fail safe. This means that if a system fails, it should fail to a state
where the security of the system and its data are not compromised.
In the situation where system recovery is not done automatically, the
failed system should permit access only by the system administrator
and not by users, until security controls are reestablished.
5. Economy of mechanism. This promotes simple and comprehen-
sible design and implementation of protection mechanisms, so that
unintended access paths do not exist or can be readily identified
and eliminated.
6. Complete mediation. This is where every request by a subject to
access an object in a computer system must undergo a valid and effec-
tive authorization procedure. This mediation must not be suspend
or become capable of being bypassed, even when the information
system is being initialized, undergoing shutdown, being restarted,
or is in maintenance mode. Complete mediation entails: (a) identi-
fication of the entity making the access request; (b) verification that
the request has not changed since its initiation; (c) application of
the appropriate authorization procedures; and (d) reexamination of
previously authorized requests by the same entity.
7. Open design. There has always been discussion of the merits and
strength of security of designs that are kept secret versus designs
that are open to scrutiny and evaluation by the community at large.
For most purposes, an open-access control system design that has
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.