4_25655_SE731_2020_1__2_1_Lecture 1 - Course Outline and Secure SDLC.ppt
- 1. Security in Software Engineering Dr. Nada Hany Sherief
- 2. Course Goals It explains the need for computer security Explains how security requirements can be met with well-established techniques Risks can be addressed though novel technologies and techniques Introduces Security Design Best Practices Explains the scope of the available technical solutions Presents techniques for evaluating security solutions
- 3. Course Lecturer’s Contact • E-mail: • nada.hany.sherief@gmail.com , • nada.sherief@aast.edu • Office hours: • Tuesday 8:30-10:30 • Wednesday 12:00-2:00
- 4. Course Grading System 7th week 20 marks on exam 10 marks on section Continuous Assessment 12th week 10 marks on exam 10 marks on section Final Exam 10 marks on sections 40 marks on exam
- 5. Course Material Delivered Textbook . PDF copy of the lectures and assignments on my Profile page at aast.edu
- 6. Course Timeline by weeks 6 4 2 Security Requirements Planning: Risk Assessment Design: Architectural Risk Analysis Course Outline and Secure SDLC Requirements: Misuse Cases Design: Secure Design Patterns EXAM
- 7. Course Timeline by weeks 13 11 9 Implementation: defensive coding practices Design: Threat Modelling Security Testing: Penetration Testing, Risk- based Security Testing EXAM 15 Assessment: CVSS Assessment: CWSS Revision Projects’ Review
- 8. Lecture 1 • Secure SDLC • The Security Development Lifecycle: Proactive vs. Reactive
- 9. Glosarry • Information Security Risks: the probability that a particular threat-source will exercise a particular information system vulnerability and the resulting impact if this should occur (NIST publication 800-27) • Software Security: a way to defend against software exploits by building software to be secure (McGraw Exploiting Software) • Application Security: a way to defend against software exploits in a post-facto way after deployment is complete (McGraw Exploiting Software)
- 10. What is at risk?
- 11. How we approach risk?
- 12. What Is Secure SDLC and Why Is Important? • Security System Development Life Cycle is defined as the series of processes and procedures in the software development cycle, designed to enable development teams create software and applications in a manner that significantly • reduces security risks, • eliminate security vulnerabilities • reducing costs. • The process, like the traditional Systems Development Life Cycle, is divided into a number of phases.
- 13. What Is Secure SDLC and Why Is Important?
- 14. What Is Secure SDLC and Why Is Important? • Development teams use different models such as Waterfall, Iterative or Agile. However, all models usually follow these phases: • Planning and requirements • Architecture and design • Test planning • Coding • Testing the code and results • Release and maintenance
- 15. What Is Secure SDLC and Why Is Important? • Developers usually performed security-related tasks only at the testing stage, resulting in discovering issues too late or not at all. • With time, teams started to integrate security activities to catch vulnerabilities early in the development cycle. • With this in mind, the concept of secure SDLC started. • Secure SDLC integrates activities such as penetration testing, code review, and architecture analysis into all steps of the development process.
- 16. Benefits of adopting a secure SDLC • The main benefits of adopting a secure SDLC include: • Makes security a continuous concern—including all stakeholders in the security considerations • Helps detect flaws early in the development process—reducing business risks for the organization • Reduces costs—by detecting and resolving issues early in the lifecycle
- 17. How Does Secure SDLC work? • Most companies will implement a secure SDLC simply by adding security- related activities to their development process already in place. • For example, they can perform an architecture risk analysis during the design phase. • There are seven phases in most SDLCs although they may vary according to the methodology used, such as Agile or Waterfall: • Concept • Planning • Design and Development • Testing • Release • Sustain • Disposal
- 18. How Does Secure SDLC work? • For example, a development team implementing the waterfall methodology may follow the following scheme:
- 19. How Does Secure SDLC work? • Each security activity should correspond with a phase in the SDLC, as follows:
- 20. How Does Secure SDLC work?
- 21. How Does Secure SDLC work?
- 22. Considerations when implementing a Secure SDLC (1) SDL Discovery • The goal should be to determine: • the security objectives required by the software, • what are the possible threats and • what regulations the organization needs to follow. • When working on the scope of the SDL, a development team should focus on deliverables such as: • security milestones, • required certifications, • risk assessments, • key security resources, and • required third-party resources.
- 23. Considerations when implementing a Secure SDLC (2) Security Baselines • Here you should list what are the requirements your product need to comply with. • For example, only using approved cryptography and libraries or using multifactor authentication. • A Gap Analysis, contrasting the product’s features against the baseline, is useful to identify the areas not complying with the security baseline. • When finding a gap, this needs to be addressed as early as possible in the lifecycle. • Since companies release a product based on the percentage of compliance with the baseline, is important to work on gaps through the development process.
- 24. Considerations when implementing a Secure SDLC (3) Security Training and Awareness • The company should provide security training sessions for developers, designers, architects, and QA. • They can focus on secure design principles, security issues, web security or encryption. • Security awareness sessions are not geared specifically for the development team, involving everyone that is connected to the project within the organization. • Sessions should be easy in terms of technical level and can include topics such as the various cybersecurity threats or risk impact and management.
- 25. Considerations when implementing a Secure SDLC (4) Threat Modeling • Modeling the software components to identify and manage threats early in the development lifecycle. • This helps the team to develop an incident response plan from the beginning, planning the appropriate mitigations early before the damage becomes more complicated to manage. • Typically follows four steps: preparation, analysis, determine mitigations and validation. • This activity can have different approaches such as protecting specific critical processes, exploit weaknesses or focus on the system design.
- 26. Considerations when implementing a Secure SDLC (5) Third-Party Software Tracking • Since third-party software can be open source or commercial use, the team needs to list all third-party tools used in the project. • This inventory should be done in the early stages of the development cycle. • There are software tools that track and list the third-party components, sending you an alert if any component needs upgrading or has licensing issues.
- 27. Considerations when implementing a Secure SDLC (6) Security Design and Peer Review • The development team should ensure the software is built with the most secure features. • When reviewing the functional feature design, the developer should include a security design review, thinking like an attacker to discover the feature vulnerabilities. • When reviewing the code, developers need to be aware of the most common coding security pitfalls. • They can follow a checklist for secure coding, for example, that ensures that important security events are logged, check the penetrability of the authentication process, or validate the user input.
- 28. Considerations when implementing a Secure SDLC (7) Security Testing • While code review focus on functionality, security testing checks how vulnerable is the new product to attacks. Some of the testing activities include: • Static Analysis—identifies the exact location of weaknesses by analyzing the software without executing it. • Dynamic Analysis—identifies weaknesses by running the software, helping find infrastructure flaws and patch errors. • Vulnerability Scanning—injects malicious inputs against running software to check how the program reacts. Mostly used to scan applications with a web interface. • Fuzzing—involves giving invalid, random data to a program, to check for access protocols and file formats. The test helps find bugs that humans often miss by generating random input and try all possible variations. • Third-party penetration testing—the tester simulates an attack to discover coding or system configuration flaws, and discover vulnerabilities a real attacker can exploit. It is required that the tester is an external party not connected to the team.
- 29. Considerations when implementing a Secure SDLC (8) Data Disposal and Retention • Usually at the end of a product’s life companies dispose of old products, or data that they don’t need to use anymore. • Many companies delete or overwrite encryption keys, in a process called “crypto- shredding”. • While getting rid of outdated data is a necessity, there are concerns when comes to keep the confidentiality of the information. • Some regulations such as General Data Protection Regulation (GDPR) have specific requirements for data disposal and retention.
- 31. The Security Development Lifecycle: Proactive vs. Reactive • Setting up an SDLC can be divided into two major approaches: proactive and reactive. • The proactive approach concerns preventing all possible flaws and breaches at the very beginning of the project, implementing solutions in a secure way. • The reactive approach aims to ensure security before the release, and to maintain it throughout the product’s existence.
- 32. The Proactive Approach • Banks use thick steel and concrete vaults with advanced electronic systems to prevent and detect break-ins • Many companies use cameras to record business activities, the idea being that cameras both deter theft and help identify perpetrators when thefts do occur • Some organizations have started using Intrusion Detection and Response Systems (IDRSes) to try to detect computer intrusions and then activate defensive measures when an attack is detected.
- 34. The Proactive Approach • It’s worth mentioning that the proactive approach is always preferred. • The consequences of finding a bug are much less serious if the bug is discovered in the development stage, before release. • It is cheaper, easier, and faster to fix the bug when the product is under development, which leads to the idea that security should be implemented on the very beginning of the project. • The best option is to consider security before the actual development is even underway, to train staff on security practices. • When people understand the importance of security procedures and how to implement them correctly, they are better able to keep their products secure.
- 35. The Proactive Approach Requirements and Design • The first two stages in the proactive approach—requirements and design—are most important. • In these stages, all security and privacy requirements are formed, quality measurements are defined, and possible attack vectors are identified. • This is the moment the "technical task" is formed. The full, detailed technical task is created, with all functions described in detail, acceptable levels of quality, and explained risks and mitigations. Static Code Analysis • The next step is the actual implementation of the project. • Throughout this step, the main idea is to use only approved tools, safe function, and, most importantly, regular static code analysis. • There are some tools to help in this challenging task, like IBM AppScan or CheckMarx, and with some effort they can be used for continuous integration with your project.
- 36. The Reactive Approach • If everything has already been built, and security needs to be implemented retroactively, the product requires a reactive approach to the SDLC. • Examples of reactive approaches include: • Disaster Recovery Plans • Use of private investigation services and loss recovery specialists • Reinstallation of operating systems and applications on compromised systems • Switching to alternate systems in other locations
- 37. The Security Development Lifecycle: Proactive vs. Reactive
- 38. The Reactive Approach Penetration Testing • One of the most interesting techniques, for a security engineer, is to do a penetration testing of the application. • Here, the work of a real hacker is imitated to uncover security flaws and issues, check the authentication and authorization management, input validation, and many other aspects of the product. Dynamic Code Analysis • Contrary to static analysis, dynamic analysis is executed while the application is in operation, and continuously monitors functional behavior, response time, system memory, and overall performance. • This approach could be easily used in continuous integration, as well as in static analysis. While automated tools cannot replace humans, it helps to accelerate and improve the work of engineers.
- 39. The Reactive Approach Web Application Firewall • A web application firewall (WAF) is a specially designed application firewall that works over HTTP protocol. • It’s comparable to a very light version of IDS (intrusion detection system), but specific to HTTP. WAF contains rules against common attacks such as SQL injection or XSS (cross site scripting). • Today popular solutions include using WAFs that are already within DDoS protection services, to kill two birds with one stone. Incident Response Plan • Before the release of the product, one important thing has to be done: an incident response plan has to be created. • The incident response plan includes all appropriate persons to contact in an emergency and the sequence of steps to perform in order to eliminate the breach. • The final security review must be done before the release.
- 40. Thank You.