This document discusses proactive and reactive approaches to software security strategy. A proactive strategy involves pre-emptive actions like vulnerability assessments, risk analysis, implementing security controls, and developing continuity plans. A reactive strategy involves responsive actions after an attack like conducting damage assessments, implementing continuity plans, determining the attack source, and repairing damages. Both proactive and reactive strategies work together using a combination of activities to develop comprehensive security policies and mitigate risks throughout the software development lifecycle.

1. PRO VS. REACTIVE 1
Running Head: PRO VS. REACTIVE
Proactive vs. Reactive Approaches to Software Security Strategy
Lindsey Landolfi
Towson University
Software Security
Professor Charles Pak
February 2012

2. PRO VS. REACTIVE 2
A few fundamental characteristics of computer systems are vital to consider during
software development and deployment. First, there is no such thing as an un-breakable computer
system and second, no unauthorized intrusion should be considered benign. Security holes in
software are common; attackers exploit these software defects in order to infiltrate a system. The
nature of software provides attackers with an advantage, software security must identify and
mitigate all the risks while an attacker needs only to identify and exploit a single fault in order to
cause damage. Developing a software security strategy and implementing associated policies and
controls is necessary to mitigate the risk of attacks. The objective of a successful security
strategy is to decrease costs and increase software reliability. A direct negative correlation is
exhibited between security controls and security risk, therefore investments in security standards
can be justified by the associated risk reduction. This paper will discuss the two major
approaches to building secure software, proactive and reactive strategies.
A general methodology for defining a security strategy is outlined in the following
paragraphs. See Appendix A for a flow chart representing the methodology discussed for
defining security strategy. It is inevitable that every software system at some point will be
successfully attacked; it is fundamental to the design of a security strategy to know which kind of
threats/attacks are priorities. Hence it is necessary to first conduct a threat/attack assessment to
identify and determine credible threats. Different assets and artifacts have different risks
associated with them; this document will focus only on issues that may affect software. Broad
vulnerability categories for computer systems range from malicious attackers, non-malicious
threats, and natural disasters. Threat categories specific to software security include local
implementation errors, interprocedural interface errors, and design-level mistakes. Design flaws
such as inconsistent error handling, language-based flaws, method overriding problems, or poor

3. PRO VS. REACTIVE 3
compartmentalization account for about half of software security issues. The other fifty percent
is attributed to implementation risks such as buffer overflows, simple bugs, format string bugs,
resource leaks, and simple race conditions, or incorrect input validation.
A single attack may be executed with a variety of different techniques, therefore in
addition to determining the possible threats plausible attack methodologies should also be
identified. A security strategy must be customized to address the different techniques of attacks.
Example attack methods include brute-force attacks specifically on authentication functions,
attacking broken access-controls (ie. taking advantage of insecure IDs, executing path traversal
attacks), session based attacks (ie. cookie poisoning), and exploiting inadequate data validation
(ie. SQL or HTML injection, Cross-Site Scripting flaws). Additional techniques include the
exploitation of conditions such as poor exception handling, race condition hazards, insecure
logging practices, weak cryptography/encryption algorithms, and buffer-overflow exploitation.
Efficient security and compliance is supported by a combination of proactive and reactive
activities and the correlating data. A proactive strategy may also be addressed as a pre-attack
strategy due to its offensive nature. A proactive strategy is comprised pre-emptive actions
designed to mitigate risk and associated damages. The major benefit of a proactive strategy is it
provides the opportunity to assess vulnerability and implement mitigation tactics prior to
deployment and distribution of software. A proactive approach is particularly beneficial to
operations that focus primarily on handling confidential information such as banks or
government contractors. A proactive strategy consists of four major components including
vulnerability assessment, risk analysis, mitigation investments, and a continuity of operations
plan (COOP); numerous proactive activities are aspects of or directly related to these four
components.

