This document outlines a secure software development course. The course goals are to explain computer security needs and requirements, introduce security best practices, and present techniques for evaluating security solutions. It will be graded through exams, assignments, and a final exam. The course material will include a delivered textbook. The timeline shows the course content by week, covering topics like risk assessment, secure design patterns, threat modeling, and security testing. The document also provides the lecturer's contact information and defines key terms like information security risks and software security.

1. Secure Software Development

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:
• Office hours:

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 .

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.

30. Software Security Frameworks

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.