CISSP: Domain3, Module 2
The course is part of this learning path
This course is the 2nd of 6 modules within Domain 3 of the CISSP, covering security architecture and engineering.
The objectives of this course are to provide you with and understanding of:
- How to capture and assess business requirements
- How to select controls and countermeasures based upon information systems security standards
- The security capabilities of information systems
This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.
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 firstname.lastname@example.org.
Now we're going to move on to section four in which we, based on the foregoing, we're going to look at selection of controls and countermeasures based on these standards. So we're going to investigate the ISO 27001 and two security standards, we're going to look at the COBIT, a standard sponsored by ISACA, Control Objectives for Information and Related Technology and we'll look at the PCI-DSS, the Payment Card Industry Data Security Standard. Now the global standard that is the ISO 27001 and two sets security standards that can be applied anywhere that you might wish around the world. These two typically travel together as the standards that organizations employ.
The ISO 27001 characterizes an information security management system. This largely describes the governance processes and requirements that any quality system must meet to properly define and establish the security management for any sort of organization. As such, it is divided up into five domains or key areas of focus. It specifies the general requirements of any sort of ISMS. It talks about management responsibilities, the due care, the due diligence and so on. It specifies an ISMS audit process so that the system, once implemented in whatever configuration it ends up in, can be measured to determine that it does in fact or does not in fact meet the stated requirements. There's a process for management review of the ISMS so that independent of an audit, management is able to look at it from an operational perspective to determine whether or not it meets the objectives of this particular enterprise and its needs and then there is, as is the common focus in many things we do these days, the continuous process improvement component so that as the management review takes place, as management responsibilities change and as internal ISMS audits indicate, the ISMS itself can be examined and improved.
Now along with the ISO 27001, comes the ISO 27002. This one is defined as the Code of Practice for Information Security Management. And it lists in 14 domains the kinds of security control objectives that need to be achieved to give the basis for the ISMS. In it is recommended a range of specific security controls according to industry best practice. So as you see in this picture, the darker blue depict the 14 domains in the current version of the ISO 27002 dated 2013 and looking at the different areas, policy, organization, human resources, security, cryptography, and on and on, it covers virtually all the domains that we have that carry concerns for us that make up the building blocks for our information security management system and overall program to achieve the objectives. As any good standard does, it specifies the kinds of activities that need to take place and the kinds of objectives that need to be achieved without specifying specifics of technology.
So the standard itself, though very general in nature, meaning that it doesn't apply to one particular enterprise type or another in any particular industry sector, it specifies how to go about doing what you need to do so that in your particular environment, it specifies what needs to be achieved and leaves it to you and the unique nature of your enterprise as to the actual nut and bolt level mechanism to achieve that.
Now as mentioned before, we have to have a mechanism for performing audits. The Control Objectives for Information and Related Technology or COBIT provides a set of generally accepted process to examine the IT, look at it for its value, look at it for its compliance and a number of other adjectives so that as we look at it, we're able to determine and draw conclusions about whether or not we are actually getting the benefit and the protection that we believe we should be from this. It will describe specifics of controls and these are usually attributes and processes that have to be attained and implemented by the control structure put in place, perhaps as directed by the ISO 27002. It specifies certain base minimum security services that we're going to need within our enterprise to achieve these particular objectives and then gives us targets so that we can implement to the level that we need to to achieve our specific goals for our specific enterprise.
One very common standard that's deployed in certain kinds of industries is the PCI-DSS. This was originally developed by American Express Discover, Visa and MasterCard to enhance the various security standards and direct them towards protecting this particular type of operation. It was meant to enhance the protection of payment card data especially considering that more and more purchasing online using payment cards was exposing this very sensitive information to compromise. As such, it provides a framework of specifications to ensure the safe processing, storage and transmission of cardholder information. The next few slides will provide some specific examples of these controls.
So looking at the left-hand column, we have build and maintain a secure network and systems. Protect cardholder data and maintain a vulnerability management program. So it does talk initially about the sort of design and build and the collection of requirements that will facilitate deriving a very secure system to handle this sensitive data. And the PCI-DSS then specifies the requirements that these goals, that the processes to derive these goals must achieve to be able to establish compliance with PCI-DSS. So to pick some examples, install and maintain a firewall configuration to protect cardholder data. Clearly, that will imply that we have to write and test and implement rules to do this. It means that periodically we have to patch our system and that means a proper secure configuration management system for the firewall. Obviously it also means we're going to have to monitor it running logs and examining those from time to time.
The second one, do not use vendor supply defaults for system passwords or other security parameters. A form of what we would take as commonsense these days, making sure that what we get from the vendor, we change to meet our own standards and our own policies and do not leave these because these may be well known and well understood across the world in terms of the information that hackers share with each other which means we would be a candidate for hacking should we leave any of these things in place. A general goal, protecting stored cardholder data. Four, encrypt transmission of cardholder data across open public networks. This is, of course, a reference to the data in transit requirement that many industries have put in place. Use and regularly update antivirus software or programs. Clearly we have to install these programs to begin with and as you would expect, we have to maintain them and then develop and maintain secure systems and applications. Now many of these PCI-DSS requirements aren't sufficient just taken at face value.
As I described a few minutes ago, it means that we have to have proper systems in place so that we can achieve this particular requirement such as develop and maintain secure systems and applications. There is a very rich amount of work that goes into doing requirement number six, meaning we have to go through proper design, development, testing, and that sort of thing to make sure that we are able to achieve them. So we have some more. Now this is only a very small sampling of what the PCI-DSS has as its set of requirements. On the test, these kinds of requirements may be asked of you in a very general way because this is not a test about PCI-DSS and its specific standards or its specific requirements but there may be a kind of question that you could face that would ask you this in a more general way. As I've mentioned, this is not a vendor-specific or a technology-specific exam but in terms of the widespread acceptance of such standards as you see here, there is a context in which you might see these.
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.