CISSP® - Software Development Security

This course covers topics that are related to the CISSP® software security domain.
Course info
Rating
(113)
Level
Intermediate
Updated
Mar 30, 2015
Duration
3h 6m
Table of contents
Description
Course info
Rating
(113)
Level
Intermediate
Updated
Mar 30, 2015
Duration
3h 6m
Description

This course provides coverage of the Software Development Security (Understanding, Applying, and Enforcing Software Security) domain from the April 2015 ISC2 CISSP® exam objectives. You will be made familiar with the importance of building security into the development process and learn about system life cycle security, the basics of software development, the different types of threats that applications face, and some countermeasure examples. This course is focused on the 8th of 8 domains in the CISSP® exam, and as such there will basic to intermediate coverage of many different concepts that CISSP® candidates will be expected to have some understanding of. The goal of the course will be to ensure the learner has a basic understanding of the concepts, why they are important, and when they should be used.

About the author
About the author

Lee Allen is a penetration tester by trade. Lee has authored four books about penetration testing and has created several Pluralsight courses.

More from the author
Threat Modeling: The Big Picture
Beginner
1h 5m
Jun 27, 2017
Section Introduction Transcripts
Section Introduction Transcripts

Application Security
Hi, and welcome to Pluralsight. My name is Lee Allen. In this module, we will review Application Security as it relates to ISC-squared's CISSP software development security domain. Often times, people seem to place a large portion of their security focus on network and system level security controls. Many of these are tools that are designed to prevent or protect from a very specific type of threat. With application development security, we get the opportunity to ensure that security is considered at the most important place of all, in the development of software. In this course, we are going to discuss the role of application security and why security practitioners and developers alike should care about application development. We will discuss governance methodologies, and the development controls, change control, and versioning options that are available. We also take a look at the fact that well-defined and improved processes lead to cleaner code and applications with fewer vulnerabilities, and what we should be concerned with in regards to the employees that actually have access to development resources, such as source code.

Development Life Cycle
Hi and welcome to Pluralsight. My name is Lee Allen. As you go through this module, keep in mind that in general, a security professional will not be expected to have years of programming experience, but will usually be expected to understand the basics of software development concepts and have some familiarity with the different software development models that are available. It is important to understand that software development can be a resource intensive and complex process. In order to provide efficient and repeatable processes that can be managed, measured, and improved over time, software development needs to be performed in a consistent and well thought out manner. Luckily this is a problem that has been worked on for many years by the software development community, and as security professionals, we are generally only expected to understand the basic concepts and lingo that is being used. That being said, many of the vulnerabilities that are being seen these days could be avoided altogether if security had been part of the entire software development life cycle in the first place. In this module I review the more common terminology that you need to be familiar with, what a systems development life cycle and systems life cycle is, and why understanding these should be important to us as security professionals, and I then provide an overview of frequently used software development models.

Security Impact of Acquired Software
Hi, and welcome to Pluralsight. In this module of the CISSP software development security course, we will discuss the security impact of acquired software. We start off by taking a look at the different security concerns that we should have in regards to acquired software. This includes the different concerns about how acquired software impacts the SDLC, what we need to worry about in regards to personnel, and even things like warranties. We are also going to review the governance requirements that you should have in place to ensure that acquired software actually meets the policies that you have in place for your environments.

Software Threats
Hi and welcome to Pluralsight. In this course module, we will briefly discuss the different types of software threats that you are should have some basic familiarity with prior to attempting the CISSP examination. In this module, we will review various threats which you have no direct control over, such as user error, or even social engineering. Even though you cannot control the existence of these threats, the threats that apply to your environments must be identified, so that you can at least prepare for them. We also take a look at various software vulnerabilities that must be dealt with to make certain that your environments are always secure.

Programming Language Concepts and Concerns
Hi and welcome to Pluralsight. My name is Lee Allen. In this course module, we will be discussing the programming language concepts and concerns that you should be aware of before attempting the CISSP examination. So let's get started and talk about programming language concepts and concerns for a moment. A security professional may not always be required to fully understand everything there is to know about programming; however, the security professional should have an idea of what a programming language is and what the primary components of a programming language are. During this course module, we will discuss what a programming language is and briefly discuss the different generations of programming languages. We also touch up on the difference between interpreted and compiled programming languages. We will take a look at object oriented programming concepts, such as inheritance, abstraction, and polymorphism, and discuss why it is so important that security professionals are familiar with these concepts. We will also take a quick look at components of distributed programming, such as the common object request broker architecture and distributed component object model.

Secure Coding and Security Control Concepts
Hi and welcome back. In this module, I will discuss secure coding best practice and provide examples of the different security controls that are available to ensure that the code being produced by your team is actually secure. Security may not always be the largest concern that your developers or any developers for that matter may face on a day-to-day basis. As security professionals, it is our job to ensure that a focus on security is given at all stages of the development cycle. There are many controls that can be used towards that goal. The controls we talk about within this course module may assist in ensuring that any code that is produced by your teams is being created and maintained is a secured manner at all times. We begin this module by speaking about how software vulnerabilities occur in the first place. There are reasons why code is so often laden with mistakes that cause security issues later in the life cycle of the system. We then move on to a discussion of common security controls that may prevent these issues from occurring in the first place. Many of the concepts that are discussed within this module are probably going to be familiar to you already. For those areas, just consider this a brief review and even confirmation of skills that you may already have. For other areas, be sure to understand how these all fit together with the concepts that you already know about in order to ensure that your developers are following secure coding best practice.