CS 5950 6030 Network Security Class 16 F 10 7 05

CS 5950/6030 Network Security Class 16 (F, 10/7/05) Leszek Lilien Department of Computer Science Western Michigan University Based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U. ), Amsterdam, The Netherlands Slides not created by the above authors are © by Leszek T. Lilien, 2005 Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

3. Program Security 3. 1. Secure Programs – Defining & Testing 3. 2. Nonmalicious Program Errors 3. 3. Malicious Code 3. 3. 1. General-Purpose Malicious Code (incl. Viruses) 3. 3. 2. Targeted Malicious Code a. Trapdoors Class 15 2 a. b. Salami attack Covert channels

b. Salami attack - merges bits of seemingly inconsequential data to yield powerful results § § § 3 Old example: interest calculation in a bank: § Fractions of 1 ¢ „shaved off” n accounts and deposited in attacker’s account § Nobody notices/cares if 0. 1 ¢ vanishes § Can accumulate to a large sum Easy target for salami attacks: Computer computations combining large numbers with small numbers § Require rounding and truncation of numbers § Relatively small amounts of error from these op’s are accepted as unavoidable – not checked unless a strong suspicion § Attacker can hide „salami slices” within the error margin

c. Covert Channels (CC) (1) § 4 Outline: i. Covert Channels - Definition and Examples ii. Types of Covert Channels iii. Storage Covert Channels iv. Timing Covert Channels v. Identifying Potential Covert Channels vi. Covert Channels - Conclusions

Class 15 Ended Here 5

3. Program Security 3. 1. Secure Programs – Defining & Testing 3. 2. Nonmalicious Program Errors 3. 3. Malicious Code 3. 3. 1. General-Purpose Malicious Code (incl. Viruses) 3. 3. 2. Targeted Malicious Code a. Trapdoors Class 15 Class 16 6 a. b. Salami attack Covert channels 3. 4. Controls for Security a. Introduction b. Developmental controls for security — PART 1

3. 4. Controls for Security § § 7 How to control security of pgms during their development and maintenance Outline: a. Introduction b. Developmental controls for security c. Operating system controls for security d. Administrative controls for security e. Conclusions

a. Introduction § „Better to prevent than to cure” § § 8 Preventing security flaws § We have seen a lot of possible security flaws § How to prevent (some of) them? § Software engineering concentrates on developing and maintaining quality s/w § We’ll take a look at some techniques useful specifically for developing/ maintaining secure s/w Three types of controls for security (against pgm flaws): 1) Developmental controls 2) OS controls 3) Administrative controls

b. Developmental Controls for Security (1) § Nature of s/w development § Collaborative effort § Team of developers, each involved in 1 of stages: § § § § § 9 Requirement specification § Regular req. specs: „do X” § Security req. specs: „do X and nothing more” Design Implementation Testing Documenting at each stage Reviewing at each stage Managing system development thru all stages Maintaining deployed system (updates, patches, new versions, etc. ) Both product and process contribute to overall quality — incl. security dimension of quality

Developmental Controls for Security (2) § Fundamental principles of s/w engineering 1) Modularity 2) Encapsulation 3) Info hiding 1) Modularity § Modules should be: § Single-purpose - logically/functionally § Small - for a human to grasp § Simple - for a human to grasp § Independent – high cohesion, low coupling § § § 10 High cohesion – highly focused on (single) purpose Low coupling – free from interference from other modules Modularity should improve correctness § Fewer flaws => better security

Developmental Controls for Security (3) 2) Encapsulation § Minimizing info sharing with other modules => Limited interfaces reduce # of covert channels § Well documented interfaces § „Hiding what should be hidden and showing what should be visible. ” 3) Information hiding § § § 11 Module is a black box § Well defined function and I/O Easy to know what module does but not how it does it Reduces complexity, interactions, covert channels, . . . => better security

Developmental Controls for Security (4) § Techniques for building solid software 1) Peer reviews 2) Hazard analysis 3) Testing 4) Good design 5) Risk prediction & mangement 6) Static analysis 7) Configuration management 8) Additional developmental controls . . . all discussed below. . . 12 [cf. B. Endicott-Popovsky]

Developmental Controls for Security (5) 1) Peer reviews - three types n Reviews n Informal n Team of reviewers n Gain consensus on solutions before development n Walk-throughs n Developer walks team through code/document n Discover flaws in a single design document n Inspection n Formalized and detailed n Statistical measures used n 13 Various types of peer reviews can be highly effective [cf. B. Endicott-Popovsky]

