Your SlideShare is downloading. ×
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Proactive vs. Reactive Approaches to Software Security Strategy
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Proactive vs. Reactive Approaches to Software Security Strategy

3,116

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,116
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
49
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. PRO VS. REACTIVE 1Running 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 duringsoftware development and deployment. First, there is no such thing as an un-breakable computersystem and second, no unauthorized intrusion should be considered benign. Security holes insoftware are common; attackers exploit these software defects in order to infiltrate a system. Thenature of software provides attackers with an advantage, software security must identify andmitigate all the risks while an attacker needs only to identify and exploit a single fault in order tocause damage. Developing a software security strategy and implementing associated policies andcontrols is necessary to mitigate the risk of attacks. The objective of a successful securitystrategy is to decrease costs and increase software reliability. A direct negative correlation isexhibited between security controls and security risk, therefore investments in security standardscan be justified by the associated risk reduction. This paper will discuss the two majorapproaches to building secure software, proactive and reactive strategies. A general methodology for defining a security strategy is outlined in the followingparagraphs. See Appendix A for a flow chart representing the methodology discussed fordefining security strategy. It is inevitable that every software system at some point will besuccessfully attacked; it is fundamental to the design of a security strategy to know which kind ofthreats/attacks are priorities. Hence it is necessary to first conduct a threat/attack assessment toidentify and determine credible threats. Different assets and artifacts have different risksassociated with them; this document will focus only on issues that may affect software. Broadvulnerability categories for computer systems range from malicious attackers, non-maliciousthreats, and natural disasters. Threat categories specific to software security include localimplementation errors, interprocedural interface errors, and design-level mistakes. Design flawssuch as inconsistent error handling, language-based flaws, method overriding problems, or poor
  • 3. PRO VS. REACTIVE 3compartmentalization account for about half of software security issues. The other fifty percentis 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 inaddition to determining the possible threats plausible attack methodologies should also beidentified. 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 traversalattacks), session based attacks (ie. cookie poisoning), and exploiting inadequate data validation(ie. SQL or HTML injection, Cross-Site Scripting flaws). Additional techniques include theexploitation of conditions such as poor exception handling, race condition hazards, insecurelogging practices, weak cryptography/encryption algorithms, and buffer-overflow exploitation. Efficient security and compliance is supported by a combination of proactive and reactiveactivities and the correlating data. A proactive strategy may also be addressed as a pre-attackstrategy due to its offensive nature. A proactive strategy is comprised pre-emptive actionsdesigned to mitigate risk and associated damages. The major benefit of a proactive strategy is itprovides the opportunity to assess vulnerability and implement mitigation tactics prior todeployment and distribution of software. A proactive approach is particularly beneficial tooperations that focus primarily on handling confidential information such as banks orgovernment contractors. A proactive strategy consists of four major components includingvulnerability assessment, risk analysis, mitigation investments, and a continuity of operationsplan (COOP); numerous proactive activities are aspects of or directly related to these fourcomponents.
  • 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 successfulattack. A model based vulnerability analysis (MBVA) best supports a comprehensive andcohesive vulnerabilities analysis; it is beneficial to incorporate a collaborative yet standardizedassessment model into the budget allocation of a risk management strategy in order to promotebudget implementation designed to best achieve the intended risk mitigation results. Tacticsemployed in a MBVA include fault tree analysis and event tree analysis which producemeaningful data for evaluative purposes. A fault tree identifies the root cause and displays thecause-effect/consequence relationship organized as a hierarchy connected by logic gates(OR/AND – propagation connections). Where as an event tree analysis begins with an identifiedprimary threat and details the sequence of possible events leading up to the major fault. Everypossible combination of events is enumerated and probability assessed. The annualized rate ofoccurrence (ARO) of attacks applicable to the software under-development should help todetermine which primary threats should be included in an event tree. There are a few weaknessesin these MBVA tactics, they are primarily focused on known threats, yet-unknownvulnerabilities are excluded from assessment and therefore the associated risks remainunmitigated/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 riskmanagement strategy specifically budget allocation. Vulnerability is not the same as risk; vulnerability, the probability of threat and potentialimpact, is an aspect of the risk equation. Risk measures potential ramifications associated to
  • 5. PRO VS. REACTIVE 5threats. 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 inorder to develop and implement appropriate risk mitigation strategies. The risk equation is afundamental concept in security software, it is simply expressed as Risk = Threat x Vulnerabilityx 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 ofresources when investing for risk mitigation. Vulnerability assessment can enhance an allocationstrategy for example, choosing between an equal distribution of funding designed to protectagainst all threats or in a distribution in accordance with the severity and/or frequency of theevent. After vulnerability and risk analyses are conducted resource allocations should beimplemented towards risk mitigation efforts. Complementary combination of security policy andcontrols should be individualized to address the security needs and risks associated with anorganization and/or its software. Examples of proactive security mechanisms include anti-virusprotection, spyware scanners, and honey-pots. The best strategy to proactive security is buildingsecurity into the program design. The Building Security in Maturity Model (BSIMM) is adescriptive model featuring a collaboration of observed software security activities and data fromnumerous industry leaders. 109 security activities are organized into 12 practices according tothe Software Security Framework (SSF); the 12 practices are organized into 4 domains. BSIMMis a functional guide to software security initiatives. Additionally, BSIMM has analysiscapabilities; BSIMM can be used to help determine where an organization stands in the softwaresecurity initiative in comparison to what ‘everyone’ else is doing. See Appendix B for anexplanation of the SSF practices and domains.
  • 6. PRO VS. REACTIVE 6 Developing a continuity of operations plan (COOP) is a necessary step in a proactivesoftware security approach. COOP is an alternative operations plan designed to provide aflexible guidelines to assist in crisis preparation and response. The primary crisis scenario insoftware security is when security controls are successfully breached and an attack is executedresulting in damage to the system and/or disturbance to normal functionality. Including withinthe COOP should be individualized plans specific for each type of threat/attack. COOPhighlights the interconnection between proactive and reactive tactics. Where the development ofa COOP is a proactive activity and its implementation is considered reactive. A post-attack strategy, referred to as a reactive strategy, complements a proactiveapproach. Reactive strategy is comprised of responsive actions that help to identify, assess, andrepair attack related damages. Addressed in the following paragraphs are four major componentsnecessary to a support an efficient reactive approach specifically conducting damageassessments, implementing a COOP, determining a source of attack, and to repair and documentany resulting damages. A reactive approach may be considered to be cost beneficial as it doesnot negatively affect budget unless an incident occurs. Necessary incident response resources, asoutlined 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 bya successful attack. Once damages are identified restoration operations can begin, therefore it isimportant to assess damages as quickly and accurately as possible. If normal system functionalityis compromised then the COOP should be implemented immediately in order to maintainoperations. COOP will foster timely and successful emergency resolutions for a variety of attacksituations, detailed within the COOP are alternative system procedures, procedures for security
  • 7. PRO VS. REACTIVE 7patch updates, information on data recovery, and more depending on the organizationsoperations and requirements. COOP goal is to maintain or restore organization/productfunctionality. Once the damages are assessed it is necessary to determine the source of attack in orderto gain a better understanding of what system vulnerabilities were exploited to perpetrate theattack. Review audit and log trails to support investigations and identify possible fraudulentactivities. Security policy should include requirements for management logging activities; itshould be noted that logging analysis is a reactive tactic while logging maintenance is a proactiveactivity. For example as part of a reactive strategy, software security may be enhanced withintrusion detection and prevention systems (IDPS) the IDPS can be passive (solely for detectionpurposes) 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 recoveryprocesses. It should be noted that proper documentation is necessary during all stages of theSDLC and while executing proactive and reactive security tactics such as risk or damageassessments. In a reactive strategy documentation could support investigative activities such asthe reconstruction and evaluation of an attack. Good documentation practices such asconsistency, reliability, comprehensibility, and accessibility are essential to establish dataintegrity. A security policy establishes the recommendations an organization uses to manage andprotect 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 8regularly reviewed for its effectiveness in mitigating risks. Evaluations should consider thenature, 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 conductedqualitatively or quantitatively. Post-evaluation the security policy should be adjustedaccordingly; policy revisions and enhancements should be coordinated with the policyweaknesses identified during evaluation. Proactive and reactive strategies work together to develop security policies and controlsdesigned to best mitigate risk. This can be seen in how software security assurance is presentedthrough Touchpoints. The Touchpoints use a holistic approach, a careful balance ofconstructive/offensive and destructive/defensive activities, to achieve comprehensive risk-basedsecurity testing and address system-wide security issues. Adherence to guidelines such as thoseoutlined in the software security Touchpoints are necessary to build more secure software.The paragraphs below outline the seven Touchpoints ordered according to effectiveness andimportance, 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 avoidimplementation issues. Though code review is constructive in nature it is informed by reactive orblack hat history. Architectural risk analysis is of a similar tactical nature as code review butinstead it objectives are to prevent design flaws. The combination of these two activities is vitalto build security into software as all threats to software can basically be categorized as either animplementation bug or design flaw. The remaining five tactics can be arranged in the order thatis best suited to an organization’s security needs. Penetration testing is an active analysis conducted during a simulated attack designed toassess for proper implementation and configuration while exploiting known vulnerabilities;
  • 9. PRO VS. REACTIVE 9testing should be conducted throughout the SDLC. Penetration testing is of a reactive nature, itis a black hat activity. Efficient testing is supported by white hat information regarding softwaredesign and associated risks. The next Touchpoint employs a holistic approach, a combination ofboth white and black hat activities. Risk-based security tests are a security testing strategy basedon known attack patterns specifically the system’s architecture (functional security testing) andan attacker’s mindset (adversarial security testing). The destructive aspect is the creation ofsecurity related artifacts such as model attack patterns; however, white hat data such asvulnerability and risk analyses are necessary to support efficient test development. Abuse cases should be conducted throughout the SDLC. An abuse case assesses whatshould be protected from whom and for how long based on the systems assumed behavior duringan 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, securityrequirements are developed using white hat information. A black hat approach is also necessaryin 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 proactivestrategy. 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 tointegrate software security operations with network security. Security operations are considered aweakly a proactive activity because it is essential to security however many of the tacticsexecuted are reactive. Security should not be an afterthought; software security should be designed to beproactive and reactive against attacks. It is beneficial to have a method in place, such as the one
  • 10. PRO VS. REACTIVE 10discussed in this paper, in order to acknowledge and mitigate security risks throughout theSDLC. Since the cost of fixing defects increases as the software progresses forward in the SDLCthe best way to build security into the software is when security is considered from the beginningof the SDLC. It is important o remember that software security is not a onetime activity but anintegral part of the SDLC. There is no single overarching security policy that can be applied which wouldeffectively protect the entire IT industry. A security strategy should be individualized to eachorganization and in some situations the overarching strategy should be further curtailed forindividual programs/products. In order to properly tailor a security strategy an organization mustfirst establish the level of their security needs and then determined which combination ofproactive and reactive strategies is associated with the lowest rates of security failure for theorganization. Knowledge of the plausible software vulnerabilities and associated risks can helpto determine the ideal blend of proactive or reactive approaches. While this paper has worked toestablish a clear definition between these two approaches, it should be noted that proactive andreactive strategies are not mutually exclusive interactions and overlays occurs between these twomajor strategies. The general goal of a software security system has both proactive and reactiveelements, to have a fault tolerant design and maximum system availability in case an attack isperpetrated.
  • 11. PRO VS. REACTIVE 11Appendix 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 accordinglyAppendix B:Average maturity level from all 42 BSIMM firmsSoftware 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. TRAININGThe software security framework (SSF). (n.d.). BSIMM3. Retrieved February 25, 2012, from Cigital website: http://bsimm.com/online/

×