CSC 1029 Week 03 Secure Software Fundamentals PDF
Document Details
Uploaded by DivineZebra9695
Red Rocks Community College
Tags
Related
- 2 - RANSAQ - Searching Source-Binary Hybrid Code Property Graphs for Vulnerabilities.pdf
- TUP 3er Cuatrimestre: Seguridad Informática y Exportación de Software PDF
- Common Software Vulnerabilities PDF
- Security Principles and OS Security PDF
- CISSP All-in-One Exam Guide: Secure Software Chapter 25 PDF
- CSC 1029 Week 12 Buffer Overflow PDF
Summary
This document is a collection of class notes for a secure software fundamentals course (CSC 1029). It covers various security concepts, common software attacks and vulnerabilities, and strategies for mitigation. The document includes explanations and examples to help students understand the topics.
Full Transcript
CSC 1029 SECURE SOFTWARE FUNDAMENTALS OBJECTIVES AGENDA: WEEK 03 Identify common software 1. Why Software Security vulnerabilities. 2. Software Security & Risk Mana...
CSC 1029 SECURE SOFTWARE FUNDAMENTALS OBJECTIVES AGENDA: WEEK 03 Identify common software 1. Why Software Security vulnerabilities. 2. Software Security & Risk Management Identify what secure programming is and why it is needed 3. What are we protecting 4. Security Policy: CIA Overview of the problems and introduces security terms and 5. Security Trade-Offs concepts 6. Common Software Attacks 7. Secure Software Mitigation Practices Provide insight into why so many vulnerabilities are found in different 8. What is the cost programming languages 9. Software Security Practices Describe security principles, including 10. Terminology the CIA triad. 11. Programming language vulnerabilities 12. TODO & Resources for Help WHY SECURE SOFTWARE Most software systems today contain numerous flaws and bugs that get exploited by attackers. New threats emerge every day. Convenience trumps security measures. Exponential increase in vulnerabilities in software systems. Software security is everybody's job. Programmers have a long history of The easiest way to break system repeating the same security-related security is often to circumvent it mistakes! https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation- rather than defeat it. materials/stevensonhunteralharbikhali.pdf Source unknown - photograph depicted a street (named Konsequenz) in the University Bielefeld, Germany, at lat/long. 52.036818, 8.491467 SOFTWARE SECURITY Software security is the idea of engineering software so that it continues to function correctly under malicious attack. Software Security aims to avoid security vulnerabilities by addressing security from the early stages of software development life cycle. "Security is a risk management. SOFTWARE REQUIREMENTS & MISCONCEPTIONS Software developers tend to describe software requirements in terms of what a system will do when everything goes right The focus has been on functionality Often the assumption is that the system won’t be intentionally abused G. McGraw, Software security: building security in vol. 1: Addison-Wesley Professional, 2006 Some developers consider security only as a set of features For example, “implemented SSL”, “included 128-bit encryption” Security features alone are not sufficient for building secure software Security must be built in as a critical part of the design from beginning to end BUILDING SECURE SOFTWARE Developers need to make explicit tradeoffs when specifying system requirements Tradeoffs between performance and functional security features Obvious features such as authentication and authorization may not be sufficient to stop attackers Security approaches need to put deep in the many-tiered heart of a software system Need to incorporate thinking like an attacker throughout the development process SOFTWARE SECURITY = RISK MANAGEMENT Prevention (proactive) measures to stop breaches of security goals Detection (proactive) measures to detect breaches of security goals Reaction measures to recover assets, repair damage, and persecute (and deter) offenders Multi-layer (in depth) control A software system with access control mechanisms (prevention) should also designed with detection mechanisms. WHAT ARE WE PROTECTING? Data at Rest: data that is stored in Media Data in Transit: data transmitted from one location to another Data in Use: data that is loaded in the computer memory for processing COMMON SOFTWARE ATTACKS Software Vulnerabilities: Sources of Vulnerabilities: Input Validation Homogeneity – sourcing from Buffer overflow open source or common vendors Stack overflow Complexity – needlessly complicated code Command injection Poor design – poor access SQL injection control, etc Dangling pointers Connectivity – increases attack Cross site scripting paths SECURE SOFTWARE MITIGATION PRACTICES Review the Top 10 Secure Coding Practices https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+ Secure+Coding+Practices WHAT IS THE COST OF POOR SOFTWARE QUALITY IN THE U.S.? Review the article and indicate the cost of poor software https://www.syno psys.com/blogs/ software- security/poor- software-quality- costs-us/ SOFTWARE SECURITY PRACTICES Better Software Development a preventive control mechanism Patching a reactive control mechanism. expensive damages can occur before patching. Testing -- detection a proactive control mechanism-detection inherently limited on coverage and depth Auditing (often manual) - detection a proactive control mechanism- detection improvement on automation and quality of audits is needed TERMINOLOGY Defects – implementation vulnerabilities and design vulnerabilities Bugs – implementation-level errors that can be detected and removed Buffer Overflow Flaws – problems at a deep level. They are instantiated int the code and present or absent at design-level Error handing problem Failures – the inability of the software to perform its required function TIOBE INDEX Direct quote from TIOBE: The TIOBE Programming Community index is an indicator of the popularity of programming languages. It is important to note that the TIOBE index is not about the best programming language or the language in CSC 2045 which most lines of code have been written. The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system. INTERPRETED COMPARED TO COMPILED Interpreted languages are easier and quicker to use to develop an application but typically have more overhead and leave more open to attackers Compiled languages are more difficult to develop an application with quickly, but can create a far more secure and efficient binary file COMPARING C AND C++ C is a programming language originally developed for developing the Unix operating system. It is a low-level and powerful language, but it lacks many modern and useful constructs. C++ is a newer language, based on C, that adds many more modern programming language features that make it easier to program than C. C++ maintains all aspects of the C language, while providing new features to programmers that make it easier to write useful and sophisticated programs. C++ makes it easier to manage memory and adds several features to allow "object-oriented" programming and "generic" programming. C++ makes it easier for programmers to stop thinking about the nitty-gritty details of how the machine works and think about the problems they are trying to solve. PROGRAMMING LANGUAGE VULNERABILITIES Read the article and share the language and topic that most caught your attention: https://www.mend.io/most-secure-programming-languages/ WHY SOFTWARE SECURITY? Most software systems today contain numerous flaws and bugs that get exploited by attackers. New threats emerge every day. Convenience trumps security measures. Exponential increase in vulnerabilities in software systems. Software security is everybody's job. Programmers have a long history of repeating the same security- related mistakes! https://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/stevensonhunteralharbikhali.pdf Secure Coding Standards https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682 HOW MANY MILLIONS LINES OF CODE Shifting Paradigm for Software Software-Enabled Products Security Risks in Application Software Data Breaches Software Vulnerabilities Software Security Flaws Review Security Requirement Match Description by drawing a connection line Identification, authentication No parties using the system can deny any of their actions & authorization Integrity Ability to examine and review all the actions taken Confidentiality Sensitive data, communication are protected from unauthorized access, both internally & externally Service Availability Verify that a user is who they says they are before they can interact with the system Non-Repudiation Identify & record all unauthorized access to the system Security Auditing Ensure that all critical data can be recovered in system failure Malicious Activities Detection Unauthorized actions on data, component, and communication prohibited Backup and Recovery User can use the service provided by application at any time based on a set time requirement. EARN YOUR PRE-WORK GRADE Post your weekly discussion question and research solution to D2L TODO Complete Week 03 Content Module in D2L to 100% WHAT'S COMING UP NEXT...WEEK 04 QUESTIONS | CLARIFICATIONS | HELP Student Office Hours: Schedule Meeting with Julie o By Appointment (both on-campus and remote via Zoom) o Drop-In Times Available (on-campus) Email: [email protected] RRCC On Campus Tutoring: https://www.rrcc.edu/learning- commons/tutoring 24/7 Online Tutoring: D2L > Content > Resources for Help