September 13, 2012

Last Updated on January 13, 2024

Recently I have been discussing an interesting project with a potential client that is in the engineering business.  This organization needs to provide attestation of their ability to secure critical engineering designs in both the private and public sector.  A new contract is driving the project and making the first portion of the work effort NIST centric, but there is awareness that providing the same assurance to private sector clients using something like ISO 27001 is also of value.
I’m always “surprised” when I revisit NIST documents that I am familiar with and have used for years and find great content.  I guess it’s the idea of viewing the “old” content through the “new” lens of my ongoing work experiences.
The particular guidance that I really enjoyed re-reading was from NIST 800-37 “Guide for Applying the Risk Revision 1 Management Framework to Federal Information Systems,” which is the NIST guidance for Systems Certification & Accreditation (SC&A).  The document does a great job of explaining the importance of proper ISO-27001 scope definition:

“One of the most challenging problems for information system owners … is identifying appropriate boundaries for organizational information systems. Well-defined boundaries establish the scope of protection for organizational information systems (i.e., what the organization agrees to protect under its direct management control or within the scope of its responsibilities) and include the people, processes, and information technologies that are part of the systems supporting the organization’s missions and business processes …  Information system boundaries that are too expansive (i.e., too many system components and/or unnecessary architectural complexity) make the risk management process extremely unwieldy and complex.  Boundaries that are too limited increase the number of information systems that must be separately managed and as a consequence, unnecessarily inflate the total information security costs for the organization.”

While scoping in the NIST world is relevant to the System Security Plan (SSP), and ISO 27001’s scoping is relevant to the Information Security Management System (ISMS), the key tenants are the same:

  • Choose a scope that is “manageable” but still encompasses the business processes that the entity receiving the assurance (Security Assessment Report or ISO-27001 Certificate) is looking for.
  • Understand critical system boundaries and ensure that the SSP or ISMS reflects the controls relevant to critical risks outside the direct control of the organization. For example, if the scope is reliant on a third party for data storage, how do you ensure that the risk associated with this storage that you don’t directly control is communicated, verified, and monitored?

On this particular project, we expect to develop their SSP in a manner that reflects the fact that they are going to want to ISO-27001 certify the environment next year.
What is also interesting to me is that we have a second project gearing up that is nearly identical – a cloud service provider that wants to be both FedRAMP and ISO-27001 certified. I suspect that this won’t be the last blog post I write about “new” NIST guidance I find in “old” NIST documents.

Perhaps I’m not the old dog I feared I was.