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?


rebelslant said…
I agree...800-27 is an excellent general reference. There are tons of others, also free that can be found in the NIST SP 800-x series, specific to certain security problems. And other organizations such as ISACA and ISO offer free guidance as well (ie. ISO 15408 "Common Criteria" used for Information Technology Security Evaluation. As a general reference, however the one I prefer is ISF's "Standard Of Good Practice for Information Security" It's a great overview comparable to 800-27 in most ways, and it's in a form that's ready to use in the real world. (see http://www.isfsecuritystandard.com/index_ie.htm).

In most cases, however, you need to mix and match guidance to address specific security challenges. But the guidance is out there if you are really interested (see: http://qualityit.net/content/view/114/71/ for guidance on Standards pairing to address specific problems.

CISSP is a different animal entirely. It's a certification, not a standard. Like most other general certifications, its objective is not to impart specific role based knowledge, but to ensure a candidate understands substantive information at a high level, and mostly only to support contextual perspective. In other words, it doesn't try to prove you have all the information you need to do your job, but that you have knowledge to obtain perspective in doing your job. It tries to provide a broad enough understanding of all the areas that make up the security domain, and of how security impacts an organization that you can make sound judgements as to how to approach problems, understand the common methods used, and know where to go to get more information.

Security is a broad topic. It means different things to a manager, a network analyst, a sys admin, a dev or a tester. Maybe there should be different flavors of CISSP that distinguish these roles and go deeper in role specific subject matter. But as it is, the proof of the CISSP CBOK is that very few candidates walk aways from the exam not having learned anything they didn't already know, and most all I've met come away with a better appreciation of the challenges faced by other roles in their organizations. That can't be a bad thing.

If you're interested, I've collected information about most of the better guidance documentation, mostly free, at: http://qualityit.net/component/option,com_weblinks/catid,111/Itemid,4/

Bar Biszick-Lockwood
Anonymous said…
I stumbled upon the following as the result of a Google search :

:-O , :-) !

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia