This post is my admittedly imperfect attempt to “reconnect” data security controls to threats. It is also my intent to continue pulling on the thread I touched in this post— so expect more posts about that.
Let’s first get this out of the way: there are absolutely security controls that are NOT connected to threats, regulations or business requirements. They just are, like Winnie the Pooh. And this is OK. My former team had excellent research on this very topic, under the label of “security hygiene.” This said, my “cyber-intuition” tells me to be very, very conservative with tossing controls (whether technical or paper/administrative) into the hygiene, baseline, default or “best practice” bucket.
Specifically, many security professionals were burned — some perhaps even scarred for life — when they told the business to implement a particular security technology because “it is a best practice” and then were beaten up bloody as a result :-) Even when the above research was being written, there were a few savage fights … eh … gentlemanly discourses on the team about some technologies being IN or OUT of the hygiene bucket. If I recall correctly, patch management was non-controversial as a hygiene control (even though the remediation time variable is set by risks or compliance frameworks such as 30 days in PCI DSS).
So, let’s pre-summarize this by stating that a small number of such controls exists, and there is that. Now, another brief side note, where else can security controls come from? Naturally, compliance requirements (PCI DSS, GDPR, HIPAA etc), business requirements (such as from partners, contracts, etc) and of course threats — our dear subject here. Notice that I am now going to punt a small problem — I will not bring up the voluntary control frameworks like NIST CSF, ISO27001 and others (in all honesty, they are meant to be tuned based on your risks/threats, rather than followed blindly like compliance). Lately, BTW, I’ve been realizing that perhaps there is also a category of security controls that make people feel secure … but I digress.
Now, data security. Let’s pick a few data security controls such as encryption (my recent favorite for some reason), Data Loss Prevention (DLP) including data discovery, data classification (note the paper title here and see this too), tokenization, data masking, data-level access control, etc.
Encryption. Naturally, a large number of mandates prescribe that you encrypt data, whether in transit or in storage. PCI DSS is very clear about that. HIPAA strongly implies it. Numerous other guidance documents do too. Some even veer into key management advice, but some do not — so you must encrypt, but it’s OK to leave the key under the doormat … However, given the costs and the risks (such as if you encrypt properly, losing the key also loses the data for you … duh!), I prefer to treat encryption as a threat-based control as well as a compliance-based one.
Here is a trivial case: encrypt the mobile device to prevent data loss in case of device theft. Naturally, the thief — the likely threat actor in question — does not have a key (unless Post-It notes are involved). Here is a harder case: servers in a data center. Ah, what is the threat here? Not server theft, I hope. Around 2013, Gartner published a piece that perhaps you should not encrypt data center servers unless you know why specifically you are doing it. It caused a small uproar among the “but encryption is a best practice!” crowd. To have encryption be truly threat-based here, one needs to think about what problem you are solving with encryption, frankly. Because you sure are paying the cost, so won’t it be nice to be clear about the benefits?!
Here is an even harder case: encryption of public cloud instances. Now, please don’t say server theft. Is it about a fellow cloud user taking your data? An attacker with access to your instance? A cloud provider rogue employees? BTW, we just launched this ingenious piece of technology called External Key Manager that allows you to keep your cloud encryption keys on premise and not in the cloud. Could you guess the threat model for that? More on this in future posts…
BTW, I feel like “guess the threat model” should be a mandatory game for many security leaders who push control frameworks and other “solutions before problems” security approaches …. The forgotten art of threat assessment needs to be practiced more! Encryption and key management used to protect against device theft and encryption deployed to protect against another government getting to your corporate data look very, very different from the implementation perspective. Encryption is not a compliance checkbox … or rather shouldn’t be.
DLP. With DLP, things are a bit murky as well. There is still a raging debate about whether DLP can be effective against anything but accidental leaks by a well-meaning employee. However, this still counts as good news, because there is an explicit threat here — albeit a deeply unimpressive one. DLP (last I checked) is not explicitly mandated by any compliance documents. However, it is a very popular implied control for many regulations, again PCI DSS and GDPR come to mind. Admittedly, very few people treat DLP as “basic security goodness” because of huge operational burden associated with it, especially if DLP is aimed at catching technically adept malicious insiders (and, yes, I’ve seen such cases — and DLP worked well… as long as the team of 50 top-notch security engineers were there to make it work…). Just as with encryption, a DLP implementation to cover a couple of PCI DSS compliance cases will look dramatically different from a multi-pronged large scale deployment aimed at preventing the insiders from stealing your secrets. DLP to support privacy in the cloud would look different from cloud DLP focused on user mistakes and omissions. In other words, threat models matter here as well!
Let’s summarize: start from the painfully obvious “don’t deploy security controls — whether data security or others — unless you know what problem you are solving.”
A deeper conclusion is “explicit threat models do make security better, save money, reduce risk, etc.” Finally, “accept that some security controls just are — and this is OK as long as the list is small.”
Definitely, to be continued …
Related blog posts:
(cross-posted from Anton on Security)
Comments