Internal and External Requirements
Start course

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


Now to touch on the requirements, we need to look at them because they come to us in various forms. We have the internal and external sources that they come from. We have the functional, which talks about the actions that they will take. And we have non-functional, which refers to states or conditions that must exist in the system. They typically will come in about three categories, some being mandatory, those things that the system absolutely must do without fail.

Some will be highly desirable, nice to haves and a higher priority. Not quite that of the mandatory ones, but it would be nice if we had these. Then we have the optional, the nice to haves, if you will. Good things, nice things, functional things, user pleasing things maybe, but they're optional. The mandatory and highly desirable are two top priorities.

Now the internal will typically come, and they will be employed by the system to protect internal data: audit logs, controls, other types of very sensitive and very important records. It'll protect the inter-process communications, and control traffic. And it will also make certain that alerts go through without tampering. Interference or alteration of these particular rules and requirements, are going to result in unauthorized operations, and data compromise, if they are not properly handled.

Now, typically the external requirements that we look for are those related to the external obligations we all face. And these will come in the source of regulations, compliance requirements, contract performance, and perhaps other forms of requirements that we must meet that may be based on industry standards. The thing that we are concerned with here is that interference with these may result in non-compliance, threat blindness, or a failed control or, other compromise, that would result in the systems being tampered with, and having been done in a way that we haven't been able to detect. Now to sum up where we are so far, we've discussed various elements from which the requirements are derived.

Now, the importance of requirements cannot be overstated. And the fact that they are needed from concept and design phases, and carried all the way through the system, realizing, of course, that reality being what it is, will cause various types of changes in these requirements, as we go through the process.

In the end, they're going to ensure that issues of operations, performance and compliance, are identified and validated as early as we can in the software development life cycle. Now from these sources requirements can be disassembled, analyzed and transformed into states, functions and products that satisfy the originating needs that drove this product's conception from its very beginnings.

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.