In case you missed it, NIST released draft cyber security Information Sharing Guidance. I’m sharing some of my thoughts on the document with the general public.
My first post dealt with recommendation 2. Now let’s look at recommendation 1. It reads:
Organizations should perform an inventory that catalogues the information an organization currently possesses, the information that it is capable of producing, and document the circumstances under which this information may be shared.
The underlying concept behind this recommendation is absolutely solid. It’s a necessity.
However, it seems wordy to me — too much good stuff smashed in there. How about splitting it into two pieces: one for information collection/receiving (which the NIST draft calls “an inventory”), and one for sharing (which NIST calls “document the circumstances”).
I am going to focus on the collection/receiving piece. Here’s what I suggest:
Organizations should conduct a security intelligence gap analysis, that describes intelligence requirements the organization is and is not meeting.
I believe that information sharing is inherently an intelligence discipline rather than a cyber discipline. I think we should use language and concepts that have been used for years by intelligence professionals.
So, to do cyber information sharing, you have to start with “requirements” — as in “intelligence requirements”. These are what you want to know — but don’t know yet. There is real value in taking the time to identify those “known unknowns”.
Generating intelligence requirements requires a coordinated effort among many stakeholders across an organization.
For example, let’s take an electric utility: does your intelligence team know the vendor, product, and version of the PLC controlling the coal conveyor at Plant 16? Because without knowing 1) that requirement, and 2) the person who has that requirement, the intelligence team cannot effectively collect and report. And if your intelligence team isn’t collecting and reporting, then your plant security lead isn’t taking appropriate action based on the dynamic threat environment.
A few rough example requirements might include:
- When were coal conveyors last attacked? Who did those attacks? Why? Where? How?
- What exploit tools are known to enable attacks against PLCs controlling coal conveyors?
- What IDS signatures exist for detecting those attacks?
I have to tell you: when it comes to threat intelligence/situational awareness, if you take short cuts up front — if you skip, or neglect, or rush the requirements — you are only impairing your ability to take appropriate action. Don’t do that!
Critical Intelligence is on the cusp of releasing a unique tool that helps operators of critical infrastructure generate intelligence requirements — and then collect against those requirements. If you are an intelligence analyst or a security manager working in critical infrastructure, shoot an email to firstname.lastname@example.org to request a demo.