4. PRO VS. REACTIVE 4
Vulnerability assessments determine potential impact of a successfully executed attack,
in other words it identifies the possible negative operational effects associated with a successful
attack. A model based vulnerability analysis (MBVA) best supports a comprehensive and
cohesive vulnerabilities analysis; it is beneficial to incorporate a collaborative yet standardized
assessment model into the budget allocation of a risk management strategy in order to promote
budget implementation designed to best achieve the intended risk mitigation results. Tactics
employed in a MBVA include fault tree analysis and event tree analysis which produce
meaningful data for evaluative purposes. A fault tree identifies the root cause and displays the
cause-effect/consequence relationship organized as a hierarchy connected by logic gates
(OR/AND – propagation connections). Where as an event tree analysis begins with an identified
primary threat and details the sequence of possible events leading up to the major fault. Every
possible combination of events is enumerated and probability assessed. The annualized rate of
occurrence (ARO) of attacks applicable to the software under-development should help to
determine which primary threats should be included in an event tree. There are a few weaknesses
in these MBVA tactics, they are primarily focused on known threats, yet-unknown
vulnerabilities are excluded from assessment and therefore the associated risks remain
unmitigated/unpatched. Additionally, the volume of the information (identified vulnerabilities)
may prove to be a hindrance; if the expanse of data becomes too complex (to many possibilities)
it may render the analysis more difficult to interpret and to properly integrate into the risk
management strategy specifically budget allocation.
Vulnerability is not the same as risk; vulnerability, the probability of threat and potential
impact, is an aspect of the risk equation. Risk measures potential ramifications associated to

5. PRO VS. REACTIVE 5
threats. Whereas a risk analysis attempts to assess and limit the potential for monetary,
reputational, or legal losses a vulnerability analysis attempts to identify rank vulnerabilities in
order to develop and implement appropriate risk mitigation strategies. The risk equation is a
fundamental concept in security software, it is simply expressed as Risk = Threat x Vulnerability
x Cost. Vulnerability and risk assessments are a valuable tool to use in resource allocation.
Being aware of vulnerabilities, their significance and potential, allows for efficient allocation of
resources when investing for risk mitigation. Vulnerability assessment can enhance an allocation
strategy for example, choosing between an equal distribution of funding designed to protect
against all threats or in a distribution in accordance with the severity and/or frequency of the
event.
After vulnerability and risk analyses are conducted resource allocations should be
implemented towards risk mitigation efforts. Complementary combination of security policy and
controls should be individualized to address the security needs and risks associated with an
organization and/or its software. Examples of proactive security mechanisms include anti-virus
protection, spyware scanners, and honey-pots. The best strategy to proactive security is building
security into the program design. The Building Security in Maturity Model (BSIMM) is a
descriptive model featuring a collaboration of observed software security activities and data from
numerous industry leaders. 109 security activities are organized into 12 practices according to
the Software Security Framework (SSF); the 12 practices are organized into 4 domains. BSIMM
is a functional guide to software security initiatives. Additionally, BSIMM has analysis
capabilities; BSIMM can be used to help determine where an organization stands in the software
security initiative in comparison to what ‘everyone’ else is doing. See Appendix B for an
explanation of the SSF practices and domains.

6. PRO VS. REACTIVE 6
Developing a continuity of operations plan (COOP) is a necessary step in a proactive
software security approach. COOP is an alternative operations plan designed to provide a
flexible guidelines to assist in crisis preparation and response. The primary crisis scenario in
software security is when security controls are successfully breached and an attack is executed
resulting in damage to the system and/or disturbance to normal functionality. Including within
the COOP should be individualized plans specific for each type of threat/attack. COOP
highlights the interconnection between proactive and reactive tactics. Where the development of
a COOP is a proactive activity and its implementation is considered reactive.
A post-attack strategy, referred to as a reactive strategy, complements a proactive
approach. Reactive strategy is comprised of responsive actions that help to identify, assess, and
repair attack related damages. Addressed in the following paragraphs are four major components
necessary to a support an efficient reactive approach specifically conducting damage
assessments, implementing a COOP, determining a source of attack, and to repair and document
any resulting damages. A reactive approach may be considered to be cost beneficial as it does
not negatively affect budget unless an incident occurs. Necessary incident response resources, as
outlined in a disaster recovery plan, should already be incorporated into the security budget.
Conducting a damage assessment it is important to assess the extent of damage cause by
a successful attack. Once damages are identified restoration operations can begin, therefore it is
important to assess damages as quickly and accurately as possible. If normal system functionality
is compromised then the COOP should be implemented immediately in order to maintain
operations. COOP will foster timely and successful emergency resolutions for a variety of attack
situations, detailed within the COOP are alternative system procedures, procedures for security

