Design and Development (A4): SDL Activities and Best Practices 171
o
General issues that affect confidentially, integrity, and availability
o
Issues related to your application’s security quality-of-service
requirements
o
Issues related to your application’s compliance requirements
o
Issues related to the technologies your application uses
o
Issues related to the functionality your application exposes
o
Issues you found during threat modeling
• Out-of-scope items: Identify what you will not be looking for. Explain
why these things are out of scope.
3
2. Perform Preliminary Scan
Static analysis is used to find an initial set of security issues and to improve
your understanding of where you will be most likely to find security issues
when you review the code more fully and to discover hot spots where
additional security issues are likely to be discovered in later steps. This is
typically done with automatic scans, manual scans, or a combination of
both, depending on the review objectives and time limitations of the code
review plan. Automated scans have an advantage in their ability to quickly
identify “low-hanging fruit” across large sets of applications. The results
from these scans are used in creating a prioritized list of potential security
vulnerabilities and security mechanisms to review and investigate.
An automatic scan can be used to supplement a manual review, as an
extra check to go through large volumes of code that would be cost- and/
or time-prohibitive to do manually, to target areas to focus on for manual
reviews, and to find security issues that may have been missed during
manual review. Automatic scanning tools are typically good at finding
security issues that are a result of single lines of code, finding security
issues that span multiple lines of code in a single function, and may find
problems that manual reviews will miss. Although automatic scanning can
supplement a manual review, it should not be used to replace it because of
the contextual problems and inability to find security issues over multiple
functions such as those found in SaaS/cloud applications. Another issue
with automated tools is the number of false positives and negatives that
are found, which may require significant efforts to tune down to a rea-
sonable number. On the positive side, these types of results will force you
to gain a better understanding of the code, including controls and data
flow, by forcing you to review why a false positive is false. Another risk of
172 Core Software Security
using automated tools is the possible sense of security in believing there
are no security issues in your software if no security issues are identified
as a result of the scan. A significantly sized and complex software product
should never be assumed to be free of security vulnerabilities. All possible
steps should be taken to limit the number of coding errors and reduce
their practical impact, but something is always missed. Automated secu-
rity tools are able to identify more and more coding errors, but some vul-
nerabilities will still be missed and either not detected or hidden among
large numbers of false positives. Manual source code analysis is not a
replacement for these tools, but it helps maximize the identification of
vulnerabilities when integrated with them. As mentioned throughout this
book, it requires a holistic approach to security, including a human ele-
ment, to ensure that both false positives are false and that the code is really
free of security vulnerabilities in spite of being given what appears to be a
clean bill of health by the automated tools. Using both methods together
enables reviewers to identify more software security vulnerabilities both
efficiently and cost-effectively. For these reasons, automated review com-
bined with a manual review is the best approach.
To catch the simpler issues, available security tools should be run
against the code before manual review begins. To avoid finding already-
known issues, all previously identified security vulnerabilities should be
fixed. A manual scan is then conducted to gain a better understanding
of the code and to recognize patterns; the results of the scan will iden-
tify areas that merit further analysis as the reviewers analyze the code for
security issues in Step 3 below. This effort, however, should be a small
percentage of the total code review time and should focus on answering
the following questions:
• Input data validation: Does the application have an input validation
architecture? Is validation performed on the client, on the server, or
both? Is there a centralized validation mechanism, or are validation
routines spread throughout the code base?
• Code that authenticates and authorizes users: Does the application
authenticate users? What roles are allowed, and how do they inter-
act? Is there custom authentication or authorization code?
• Error-handling code: Is there a consistent error-handling architecture?
Does the application catch and throw structured exceptions? Are
there areas of the code with especially dense or sparse error handling?
Design and Development (A4): SDL Activities and Best Practices 173
• Complex code: Are there areas of the code that appear especially
complex?
• Cryptography: Does the application use cryptography?
• Interop: Does the application use interop to call into native code?
4
3. Review Code for Security Issues
The results from Step 2 are typically used to focus the analysis of the
reviewer during Step 3.
4. Review for Security Issues Unique to the Architecture
This is where the software security architect or seasoned software security
champion come into play. In some cases, a third party may be used if
you don’t have the expertise in-house. This allows experts to apply their
knowledge of the business logic, use and abuse cases, and prior experience
to identify vulnerabilities while reducing the likelihood of false positives
and false negatives. Static analysis tools are incapable of finding applica-
tion flaws and business logic vulnerabilities and require the context and
application understanding of a human analyst to identify. Having sea-
soned security professionals involved throughout the SDLC process will
balance the developers’ tendency to overlook certain coding errors even
though they wrote the specific fragments of code and usually understand
them best. Seasoned security experts can also help in understanding the
technological context of the code, including not only the specific tech-
nologies that are used in the software product, but also operating-system
and third-party dependencies as well as tools used in development. From
a security perspective, these security experts can identify relationships
between a product and other systems, applications, or services. In the
context of security, it is possible for them to determine what compo-
nents a product relies on, as well as what other software depends on the
pro duct, and how these relationships can be used to determine how a
pro duct affects the rest of the system and how it may be affected by it.
Human errors are typically the cause of most security problems; given the
current shortcomings of automated tools, humans should also be part
of the solution. For example, a small coding error can result in a critical
vulnerability that ends up compromising the security of an entire system
or network or may result from a sequence of errors that occur during the
174 Core Software Security
course of the development cycle where a coding error is introduced and
goes undetected during the testing phases, and available defense mecha-
nisms do not stop a successful attack. This is just another example of why
the human element is necessary in the process, to be able to assess these
types of situations which are currently beyond the capabilities of auto-
mated software security tools.
The basic design of a product may also contain flaws, and it should
be noted that some coding errors, although they may affect product reli-
ability, are not actual vulnerabilities. Remember that the ultimate goal of
security code reviews is to find code vulnerabilities that are accessible by
an attacker and that may allow the attacker to bypass a security boundary.
6.4 Security Analysis Tools
The final goal of the security code review process is to improve the overall
security of the product and to provide output that can be used by the
development team to make changes and/or mitigations that will achieve
improved software product security compared to what existed at concept
commit for the start of the SDLC/SDL process. In this section we discuss
the details of what functions and roles static analysis, dynamic analysis,
fuzz testing, and manual code review have in this overall process. Before
we begin, however, it is important to recognize that each approach has
certain practical advantages and limitations.
Advantages of Static Code Analysis
1. Access to the actual instructions the software will be executing
• No need to guess or interpret behavior
• Full access to all of the software’s possible behaviors
2. Can find exact location of weaknesses in the code
3. Can be conducted by trained software assurance developers who
fully understand the code
4. Allows quick turnaround for fixes
5. Relatively fast if automated tools are used
6. Automated tools can scan the entire code base.
7. Automated tools can provide mitigation recommendations, reducing
research time.
Design and Development (A4): SDL Activities and Best Practices 175
8. Permits weaknesses to be found earlier in the development lifecycle,
reducing the cost to fix
5,6
Limitations of Static Code Analysis
1. Requires access to source code or at least binary code and typically
needs access to enough software artifacts to execute a build
2. Typically requires proficiency in running software builds
3. Will not find issues related to operational deployment environments
4. Time-consuming if conducted manually
5. Automated tools do not support all programming languages.
6. Automated tools produce false positives and false negatives.
7. There are not enough trained personnel to thoroughly conduct
static code analysis.
8. Automated tools can provide a false sense of security that everything
is being addressed.
9. Automated tools are only as good as the rules they are using to scan
with.
10. Does not find vulnerabilities introduced in the runtime environment
7,8
Advantages of Dynamic Code Analysis
1. Limited scope of what can be found
• Application must be footprinted to find the test area.
• That can cause areas to be missed.
• You can only test what you have found.
2. No access to actual instructions being executed
• The tool is exercising the application.
• Pattern matching on requests and responses.
3. Requires only a running system to perform a test
4. No requirement to have access to source code or binary code
5. No need to understand how to write software or execute builds
• Tools tend to be more “fire and forget.”
6. Tests a specific operational deployment
• Can find infrastructure, configuration, and patch errors that static
analysis tools will miss.
7. Identifies vulnerabilities in a runtime environment
8. Automated tools provide flexibility on what to scan for.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.