Incorporating Service Degradations into a Security Plan

1. Incorporating Service Degradations into a Security Plan Gertrude N. Levine, Fairleigh Dickinson University Track 1:Refereed Papers Session: Reliability, Resilience & Security, #1

2. Issues to be Discussed • What is a service degradation? • How do service degradations support security goals? • How is a Model that was developed for resource services appropriate for security? • How do we use a Template to incorporate service degradations into security mechanisms? • How do we standardize the Template?

3. What is Resource Degradation? • Resource states are: • Fully operable (able to render full services) • Producing • Idle (Listening) • Degraded (operable but able to render only partial services) • Producing or idle • Inoperable (failed; unable to render service) • Degraded mode is a resource state in which either nonessential service units (requests) are abandoned or else service units provide lesser functionality or quality. • Resources in degraded mode render partial services that are tolerable according to requirements. • Example: congested roads (delay degradation) • Example: pitted roads (sensory degradation)

4. What is Service Degradation? • Service degradation is partial servicerendered by resources operating in degraded mode. We identify four types: • Metric degradation • Examples: delay degradation, decreased throughput • Dependency degradation • Example: the deactivation of a non-essential resource or service such as a USB port • Sensory degradation (in particular, data degradation) • Examples: distorted images,, pitted roads, CAPTCHA (Completely Automated Turing test to tell Computers and Humans Apart). • Priority degradation • Example: installing weaker virus detecting software or corrupted apps

5. Sample Keyboard Degradations Assume that a keyboard’s paint is eroded: • Key values may be difficult to determine, a data degradation. • Keyboard keys may remain usable but cause lowered throughput, a metric degradation. • Keyboard keys can be chosen by touch rather than by sight, a dependency degradation. • Essential keyboard service is delivery of the key’s value. • Identification by sight is nonessential for touch typists. • Using an on-line keyboard to avoid the degraded keys is a priority degradation if the paint on the keys that will be used are not damaged on the real keyboard.

6. Service degradations and security • Are service degradations insidious and injurious for security mechanisms? • Are they useful? • Are they necessary? • Service degradations are an important part of security mechanisms but should be recognized and documented as such to maximize their usefulness.

7. Security • Security is primarily the protection of resources from unauthorized access. • Total protection is not practical, so that security mechanisms are applied at multiple layers. • Security mechanisms (prevention, detection, recovery) incurs costs. • We consider these costs to be service degradations.

8. Service Degradations have Two Major Roles. • They enable service continuation after a fault is activated. • RS232-C has tolerance levels for specified unplanned deviations in voltage levels +/-3 to+/-15 (later broadened to +/-25) • RS232-C has acceptance levels for deviations in USB plug temperatures 21 +/- 4º C • Requirements should be broadened if possible. 2) Service Deviations are monitored for alerts of security violationsand other unplanned events.

9. What are the main goals of information assurance? ISO core goals of information assurance are: Confidentiality Integrity Availability We investigate how service degradations assist security mechanisms in obtaining these goals at different layers of a computer system.

10. Confidentiality “assuring that information is accessible only to those authorized to have access” [ISO] • Restrict physical access to system • Locks; cabinets; fiber cables • Identification and authentication mechanisms • These mechanisms cause delay and cost metric degradations; if bulky, they can cause sensory degradation • Restrict access to data • Authorization mechanisms • Determine authorization based on a need-to-know basis • Limit misuse of granted authority • Install anti-malware software

11. Confidentiality (continued) • Prevent unauthorized output of data past system boundary1 • Reverse firewalls • Disable nonessential services and close nonessential ports. • Restrict BYOD (Bring Your Own Device) • The above cause dependency degradations • Prevent unauthorized extraction of information from data • Encryption • Friendly jamming • The above cause data degradation • Prevent unauthorized utilization of extracted information • Crime Reduction through Product Design • Obsolescence built into the product causing metric degradation

12. Integrity “guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity”[ISO] • Prevent unauthorized access to system and data • Prevent unauthorized output of data from the system • Prevent extraction of information from data • Install anti-malware software • Prevent unauthorized input of data into the system • Prevent input using firewalls, a dependency degradation • Utilize detection and recovery mechanisms • Monitor CRC, ICV, or similar mechanisms to detect data degradation • Replace failed resources, perhaps causing sensory (noisier) ,metric (slower), dependency (abandoned service) and/or priority (wrong choice) degradation.

13. Availability “ensuring timely and reliable access to and use of information” [ISO] • Intrinsic availability is commonly defined by the reliability community asMTBF/ (MTBF + MTTR). • Operational availability has been defined as Uptime/ (Uptime + Downtime) • Endogenous availability is measured by the loss of throughput following failure.2 • All are measures of metric degradation