7. PRO VS. REACTIVE 7
patch updates, information on data recovery, and more depending on the organizations
operations and requirements. COOP goal is to maintain or restore organization/product
functionality.
Once the damages are assessed it is necessary to determine the source of attack in order
to gain a better understanding of what system vulnerabilities were exploited to perpetrate the
attack. Review audit and log trails to support investigations and identify possible fraudulent
activities. Security policy should include requirements for management logging activities; it
should be noted that logging analysis is a reactive tactic while logging maintenance is a proactive
activity. For example as part of a reactive strategy, software security may be enhanced with
intrusion detection and prevention systems (IDPS) the IDPS can be passive (solely for detection
purposes) or reactive featuring auto-response to suspicious activity.
Much of the costs associated with a system failure are correlated with the loss of service,
productivity, or data during and/or after a breach. A reactive strategy supports quicker repairs.
Having a workable disaster recovery plan in place will accelerate the restoration and recovery
processes. It should be noted that proper documentation is necessary during all stages of the
SDLC and while executing proactive and reactive security tactics such as risk or damage
assessments. In a reactive strategy documentation could support investigative activities such as
the reconstruction and evaluation of an attack. Good documentation practices such as
consistency, reliability, comprehensibility, and accessibility are essential to establish data
integrity.
A security policy establishes the recommendations an organization uses to manage and
protect software and its functionality. A good security policy will address the entire program,
system-specific aspects, and issue-specific levels of operations. A security policy should be

8. PRO VS. REACTIVE 8
regularly reviewed for its effectiveness in mitigating risks. Evaluations should consider the
nature, quantity, and impact of all security related incidents as well as operational requirements,
security strategy and tactics, and control measures. Security policy analysis can be conducted
qualitatively or quantitatively. Post-evaluation the security policy should be adjusted
accordingly; policy revisions and enhancements should be coordinated with the policy
weaknesses identified during evaluation.
Proactive and reactive strategies work together to develop security policies and controls
designed to best mitigate risk. This can be seen in how software security assurance is presented
through Touchpoints. The Touchpoints use a holistic approach, a careful balance of
constructive/offensive and destructive/defensive activities, to achieve comprehensive risk-based
security testing and address system-wide security issues. Adherence to guidelines such as those
outlined in the software security Touchpoints are necessary to build more secure software.
The paragraphs below outline the seven Touchpoints ordered according to effectiveness and
importance, with specific focus of either the proactive or reactive nature of the Touchpoint.
Code review is a proactive activity (also known as a white hat tactic) designed to avoid
implementation issues. Though code review is constructive in nature it is informed by reactive or
black hat history. Architectural risk analysis is of a similar tactical nature as code review but
instead it objectives are to prevent design flaws. The combination of these two activities is vital
to build security into software as all threats to software can basically be categorized as either an
implementation bug or design flaw. The remaining five tactics can be arranged in the order that
is best suited to an organization’s security needs.
Penetration testing is an active analysis conducted during a simulated attack designed to
assess for proper implementation and configuration while exploiting known vulnerabilities;

9. PRO VS. REACTIVE 9
testing should be conducted throughout the SDLC. Penetration testing is of a reactive nature, it
is a black hat activity. Efficient testing is supported by white hat information regarding software
design and associated risks. The next Touchpoint employs a holistic approach, a combination of
both white and black hat activities. Risk-based security tests are a security testing strategy based
on known attack patterns specifically the system’s architecture (functional security testing) and
an attacker’s mindset (adversarial security testing). The destructive aspect is the creation of
security related artifacts such as model attack patterns; however, white hat data such as
vulnerability and risk analyses are necessary to support efficient test development.
Abuse cases should be conducted throughout the SDLC. An abuse case assesses what
should be protected from whom and for how long based on the systems assumed behavior during
an attack. They provide insight to how an attack can abuse the system (attack models).
Knowledge of security requirements is necessary for the development of an abuse case, security
requirements are developed using white hat information. A black hat approach is also necessary
in order to derive model attack patterns. Abuse cases are a predominantly reactive activity.
Security requirements and the resulting security functionality present the concept of a proactive
strategy. They are designed specifically to defend against destructive (black hat) activities.
Security requirements should capture both overt functional security (engineering/cryptography)
and emergent characteristics (evident in attack models/patterns). Finally, it is necessary to
integrate software security operations with network security. Security operations are considered a
weakly a proactive activity because it is essential to security however many of the tactics
executed are reactive.
Security should not be an afterthought; software security should be designed to be
proactive and reactive against attacks. It is beneficial to have a method in place, such as the one