Developmental Controls for Security (6) 2) Hazard analysis = systematic techniques to expose potentially hazardous system states, incl. security vulnerabilities n n 14 Components of HA n Hazard lists n What-if scenarios – identifies non-obvious hazards n System-wide view (not just code) n Begins Day 1 n Continues throughout SDLC (= s/w dev’t life cycle) Techniques n HAZOP – hazard and operability studies n FMEA – failure modees and effects analysis n FTA – fault tree analysis [cf. B. Endicott-Popovsky]

Developmental Controls for Security (7) 3) Testing – phases: n Module/component/unit testing of indiv. modules n Integration testing of interacting (sub)system modules n (System) function testing checking against requirement specs n (System) performance testing n (System) acceptance testing – with customer against customer’s requirements — on seller’s or customer’s premises n (System) installation testing after installation on customer’s system n n Regression testing after updates/changes to s/w Types of testing n Black Box testing – testers can’t examine code n White Box / Clear box testing – testers can examine design and code, can see inside modules/system 15

Developmental Controls for Security (8) 4) Good design n Good design uses: i. Modularity / encapsulation / info hiding ii. Fault tolerance iii. Consistent failure handling policies iv. Design rationale and history v. Design patterns i. Using modularity / encapsulation / info hiding - as discussed above 16

Developmental Controls for Security (9 a) 4) Good design – cont. 1 a ii. Using fault tolerance for reliability and security n System tolerates component failures n System more reliable than any of its components n n Different than for security, where system is as secure as its weakest component [cf. B. Endicott-Popovsky] Fault-tolerant approach: n Anticipate faults (car: anticipate having a flat tire) n Active fault detection rather than pasive fault detection (e. g. , by use of mutual suspicion: active input data checking) n n n 17 Use redundancy Isolate damage Minimize disruption (car: have a spare tire) (car: replace flat tire, continue your trip)

Developmental Controls for Security (9 b) 4) Good design – cont. 1 b n n Example 1: Majority voting (using h/w redundancy) n 3 processor running the same s/w n E. g. , in a spaceship n Result accepted if results of 2 processors agree Example 2: Recovery Block (using s/w redundancy) Primary Code e. g. , Quick Sort Secondary Code e. g. , Bubble Sort Acceptance Test 18 Quick Sort – – new code (faster) Bubble Sort – – well-tested code

Developmental Controls for Security (10) 4) Good design – cont. 2 iii. Using consistent failure handling policies n Each failure handled by one of 3 ways: n Retrying n n Correcting n n 19 Restore previous state, correct sth, run service using the same code as before Reporting n n Restore previous state, redo service using different „path” n E. g. , use secondary code instead of primary code Restore previous state, report failure to error handler, don’t rerun service Example — How fault-tolerance enhances security n If security fault destroys important data (availability in CIA), use f-t to revert to backup data set

Developmental Controls for Security (11) 4) Good design – cont. 3 iv. Using design rationale and history n Knowing it (incl. knowing design rationale and history for security mechanisms) helps developers modifying or maintaining system v. Using design patterns n 20 Knowing it enables looking for patterns showing what works best in which situation

Developmental Controls for Security (12) n Value of Good Design n Easy maintenance n Understandability n Reuse n Correctness n Better testing => translates into (saving) BIG bucks ! 21 [cf. B. Endicott-Popovsky]

Developmental Controls for Security (13) 5) Risk prediction & management n Predict and manage risks involved in system development and deployment n Make plans to handle unwelcome events should they occur n Risk prediction/mgmt are esp. important for security n Bec. unwelcome and rare events can have security consequences n Risk prediction/mgmt helps to select proper security controls (e. g. , proportional to risk) 22

Developmental Controls for Security (14) 6) Static analysis n Before system is up and running, examine its design and code to locate security flaws n n More than peer review Examines n Control flow structure (sequence in which instructions are executed, incl. iterations and loops) Data flow structure (trail of data) n Data structures Automated tools available n n 23 [cf. B. Endicott-Popovsky]

Developmental Controls for Security (15) 7) Configuration management = process of controling system modifications during development and maintenance n Offers security benefits by scrutinizing new/changed code n Problems with system modifications n One change interefering with other change n n Proliferation of different versions and releases n n n 24 E. g. , neutralizing it Older and newer For different platforms For different application environments (and/or customers categories)

End of Class 16 25