1 / 17

CSCE 548 Building Secure Software

This lecture provides an introduction to software security, highlighting its importance in our increasingly digital lives. We will discuss key concepts, including the principles of confidentiality, integrity, and availability, alongside the complexities introduced by modern software. Through case studies and news articles, we will explore current security vulnerabilities and common pitfalls in software development. Participants will learn about integrating security throughout the Software Development Life Cycle (SDLC) and the necessity of risk management in achieving robust security practices.

moana-herring
Download Presentation

CSCE 548 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. CSCE 548 Building Secure Software

  2. Reading • This lecture: • McGraw: Chapter 1 • Recommended: • CyberInsecurity: The Cost of Monopoly, http://cryptome.org/cyberinsecurity.htm • Next lecture: • McGraw: Chapter 2

  3. Why do we need software security? • Software is essential in most every aspect of our life • Current news (recommended): • Kelly Jackson Higgins, Dark Reading, SQL Injection Hack Infects 1 Million Web Pages, InformationWeek, January 5, 2012, http://www.informationweek.com/news/security/attacks/232301355 • Gregg Keizer, Adobe plugs 6 critical holes in Reader, Computerworld, January 11, 2012, http://www.computerworld.com/s/article/9223344/Adobe_plugs_6_critical_holes_in_Reader • Gregg Keizer, Microsoft patches critical Windows drive-by bug, Computerworld, January 10, 2012, http://www.computerworld.com/s/article/9223326/Microsoft_patches_critical_Windows_drive_by_bug

  4. How to address software security? • Do not address at all • Ad-hoc evaluation • Add security features after the fact • Identify security vulnerabilities • Test security level • Incorporate security throughout of SDLC

  5. This Course • Not a software engineering course • Understand basic security concepts and their impact • Introduce systematic security design and development along project management • Best practices

  6. Security Objectives • Confidentiality: prevent/detect/deter improper disclosure of information • Integrity: prevent/detect/deter improper modification of information • Availability: prevent/detect/deter improper denial of access to services Which objective SW security addresses?

  7. Software Security • NOT security software! • Engineering software so that it continues to function correctly under malicious attack • Functional requirements • Non-functional requirements (e.g., security)

  8. Why Software? • Increased complexity of software product • Increased connectivity • Increased extensibility Increased risk of security violations!

  9. Security Problems • Defects: implementation and design vulnerabilities • Bug: implementation-level vulnerabilities (Low-level or mid-level) • Static analysis tool • Flaw: subtle, not so easy to detect problems • Manual analysis • Automated tools (for some but not design level) • Risk: probability x impact

  10. Application vs. Software Security • Usually refers to security after the software is built • Adding more code does not make a faulty software correct • Sandboxing • Network-centric approach • Application security testing: badness-ometer Who Knows Deep Trouble

  11. Three Pillars of Software Security • Risk Management • Software Security Touchpoints • Knowledge

  12. Risk Management • How much effort to invest in security • Consequences of security breaches • Acceptable-level of security • Tracking and mitigating risk throughout the full SDLC

  13. Touchpoints • System-wide activity: from design to testing and feedback • Focus on security from ground up • Touchpoints: • Code review • Architectural risk analysis • Penetration testing • Risk-based security testing • Abuse cases • Security requiremetns • Security operations

  14. Knowledge • Gathering, encapsulating, and sharing security knowledge • Knowledge catalogs: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, historical risks • Knowledge categories: • Prescriptive knowledge • Diagnostic knowledge • Historical knowledge • Applied along the SDLC

  15. Security Engineering • Reduce the need for reactive technologies (e.g., intrusion detection) by safer products  Understand software • Need for: • Software developers • Operations people • Administrators • Users • Executives

  16. Start with Software Developers!

  17. Next Class • Risk Management

More Related