1 / 19

Building Secure Software

Building Secure Software. Kim Tracy Northeastern Illinois University, CIO IEEE Chicago Section Tech Conference 08 Nov 2012, Argonne NL. Outline. Background Philosophy of secure software Overview of approach Details: t echniques at each stage Summary Resources. My Background.

elana
Download Presentation

Building Secure Software

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. Building Secure Software Kim Tracy Northeastern Illinois University, CIO IEEE Chicago Section Tech Conference 08 Nov 2012, Argonne NL

  2. Outline • Background • Philosophy of secure software • Overview of approach • Details: techniques at each stage • Summary • Resources

  3. My Background • Teaching Computer Security since around 1992 • Teaching secure software now • Various security software projects at Bell Labs

  4. Protecting “CIA” Defining Security (for data) Protecting Integrity Protecting Confidentiality Assets (HW/SW/Data) Data Protecting Availability Pfleeger’s notation for information security

  5. Philosophy of Secure Software

  6. Tools and Techniques • Software development methodologies are split into distinct functions/phases • Various tools and techniques apply to each phase • This presentation groups these tools by generic phase of SDLC development • i.e. it does not imply a particular development model or method and can be applied to Agile, Evolutionary, etc. • Security early in process (requirements and design) is critical

  7. Overview

  8. Requirements • Risk analysis should be done to identify important risks • Security policies should drive security requirements • E.g. “No unauthorized users” -> every user must login • Reliability requirements important • Other bugs/un-documented behavior can be exploited; e.g. Backdoors

  9. Design • A design with security in mind can better enforce security requires • Difficult to do security after the fact • There are several security models for enforcing secrecy and integrity (e.g. Bell-LaPadula and Biba) • Security protocols for common security tasks • Voting, contract-signing, etc. • Security Design Principles and Patterns

  10. Design Principles (Viega/McGraw) • Secure the weakest link • Defense in depth • Fail securely • Least privilege • Compartmentalize • Keep it simple • Promote privacy • Hiding secrets is hard

  11. Design Principles (cntd.) • Be reluctant to trust • Use security community resources • Also, Use security design patterns • Approaches to common security issues • Yoder & Barcalow classic paper, “Architectural Patterns for Enabling Application Security,” 1997, http://www.idi.ntnu.no/emner/tdt4237/2007/yoder.pdf • Schumacher, et al, Security Patterns, Integrating Security and Systems Engineering, 2006, Wiley, ISBN 0-470-85884-2

  12. Implementation • Code security reviews • Can be very effective • Require security professionals and time • Code analysis tools • Static analysis • Tools to scan and analysis code base for errors/problems • Dynamic analysis • Tools to analyze running system and determine problems or find problems

  13. Unit Testing • Code analysis tools can help • Find common mistakes such as using unsafe function calls which may be subject to buffer overflows • Security Testing tools • Such as “Fuzzing” – taking valid input, making slight changes, and testing

  14. Integration • External code and libraries a serious issue • Want to reuse code • Difficult to test and trust • Can use automated tools to find easy problems • Ideally, would do security code inspection • Too expensive in most cases • Rigorous testing at this and other stages

  15. System Test • Use security-specific testing: • Scanners (may find issues in configuration, other components) • Penetration testing tools to test against common attacks • Stress testing and dynamic testers • Test removal of files, resources, unexpected error conditions • Rigorous system testing against requirements

  16. Deployment & Operations • Secure updates • Trusting source of updates • Not introducing new bugs to exploit • Preventing system from being vulnerable • During update • Updates must be from trusted source • Secure operations

  17. Summary

  18. Some resources to get started • Viega & McGraw, Building Secure Software, ISBN 0-201-72152-X • Whittaker & Thompson, How to Break Software Security, ISBN 0-321-19433-0. • Andrews and Whittaker, How to Break Web Software, ISBN 0-321-36944-0 • Chess and West, Secure Programming with Static Analysis, ISBN 0-321-42477-8 • David Wheeler, Secure Programming for Linux and UNIX HOWTO—Creating Secure Software, free at: www.dhwheeler.com along with many other security resources. • Ken Thompson, “Reflections on Trusting Trust,” ACM Turing Award Lecture, ftp://cm.bell-labs.com/cm/cs/who/ken/trust.html.

More Related