DOC PREVIEW
UI CS 448 - Introduction

This preview shows page 1-2-3-4-5 out of 14 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

UI CS 448 - Introduction

Download Introduction
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Introduction and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Introduction 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?