Writing Secure Programs - PowerPoint PPT Presentation

About This Presentation
Title:

Writing Secure Programs

Description:

Defensive driving!! Program Security. CSCE 522 - Farkas/Eastman - Fall 2005. 29. Code Examination ... Learn from mistakes. Keep track of mistakes! ... – PowerPoint PPT presentation

Number of Views:22
Avg rating:3.0/5.0
Slides: 36
Provided by: far1
Learn more at: https://cse.sc.edu
Category:

less

Transcript and Presenter's Notes

Title: Writing Secure Programs


1
Writing Secure Programs
2
Program Flaws
  • Taxonomy of flaws
  • how (genesis)
  • when (time)
  • where (location)
  • the flaw was introduced into the system

3
Security Flaws by Genesis
  • Genesis
  • Intentional
  • Inadvertent

4
Intentional Genesis
  • Malicious Trojan Horse, Trapdoor, Logic Bomb,
    covert channels
  • Non-malicious

5
Inadvertent Genesis
  • Validation error
  • Domain error
  • Serialization error
  • Identification/authentication error
  • Other error

6
Program Security Topics Today
  • Faults, flaws, and failures (Terminology)
  • Nonmalicious program errors
  • Covert channels
  • Controls against program threats

7
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
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
Nonmalicious Program Errors
  • Buffer overflows
  • Incomplete mediation
  • Time-of-check to time-of-use errors

10
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
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
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
Incomplete Mediation Example
  • Things.com
  • Customer order returned to company system as url
  • http//www.things.com/. . . total205
  • User changes total to 25
  • Real (unidentified) company

14
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
Indirect Information Flow Channels
  • Covert channels unintended channels of
    communication
  • Inference channels determining sensitive data
    using nonsensitive data
  • A kind of covert channel

16
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
Covert Channel
  • Timing Channel based on system times
  • Storage channels not time related communication
  • Can be turned into each other

18
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
Covert Channels
  • Noise
  • Synchronization
  • Protection (user state, system state)
  • Removal
  • Slow down
  • Audit

20
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
Inference Channels
  • Non-sensitive
  • information

Sensitive Information

Meta-data

22
Inference Channels
  • Statistical Database Inferences
  • General Purpose Database Inferences
  • Will return to inference channels later in course

23
Controls Against Program Threats
  • Good software engineering
  • Applications
  • Systems programs
  • Good project management
  • Good system management
  • No silver bullet

24
Developmental Controls
  • Modularity, encapsulation, and information hiding
  • Peer reviews
  • Hazard analysis
  • Testing
  • Good design
  • Prediction
  • Static analysis
  • Configuration management
  • Analysis of mistakes

25
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
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
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
Good Design
  • Concepts addressed here are fault detection and
    fault tolerance
  • Passive vs. active fault detection
  • Fault tolerance retry, correct, restore
  • Defensive driving!!

29
Code Examination
  • Static analysis
  • Proofs of program correctness

30
Static Analysis
  • Control flow structure
  • Data structure
  • Data flow structure

31
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
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 didnt do it this way

33
Operating System Controls
  • Trusted software
  • Mutual suspicion
  • Confinement
  • Access logs
  • More later

34
Administrative Controls
  • Standards of program development
  • Security audits
  • Separation of duties
  • More later

35
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
Write a Comment
User Comments (0)
About PowerShow.com