What the CISSP Should Be

Today I saw a new comment on my criticism of the ISC2's attempt to survey members on "key input into the content of the CISSP® examination." Several of you have asked what I would recommend the Certified Information Systems Security Professional (CISSP) exam should cover. I have a very simple answer: NIST SP 800-27, Rev. A (.pdf).

This document, titled Engineering Principles for Information Technology Security (A Baseline for Achieving Security), is almost exactly what a so-called "security professional" should know. The document presents 33 "IT Security Principles," divided into 6 categories. These principles represent sound security theories. For future reference and to facilitate discussion, here are those 33 principles.

1. Security Foundation




• Principle 1. Establish a sound security policy as the “foundation” for design


• Principle 2. Treat security as an integral part of the overall system design.


• Principle 3. Clearly delineate the physical and logical security boundaries governed by associated security policies.


• Principle 4. Ensure that developers are trained in how to develop secure software.




2. Risk Based




• Principle 5. Reduce risk to an acceptable level. [Note: It does not say "eliminate risk;" smart.]


• Principle 6. Assume that external systems are insecure. ["External" here means systems not under your control.]


• Principle 7. Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness. [The wording is poor. The idea is to identify situations where information owners decide to accept risks in order to satisfy other operational requirements.]


• Principle 8. Implement tailored system security measures to meet organizational security goals.


• Principle 9. Protect information while being processed, in transit, and in storage.


• Principle 10. Consider custom products to achieve adequate security.


• Principle 11. Protect against all likely classes of "attacks."




3. Ease of Use




• Principle 12. Where possible, base security on open standards for portability and interoperability.


• Principle 13. Use common language in developing security requirements. [In other words, definitions matter.]


• Principle 14. Design security to allow for regular adoption of new technology,
  including a secure and logical technology upgrade process.


• Principle 15. Strive for operational ease of use.




4. Increase Resilience




• Principle 16. Implement layered security (Ensure no single point of vulerability).


• Principle 17. Design and operate an IT system to limit damage and to be resilient in response.


• Principle 18. Provide assurance that the system is, and continues to be, resilient in the face of expected threats.


• Principle 19. Limit or contain vulnerabilities.


• Principle 20. Isolate public access systems from mission critical resources (e.g., data, processes, etc.).


• Principle 21. Use boundary mechanisms to separate computing systems and network infrastructures.


• Principle 22. Design and implement audit mechanisms to detect unauthorized use and to support incident investigations. [In other words, from the network side, this means network security monitoring.]


• Principle 23. Develop and exercise contingency or disaster recovery procedures
  to ensure appropriate availability.




5. Reduce Vulnerabilities




• Principle 24. Strive for simplicity.


• Principle 25. Minimize the system elements to be trusted.


• Principle 26. Implement least privilege. [Note: The text also recommends "separation of duties."


• Principle 27. Do not implement unnecessary security mechanisms.


• Principle 28. Ensure proper security in the shutdown or disposal of a system.


• Principle 29. Identify and prevent common errors and vulnerabilities.




6. Design with Network in Mind




• Principle 30. Implement security through a combination of measures distributed
  physically and logically.


• Principle 31. Formulate security measures to address multiple overlapping information domains.


• Principle 32. Authenticate users and processes to ensure appropriate access control decisions both within and across domains.


• Principle 33. Use unique identities to ensure accountability.

Given these principles, the next step is to devise practices or techniques for each. For example, Principle 26 states "Implement least privilege." Practices or techniques include (but are not limited to) the following, which represent my own thoughts; NIST does not reach to this level:

• Create groups which provide functions needed to meet an operational requirement.


• Operate mechanisms which allow temporary privilege escalation to accomplish specific tasks.


• Assign systems administrators the primary task of administering systems. Assign security operators the primary task of auditing system use.

I recommend the exam not delve deeper into specific implementations or tools. One could imagine what those would be, however. Here are examples from FreeBSD; again, these are my thoughts:

• Use the group functionality and assign privileges as required. (Windows might provide a better example, given the number of groups installed by default and their variety of privileges.)


• Use sudo to execute commands as another (presumably more powerful) user.


• Configure system logging though syslog and export logs to one or more remote, secure logging hosts under the control and review of the security team. Consider enabling process accounting via acct. Also consider implementing Mandatory Access Controls.

I do not think an exam like the CISSP should delve as deep as implementations or tools. Staying at the levels of theory/principle and techniques/practices is vendor-neutral, more manageable, and less likely to become obsolete as technologies change.

While I may not be happy with all of NIST's principles, they are much more representative of what the CISSP should address. As a bonus, this NIST publication already exists, and the sorts of people who haggle over principles like these tend to gravitate toward documentation from .gov institutions. Furthermore, one of the better CISSP exam prep guides references the older version of SP 800-27: The CISSP Prep Guide: Mastering the CISSP and ISSEP Exams, 2nd Edition, by Ronald L. Krutz and Russell Dean Vines. In fact, the exact chapter mentioning 800-27 principles (albeit the 2001 versions) is online (.pdf).

A Google search of cissp 800-27 only yields 48 hits, meaning not too many people are making the link. Krutz and Vines have, which is a great start.

What do you think?