Contents
Domain 3:2 - Design Considerations
This is the second 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 security design principles as different from actual software design principles
- Understand the relationship between the interconnectivity and the security management interfaces
- Learn how to balance potentially competing or seemingly conflicting requirements to obtain the right security level
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.
Now, as I've been saying, it is vitally important that we seek to do all of the right things. Achieve good and sufficient security, but we need to do this with the idea of balance in design. As has been said, it is important to recognize that it may not be possible to design for each of these security principles in its fullness, within the software under development, And it will necessitate various forms and trade-off decisions. But these of course need to be very carefully considered as to what we are seeking to balance and what we are trading away to do so.
For example, while a single sign on system can heighten and ease the user experience and increase psychological acceptability, it contradicts the principle of complete mediation so that a business decision is necessary to determine the extent to which SSO is designed into the software, or it's determined that it is not even an option to be considered.
Security, of course, as we've been saying, must be designed in, but design alone is insufficient. It must be configured to operate efficiently within the specific context, but must do so on a balanced form with the intended functionality of the system. As we know all too well from history, if security interferes beyond a certain point with how the software will work or the users' acceptability of how the software works with security built-in, security typically by management decision. And this is not entirely inappropriate. It will either be torn out, or it will be reduced to make it more acceptable to users. And so by seeking to achieve this balance early on, we can avoid this.
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.