This is the first 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 main security models used for developing software in a secure way
- Learn how to develop and implement security models
- Understand how to manage risk and threats
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.
So let's look at our classic threat treatment strategy components with risk avoidance. Now, this is something that, in the phase that we're in in the design project, this may be something that is an open option to us because now, once we identify threats that can be introduced, we can now plan to try to keep that from happening or eliminate those that have already made their way into the design. In the real world, once it's productional, this becomes one of the least possible of all the risk mitigation strategies we can take. So this is something that we need to explore and take advantage of to the extent possible.
The most common, of course, is to do risk mitigation. These are things that we know work. The standard mitigation attempts. We can also look at which risks can and would properly be best mitigated by the transfer of them to some other third party, such as a contractor, such as a service organization. But we have to be careful because with risk transfer, which also includes the purchase of business interruption insurance, we have to be careful to recognize that the accountability for what we're transferring still rests with us and that the responsibility through the contract vehicle or the insurance policy is transferred to that third party. But the accountability carries a legal implication with it that responsible does not, so we have to be sure we aren't blinded or overlook this particular aspect if this is the strategy method that we choose.
In the end, after we've done everything we can that is cost-effective, we have to accept the risk that it remains after all of these steps have been properly taken. Now, risk acceptance, as a point of clarification, does not mean doing nothing. Doing nothing is considered negligent in this particular context, so risk acceptance is what we do at the end of this process. We don't accept risk unless there are simply things that will not bear mitigation in any way. An example might be what the insurance people call act of God or force majeure, something that no one can plan for, no one can prevent, or even really predict accurately as an occurring item. So it does mean we've done other things instead first, and that this remains.
When we're done with the modeling process and it's reviewed by the team members, we have to go through the validation and acceptance process to make sure that all are in agreement that this provides a well-constructed and overarching look at the threat asset attack scenario type of approach that we seek to model and thus attempt to mitigate. Once it's reviewed and accepted, it will then be employed throughout each succeeding phase of this project.
As it progresses through through each phase, the threat model is re-validated for both threats and mitigations. Software is as much an art as it is a science and a professional pursuit. But as the art suggests, it's going to evolve, change. Things that we thought would work early on turn out not to, either at all or as well as we had hoped. And so we need to be prepared to re-validate and re-verify that the model remains applicable.
If the verification should prove negative, then the model must be revisited and updated or reconstructed, or perhaps even disposed of and a new model constructed if the circumstances show that that's what we need to do. We have to make sure we re-verify, and this is a very important point, the interdependencies that may have appeared at this and later stages that did not appear in earlier ones. And as with all assumptions, we cannot work with unvalidated ones. So these will all have to be validated initially and then periodically re-validated as the project progresses.
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.