1 Introduction Firewall mentality – on the Internet the cornerstone of security is the notion of a firewall – a logically bounded system within a physically unbounded one – bounded-system thinking within unbounded domains can lead to security designs and architectures that are fundamentally flawed from a survivability perspective – firewalls are state of the art for security systems but not for survivable systems – firewalls are passive and implement filter functions – how “managed” is the firewall, i.e. is it configured effectively? » Danger: False sense of security! 1 Sequence 4 © A.K. Krings 2011 Introduction Defining Requirements for Survivable Systems – Survivability requirements depend on main issues: » system scope » criticality » consequences of failure and interruption of service – In addition to software functionality, survivability must address requirements for » software usage, » development, » operation, » evolution. 2 Sequence 4 © A.K. Krings 20112 Introduction Defining Requirements for Survivable Systems (cont) – New paradigm characterized by: » distributed services » distributed logic » distributed code » distributed hardware » shared communications and routing infrastructure » diminished trust » lack of unified administrative control – Paradigms formidable effort for software engineering research » traditional computer security measures are augmented by comprehensive system survivability strategies 3 Sequence 4 © A.K. Krings 2011 Introduction Survivability Requirements – we now discuss each of the following topics briefly: » System/Survivability Requirements » Usage/Intrusion Requirements » Development Requirements » Operations Requirements » Evolution Requirements 4 Sequence 4 © A.K. Krings 20113 Introduction CMU/SEI-97-TR-013 5 Sequence 4 © A.K. Krings 2011 Introduction Survivability Requirements – refer to capability of system to » deliver essential services in the presence of intrusions » recover full services – system should be organized into essential and non-essential services » essential services must be maintained even during successful intrusion may have different levels, – “prioritize by severity and duration of intrusion” must be augmented with survivability requirements » non-essential services are recovered after intrusion has been handled » in this paper the view is “binary”, however that must not be the case 6 Sequence 4 © A.K. Krings 20114 Introduction System Requirements – describe traditional user functions a system must provide – example: network management system must provide » monitoring of system, performance adjustments, etc. – may include non-functional aspects » timing, performance, reliability 7 Sequence 4 © A.K. Krings 2011 Introduction Survivability Requirements (cont.) – COTS components not developed with survivability objective » may provide both essential and non-essential services » may require functional requirements for isolation and control (using wrappers and filters) – survivability imposes new requirements on system » resistance to, recognition of and recovery from malicious acts » adaptation and evolution 8 Sequence 4 © A.K. Krings 20115 Introduction CMU/SEI-97-TR-013 9 Sequence 4 © A.K. Krings 2011 Introduction System/Survivability Requirements (cont.) – term emergent behavior requirements at network level » underlines that requirements are not associated with a particular node, but emerge from the collective behavior » issue is survivability of the overall network capability e.g., message routing in the presents of topology degradation – capability of adapting » behavior, function, resource allocation » resources may be shifted from non-essential to essential services 10 Sequence 4 © A.K. Krings 20116 Introduction System/Survivability Requirements (cont.) – survivability requirements may vary greatly » small systems may only have non-essential services (recovery in hours) » large systems (large networks) may have core set of essential services, automated intrusion detection (recovery in minutes) » embedded control systems may require essential services in real-time (recovery in milliseconds) – no free lunch » attainment and maintenance of survivability consumes resources in development, operation, evolution » cost and risk analysis to manage resources wisely 11 Sequence 4 © A.K. Krings 2011 Introduction Usage/Intrusion Requirements – testing must demonstrate » correct performance of essential and non-essential system services » survivability of essential services under intrusion » “How does one do this?” – but this depends totally on the system’s use » use of usage scenarios derived from usage models – usage models » are developed from usage requirements » they specify usage environments and scenarios of system use – usage requirements for essential and non-essential services must be defined in parallel with system and survivability requirements 12 Sequence 4 © A.K. Krings 20117 Introduction Usage/Intrusion Requirements (cont.) – relationship between legitimate and intrusion use – intruder may engage in scenarios beyond legitimate scenarios » but may use legitimate usage CMU/SEI-97-TR-013 figure 4 13 Sequence 4 © A.K. Krings 2011 Introduction Development Requirements – stringent requirements on system development and testing practices – inadequate functionality and software errors can have devastating effects (provide opportunities for intrusion) – sound engineering practices are required – this also holds for legacy and COTS software components 14 Sequence 4 © A.K. Krings 20118 Introduction Development Requirements (cont.) – Some example requirements for survivable-system development and testing practices: For some you will say: Yeah right! - How big is the system?!@#$% » Precisely specify the system’s required functions in all possible circumstances of system use. » Verify the correctness of system implementations with respect to the
View Full Document