CSSLP Domain 3:4 - Technologies
Domain 3:4 Technologies - Introduction

This is the fourth course in Domain 3 of the CSSLP certification and covers the essential ideas, concepts, and principles that you need to take into account when building secure software.

Learning Objectives

  • Understand the process and controls available to secure your software
  • Learn about the main security technologies available

Intended Audience

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


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.


Now, the concepts that you see here are ones that we have talked about before, but due to their importance, we're going to, again, discuss them with a lot more depth and from a different angle this time. So to briefly recap just a word or two about this, when we think about good enough security, we're always thinking about the fact that security is not an absolute with a definite black and white type of definition. But one thing we don't regard that there is such a thing is perfect or complete or absolute security. So what it does by conceiving of what good enough really means in the context in which we're working, we're going to design the security to be sufficient for the needs, and the utilities and the data and all of their sensitivity and confidentiality attributes will be appropriately dealt with.

Now, least privilege of course means giving authorized users the amount of access that they need at the lowest possible level of exposure, which is not to inhibit them in any way, but it is to protect the data from any sort of overexposure which can lead to damage or corruption of other kinds. We need to be sure that we understand what separation of duties will mean. And what we're trying to avoid with this is the creation of conflicts of interest. Putting too much power in too few hands or providing a combination of access to various resources that produces that kind of a conflict of interest.

The key element of fail secure is to ensure that when the software fails, as all software will eventually, that it fails in such a way that it does not release control over protection of the data that it's been processing, but in fact fails around it like a wrapper to protect it from the kind of disclosure. It's well known that hackers prefer to cause an application to fail in the event and in the hope that it will fail open, giving them access to the asset that it's been utilizing or protecting.

Economy of mechanism means keeping things simple. The least common mechanism attempts to avoid combinations of services that use something to avoid the failure of one service underlying several things and bringing them all down when the service itself fails. Complete mediation means that mediation is done for each and every subject-object interaction, and it is done each and every time the subject-object interaction takes place so that mediation can be said to be system-wide and functionally related and complete in all cases.

Of course, we know what weakest link means. Like the old analogy with the chain, the attack, if it hits the weakest link, causes the entire thing to fall apart. And so going through, we have to recognize two points. One is it may not be possible to remove it, and two, it may be also the single point of failure. So when we think about weakest link and single point of failure, and having to accept that removal of this may not be possible and still have the software do its job, we will find ways to compensate for it, which brings us back to the concept of defense in depth.

Open design means there are no black boxes. That knowing how things work will be possible throughout all the authorized users and the authorized designers and builders to make sure that there are no secrets. That the functionality of something which itself by concealment could become a great weakness is prevented. Leveraging existing components means let's use what we have and make the best use of it and augment when and as necessary, but not excessively so. And then the psychological acceptability brings in the aspect of having to consider how this will all impact the user. If we make things too complicated, too convoluted, too difficult, or too confusing, it's quite possible that users may entertain the idea of creating shortcuts. Trying not to do something when they can get away with it. But in doing so bypassing or in some way inhibiting security from doing its job. And in order to do that, we must consider the impact on the end user and try to keep from having those things result. So let's look at some additional types of concepts and principles that need to be employed.

All the design elements are products of our concept and the requirements that must be met with the finished product. And that would include functional, which means actions performed, and non-functional, or states that must exist in which these actions will be performed. Like any sort of a construct, it needs to bear certain kinds of attributes so that we can be sure that we're actually doing the things that we need to and that we can measure them, so that we know that the metrics are being met, that they are auditable, so that we can determine whether or not compliance has been attained and operations are proceeding as intended, that they are reasonable, that it obtains the objectives on balance with operational criteria, and that they are realistic. In other words, they're not theoretical. That we can put a number to it, so to speak. And that they can be demonstrated as proven and capable or of course with equal importance, that they are proven as not possible. Proof is what we need and that's the essence of realistic. Now, these aspects of design have to include the idea of enhancements to software quality since quality reduces certain security issues, such as data and operational integrity.

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.

Covered Topics