Leveraging NIST 800 body of work for regulatory compliance

Regulators should leverage NIST’s body of work

People are tired of hearing it from me but I am not tired of saying that I’m a big fan of the work done by NIST over the years. You hear many ‘experts’ saying that NIST is behind the curve, we are in Web 2.0, cloud, social networking, iPad era and NIST guidance is for the 90s. There is an element of truth in that but I would like to state the following:

1.       There are thousands of people and companies innovating every day and for every major product or service that gains acceptance, there are 19 that fade away. As a rule-making body, you cannot be analyzing and making rules for all 20 but only for the one that gains wide-spread usage. The remaining 19 (or those that survive) will be used by some folks because it is particularly relevant to them or because they are geeks who love non-standard stuff but you cannot invest time and money in making rules around each of them, especially if you are public body and give away most of your work free in the public domain.

2.       It is important to understand that rule-making, while important & useful at granular level, is not about technology. It is about creating a systematic approach to securing and monitoring technology platforms that you use. Many people see these rules as if they need to have a one-to-one correspondence with each technology product and that is quite unnecessary. Even if you look at something as granular as PCI DSS, there will be a new security device that does things differently and one may say PCI DSS does not give guidance on how to handle that and hence, it is behind the curve. Security, audit, monitoring and reporting principles are universal and if adopted properly, equip a good security analyst or auditor to easily adopt them to new or emerging technologies.

3.       NIST is accelerating its research and publication process in 2011 and hopefully will receive the funding and priority to keep it up going forward.

Let us take a new release from NIST on “Managing Information Security Risk” (800-39) released this week (March, 2011). It introduces two important ideas for any organization to consider:

1.       Multi-tiered strategic view of risk management:

a.       Tier-1 view of enterprise wide risk (tolerance policy, investment in ERM, appetite)

b.      Tier-2 view of business process level risk (point of failure, architecture, controls)

c.       Tier-3 view of Information system level risk (SDLC, vendor security, audits)

(Only after performing this analysis, move to tactical risk management actions)

2.       Lifecycle view of risk management

a.       Closely linked to the above, see the total picture of what you are doing and do not spend money and efforts on stand-alone sporadic actions

b.      E.g. a “point-in-time penetration test” on your network devices to comply with, say, PCI DSS, and next day you have a major breach that shakes your company and reputation. Why does it happen? There are many reasons and they are mostly managerial rather than technical. Issues like how did you decide which part of your network needs to be tested, where is your data stored, what is your access control policy and practice, are you config and security patches up-to-date and so forth. Most of the vendors and tools that you use for a penetration test will do a reasonable job  (occasionally they do a bad job as well) but the risk management process fails to them what to look for and that is why the money and effort on that test does not get you results.

I do not know if bodies such as FFIEC and SEC make conscious and extensive use of the NIST resources as NIST’s mandate is the Federal Government security (FISMA). The Frank Dodd Act is sure to bring many more regulatory rules (the process has already begun and we can clearly see that the documentation aspects of compliance are going to expand significantly) and NIST provides a great foundation for an organization to take a very systematic, regulation-agnostic approach to technology risk management as an “in-principle” and “proactive” compliance rather than “topical” and “reactive” compliance. No business manager needs to be told what is better.

If a regulator can give specific guidance on how compliance is measured, it enables the regulated entities to work on it. E.g. as PCI DSS provides detailed instructions, compliance has become an organized process. On the other hand, say, SOX 404 does not state anything on how, what or where, compliance efforts have been sporadic and expensive and many extensions and dilutions were granted in its implementation.

A hacker hacks into a government website using exactly the same tools and techniques that he will use to hack into a bank’s website. Hence, if NIST guidelines are good enough to protect the government website, it is good enough to protect the bank website too.

If you use NIST as your information security framework, you don’t need to wait for all the rules of FDA to emerge, you can proactively accelerate your process not only to comply with the laws but actually make your information more secure. Don’t hesitate to tell your regulatory examiners and external auditors that you use NIST as the foundation for your information security governance. If they continue to maintain a poker-face, you know you have made progress.

Buck Kulkarni

March 4, 2011