10. PRO VS. REACTIVE 10
discussed in this paper, in order to acknowledge and mitigate security risks throughout the
SDLC. Since the cost of fixing defects increases as the software progresses forward in the SDLC
the best way to build security into the software is when security is considered from the beginning
of the SDLC. It is important o remember that software security is not a onetime activity but an
integral part of the SDLC.
There is no single overarching security policy that can be applied which would
effectively protect the entire IT industry. A security strategy should be individualized to each
organization and in some situations the overarching strategy should be further curtailed for
individual programs/products. In order to properly tailor a security strategy an organization must
first establish the level of their security needs and then determined which combination of
proactive and reactive strategies is associated with the lowest rates of security failure for the
organization. Knowledge of the plausible software vulnerabilities and associated risks can help
to determine the ideal blend of proactive or reactive approaches. While this paper has worked to
establish a clear definition between these two approaches, it should be noted that proactive and
reactive strategies are not mutually exclusive interactions and overlays occurs between these two
major strategies. The general goal of a software security system has both proactive and reactive
elements, to have a fault tolerant design and maximum system availability in case an attack is
perpetrated.

11. PRO VS. REACTIVE 11
Appendix A:
Security Strategy
Threat/attack assessment
Per - attack/threat develop:
Proactive Strategy
Vulnerability assessment
Risk analysis
Mitigation investments (policies/controls)
Continuity of operations plan (COOP)
Reactive Strategy
Damage assessment
Implement COOP
Determine source of attack
Repair and document damages
Review outcome & policy effectiveness
Adjust policy accordingly
Appendix B:
Average maturity level from all 42 BSIMM firms
Software Security Framework (SSF):
INTELLIGENCE:
1. ATTACK MODELS: Threat modeling, abuse cases, data classification, technology-
specific attack patterns.
2. SECURITY FEATURES AND DESIGN: Security patterns for major security controls,
middleware frameworks for controls, proactive security guidance.

12. PRO VS. REACTIVE 12
3. STANDARDS AND REQUIREMENTS: Explicit security requirements, recommended
COTS, standards for major security controls, standards for technologies in use, standards
review board.
SSDL TOUCHPOINTS:
1. ARCHITECTURE ANALYSIS: Capturing software architecture diagrams, applying lists
of risks and threats, adopting a process for review, building an assessment and
remediation plan.
2. CODE REVIEW: Use of code review tools, development of customized rules, profiles
for tool use by different roles, manual analysis, ranking/measuring results.
3. SECURITY TESTING: Use of black box security tools in QA, risk driven white box
testing, application of the attack model, code coverage analysis.
DEPLOYMENT:
1. PENETRATION TESTING: Vulnerabilities in final configuration, feeds to defect
management and mitigation.
2. SOFTWARE ENVIRONMENT: OS and platform patching, Web application firewalls,
installation and configuration documentation, application monitoring, change
management, code signing.
3. CONFIGURATION MNGT & VULNERABILITY MNGT: Patching and updating
applications, version control, defect tracking and remediation, incident handling.
GOVERNANCE:
1. STRATEGY AND METRICS: Planning, assigning roles and responsibilities, identifying
software security goals, determining budgets, identifying metrics and gates.
2. COMPLIANCE AND POLICY: Identifying controls for compliance regimens,
developing contractual controls (COTS SLA),setting organizational policy, auditing
against policy.
3. TRAINING
The software security framework (SSF). (n.d.). BSIMM3. Retrieved February 25, 2012, from
Cigital website: http://bsimm.com/online/