CSSLP Domain 2:1 Policy Decomposition
Policy Decomposition - Introduction

This course is the first installment of three courses covering Domain 2 of the CSSLP, covering the topic of policy decomposition.

Learning Objectives

  • Understand the fundamental concepts of information security and operational security
  • Learn about the CIA Triad
  • Learn about Triple A services and how they help keep software available and safe
  • Understand the internal and external requirements for building secure software

Intended Audience

This course is designed for those looking to take the Certified Secure Software Lifecycle Professional (CSSLP)​ certification, or for anyone interested in the topics it covers.


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.


If you have thoughts or suggestions for this course, please contact Cloud Academy at


Welcome to Domain Two of the CSSLP, the Certified Secure Software Lifecycle Professional examination review seminar. This particular domain covers secure software requirements. And in this module, we will cover foundational knowledge and ideas about what informs the designing and building of secure software. This domain covers the chapters five, six, and seven in the course text.

First, let's set the stage a little bit and orient how we're going to approach and think about this chapter's information. It is important to establish the fact that without software requirements, software will fail and without secure software requirements, it will be attacked successfully by hostile parties. Without properly understood and well-documented and tracked software requirements, one cannot expect the software to function without failure, or even to meet expectations. It is therefore vital to define and explicitly articulate the requirements of software that is to be built, and those kinds of software that will be acquired.

Software development projects that lack software requirements suffer from a myriad of issues. These issues include, but are not limited to, poor product quality, extensive timelines, and the ofttimes extensive timeline overruns, scope creep, increased cost to redesign and include the missed aspects and fix errors, and customer and end user dissatisfaction with the final product when it is delivered.

Software development projects that lack security requirements additionally suffer from the threats to confidentiality, integrity and availability, which include unauthorized disclosure, alteration, and destruction. It is really not a question of if, but when, as we know all too well, because it is only a matter of time before software built without security considerations will get hacked, provided the software is of any value whatever to the attacker.

It would, of course, be extremely difficult to find a building architect who would engage in building any sort of a building without a blueprint or a chef who will bake world famous pastries and cakes without a recipe that lists out the ingredients. However, we often observe that when software is built, security requirements are not explicitly stated.

Security is first and foremost viewed by the party wanting to design and build the software and the parties wanting to use it as a nonfunctional set of requirements in the software, and that the organization already has to deal with functional requirements within the constraints posed by budget, scope and security requirements are usually considered to be an additional complication and even more so, expense. Such an attitude is what leaves secure software requirements on the sidelines, if they're collected at all.

Secondly, incorporating security in software is often misconstrued as being an impediment to business agility, instead of being the enabler that it is to produce improved quality and more secure performance. The importance of incorporating security requirements, therefore, into the software requirements gathering and design phases is absolutely critical for the reliability, resilience, and recoverability of the software intended. It is therefore extremely important to explicitly articulate security requirements for the software in the software requirements specifications documents.

Now in this particular domain, we need to understand what our objectives are going to be. And as you see here on the slide, it's going to be a case of understanding how policies should be deconstructed and then transformed into requirements. We need to examine the specific attributes of the CIA triad that drive policy, and that must be re-expressed as drivers of non-functional requirements. Then we need to look at the examination of the specific attributes of the so-called Triple A Services that drive policy and themselves must be re-expressed as drivers of functional requirements. And of course, we're going to delve into the relationship between security and audit and how these translate into requirements also.

Now, as we've said before, this is not a course in secure programming. There are as many ways to compose software as there are languages in which to write it and developers who choose to build in them. This is intended as a course that programmers should use to help them build more secure, more resilient, and more resistant software while achieving the necessary balance between security and functionality. Taken in this vein, the concepts presented here are applicable, no matter what language environment is in use or what system is being built.

There can be little doubt that software, being the primary point of impact for the various attacks, flaws and other disruptions that it is subject to would greatly benefit from better, more secure methods of conceiving, designing and constructing it. Those benefits would begin with better reliability, better resilience, and improved performance. In this module, we're going to explore the origins of those benefits, which will be found in the requirements it will satisfy when it performs its work.

About the Author
Learning Paths

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.