Thesis of SNS


Published on

prepared using LATEX text editing software....

Published in: Technology
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Thesis of SNS

  3. 3. MAHARASHTRA ACADEMY OF ENGINEERING ALANDI (DEVACHI), PUNE DEPARTMENT OF INFORMATION TECHNOLOGY CERTIFICATEThis is to certify that the seminar entitled ”SURVIVABLE NETWORK SYSTEMS” hasbeen carried out by KARUNAKAR PRADEEP THAKUR under my guidance in partialfulfillment of Third Year of Engineering in Information Technology of Pune University,Pune during the academic year 2011-2012. To the best of my knowledge and belief thisseminar work has not been submitted elsewhere. Ms. Supriya Pawar Prof. S.M Bhagat Guide Head i
  4. 4. Acknowledgement I take this opportunity to thank my seminar guide Ms. Supriya Pawar and Headof the Department Prof. S.M BHAGAT for their valuable guidance and for providing allthe necessary facilities, which were indispensable in the completion of this seminar. I amalso thankful to all the staff members of the Department of Information Technology ofMaharashtra Academy Of Engineering Alandi(D) Pune for their valuable time, support,comments,suggestions and persuasion. I would also like to thank the institute for providing the required facilities, In-ternet access and important books. Karunakar Thakur ii
  5. 5. AbstractSociety is growing increasingly dependent upon large-scale, highly distributed systemsthat operate in unbounded network environments. Unbounded networks, such as theInternet, have no central administrative control and no unified security policy. Further-more, the number and nature of the nodes connected to such networks cannot be fullyknown. Despite the best efforts of security practitioners, no amount of system hardeningcan assure that a system that is connected to an unbounded network will be invulnerableto attack. The discipline of survivability can help ensure that such systems can deliveressential services and maintain essential properties such as integrity, confidentiality, andperformance, despite the presence of intrusions. Unlike the traditional security mea-sures that require central control or administration, survivability is intended to addressunbounded network environments. This seminar report describes the survivability ap-proach to help assure that a system that must operate in an unbounded network is robustin the presence of attack and will survive attacks that result in successful intrusions. In-cluded are discussions of survivability as an integrated engineering framework, the currentstate of survivability practice, the specification of survivability requirements, strategiesfor achieving survivability, and techniques and processes for analyzing survivability. iii
  6. 6. Contents1 INTRODUCTION TO SURVIVABILITY IN NETWORK SYSTEMS 1 1.1 The New Network Paradigm: Organizational Integration . . . . . . . . . 1 1.2 The Definition of Survivability . . . . . . . . . . . . . . . . . . . . . . . . 22 DOMAIN AND CHARACTERISTICS OF SURVIVABILITY 6 2.1 The Domain of Survivability: Unbounded Networks . . . . . . . . . . . . 6 2.2 Characteristics of Survivable Systems . . . . . . . . . . . . . . . . . . . . 9 2.3 Survivability as an Integrated Engineering Framework . . . . . . . . . . . 12 2.3.1 Survivability and Security . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2 Survivability and Fault Tolerance . . . . . . . . . . . . . . . . . . 13 2.4 The Current State of Practice in Survivable Systems . . . . . . . . . . . 13 2.4.1 Incident Handling Has Enhanced Survivability . . . . . . . . . . . 15 2.4.2 Firewalls Embody the Current State of Practice . . . . . . . . . . 153 DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMS 17 3.1 Expressing Survivability Requirements . . . . . . . . . . . . . . . . . . . 17 3.1.1 Requirements Definition for Essential Services . . . . . . . . . . . 22 3.1.2 Requirements Definition for Survivability Services . . . . . . . . . 234 SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATE- GIES 27 4.1 CONCEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1 Four Aspects of Survivability Solution Strategies . . . . . . . . . . 28 iv
  7. 7. 4.1.2 Support of Strategies by the Computing Infrastructure . . . . . . 29 4.1.3 Survivability Design Observations . . . . . . . . . . . . . . . . . . 31 4.1.4 Survivability Requires Trust Maintenance . . . . . . . . . . . . . 32 4.1.5 Survivability Analysis Is Protocol-Based Not Topology-Based . . . 33 4.1.6 Survivability Is Emergent and Stochastic . . . . . . . . . . . . . . 33 4.1.7 Survivability Requires a Management Component . . . . . . . . . 345 STRATEGIES TO IMPROVE NETWORK SURVIVABILITY 35 5.1 PREVENTION TECHNIQUES . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 NETWORK DESIGN AND CAPACITY ALLOCATION . . . . . . . . . 36 5.3 TRAFFIC MANAGEMENT AND RESTORATION . . . . . . . . . . . 36 5.4 ALGORITHM: FOR A PRIMAL APPROACH . . . . . . . . . . . . . . 386 RESEARCH DIRECTIONS 397 CONCLUSION AND FUTURE SCOPE 40Bibliography 41 v
  8. 8. List of Figures 1.1 Survivable System With 3 R’s:Resist,Recognise and Recover . . . . . . . 5 2.1 An Unbounded Domain Viewed as a Collection of Bounded Systems . . . 7 2.2 The Key Properties of Survivable Systems . . . . . . . . . . . . . . . . . 11 3.1 Requirements Definition for Survivable Systems . . . . . . . . . . . . . . 18 3.2 Integrating Survivability Requirements with System Requirements . . . . 19 3.3 The Relationship Between Legitimate and Intrusion Usage . . . . . . . . 21 4.1 A Taxonomy of Strategies Related to Survivability . . . . . . . . . . . . . 29 5.1 Restoration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2 Algorithm for a Primal approach. . . . . . . . . . . . . . . . . . . . . . . 38 vi
  9. 9. Chapter 1INTRODUCTION TOSURVIVABILITY IN NETWORKSYSTEMSContemporary large-scale networked systems that are highly distributed improve the effi-ciency and effectiveness of organizations by permitting whole new levels of organizationalintegration. However, such integration is accompanied by elevated risks of intrusion andcompromise. These risks can be mitigated by incorporating survivability capabilitiesinto an organization’s systems. As an emerging discipline, survivability builds on relatedfields of study (e.g., security, fault tolerance, safety, reliability, reuse, performance, veri-fication, and testing) and introduces new concepts and principles. Survivability focuseson preserving essential services in unbounded environments, even when systems in suchenvironments are penetrated and compromised.1.1 The New Network Paradigm: Organizational In- tegrationFrom their modest beginnings some 20 years ago, computer networks have become acritical element of modern society. These networks not only have global reach, they also 1
  10. 10. INTRODUCTION TO SURVIVABILITY IN NETWORK SYSTEMShave impact on virtually every aspect of human endeavor. Network systems are principalenabling agents in business, industry, government, and defense. Major economic sectors,including defense, energy, transportation,telecommunications, manufacturing, financialservices, health care, and education, all depend on a vast array of networks operating onlocal,national, and global scales. This pervasive societal dependency on networks mag-nifies the consequences of intrusions, accidents, and failures, and amplifies the criticalimportance of ensuring network survivability. As organizations seek to improve efficiency and competitiveness, a new networkparadigm is emerging. Networks are being used to achieve radical new levels of organiza-tional integration. This integration obliterates traditional organizational boundaries andtransforms local operations into components of comprehensive, network-resident busi-ness processes. For example, commercial organizations are integrating operations withbusiness units, suppliers, and customers through large-scale networks that enhance com-munication and services. These networks combine previously fragmented operations intocoherent processes open to many organizational participants. This new paradigm repre-sents a shift from bounded networks with central control to unbounded networks. Un-bounded networks are characterized by distributed administrative control without centralauthority, limited visibility beyond the boundaries of local administration, and lack ofcomplete information about the network. At the same time, organizational dependencieson networks are increasing and risks and consequences of intrusions and compromises areamplified.1.2 The Definition of SurvivabilityWe define survivability as the capability of a system to fulfill its mission, in a timelymanner, in the presence of attacks, failures, or accidents. We use the term system in thebroadest possible sense, including networks and large-scale systems of systems. The termmission refers to a set of very high-level (i.e., abstract) requirements or goals. Missionsare not limited to military settings since any successful organization or project must have 2
  11. 11. INTRODUCTION TO SURVIVABILITY IN NETWORK SYSTEMSa vision of its objectives whether expressed implicitly or as a formal mission statement.Judgments as to whether or not a mission has been successfully fulfilled are typicallymade in the context of external conditions that may affect the achievement of thatmission. For example, assume that a financial system shuts down for 12 hours during aperiod of widespread power outages caused by a hurricane. If the system preserves theintegrity and confidentiality of its data and resumes its essential services after the periodof environmental stress is over, the system can reasonably be judged to have fulfilledits mission. However, if the same system shuts down unexpectedly for 12 hours undernormal conditions (or under relatively minor environmental stress) and deprives its usersof essential financial services, the system can reasonably be judged to have failed itsmission, even if data integrity and confidentiality are preserved.Timeliness is a critical factor that is typically included in (or implied by) the very high-level requirements that define a mission. However, timeliness is such an important factorthat we included it explicitly in the definition of survivability. The terms attack, failure,and accident are meant to include all potentially damaging events; but these terms donot partition these events into mutually exclusive or even distinguishable sets. It is oftendifficult to determine if a particular detrimental event is the result of a malicious attack,a failure of a component, or an accident. Even if the cause is eventually determined, thecritical immediate response cannot depend on such speculative future knowledge. Attacks are potentially damaging events orchestrated by an intelligent adversary.Attacks include intrusions, probes, and denial of service. Moreover, the threat of anattack may have as severe an impact on a system as an actual occurrence. A systemthat assumes a defensive position because of the threat of an attack may reduce its func-tionality and divert additional resources to monitoring the environment and protectingsystem assets. We include failures and accidents as part of survivability. Failures are po-tentially damaging events caused by deficiencies in the system or in an external elementon which the system depends. Failures may be due to software design errors, hardwaredegradation, human errors, or corrupted data. Accidents describe the broad range ofrandomly occurring and potentially damaging events such as natural disasters. We tendto think of accidents as externally generated events (i.e., outside the system) and failuresas internally generated events. 3
  12. 12. INTRODUCTION TO SURVIVABILITY IN NETWORK SYSTEMS With respect to system survivability, a distinction between a failure and an ac-cident is less important than the impact of the event. Nor is it often possible to distin-guish between intelligently orchestrated attacks and unintentional or randomly occurringdetrimental events. This seminar’s approach concentrates on the effect of a potentiallydamaging event. Typically, for a system to survive, it must react to (and recover from) adamaging effect (e.g., the integrity of a database is compromised) long before the under-lying cause is identified. In fact, the reaction and recovery must be successful whetheror not the cause is ever determined.The primary focus in this seminar report is to helpsystems survive the acts of intelligent adversaries.The Survivable Network TechnologyTeam is an outgrowth of the CERT. Coordination Center, which has been helping usersrespond to and recover from computer security incidents since 1988.Finally, it is important to recognize that it is the mission fulfillment that must survivenot any particular subsystem or system component. Central to the notion of surviv-ability is the capability of a system to fulfill its mission, even if significant portions ofthe system are damaged or destroyed. This seminar sometimes use the term survivablesystem as less than perfectly precise shorthand for a system with the capability to fulfilla specified mission in the face of attacks, failures, or accidents. Again, it is the mission,not a particular portion of the system that must survive. 4
  13. 13. INTRODUCTION TO SURVIVABILITY IN NETWORK SYSTEMSFigure 1.1: Survivable System With 3 R’s:Resist,Recognise and Recover 5
  14. 14. Chapter 2DOMAIN ANDCHARACTERISTICS OFSURVIVABILITY2.1 The Domain of Survivability: Unbounded Net- worksThe success of a survivable system depends on the computing environment in which thesurvivable system operates. The trend in networked computing environments is towardlargelyunbounded network infrastructures. A bounded system is one in which all of thesystem’s parts are controlled by a unified administration and can be completely char-acterized and controlled. At least in theory, the behavior of a bounded system can beunderstood and all of its various parts identified. In an unbounded system there is no uni-fied administrative control over its parts. We use the term administrative control in thestrictest sense, which includes the power to impose and enforce sanctions and not simplyto recommend an appropriate security policy. In an unbounded system, each participanthas an incomplete view of the whole, must depend on and trust information supplied byits neighbors, and cannot exercise control outside its local domain. An unbounded systemcan be composed of bounded and unbounded systems connected together in a network. 6
  15. 15. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYFigure 2.1 illustrates an unbounded domain consisting of a collection of bounded systemsin which each bounded system is under separate administrative control. Although thesecurity policy of an individual bounded system cannot be fully enforced outside of theboundaries of its administrative control, the policy can be used as a yardstick to evaluatethe security state of that bounded system. Of course, the security policy can be ad-vertised outside of the bounded system; but administrators are severely limited in theirability to compel or persuade outside individuals or entities to follow it. This limitationis particularly true when an unbounded domain spans jurisdictional boundaries, makinglegal sanctions difficult or impossible to impose. Figure 2.1: An Unbounded Domain Viewed as a Collection of Bounded Systems When an application or software-intensive system is exposed to an environmentconsisting of multiple, unpredictable administrative domains with no measurable bounds,the system have an unbounded environment. An unbounded environment exhibits thefollowing properties: • Multiple administrative domains with no central authority 7
  16. 16. DOMAIN AND CHARACTERISTICS OF SURVIVABILITY • An absence of global visibility (i.e., the number and nature of the nodes in the network cannot be fully known) • Interoperability between administrative domains determined by convention • Widely distributed and interoperable systems • Users and attackers can be peers in the environment • Cannot be partitioned into a finite number of bounded environments The Internet is an example of an unbounded environment with many client-servernetwork applications. A public Web server and its clients may exist within many dif-ferent administrative domains on the Internet; yet there exists no central authority thatrequires all clients to be configured in a way expected by the Web server. In particular,a Web server can never rely on a set of client plug-ins to be present or absent for anyfunction that the server may want to provide. For a Web server providing a financialtransaction (e.g., for a Web-based purchase), the Web server may require that the userinstall a plug-in on the client to support a secure transaction. However, due to the un-bounded nature of the environment, previously installed plug-ins from a competitor maybe present on the client that may corrupt, subvert, or damage the Web server during thetransaction. For the Web server to be survivable there must be built-in protection frommalicious client interactions and these protections must make no assumptions about theconfiguration or features of the remote client.In this example, the Web server and its clients make up the system. The multiple admin-istrative domains are the variety of site domains on the Internet. Many of these domainshave legitimate users. Other sites are used for intrusions in an anonymous setting. Theselatter sites cannot be distinguished by their administrative domain, but only by clientbehavior. The interoperability between the server and its clients is defined by http (hy-pertext transfer protocol), a convention agreed upon between the server and clients. Thesystem, composed of Web servers and clients, is widely distributed both geographicallyand logically throughout the Internet. Legitimate users and attackers are peers in the en-vironment and there is no method to isolate legitimate users from the attackers. In other 8
  17. 17. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYwords, there is no way to bind the environment to legitimate users using only a com-mon administrative policy. Unbounded systems are a significant component of today’scomputing environment and will play an even larger role in the future. The Internetnon-hierarchical network of systems, each under local administrative control only is aprimary example of an unbounded system. While conventions exist that allows the partsof the Internet to work together, there is no global administrative control to assure thatthese parts behave according to these conventions. Therefore, security problems abound.Unfortunately, the security problems associated with unbounded systems are typicallyunderestimated.2.2 Characteristics of Survivable SystemsA key characteristic of survivable systems is their capability to deliver essential services inthe face of attack, failure, or accident. Central to the delivery of essential services is thecapability of a system to maintain essential properties (i.e., specified levels of integrity,confidentiality, performance, and other quality attributes) in the presence of attack, fail-ure, or accident. Thus, it is important to define minimum levels of quality attributesthat must be associated with essential services. For example, a launch of a missile by adefensive system is no longer effective if the system performance is slowed to the pointthat the target is out of range before the system can launch. These quality attributes areso important that definitions of survivability are often expressed in terms of maintaininga balance among multiple qualities attributes such as performance, security, reliability,availability, fault-tolerance, modifiability, and affordability. The Architecture TradeoffAnalysis project at the Software Engineering Institute is using this attribute-balancing(i.e., tradeoff) view of survivability to evaluate and synthesize survivable systems. Qual-ity attributes represent broad categories of related requirements, so a quality attributemay contain other quality attributes. For example, the security attribute traditionallyincludes the three attributes: confidentiality, integrity, and availability. The capabilityto deliver essential services (and maintain the associated essential properties) must besustained even if a significant portion of the system is incapacitated. 9
  18. 18. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYFurthermore, this capability should not be dependent upon the survival of a specificinformation resource, computation, or communication link. In a military setting, essen-tial services might be those required to maintain an overwhelming technical superiorityand essential properties may include integrity, confidentiality, and a level of performancesufficient to deliver results in less than one decision cycle of the enemy.In the publicsector, a survivable financial system is one that maintains the integrity, confidentiality,and availability of essential information and financial services, even if particular nodes orcommunication links are incapacitated through intrusion or accident, and that recoverscompromised information and services in a timely manner.The financial systems surviv-ability might be judged by using a composite measure of the disruption of stock tradesor bank transactions (i.e., a measure of the disruption of essential services). Key to the concept of survivability, then, is identifying the essential services(and the essential properties that support them) within an operational system. Essentialservices are defined as the functions of the system that must be maintained when theenvironment is hostile or failures or accidents are detected that threaten the system.There are typically many services that can be temporarily suspended when a system isdealing with an attack or other extraordinary environmental condition. Such a suspensioncan help isolate areas affected by an intrusion and free system resources to deal with itseffects. The overall function of a system should adapt to preserve essential services.We have linked the capability of a survivable system to fulfill its mission in a timelymanner to its ability to deliver essential services in the presence of attack, accident, orfailure. Ultimately, mission fulfillment must survive not any portion or component of thesystem. If an essential service is lost, it can be replaced by another service that supportsmission fulfillment in a different but equivalent way. However, we still believe that theidentification and protection of essential services is an important part of a practicalapproach to building and analyzing survivable systems. As a result, we define essentialservices to include alternate sets of essential services (perhaps mutually exclusive) thatneed not be simultaneously available. For example, a set of essential services to supportpower delivery may include both the distribution of electricity and the operation of anatural gas pipeline. To maintain their capabilities to deliver essential services, survivablesystems must exhibit the four key properties illustrated in below Table : 10
  19. 19. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYFigure 2.2: The Key Properties of Survivable Systems 11
  20. 20. DOMAIN AND CHARACTERISTICS OF SURVIVABILITY2.3 Survivability as an Integrated Engineering Frame- workAs a broadly-based engineering paradigm, survivability is a natural framework for in-tegrating established and emerging software engineering disciplines in the service of acommon goal. These established areas of software engineering, which are related tosurvivability, include security, fault tolerance, safety, reliability, reuse, performance, ver-ification, and testing. Research in survivability encompasses a wide variety of researchmethods, including the investigation of : • Analogues to the immunological functioning of an individual organism • Sociological analogues to public health efforts at the community level2.3.1 Survivability and SecurityThe discipline of computer security has made valuable contributions to the protection andintegrity of information systems over the past three decades. However, computer securityhas traditionally been used as a binary term that suggests that at any moment in timea system is either safe or compromised. We believe that this use of computer securityengenders viewpoints that largely ignore the aspects of recovery from the compromiseof a system and aspects of maintaining services during and after an intrusion. Such anapproach is inadequate to support necessary improvements in the state of the practiceof protecting computer systems from attack. In contrast, the term survivable systemrefers to systems whose components collectively accomplish their mission even underattack and despite active intrusions that effectively damage a significant portion of thesystem. Robustness under attack is at least as important as hardness or resistanceto attack. Hardness contributes to survivability, but robustness under attack (and, inparticular, recoverability) is the essential characteristic that distinguishes survivabilityfrom traditional computer security. At the same time, survivability can benefit fromcomputer security research and practice, and survivability can provide a framework forintegrating security with other disciplines that can contribute to system survivability. 12
  21. 21. DOMAIN AND CHARACTERISTICS OF SURVIVABILITY2.3.2 Survivability and Fault ToleranceSurvivability requires robustness under conditions of intrusion, failure, or accident. Theconcept of survivability includes fault tolerance, but is not equivalent to it. Fault toler-ance relates to the statistical probability of an accidental fault or combination of faults,not to malicious attack. For example, an analysis of a system may determine that thesimultaneous occurrence of the three statistically independent faults (f1, f2, and f3) willcause the system to fail. The probability of the three independent faults occurring si-multaneously by accident may be extremely small, but an intelligent adversary withknowledge of the system’s internals can orchestrate the simultaneous occurrence of thesethree faults and bring down the system. A fault-tolerant system most likely does notaddress the possibility of the three faults occurring simultaneously, if the probability ofoccurrence is below a threshold of concern. A survivable system requires a contingencyplan to deal with such a possibility.Redundancy is another factor that can contribute to the survivability of systems. How-ever, redundancy alone is insufficient since multiple identical backup systems share iden-tical vulnerabilities. A survivable system requires each backup system to offer equivalentfunctionality, but significant variance in implementation. This variance thwarts attemptsto compromise the primary system and all backup systems with a single attack strategy.2.4 The Current State of Practice in Survivable Sys- temsMuch of today’s research and practice in computer-systems survivability takes a per-ilously narrow, security-based view of defense against computer intrusions. This narrowview is dangerously incomplete because it focuses almost exclusively on hardening a sys-tem (e.g., using firewall technology or an orange book approach to host protection) toprevent a break-in or other malicious attack. This view does little about how to detectan intrusion or what to do once an intrusion has occurred or is under way. This view isalso accompanied by evaluation techniques that limit their focus to the relative hardnessof a system, as opposed to a system’s robustness under attack and ability to recover 13
  22. 22. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYcompromised capabilities. The architecture of secure bounded systems is built upon theexistence of a security policy and its enforcement, which is imposed by the exercise ofadministrative control. In contrast, an unbounded system has no administrative controlwith which to impose global-security policy. For instance, on the Internet today thebackbone architecture exists independent of security policy considerations because thereis no global administrative control. Affordability is always a significant factor in thedesign, implementation, and maintenance of systems that support the national infras-tructure (e.g., the power grid, the public switched communications networks, and thefinancial networks) and our national defense. In fact, the trend toward increased sharingof common infrastructure components in the interest of economy virtually ensures thatthe civilian networked information infrastructure and its vulnerabilities will always be aninseparable part of our national defense. Practical, affordable systems are almost never100 percent customized, but rather are constructed from commonly available off-the-shelfcomponents with internal structures that are well known. The trend toward developingsystems through integration and reuse instead of customized design and coding efforts isa cornerstone of modern software engineering. Unfortunately, the intellectual complexityassociated with software design, coding, and testing virtually ensures that exploitablebugs can and will be discovered in commercial and public domain products with inter-nal structures that are available for analysis. When these products are incorporatedas components of larger systems, those systems become vulnerable to attack strategiesbased on the exploitable bugs. Popular commercial and public-domain components offerattackers a ubiquitous set of targets with well-known and typically unvarying internalstructures. This lack of variability among components translates into a lack of variabil-ity among systems. These systems potentially allow a single attack strategy to have awide-ranging and devastating impact. The natural escalation of offensive threats versusdefensive countermeasures has demonstrated time and again that no practical systemscan be built that are invulnerable to attack.Despite best efforts, there can be no assurance that systems will not be breached. Thus,the traditional view of information systems security must be expanded to encompassthe specification and design of system behavior that helps the system survive in spite ofactive intrusions. Only then can systems be created that are robust in the presence of 14
  23. 23. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYattack and are able to survive attacks that cannot be completely repelled. In short, thenature of contemporary system development dictates that even hardened systems canand will be broken. Therefore, survivability must be designed into systems to help avoidthe potentially devastating effects of system compromise and failure due to intrusion.2.4.1 Incident Handling Has Enhanced SurvivabilityAlthough applying the term survivability to computer systems is relatively new, the prac-tice of survivability is not. Much of the survivability practice to date has been in the realmof incident response (IR) teams. In fact, the CERT Coordination Center (CERT/CC)has, throughout its history, enhanced system survivability in the Internet community.The CERT/CC provides incident response services (helping organizations respond toand recover from incidents) and publishes and distributes vulnerability advisories (akinto public health notices). Traditionally, the CERT/CC has been concerned about sur-vivability and has been successful in helping sites with risk mitigation and recovery. Theexperience of the CERT Coordination Center has shown that how organizations respondto and recover from computer intrusions is at least as important as the steps they take toprevent them. We believe that widespread availability and use of survivable systems bythe Internet community and throughout the Internet infrastructure will provide the besthope for the dramatic improvements necessary to transform the Internet into a surviv-able, networked information system of systems. Survivable systems will help make theInternet a viable medium for the conduct of commerce, defense, and government. Thismedium will also enable the support of major elements of the national infrastructure(e.g.,power grid, public switched network, and air traffic control).2.4.2 Firewalls Embody the Current State of PracticeCurrently, little of the basic technology in security engineering and system integrationapplies to unbounded systems. Instead, current practice assumes that the capabilityexists to identify, define, and characterize the extent of administrative control over asystem, all access points to that system, and all signals that may appear at those accesspoints. In unbounded systems, such as the current Internet and the future National 15
  24. 24. DOMAIN AND CHARACTERISTICS OF SURVIVABILITYInformation Infrastructure, these boundary conditions cannot be fully determined. Thecurrent state of practice in survivability and security evaluation tends to treat systemsand their environments as static and unchanging. However, the survivability and securityof systems in fact degrades over time as changes occur in their structures, configurations,and environments, and as knowledge of their vulnerabilities spreads throughout the in-truder community. On the Internet today, the cornerstone of security is the notion ofa firewall, a logically bounded system within a physically unbounded one. We assertthat bounded-system thinking within unbounded domains leads to security designs andarchitectures that are fundamentally flawed from a survivability perspective.One notableexample is the use of a firewall as the basic security component of the Internet.This approach is severely limited and can be readily circumvented by exploiting the fun-damental differences between bounded and unbounded systems. Traditional firewalls arethe state of the art for security architectures, but not for survivable systems, because theyare passive, filter-only devices. The addition of active components, such as detection anda dynamic response capability, will allow firewalls to play a role in survivable systems. 16
  25. 25. Chapter 3DEFINING REQUIREMENTSFOR SURVIVABLE SYSTEMSSurvivability requirements can vary substantially depending on system scope, criticality,and the consequences of failure and interruption of service. Categories of requirementsdefinitions for survivable systems include function, usage, development, operation, andevolution. In this section, we present definitions of survivability requirements, ways inwhich these requirements can be expressed, and their impact on system survivability.The new paradigm for system requirements definition and design is characterized bydistributed services, distributed logic, distributed code (including executable content),distributed hardware, a shared communications and routing infrastructure, diminishedtrust, and a lack of unified administrative control. Assuring the survivability of missioncritical systems developed under this new paradigm is a formidable high-stakes effortfor software engineering research. This effort requires that traditional computer securitymeasures be augmented by new and comprehensive system survivability strategies.3.1 Expressing Survivability RequirementsThe definition and analysis of survivability requirements is a critical first step in achiev-ing system survivability. Figure 3.1 depicts an iterative model for defining these require- 17
  26. 26. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMSments. Survivability must address not only requirements for software functionality, butalso requirements for software usage, development, operation, and evolution. Thus, fivetypes of requirements definitions are relevant to survivable systems in the model. Theserequirements are discussed in detail in the following subsections. Figure 3.1: Requirements Definition for Survivable Systems System/Survivability Requirements: The term system requirement refers to tra-ditional user functions that a system must provide. For example, a network managementsystem must provide functions to enable users to monitor network operations, adjustperformance parameters, etc. System requirements also include nonfunctional aspects ofa system, such as timing, performance, and reliability. The term survivability require-ment refers to the capabilities of a system to deliver essential services in the presence ofintrusions and compromises and to recover full services.Figure 3.2 - depicts the integration of survivability requirements with system require-ments at node and network levels.Survivability requires that system requirements be organized into essential services andnon-essential services. Essential services must be maintained even during successful intru- 18
  27. 27. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMS Figure 3.2: Integrating Survivability Requirements with System Requirementssions; non-essential services are recovered after intrusions have been handled. Essentialservices may be stratified into any number of levels, each embodying fewer and morevital services as the severity and duration of intrusion increases. Thus, definitions ofrequirements for essential services must be augmented with appropriate survivability re-quirements. As shown in Figure 3.1, survivable systems may also include legacy andacquired COTS components that were not developed with survivability as an explicit ob-jective. Such components may provide both essential and non-essential services and mayrequire functional requirements for isolation and control through wrappers and filters topermit their safe use in a survivable system environment. Figure 3.2 show that surviv-ability itself imposes new types of requirements on systems. These new requirementsinclude the resistance to, recognition of and recovery from intrusions and compromises,and adaptation and evolution to diminish the effectiveness of future intrusion attempts.These survivability requirements are supported by a variety of existing and emerging sur-vivability strategies, as noted in Figure 2.1 and discussed in more detail below. Finally,Figure 3.2 depicts emergent behavior requirements at the network level.These requirements are characterized as emergent because they are not associated withparticular nodes, but rather emerge from the collective behavior of node services in com-municating across the network. These requirements deal with the survivability of overallnetwork capabilities (e.g., capabilities to route messages between critical sets of nodes 19
  28. 28. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMSregardless of how intrusions may damage or compromise network topology). We envisionsurvivable systems that are capable of adapting their behavior, function, and resourceallocation in response to intrusions. For example, when necessary, functions and re-sources devoted to non-essential services could be reallocated to the delivery of essentialservices and to intrusion resistance, recognition, and recovery. Requirements for suchsystems must also specify how the system should adapt and reconfigure itself in responseto intrusions. Systems can exhibit large variations in survivability requirements. Smalllocal networks may require few or no essential services and recovery times measured inhours. Conversely, large-scale networks of networks may require a core set of essentialservices, automated intrusion detection, and recovery times measured in minutes. Em-bedded command and control systems may require essential services to be maintained inreal time and recovery times measured in milliseconds. The attainment and maintenanceof survivability consume resources in system development, operation, and evolution. Theresources allocated to a system’s survivability should be based on the costs and risks toan organization associated with the loss of essential services. Usage/Intrusion Requirements: Survivable-system testing must demonstrate thecorrect performance of essential and non-essential system services as well as the sur-vivability of essential services under intrusion. Because system performance in testing(and operation) depends totally on the system’s use, an effective approach to survivable-system testing is based on usage scenarios derived from usage models. Usage models aredeveloped from usage requirements. These requirements specify usage environments andscenarios of system use. Usage requirements for essential and non-essential services mustbe defined in parallel with system and survivability requirements. Furthermore, intrud-ers and legitimate users must be considered equally. Intrusion requirements that specifyintrusion-usage environments and scenarios of intrusion use must be defined as well. Inthis approach, intrusion use and legitimate use of system services are modeled together.Figure 3.3 depicts the relationship between legitimate and intrusion use. Intruders mayengage in scenarios beyond legitimate scenarios, but may also employ legitimate use forpurposes of intrusion if they gain the necessary privileges. 20
  29. 29. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMS Figure 3.3: The Relationship Between Legitimate and Intrusion Usage Development Requirements: Survivability places stringent requirements on sys-tem development and testing practices. Inadequate functionality and software errors canhave a devastating effect on system survivability and provide opportunities for intruderexploitation. Sound engineering practices are required to create survivable software. Thefollowing five principles (four technical and one organizational) are example requirementsfor survivable-system development and testing practices: • Precisely specify the system’s required functions in all possible circumstances of system use. • Verify the correctness of system implementations with respect to the functional specifications. • Specify function usage in all possible circumstances of system use, including in- truder use. • Test and certify the system based on function usage and statistical methods. • Establish permanent readiness teams for system monitoring, adaptation, and evo- lution.Sound engineering practices are required to deal with legacy and COTS software com-ponents as well. 21
  30. 30. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMS Operations Requirements: Survivability places demands on requirements for sys-tem operation and administration. These requirements include defining and communicat-ing survivability policies, monitoring system use, responding to intrusions, and evolvingsystem functions as needed to ensure survivability as usage environments and intrusionpatterns change over time.Evolution Requirements: System evolution responds to user requirements for new func-tions. However, this evolution is also necessary to respond to increasing intruder knowl-edge of system behavior and structure. In particular, survivability requires that systemcapabilities evolve more rapidly than intruder knowledge. This rapid evolution preventsintruders from accumulating information about otherwise invariant system behavior thatthey need to achieve successful penetration and exploitation.3.1.1 Requirements Definition for Essential ServicesThe preceding discussion distinguishes between essential and non-essential services. Eachsystem requirement must be examined to determine whether it corresponds to an essentialservice. The set of essential services must form a viable subsystem for users that iscomplete and coherent. If multiple levels of essential services are required, each set ofservices provided at each level must also be examined for completeness and coherence. Inaddition, requirements must be defined for making the transition to and from essential-service levels. When distinguishing between essential and non-essential services, all ofthe usual requirements-definition processes and methods can be applied. Elicitationtechniques such as those embodied in Software Requirements Engineering can help toidentify essential services. Tradeoff and cost/benefit analysis can help to determine thesets of services that sufficiently address business survivability risks and vulnerabilities.Provisions for tracing survivability requirements through design, code, and test mustbe established. As previously mentioned, simulation of intrusion through intruder-usagescenarios is included in the testing process. 22
  31. 31. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMS3.1.2 Requirements Definition for Survivability ServicesAfter specifying requirements for essential and non-essential services, a set of require-ments for survivability services must be defined. These services can be organized intofour general categories: resistance, recognition, recovery, and adaptation and evolution.These survivability services must operate in an intruder environment that can be charac-terized by three distinct phases of intrusion: penetration, exploration, and exploitation.Penetration Phase: In this phase, an intruder attempts to gain access to a system throughvarious attack scenarios. These scenarios range from random inputs by hobbyist hack-ers to well-planned attacks by professional intruders. These attempts are designed tocapitalize on known system vulnerabilities. Exploration Phase: In this phase, the system has been penetrated and the in-truder is exploring internal system organization and capabilities. By exploring, the in-truder learns how to exploit the access to achieve intrusion objectives. Exploitation Phase: In this phase, the intruder has gained access to desired sys-tem facilities and is performing operations designed to compromise system capabilities.Penetration, exploration, and exploitation create a spiral of increasing intruder authorityand a widening circle of compromise. For example, penetration at the user level is typi-cally a means to find root-level vulnerabilities. User-level authorization is then employedto exploit those vulnerabilities to achieve root-level penetration. Finally, compromise ofthe weakest host in a networked system allows that host to be used as a stepping-stoneto compromise other more protected hosts.Requirements definitions for resistance, recognition, recovery, and adaptation and evo-lution services help select survivability strategies to deal with these phases of intrusion.Some strategies, such as firewalls, are the product of extensive research and developmentand currently are used extensively in bounded networks. New survivability strategies areemerging to respond to the unique challenges of unbounded networks.Resistance Service Requirements: Resistance is the capability of a system to deter at-tacks. Resistance is thus important in the penetration and exploration phases of anattack, before actual exploitation. Current strategies for resistance include the use offirewalls, authentication, and encryption. Diversification is a resistance strategy that 23
  32. 32. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMSwill likely become more important for unbounded networks. Requirements for diver-sification must define planned variation in survivable system function, structure, andorganization, and the means for achieving it. Diversification is intended to create a mov-ing target and render ineffective the accumulation of system knowledge as an intrusionstrategy. Diversification also eliminates intrusion opportunities associated with multiplenodes that execute identical software and typically exhibit identical vulnerabilities. Suchsystems offer tempting economies of scale to intruders, since when one node has beenpenetrated, all nodes can be penetrated. Requirements for diversification can includevariation in programs, retained data, and network routing and communication. For ex-ample, systematic means can be defined to randomize software programs while preservingfunctionality.Recognition Service Requirements: Recognition is the capability of a system to recog-nize attacks or the probing that precedes attacks. The ability to react or adapt duringan intrusion is central to the capacity of a system to survive an attack that cannotbe completely repelled. To react or adapt, the system must first recognize it is beingattacked. In fact, recognition is essential in all three phases of attack.Current strate-gies for attack recognition include both state-of-the-art intrusion detection and mundanebut effective techniques such as logging and frequent auditing as well as follow-up in-vestigations of reports generated by ordinary error detection mechanisms. Advancedintrusion-detection techniques are generally of two types: anomaly detection and pat-tern recognition. Anomaly detection is based on models of normal user behavior. Thesemodels are often established through statistical analysis of usage patterns. Deviationsfrom normal usage patterns are flagged as suspicious. Pattern recognition is based uponmodels of intruder behavior. User activity that matches a known pattern of intruderbehavior raises an alarm. Requirements for future survivable networks will likely employadditional strategies such as self-awareness, trust maintenance, and black-box reporting.Self-awareness is the process of establishing a high-level semantic model of the computa-tions that a component or system is executing or has been asked to execute. A systemor component that understands what it is being asked can refuse requests that would bedangerous, compromise a security policy, or adversely impact the delivery of minimumessential services. Trust maintenance is achieved by a system through periodic queries 24
  33. 33. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMSamong its components (e.g., among the nodes in a network) to continually test and vali-date trust relationships. Detection of signs of intrusion would trigger an immediate testof trust relationships. Black-box reporting is a dump of system information that can beretrieved from a crashed system or component for analysis to determine the cause of thecrash (e.g., design error or specific intrusion type). This analysis can help to preventother components from suffering the same fate. A survivable-system design must includeexplicit requirements for recognition of attack. These requirements ensure the use ofone or more of the preceding strategies through the specification of architectural fea-tures, automated tools, and manual processes. Since intruder techniques are constantlyadvancing, recognition requirements should be frequently reviewed and continuously im-proved.Recovery Service Requirements: Recovery is a system’s ability to restore services afteran intrusion has occurred. Recovery also contributes to a system’s ability to maintainessential services during intrusion.Requirements for recoverability are what most clearlydistinguish survivable systems from systems that are merely secure. Traditional computersecurity leads to the design of systems that rely almost entirely on hardening (i.e., resis-tance) for protection. Once security is breached, damage may follow with little to standin the way. The ability of a system to react during an active intrusion is central to itscapacity to survive an attack that cannot be completely repelled. Recovery is thus crucialduring the exploration and exploitation phases of intrusion. Recovery strategies in usetoday include replication of critical information and services, use of fault-tolerant designs,and incorporation of backup systems for hardware and software. These backup systemsmaintain master copies of critical software in isolation from the network. Some systems,such as large-scale transaction processing systems, employ elaborate, fine-grained trans-action roll-back processes to maintain the consistency and integrity of state data.Adaptation and Evolution Service Requirements: Adaptation and evolution are criti-cal to maintaining resistance to ever-increasing intruder knowledge of how to exploitotherwise unchanging system functions. Dynamic adaptation permanently improves asystem’s ability to resist, recognize, and recover from intrusion attempts.For example,an adaptation requirement may be an infrastructure that enables the system to inocu-late itself against newly-discovered security vulnerabilities by automatically distributing 25
  34. 34. DEFINING REQUIREMENTS FOR SURVIVABLE SYSTEMSand applying security fixes to all network elements. Another adaptation requirementmay be that intrusion detection rule sets are updated regularly in response to reports ofknown intruder activity from authoritative sources of security information, such as theCERT Coordination Center. Adaptation requirements ensure that such capabilities arean integral part of a system’s design. As in the cases of resistance, recognition, and recov-ery requirements, the constant evolution of intruder techniques requires that adaptationrequirements be frequently reviewed and continuously improved. 26
  35. 35. Chapter 4SURVIVABILITY : DESIGN ANDIMPLEMENTATIONSTRATEGIES4.1 CONCEPTIn this chapter we examine strategies that support the survivability of critical systemfunctions in unbounded networks. Strategies for survivability in networked systems de-pend on several assumptions and constraints. Although they may seem obvious, theseassumptions and constraints must be made explicit. The assumptions differ radicallyfrom the implicit assumptions traditionally made for the unprocessed, multiprocessor,and bounded network systems on which most previous research and development hasbeen based. For unbounded networks, we assume that • Any individual node of the network can be compromised • Survivability does not require that any particular physical component of the net- work be preserved • Only the essential services of the network as a whole must survive 27
  36. 36. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIES • For reasons of reliability, design error, user error, and intentional compromise, the trustworthiness of a network node or any node with which it can communicate cannot be guaranteedIn this seminar report, we primarily discuss unbounded networks. The term unboundedhas a slightly different meaning depending on the purpose and situation involved. In allcases, unbounded networks relate to three principal characteristics that are present ineach definition: a lack of central physical or administrative control, absence of insightor vision into all parts of the network, and no practical limit on growth in the num-ber of nodes in the network.These assumptions impose the following constraints on thearchitecture of survivable networks and on the form of feasible survivability strategies: • There must not be a single point of failure within the network. Essential services are distributed in a manner that is not critically dependent on any particular com- ponent or node. • Global knowledge is impossible to achieve in a distributed system. There are no all-seeing global oracles. Instead, protocols define the interaction and knowledge shared between nodes. • Each node must continuously validate the trustworthiness of itself and those with which it communicates. • Computations within a given node of an unbounded network, whether for essen- tial service communication or trust validation, must have costs that are less than proportional to the number of nodes in the network.4.1.1 Four Aspects of Survivability Solution StrategiesAs dicussed earlier, there are four aspects of the survivability solution which can serve as abasis for survivability strategies. These four aspects are: resistance, recognition,recovery,and system adaptation and evolution. This section summarizes the approaches in eachof these four areas. 28
  37. 37. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIESThere are many techniques for dealing with these four aspects. Any or all of the tech-niques may apply to survivable systems. We do not list all of these techniques but insteadcategorize them within the broader aspects.Underlying Table contains the four aspectsof the survivability solution and representative taxonomies of respective strategies. Figure 4.1: A Taxonomy of Strategies Related to Survivability4.1.2 Support of Strategies by the Computing InfrastructureThe rapid growth of the Web and other Internet-based applications has encouraged thegrowth of a computing infrastructure to support distributed applications. While theinitial Web efforts concentrated on information publishing, the application domain hasexpanded to encompass a much wider spectrum of an organization’s computing needs. atechnical focus of this growth has moved from tools such as Web browsers or servers to the 29
  38. 38. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIESdevelopment of a set of Internet-compatible, commercially provided services. Examplesof these services are file, print, transaction, messaging, directory, security, and objectservices such as CORBA (Common Object Request Broker Architecture) and DCOM(Distributed Component Object Model).The commercially available distributed infrastructures are in the early phases of theirdevelopment and do not yet directly support system survivability. Recognition is not asupported service and recovery is indirectly supported by a transaction server. Typically,an organization adopts such an infrastructure to lower costs by using a common infras-tructure for intranets, extranets, and Internet applications and to simplify applicationdevelopment by capturing the complexity of distributed computing in the infrastructurerather than in each application. Managing user-profile data is an example of a servicethat a distributed infrastructure can assume. One general requirement of system surviv-ability is to provide user authentication and manage the authority given to that user fordata and systems access. Authentication can be implemented using passwords and au-thorizations that are validated by access-control lists. However, in many existing systems,such as database applications, access-control lists are maintained by the application.When system users, data, and applications are geographically distributed, the mainte-nance of user-profile data in an application is difficult. A shared directory service, whichis part of a distributed infrastructure, can provide the data storage capability and aprotocol such as LDAP (Lightweight Directory Access Protocol) for application accessand replace the application-specific access-control mechanisms. These infrastructure se-curity services can provide the mechanisms for user authentication such as a public keyinterface, mechanisms to describe access control, and the means to define a security pol-icy. The use of shared services for user authentication and authorization should reduceapplication and overall system complexity as well as provide the means to define an or-ganizational security policy. When this strategy is implemented, the system architectureis constrained by the infrastructure-supplied services and the protocols supported. Forexample, a survivability strategy may be to exchange a primary service with an alter-nate implementation of that service if the primary service has been compromised. Atthis stage of infrastructure deployment there is some interoperability supported amongservices provided by different vendors, however, there is also significant integration of 30
  39. 39. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIESservices that makes it difficult or impossible to replace a service, such as a directory ser-vice, with one from a different vendor. Using shared directory services also raises generalsurvivability issues. A widely used infrastructure should develop a robust set of services.However, their wide use develops a large and knowledgeable intruder community and awide dissemination of information about system vulnerabilities and security solutions. Acompromised or inaccessible directory can affect multiple applications and multiple sites. An essential part of providing system survivability is establishing operationaland administrative procedures for system directories so that system administrators canmonitor service and provide recovery.The design tradeoff is that implementing monitoringand recovery procedures is less costly using shared components than using an application-specific architecture. Infrastructure services provide generic support for replication andmaintenance of consistency across distributed sites. However, achieving overall missionsurvivability requires not only understanding the impact of compromised access controldata and of the design of a recovery policy, but also knowledge of the system’s appli-cations. Commercially available infrastructure products provide general services thatare independent of application domain. Some of the services listed, however, requireapplication-domain knowledge. For example, recognition of an intrusion or maintenanceof trust among nodes requires knowledge of expected behavior. A protocol can ensurethat information is delivered, but cannot validate the appropriateness of the data. Simplerecovery mechanisms can include transaction logs or file restorations; but use of trans-actions, rollback strategies, and more advanced techniques require domain expertise toidentify consistent application states and the impact of compromised data.The successful use of such recovery strategies has been in application-centered products,such as relational database systems that manage relatively homogeneous data structures.Applying such techniques to general distributed-computing systems is more difficult.4.1.3 Survivability Design ObservationsWe can draw a number of observations about the questions and issues that must beaddressed concerning system survivability in networked systems. 31
  40. 40. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIES4.1.4 Survivability Requires Trust MaintenanceAn open issue is how to determine the basis of trust and how an individual node of anetwork contributes to the survivability of the system’s essential services when • Any node can be unreliable or rogue • There is no global view or global control • Nodes cannot completely trust themselves or their neighbors Depending on the application, it may be possible through architectural designor dynamic action within the system to increase the reliability, visibility, and control ofcomponents or the trustworthiness of participants. The only absolute basis for trust main-tenance, however, is the consistency of behavioral feedback from interactions with othernodes and independent verification of claimed actions from nodes not directly involvedin the transactions. A closely related point is the absence of global view and control.If unreliable and untrustworthy components are found to be present in a system, deter-mining whether the critical functions have been compromised may be extremely difficultwithout global view and control. If global view and control are absent (and, in general,they will be) this condition does not preclude effective survivable-network architectures.In particular, it should be possible for individual nodes to generally contribute to thesurvivability goals and at worst not interfere with these goals. Genetic algorithms, forexample, achieve their effects through the collective action of the individual participants.These participants, however, cannot measure overall effectiveness or determine whethertheir contribution is positive. This example suggests that survivability solutions can ex-ist among emergent algorithms that depend on continuous interaction with neighboringnodes but do not require feedback for indications of progress and success. 32
  41. 41. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIES4.1.5 Survivability Analysis Is Protocol-Based Not Topology- BasedAnother implication for networked systems is that the important aspects of their architec-ture from the viewpoint of survivability relate to the conventions and rules of interactionbetween neighboring nodes and that the network topology is largely irrelevant. Thatis, network architectures must be specified, compared, and measured in terms of theirinteractions and not the topology of their interconnection. Survivability requires tradeoffanalysis between the responsibilities of the servers and the clients and between end-to-endprotocol monitoring by the application and general protocol monitoring provided by theinfrastructure. For such a recovery strategy, the application level may be the appropri-ate level in which to analyze application-state and user behavior and select appropriaterecovery actions.4.1.6 Survivability Is Emergent and StochasticSurvivability goals are emergent properties that are desired for the systems as a whole,but do not necessarily prevail for individual nodes of the system. This approach contrastswith traditional system designs in which specialized functions or properties are assuredfor particular nodes and the composition of the system must ensure that those propertiesand functional capabilities are preserved for the system as a whole. For survivability, wemust achieve system-wide properties that typically do not exist in individual nodes. Asurvivable system must ensure that desired survivability properties emerge from the in-teractions among the components in the construction of reliable systems from unreliablecomponents.Survivability is inherently stochastic. If survivability properties are emergent, they arepresent only when the number of contributing component nodes of a system is suffi-ciently large. If the number or arrangement of nodes falls below a critical threshold, theattendant survivability property fails. An example of this type of critical survivabilityproperty is connectivity in a communications system. You can design the architecture of 33
  42. 42. SURVIVABILITY : DESIGN AND IMPLEMENTATION STRATEGIESthe system to maximize the number of paths between any two nodes; but if enough linksare compromised to partition the network, communication between arbitrary nodes willno longer succeed. Thus, survivability properties, algorithms, and architectures shouldbe specified, viewed, and assessed to determine the probability of their success undergiven conditions of use and not determined as discrete quantities.4.1.7 Survivability Requires a Management ComponentThe design of a survivable system also includes management operations and adminis-tration. Poor system administration is a frequent source of vulnerabilities at centrallyadministered sites. In unbounded network systems, system administration must be coor-dinated across multiple sites. Existing system administration procedures typically assumea bounded environment and full administrative control over the required services. Thecomplexity of infrastructure and the use of services outside an organization’s immediatecontrol require expanding the administrative services and providing a monitoring func-tion as part of the infrastructure. 34
  43. 43. Chapter 5STRATEGIES TO IMPROVENETWORK SURVIVABILITYTechniques to improve network survivability can be classified into three categories:1.Prevention : improving component and system reliability(fault tolerant hardware)2.Network design and capacity allocation : placing sufficient diversity and capacity inthe network topology.3.Traffic management and restoration : direct the network load such that a failure has aminimum impact on the network. The ”ideal” survivability goal is to make a network failure imperceptible to thenetwork users by providing service continuity and minimizing network congestion.5.1 PREVENTION TECHNIQUESPrevention techniques focus primarily on improving component and system reliabili-ties.Some examples are the use of fault-tolerant hardware architechturesin switch de-sign,provision for backup power supplies,use of frequency hopped spread spectrum tech-niques to prevent jamming in military radio networrks and so on. 35
  44. 44. STRATEGIES TO IMPROVE NETWORK SURVIVABILITY5.2 NETWORK DESIGN AND CAPACITY ALLO- CATIONNetwork design techniques try to use survivability strategies in the design phase to elimi-nate the effects of system level failures such as link or node failures on the network.Placingsufficient capacity in the network topology can reduce traffic loss effect on the network inthe presence of a failure.Spare capacity allocation(SCA) ensures enough spare capacityfor the physical network or virtual network to recover from a failure via traffic rerout-ing.The problem can be stated as how much spare capacity should be provisioned andwhere it should be located in order to minimize the impact of link or node failure on thenetwork. Based on when spare resources for backup paths are reserved,spare capacity al-location can be done in two ways:1.Pre-planned : 1+1 DP,1:1 DP (DP-Diverse Protection)2.Dynamic : Dynamic methods try to allocate the spare resources when the failurehappens.Example- 1:N DP5.3 TRAFFIC MANAGEMENT AND RESTORA- TIONRestoration strategy specifies the responding action when a failure happens in a network.The restoration steps are given in following figure. 36
  45. 45. STRATEGIES TO IMPROVE NETWORK SURVIVABILITY Figure 5.1: Restoration Steps 37
  47. 47. Chapter 6RESEARCH DIRECTIONSResearch Summary There is a number of promising research areas in survivable systems. The plansfor the Survivable Network Technology team at the SEI include : • Adapting and developing architectural description techniques to adequately de- scribe large-scale distributed systems with survivability attribute. • Representing intruder environments through intruder usage models. • Creating an analysis method to evaluate survivability as a global emergent property from architectural specification. • Refining the analysis technology and instruments through pilot tests of real dis- tributed systems. 39
  48. 48. Chapter 7CONCLUSION AND FUTURESCOPESecurity requirements are best refined in parallel with the system operations and designin a spiral-type development process. Considering the possible avenues of attack duringthis process, i.e., making the process intrusion-aware, is critical to ensuring sufficientprotection against and recovery from malicious attack. The methodological requirementsdescribed above, therefore, apply to methods for engineering security requirements. At-tack trees, and the use of attack patterns for reuse, help to achieve these requirements.They organize related intrusion scenarios in a compact way that relates back to the sur-vivability of the enterprise mission. Attack trees allow the refinement of attacks to alevel of detail chosen by the developer. The developer is free to explore certain attackpaths in more depth than others while still being able to generate intrusion scenarios thatmake sense. Refining the leaves of the attack tree simply generates new leaves resultingin intrusion scenarios at the new lower level of abstraction. An attack pattern provides a structure to encode expert security knowledge forreuse. In addition, asking resistance, recognition, and recovery questions at attack treenodes may suggest improvements to both requirements and design. Attack trees providea powerful mechanism to document the multitude of diverse types of attacks, to abstract 40
  49. 49. CONCLUSION AND FUTURE SCOPEfrom intrusion details as a buffer against attack volatility, and to suggest improvementsto requirements and design. They are, however, only a relatively small part of the answeras to how to use intrusion scenarios to improve security requirements engineering. Thelack of accurate adversary models and risk analysis methods obstructs the progress onthis front. A rich attack pattern library populated with attack patterns at the right levelof abstraction is needed to build enterprise attack trees more systematically. Finally, thelack of robust resistance, recognition, and recovery countermeasures hampers our abilityto improve designs and requirements. Overcoming these obstacles will require a trulyinterdisciplinary effort. 41
  50. 50. Bibliography[1] Survivability Analysis Framework [By Robert J. Ellison and Carol Woody] Year:June 2010[2] SURVIVABLE NETWORK SYSTEMS:ITS ACHIEVEMENTS AND FUTURE DI- RECTIONS [By M.Keshtgary(Ph.D) and A.H Jahangir(Ph.D)] Year:July/December 2007[3] Survivable Networks [By Sundeep Selvaraj Pundamale] Year:January 2005[4] The Survivability of Network Systems: An Empirical Analysis [By Soumyo D. Moitra and Suresh L. Konda] Year: December 2000[5] A Case Study in Survivable Network System Analysis [By R. J. Ellison ,R. C. Linger ,T. Longstaff and N. R. Mead] Year:September 1998 42