Don't Miss NIST...

I interact with NASCIO (National Association of State Chief Information Officers) and its members on several fronts.  The good advice and lessons learned that come out of those discussions are ridiculously helpful in talking with different State & Local (S&L) organizations in my travels around the country.  In that context, we have a lot of debate about "best practices" when it comes to security and risk in the Public Sector space.  Even if you're a S&L agency, not a FISMA regulated entity, and the question isn't pointed directly at the intersection of security and risk, for so many concerns I see the world through "NIST-colored" glasses.  No matter your size, charter, state/local/tribal/federal orientation, or your bench of skillsets, I feel checking your alignment with NIST standards and specs can and will make your life much easier in the long run.  Why NIST?


1)                  The word "mandatory" springs to mind.  If you're in the Federal Executive Branch (subject to FISMA) or several other arms of the Federal Government, if you interact with Federal systems (e.g. Health, Revenue, Justice, Public Safety, etc.) or touch some type of Federally funded program (SLDS, ARRA, DHS, etc.) odds are some piece of legislation somewhere says "thou shalt do ___________."  And odds also are that NIST developed the required specs you're using to connect, authenticate, share, secure, etc. on the heavy lifting side of that mandate.

2)                  It's clear.  There's that old line about "sausage and legislation...two things no one wants to see being made."  The triple-column, dry legal code and requirements that the Legislature spits out is seldom worded for rapid IT consumption and implementation (occasionally basic comprehension can even be a challenge.)  NIST was put here to connect the dots between the occasionally coherent requirements we're faced with and the care and feeding of our core systems.

3)                  It needs to stand on it's own.  An entire industry has grown up around governance, risk, and compliance (GRC) frameworks.  No small part of the GRC industry is consulting services.  This is not a knock on consulting services, they can play a huge part in righting the risk mitigation and security ship.  But part of the premise of the NIST body of work is that most components have to be at least comprehensible without a 12 week professional services engagement.

4)                  It's relevant.  The Public Sector is it's own unique animal.  Granted, many of the individual security controls you're addressing in a SOX 404 exercise, a PCI Self-Assessment Questionnaire, and a FISMA audit may be nearly identical, but there's value in the continuity of a public-sector facing set of standards.  While the needs and characteristics of a County Dept of Corrections will vary widely from those at a State Dept of Fish and Wildlife, and those will stand in stark contrast to what's required at FEMA or a Dept. of Energy Laboratory, there is a commonality running through the operations of public sector IT.  The core funding and mission flows from public dollars to public services.  At the individual control level, we may not see much difference - but when it comes time to rationalize procurement and enterprise architecture decisions with our collective raison d'etre, Public and Private Sector are two distinct worlds.

5)                  NIST is comprehensive.  As technologies and processes change, NIST answers the call for guidance by adding another piece to the corollary of documentation.  Wireless protocols no longer secure and obsolete?[i]  Slapped with a new mandate for multi-factor authentication?[ii]  Need to provide a new batch of security metrics for oversight?[iii]  The answers are likely sitting in a Special Publication, Processing Standard, Inter Agency Report, or Lab Bulletin out there or currently under development.

6)                  It's free.  Now I'm not suggesting that the best framework for your org should come out of a "lowest-bidder" exercise, but there are a few practical freedoms in using a standard that isn't covered by copyright.  You can sample, disseminate, model, replicate, tailor, cite, and train on it without a whole slew of problems that come out of using a proprietary body of work.  This probably isn't as important to you if I had your attention at #1 - "It may be mandatory."  But if you're not specifically subject to any of the NIST standards or regulations, there's a lot of agility working with a public domain framework affords.


There's also the common sense vibe that sometimes NIST is the only place with a description, catalog, or specification that's on point for your needs.  To be clear, by saying all this I'm not disparaging any other (public or private) guidance or framework.  Just as no one security piece or practice will secure your entire enterprise - no one standard will be a "magic bullet."  Security is an iterative process of multiple efforts and course corrections, and sound advice will come from a number of sources.  I do, however, suggest that if you're in the Public Sector, NIST needs to be in your toolbox.  And like it or not, funding specs, compliance mandates, and programmatic requirements are making alignment with NIST part of our critical path.  Seriously...don't miss NIST.


[i] NIST Special Publications 800-97, 800-120, 800-127 for example...

[ii] Just one route might be a card solution - try NIST Special Publications 800-73, 800-85, 800-96, 800-104, and 800-116 for starters

[iii] NIST SPs 800-117 & 800-126 detail one approach.


Post a Comment:
  • HTML Syntax: NOT allowed

Identity and Access Management topics related to Federal, State and Local government agencies


« June 2016