1 / 14

2011 SANS Top 25 Most Dangerous Software Errors

2011 SANS Top 25 Most Dangerous Software Errors. Category 1: Insecure Interaction Between Components These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems .

moses
Download Presentation

2011 SANS Top 25 Most Dangerous Software Errors

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2011 SANS Top 25 Most Dangerous Software Errors Category 1: Insecure Interaction Between Components These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems. Category 2: Risky Resource Management The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources. Category 3: Porous Defenses The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored. See http://www.sans.org/top25-software-errors/

  2. ACM Review Mallory exploits a bug … … & gains ‘w’ on /u/Bob !

  3. Security via Information Confinement Information may only flow to those with the appropriate clearance and need-to-know.

  4. Information Flow based on: ClearanceLevel c1 <= c2 Top Secret Secret Confidential Unclassified ClearanceLevels {“Unclassified”, “Confidential”, “Secret”, “Top Secret” }

  5. Compartments & Sensitivity Levels Compartment 1 Compartment 2 Compartment 3 Adapted from Pfleeger & Pfleeger, Security in Computing, 4th ed.

  6. Information Flow based on: Need-to-Know d1 d2

  7. Information Flow based on: ClearanceLevel c1 <= c2Need-to-Know d1 d2

  8. Bell-LaPadula Model for Confidentiality • Simple Security Propertyno-read-up rule: a subject can’t read data from an object “above” it. • *-Property no-write-down rule: a subject that can read data in one class can’t write data to a lower class. • Discretionary Security PropertyS can access O only if that access is allowed by the S-O entry of the current ACM

  9. B-P *-Property

  10. Biba Model for Integrity • Simple integrity axiomsubject at one level of integrity may not read an object at a lower integrity level(no read down) • *-integrity axiomsubject at one level of integrity may not write to an object at a higher integrity level.(no write up)

  11. Problems with Biba • How do you assign integrity levels? • What do integrity categories mean? • A high-integrity program is not allowed to read and validate lower-integrity data … but then isn’t that just what those programs should be capable of doing?

  12. Bye-Bye Biba • Java and ActiveX models of digitally signed code resemble the Biba model … however • They still have no basis for assigning integrity level • Just because company X wrote and signed some code doesn’t mean it’s secure or trustworthy. • Pure Biba not used for much in the last 20 years.

More Related