1. Home
  2. Training Library
  3. Security
  4. Security Courses
  5. CSSLP Domain 6:3 - Completion Criteria

Completion Criteria

Contents

keyboard_tab
Completion Criteria
1
Introduction
PREVIEW3m 7s
2
Completion Criteria
PREVIEW5m 27s

The course is part of this learning path

Completion Criteria
Overview
Difficulty
Beginner
Duration
9m
Students
15
Ratings
5/5
starstarstarstarstar
Description

This course covers section three of CSSLP Domain 6 and looks at the completion criteria necessary to close out a project.

Learning Objectives

  • Learn about software engineering product quality standards
  • Understand the main factors of completion criteria including maintainability, efficiency, portability, reliability, functionality, and usability

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

First we have functionality. Now these will be criteria that measure suitability for purpose, output accuracy, interoperability, compliance and security. Next, we have reliability sometimes called performance. Now the criteria here will reflect product maturity, fault tolerance, frequency of failure and recoverability. Our third category is utility also referred to as ease of use.

Now, the criteria for this will typically be the gradient of the learning curve, understandability to the end user and the time of attainment to proficiency for the end user. We look at the category of efficiency. Now the criteria set here will be for response times, computational time and throughput rates. It also examines resource consumption and duration of resource deployment before the resource is released for other uses.

Moving on to maintainability. The criteria here are defined for problem-solving and resolution with attention to differences between functional changes and structural changes. And therefore, by the generalist stability of the program itself. Then we have portability. Here, we look at the overall evaluation of ease or difficulty of adaptation of the program to alternate operating environments, ease of installation and ability to be reconfigured as necessary to accommodate changes in functional compliance requirements.

Now it's always critical to think in terms of what risks are present, which ones are acceptable and which ones are not. Now the process for determining risks that are and are not acceptable for this final to be released version must be considered in their context. These will include elements such as implicit and explicit safety concerns, implicit and explicit security concerns, System complexity and technical fragility, as well as performance and reliability.

Now, anytime we ask the question, what risks can be accepted, we need to consider two basic questions. What is the probability of the risk's occurrence? The second one being, what is the type in order of magnitude of the risk's impact should it occur? Now, the considerations that we make in this category of activities need to be credible. We're considering what is probable not what is possible. What is probable is a much smaller, more contained grouping of things than the universe that could be what is possible.

One of the ways to look at this would be to use a risk scoring matrix as you see here. We have the probability of occurrence ranging from frequent to improbable and the consequence or impact magnitude ranging from negligible to catastrophic. Now the goal here is to prioritize those risks which have both a high-probability of occurrence and a very high likely impact and scale downwards from there. Those at the higher-end of the scale will receive commensurate resource allocations for mitigation. And those appearing at the lower-end are likely candidates for acceptance. But as we've said before in the course of this training, we're not to take anything for granted. We have to look at each one because we will have neither all the time, all the money, or all the manpower necessary to mitigate everything. And so, we must make these decisions in light of all of those constraints.

Now the risk assessments for software need to look at it before it is release and put into operation. And the risk assessment needs to be updated many times before this. Now the risk assessment that was made in the actions derived from its findings becomes the point of departure not the end-point, because now the software will face dynamic challenges that it did not face prior to deployment into the real-world in which it will work.

Every risk assessment is a point in time evaluation of the software target and the threat landscape around it that existed at that moment. Consequently, it must be reassessed periodically to ensure that remains reasonably resilient. Now these threat analysis accompany to ensure the dynamic nature of the landscape is tracked and prepared for as best as can be. Subject to the available intelligence and constrained by the available protective resources. And as mentioned, the goal even now remains what is probable not what is possible.

About the Author
Avatar
Ross Leo
Instructor
Students
5766
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.

Covered Topics