1. Writing Secure Programs

2. Program Security CSCE 522 - Farkas/Eastman - Fall 20052 Program Flaws Taxonomy of flaws: how (genesis) when (time) where (location) the flaw was introduced into the system

3. Program Security CSCE 522 - Farkas/Eastman - Fall 20053 Security Flaws by Genesis Genesis Intentional Inadvertent

4. Program Security CSCE 522 - Farkas/Eastman - Fall 20054 Intentional Genesis Malicious: Trojan Horse, Trapdoor, Logic Bomb, covert channels Non-malicious

5. Program Security CSCE 522 - Farkas/Eastman - Fall 20055 Inadvertent Genesis Validation error Domain error Serialization error Identification/authentication error Other error

6. Program Security CSCE 522 - Farkas/Eastman - Fall 20056 Program Security Topics Today Faults, flaws, and failures (Terminology) Nonmalicious program errors Covert channels Controls against program threats

7. Program Security CSCE 522 - Farkas/Eastman - Fall 20057 Security Terminology Terms used in software engineering and security communities not consistent Vulnerability, threat, attack, control, flaw A threat is blocked by control of a vulnerability A flaw may result in a vulnerability An attack exploits a vulnerability

8. Program Security CSCE 522 - Farkas/Eastman - Fall 20058 IEEE Standard 729 for Software “Bugs” Error – Human mistake Fault – Incorrect code Failure – Incorrect system behavior Errors may (or may not) cause faults One error may generate many faults Faults may (or may not) cause failures

9. Program Security CSCE 522 - Farkas/Eastman - Fall 20059 Nonmalicious Program Errors Buffer overflows Incomplete mediation Time-of-check to time-of-use errors

10. Program Security CSCE 522 - Farkas/Eastman - Fall 200510 Buffer Overflows Probably most publicized class of nonmalicious program errors Result from attempt to write too much data into a buffer without checking size May simply interfere with user program or allow system to be taken over

11. Program Security CSCE 522 - Farkas/Eastman - Fall 200511 Mediation Mediators facilitate communication among two or more parties Mediators attempt to resolve differences Mediation may be final Intermediaries are also “go-betweens” Usage close but not exactly the same in computer security

12. Program Security CSCE 522 - Farkas/Eastman - Fall 200512 Incomplete Mediation Complete mediation – all data accesses handled by an intermediary Required for a trusted computing system Incomplete mediation allows incorrect data into the system, which may not be able to handle it

13. Program Security CSCE 522 - Farkas/Eastman - Fall 200513 Incomplete Mediation Example Things.com Customer order returned to company system as url http://www.things.com/... &total=205 http://www.things.com/ User changes total to 25 Real (unidentified) company

14. Program Security CSCE 522 - Farkas/Eastman - Fall 200514 Time-of-Check to Time-of-Use Errors TOCTTOU Time interval between checking that a data item is valid and actually using it Value changed during that time period Serialization or synchronization flaw Must ensure that check/use is handled as a transaction

15. Program Security CSCE 522 - Farkas/Eastman - Fall 200515 Indirect Information Flow Channels Covert channels – unintended channels of communication Inference channels – determining sensitive data using nonsensitive data A kind of covert channel

16. Program Security CSCE 522 - Farkas/Eastman - Fall 200516 Communication Channels Overt Channel: designed into a system and documented in the user's manual Covert Channel: not documented. Covert channels may be deliberately inserted into a system, but most such channels are accidents of the system design.

17. Program Security CSCE 522 - Farkas/Eastman - Fall 200517 Covert Channel Timing Channel: based on system times Storage channels: not time related communication Can be turned into each other

18. Program Security CSCE 522 - Farkas/Eastman - Fall 200518 Covert Channel Need: Two active participants Encoding schema Example: sender modulates the CPU utilization level with the data stream to be transmitted Sender: repeat get a bit to send if the bit is 1 wait one second (don't use CPU time) else busy wait one second (use CPU time) endif until done

19. Program Security CSCE 522 - Farkas/Eastman - Fall 200519 Covert Channels Noise Synchronization Protection (user state, system state) Removal Slow down Audit

20. Program Security CSCE 522 - Farkas/Eastman - Fall 200520 Wells and Eastman Examined a covert channel involving patterns of access to encrypted database blocks stored as a B-tree Can determine tree structure, given a sufficient access log Can not determine actual data values simply from access log However, given some data values can guess values for others

21. Program Security CSCE 522 - Farkas/Eastman - Fall 200521 Inference Channels + Meta-data Sensitive Information Non-sensitive information =

22. Program Security CSCE 522 - Farkas/Eastman - Fall 200522 Inference Channels Statistical Database Inferences General Purpose Database Inferences Will return to inference channels later in course

23. Program Security CSCE 522 - Farkas/Eastman - Fall 200523 Controls Against Program Threats Good software engineering Applications Systems programs Good project management Good system management No silver bullet

24. Program Security CSCE 522 - Farkas/Eastman - Fall 200524 Developmental Controls Modularity, encapsulation, and information hiding Peer reviews Hazard analysis Testing Good design Prediction Static analysis Configuration management Analysis of mistakes

25. Program Security CSCE 522 - Farkas/Eastman - Fall 200525 Peer Reviews Have been shown to be one of the most effective ways to find and correct software faults Distinguish different kinds of peer review Review (informal) Walk-through (systematic examination of code/documentation) Inspection (use checklist)

26. Program Security CSCE 522 - Farkas/Eastman - Fall 200526 Hazard Analysis Set of systematic techniques to identify and manage potential hazards Form of risk analysis Most effective approaches include HAZOP – Hazard and operability studies FMEA – Failure modes and effects analysis FTA – Fault tree analysis

27. Program Security CSCE 522 - Farkas/Eastman - Fall 200527 Prediction Not clearly separated from hazard analysis Predict the risks involved in building and using the system OCTAVE approach to security involves identifying most important risks and concentrating on those

28. Program Security CSCE 522 - Farkas/Eastman - Fall 200528 Good Design Concepts addressed here are fault detection and fault tolerance Passive vs. active fault detection Fault tolerance – retry, correct, restore Defensive driving!!

29. Program Security CSCE 522 - Farkas/Eastman - Fall 200529 Code Examination Static analysis Proofs of program correctness

30. Program Security CSCE 522 - Farkas/Eastman - Fall 200530 Static Analysis Control flow structure Data structure Data flow structure

31. Program Security CSCE 522 - Farkas/Eastman - Fall 200531 Proofs of Correctness Proving that the program performs exactly as specified is also equivalent to the halting problem (and thus not possible) Program verification – sometimes limited to analysis of preconditions and postconditions Formal methods

32. Program Security CSCE 522 - Farkas/Eastman - Fall 200532 Software Development Practices Learn from mistakes Keep track of mistakes!! Systematic approach to documenting and using information about problems and what was done about them Negative information useful Why we didn’t do it this way

33. Program Security CSCE 522 - Farkas/Eastman - Fall 200533 Operating System Controls Trusted software Mutual suspicion Confinement Access logs More later

34. Program Security CSCE 522 - Farkas/Eastman - Fall 200534 Administrative Controls Standards of program development Security audits Separation of duties More later

35. Program Security CSCE 522 - Farkas/Eastman - Fall 200535 CSCE 548: Building Secure Software Construction of software systems resistant to vulnerabilities and attacks. Cryptographic tools. Language, operating system, and network security. Case studies. Development of best practices through programming assignments Prereq: CSCE 510 or consent of instructor