1. Home
  2. Training Library
  3. Security
  4. Security Courses
  5. CSSLP Domain 6:4 - Post-release Activities

CSSLP Domain 6:4 - Post-release Activities

Contents

keyboard_tab
CSSLP Domain 6:4

The course is part of this learning path

Post-release Activities
Overview
Difficulty
Beginner
Duration
8m
Students
39
Ratings
5/5
starstarstarstarstar
Description

This course covers CSSLP Domain 6:4 - Post-release Activities and looks at verification and validation, from both a technical and management perspective, and the differences between the two. We'll also look at independent testing.

Learning Objectives

  • Understand post-release activities to carry out to ensure the security of your software

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

Post-Release Activities. At which we're going to look at verification and validation, the management verification and validation, the technical verification and validation, the differences between the two and independent testing.

Now immediately following the successful installation of the deployed software, we need to begin several necessary activities. These will include a configuration audit to ensure that all required settings are in fact and verified as correctly implemented. We will undertake hardening to ensure that all security measures are in place and that the attack surface has been optimally minimized. We need to ensure that we capture all of the installation issues and documentation of those corrective actions to resolve them. And the capturing of a new master image baseline and the creating of the original clean source backup of it.

Now, the required procedural documentation must also be created and used to ensure that these critical aspects are created, maintained, and improved as the software is made to adapt and evolve through the change management process. So, verification and validation. Now taken together, these are processes to confirm that it is the correct build that functions correctly. To break it down a little further, it means that the software was constructed correctly and meets the quality and performance measures. Also, that it meets the user functional requirements when in operation.

To put it another way, it is, we have built the right thing and we have built it the right way. These processes are performed in the concluding steps of each stage of your software development life cycle and a final one at deployment, with procedures to ensure that we capture anomaly incident and problem reporting, that auditing is done for deviations and exceptions, that we establish baseline control and configuration management, and that we have an evaluation process to ensure continual alignment with business requirements and change management processes to bring about controlled evolution to maintain this.

Now, overall, the verification and validation processes break out into two separate groups. Now they are separate, but they are of course, intimately related. Now the management V&V are the processes geared towards management process behaviors and requirements that will involve the software. These typically include comparison to plans or schedules to evaluate project suitability, outcomes that will typically impact corrective actions, resource allocations, and project scoping.

Outcomes will often include changes and corrective actions and the roles that are typically involved in this process will include the decision makers, the management staff, the tactical staff and the user representatives. From the aspect of the technical V&V, this is the verification and validation set of processes that are geared towards the software itself. All the documentation including code, test, and installation. 

Now these will involve analysis concerns of the configuration and conformance to the specific standards, outcomes management and customer support, supports problem, anomaly and incident management, and it typically involves the very same set of roles, decision makers, management staff, technical staff and user representatives in a separate, but related set of issues. Now, a subject that must be addressed by anyone involved in the management or the tactical build of any program will be independent testing an audit.

Testing by third parties is often employed to obtain objective results and thus heighten the confidence that the receiver will have in the delivered software. Now it's common to separate duties throughout these kinds of processes, but here the separation between builder and buyer tends to inspire more confidence by elimination of the inherent bias in either party, as well as the possible influence over the decisions that might be made concerning it. Auditor independence has long been a requirement throughout many of these aspects within IT and specifically when it comes to assurance and certification.

In these cases, it has to ensure that there is integrity and confidence in the quality and compliance of the delivered product. In addition to that, third party audits are often required in these arrangements where compliance certification and attestation are mandatory. Now, as in the case of the SSAE-18 Audit, often called a SOC, which is an abbreviation for the report that is produced by the SSAE-18 Audit, these activities are planned with scope, risk assessment, methodological organization and execution.

As with all audits, items and artifacts are to be examined or outlined. The methods of examination and evidence artifacts are described in detail. The attributes and the pass fail factors are defined. Requirements to be met are compiled with their related metrics. And the reporting delivers the findings, recommendations and typically what follow up activities will follow next. Now, this report, which we have in the closing phases of the software is delivering, and all of its related documents and actions will become part of the history of the software and will be employed as the original source to guide future activities and adaptation and the progressive improvement of it to ensure it remains in alignment with its original and evolving objectives.

We have discussed and learned that before software that is built or bought and is decided as ready for deployment or release, it must go through a formal acceptance process. Now benefits of a formalized software acceptance process include validation of security requirements and the verification of the controls, meaning that we ensure that it is not only operationally hack resistant but also compliant with the applicable regulations. We've also covered that prior to the acceptance of the software, several things have to be taken into consideration. Including the satisfaction of the redefined completion criteria which must be defined as precisely as possible. The establishment of a change management process which is key to the products installation and to its future evolution and adaptation. The process of approvals to deploy release, including the risk acceptance and any exceptions to this policy and the completeness of pertinent documentation.

About the Author
Students
6571
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