So here 's a question that came up in my head and one that I suggested to Bjoern after the session today. Worth some noodling...
When building a cyber program do you:
A) Get a framework? - Most times, people don't know what they don't know and they end up going out to the internet to grab some kind of checklist to "cover the bases" with respect to network security. Frameworks like NIST 800-53 and 800-171 as its checklist are great because they'll cover everything.
But a framework has the tendency for those who use one to cover more than we need. Do we pick and choose which parts to use? Can we say that we used the NIST framework if we only use a part of it? Going through a framework can create a lot of documentation that no one will ever read.
(kinda like all the documentation we write, but alas)
B) Perform a Risk Assessment? - The risk assessment is the way an organization can tailor its cyber program to meet its specific needs. An organization can walk through all its assets and services and define priorities.
However, I've always seen two things when doing a risk assessment. One, the defining the risk tends to get subjective. We can put impact to a cost scale, but probability is a little more nebulous. Say you have two incidents on a risk in year 1, none in year 2, and none in year 3. High risk? Medium risk? Or do we define it ourselves in a subjective kind of way. Sure that brings in the idea of risk appetite, so its different for everyone. The other thing I see in risk assessment is making sure we've identified everything. Seems like that's an ongoing process, like one day, you're walking by an office and notice an IoT device that's been there for an age, but we forgot about it in risk planning.
So, what do you think about this? Chime in and let's see what you think.
/r
UPDATE: I might have also wrote the question a little badly - the question isn't whether we do those things - it's the approach you take first in doing a cyber program build. Some will go with the Framework first, which prescribes a risk assessment, the other will do the risk assessment first which prescribes a framework. ..
When building a cyber program do you:
A) Get a framework? - Most times, people don't know what they don't know and they end up going out to the internet to grab some kind of checklist to "cover the bases" with respect to network security. Frameworks like NIST 800-53 and 800-171 as its checklist are great because they'll cover everything.
But a framework has the tendency for those who use one to cover more than we need. Do we pick and choose which parts to use? Can we say that we used the NIST framework if we only use a part of it? Going through a framework can create a lot of documentation that no one will ever read.
(kinda like all the documentation we write, but alas)
B) Perform a Risk Assessment? - The risk assessment is the way an organization can tailor its cyber program to meet its specific needs. An organization can walk through all its assets and services and define priorities.
However, I've always seen two things when doing a risk assessment. One, the defining the risk tends to get subjective. We can put impact to a cost scale, but probability is a little more nebulous. Say you have two incidents on a risk in year 1, none in year 2, and none in year 3. High risk? Medium risk? Or do we define it ourselves in a subjective kind of way. Sure that brings in the idea of risk appetite, so its different for everyone. The other thing I see in risk assessment is making sure we've identified everything. Seems like that's an ongoing process, like one day, you're walking by an office and notice an IoT device that's been there for an age, but we forgot about it in risk planning.
So, what do you think about this? Chime in and let's see what you think.
/r
UPDATE: I might have also wrote the question a little badly - the question isn't whether we do those things - it's the approach you take first in doing a cyber program build. Some will go with the Framework first, which prescribes a risk assessment, the other will do the risk assessment first which prescribes a framework. ..
Last edited: