More than once, I’ve been in the meeting where someone is questioning whether or not to get a particular security system. This someone asks, “OK, so if someone has the CEO at gunpoint and forces him to log in to his PC and then takes pictures of the documents visible on his screen, then blackmails the CEO to say nothing to the local police as he slips away into the shadows and to a foreign nation where extradition is difficult, will you be able to stop that data exfiltration?”

“Uh, no…”

And then that someone crosses arms and boldly states, “Then why bother with all this trouble if it’s useless against a *real* hacker?”

Now, maybe it’s not exactly that scenario. But whatever’s offered up is an advanced use case that even the tightest of security nets would have trouble catching. And if the current state of the IT environment is where someone could bring a PC from home and copy all the files off the main server, maybe that group of advanced use cases isn’t what anyone should be worrying about right now.

Which is why it’s important to consider such exotic cases, but rate them for what they are – exotic. When someone brings up a basic use case that is well within the capabilities of the security product to restrict, rate that as a basic case that will be among the first to be dealt with as the system is introduced. As the system matures, then the more mature cases can be considered.

I deal with NAC in my role, so I see the range of use cases all the time in my meetings with customers. Block a PC that isn’t part of your firm? This is not difficult to do. Block someone spoofing the MAC address of a printer? Well, that’s more than a basic task. I have to ask how we can tell a legitimate printer apart from a spoofed device. If there is no way to tell, then we have to ask if it’s possible to treat all printers as outsiders and restrict their access. This is where maturity comes into consideration.

Maybe we just proceed forward with the PC use case and think some more about that printer issue. Perhaps once we have the PC use case dealt with, there may have been time enough to set up an SNMPv3 credential to use to log on to legitimate printers. Maybe there was enough time to determine how to set up printer VLANs and restrict them. If so, then we’re ready to deal with that printer issue. While we’re doing that, we could be thinking about how to handle the security camera issue, or something like that.

Each environment will have different levels of maturity for their use cases. Perhaps at one firm, it is easier to deal with securing PCs than it is with MacOSs. At the next one, they could have a better handle on their MacOS management than they do with PCs. Maturity could simply be deciding between equally-difficult tasks about which one will be done first.

Maturity can also be seen in calling out when a use case goes beyond the capabilities of the product under consideration. A proxy server does not provide its own physical security system, for example. So, if we entertain scenarios in which physical security is defeated, we should be tabling those until we’re looking at a physical security system. By the same token, if for a scenario to be plausible another security system has to be defeated, then that begs an argument about the safeguards and durability of the system that has to be defeated, not the one under current consideration.

We also see maturity in getting different systems to work together. Being able to automate responses from one system to another gives firms the ability to deal with increasingly advanced threats. All the while, as long as we keep a perspective on how mature our security systems are, we know what level of threat we can deal with.