14. Availability • Security, Reliability, and Stability requirements • Prevent/ control unauthorized access to system • Control authorized accesses • Concurrent accesses can cause inconsistent resource states; dead states; starvation • Bursts of accesses can cause instability and/or congestion • Controlling mechanisms are similar to DDoS control. • Traffic patterns are non-uniform and unpredictable for security analysis. • Large amounts of unauthorized traffic mixed with authorized traffic are particularly problematic for security systems.

15. Availability • Limit accesses to and within the system • Control traffic bursts detected by monitoring throughput, response time, data patterns • Apply throttling mechanisms (based on monitoring metric degradations) • Scrub unauthorized traffic (based on heuristics of degraded data patterns) • Develop recovery mechanisms • Provide redundant dependencies of data and hardware, allowing for dependency degradations

16. The Model A Model developed for other applications is appropriate for service degradations. We specify 3 dimensions for the Model. The Layers of the System: M The Resources of the System: R The Units of Time: T

17. M: the Layers of the System We specify 5 layers: Execution Layer Execution Buffer Layer Independent Delivery Layer Development Buffer Layer Development Layer Most systems have more layers. Some have less. Some layers are further divided into sublayers. The layer ordering is specified with “>” Execution Layer > Execution Buffer Layer > Independent Delivery Layer > Development Buffer Layer > Development Layer

18. The Request • A request is the smallest unit that requests or renders the service of input or output. • A request is denoted by the tuple (m, r, t) mεM; r ε R; tε T • Each request is assigned attributes such as • Data values, constraints and a shared work area • Requests move between layers • User requests request to advance, i.e., move to a layer higher (>) so as to complete service.

19. R: The Resources of the System • R is a set of software and hardware resources composed of requests that render either input or output service. • Requests of reusable resources request to advance to the layer at which they render services and then retreat to their “listening” layer. • Requests of consumable resources are abandoned after rendering services.

20. T: Time units of a computer system • T is a finite, linearly ordered set of discrete units of time. • The length of each unit is the greatest common divisor of the time interval for each request’s input or output.

21. Request Movement

22. Request Movement

23. Request Movement

24. Request Movement

25. Request Movement

26. Request Movement

27. Request Movement

28. Request Movement

29. Request Movement

30. Request Movement

31. Request Movement

32. The Constraints • Requests are synchronized in their movements by constraints. • Dependency constraints • Advancing and Retreating dependency constraints • Events that must occur before a request advances or retreats • Metric constraints • Advancing and Retreating metric constraints • Minimum and maximum number of times at a layer that a request is rescheduled within a given interval • Priority constraints resolve request competition

33. The Computer System A computer system is a quintuple (M, R, T, P, F) where M is a set of ordered layers of requests R is a set of Resources T is a finite set of discrete units of time P is a set of requests bound with constraints F is a function that controls request mapping.

34. The Mapping Function F assigns a relation, gm for each set of requests in each single and composite layer m εM: gm (m, r, t) = (m’, r’, t’), m’> m, if constraints permit (called advancing), else gm (m, r, t) = gm(m, r’, t’), t’> t, if constraints permit (called rescheduling), else gm (m, r, t) = gm (gm’(m’, r’, t’)), m > m’, if constraints permit (called retreating), else gm (m, r, t) = (m, φ, t’), t’> t (called abandoning) φ is a “black hole” – a resource at each layer that renders input service only

35. Maximizing use of Service Degradations • Service Degradations are an important part of security mechanisms at this time. • Their use should be recognized. • They should be standardized and utilized to maximize effectiveness. • A template will be introduced for this purpose.

36. A Template for Service Degradation Structure of the Template • 5 rows (the layers of the Model) • 4 columns (degradation types) • The template on the next slide contains examples of the toleration of degradations • The template on the following slide contains examples of the monitoring of degradations

37. Tolerating Degradations

38. Monitoring degradations

39. What Next? • Hardware engineers conduct fault tolerance analysis to obtain permissible tolerance limits for continued usage of resources. • Software Engineers, specifically security personnel, must conduct a fault tolerance analysis for each vulnerable software resource. • Identify and document services, vulnerabilities. • Identify and document deviation limits.

40. References 1) A. Avizienis, J. Laprie, B. Randell, and C. Landwehr, “Basic concepts and taxonomy for dependable and secure computing,” IEEE Transactions on Dependable and Secure Computing, 1, 1, Jan. - Mar. 2004, pp. 11-33. 2) J. Schryver, J. Nutaro, and M. J. Haire, “Metrics for availability analysis using a discrete event simulation method,” Simulation Modelling Practice and Theory, 21, 2012, pp. 114-122. 3) ISO/IEC. Information technology. Code of practice for information security management, ISO/IEC 17799: 2000(E), Geneva, Switzerland.