1. Home
  2. Training Library
  3. Security
  4. Security Courses
  5. CSSLP Domain 5:1 - Security Quality Assurance Testing

Problem Management

The course is part of this learning path

Start course
Overview
Difficulty
Beginner
Duration
32m
Students
61
Ratings
5/5
starstarstarstarstar
Description

This course covers section one of CSSLP Domain Five and looks at security quality assurance testing. You'll learn about important and foundational concepts on the process and execution of testing, topics regarding quality and product integrity, and various other considerations.

Learning Objectives

Obtain a solid understanding of the following topics:

  • Security testing use cases
  • Software quality assurance standards
  • Testing methodologies and documentation
  • Problem management
  • The impact of environmental factors on security

Intended Audience

This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.

Prerequisites

Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

Transcript

Throughout this process, we're going to have to deal with problem management. Now, problem management in this context is defined as defects in product that is being produced. And in that, we have flaws and these would be characterized as errors in design. We have behavioral anomalies which can produce things that are operational issues or a strangeness, which if we think carefully about that, it is something that may not appear blatantly obvious and wrong, but it is something that seems odd in comparison to the results we've gotten from previous tests. A certain odd kind of behavior, possibly due to a combination of things or other characteristics.

We also of course have errors and faults. These are typically outcome-based issues and these can be derived from other sources as well, impacts from other modules or other elements within the code. Then of course, we have our vulnerabilities and these would prove to be targets of hostile manipulation, exploitation. And these would be things like weak controls, poor coding practices and choices that would be prone to exploitation, bad implementation, and other elements.

We have, of course, the infamous bug which are defined as errors in coding. Now, when bugs are found, we need to develop a method for both detecting and tracking them. Because what we need to look at is how to elaborate when we find a bug. And that means, looking at it in greater and greater detail, getting better and deeper knowledge about how it works or how it fails so that we can do a better job of prioritization, and thus repair. We, of course, want to try to remove the bug but history tells us that removing the bug may in fact be very costly. That means that we're going to have to change our focus to instead of removing it, mitigating by perhaps to put it one way, writing a rounded.

We either have to correct the bug itself or we have to compensate in that way. We could, of course, if the bug itself is harmless in what it does truly harmless not perceived as that, we might be able to ignore it. We're always gonna have consider the cost-benefit analysis in determining things like prioritization, repair, correction, compensation, mitigation, removal, and other related issues. Because we must determine the most efficient course and that means what is the impact that it will have on the schedule or cost to produce the final product. And also in the process, as is well-known trying to remove bugs often times instead of removing alone. It also introduces the possibility of more bugs.

About the Author
Students
5787
Courses
75
Learning Paths
17

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.

 

Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.