I’ve always found the study of the law to be fascinating. Not enough to actually study it, though; I just enjoy picking up various tidbits and concepts. Don’t take anything you read here (or in any other security column, for that matter) as legal guidance. With that said, in this installment I wanted to talk about two kinds of crimes, and how you can practically apply that knowledge to securing your network and services.
A Little Useful Latin
Most legal systems distinguish between crimes that are “malum prohibitorum” and those that are “malum in se.” If your Latin is rusty, you’ll probably be glad to see these translated as “illegal” and “morally wrong” respectively. That is, crimes that are malum prohibitorum are crimes because there’s a law that says so. Not paying your taxes is one example, as is securities fraud. Crimes that are malum in se are inherently wrong—examples might include sexual assault and murder. The exact definitions of “illegal” and “morally wrong” may of course vary between different cultures and societies; there are whole branches of anthropology and sociology dedicated to studying these differences. The distinction is still useful from an information security perspective though.
Two Blocking Mechanisms
If we accept the split between two types of crimes, it seems fair that we’d also have two ways to mitigate offenses. One is to provide technical controls that prevent them. Most of the security work done in the world revolves around this approach; security policies, monitoring, enforcement tools, and so on all fall into this category. The other way to mitigate the problem is to try to teach, train, inform, encourage, and/or evangelize people to get the behavior that we want. Think of all the zillions of hours of anti-phishing training that users around the world are subjected to each year.
The most effective mechanism tends to be some combination of these two methods. For example, the huge reduction in the number of US road deaths due to driving while intoxicated came about both because of technical controls (such as long mandatory jail sentences and high fines for driving while impaired) coupled with non-technical controls (marketing and public awareness campaigns led in large part by Mothers Against Drunk Driving).
Things that are Bad by Definition
From a security viewpoint, we can start by defining some things that are unambiguously always bad. For example, knowingly installing malware on a computer is 100% bad, under pretty much every circumstance you can imagine. The same is true of purposely destroying data. For the most part, though, these kinds of actions aren’t the biggest problems we face. They don’t happen often, and in many cases, they can be mitigated by existing technical controls (such as anti-malware scanners). There are still a few examples of things that can’t be mitigated before the fact, though, human-operated ransomware being one great example. If a financially motivated malicious insider wants to use her authorized privileges to infect a network, it’s very, very difficult to stop them beforehand… leaving you with non-technical controls such as “call the cops” as alternatives.
Of course, there are lots of other bad-by-definition security practices, like reusing passwords between services. Some of these practices might seem like they could shade into “bad only if you get caught” territory, but that’s a slippery slope indeed. The nature of security is that you can’t perfectly predict what an attacker might do, so you have to focus on what they could do and defend against it. This fact argues in favor of strong technical security controls to prevent accidental or careless bad behavior, such as accidental leaks of sensitive information. Microsoft is happy to sell us all the full set of Defender and Purview products to enforce these controls, of course.
Things that are Situationally Bad
Although malum prohibitorum means something that’s wrong specifically because it’s prohibited, it’s probably more useful to think of why we prohibit certain behaviors when it comes to IT security. The first-order reason is that those behaviors introduce risk. When we dig deeper, and think of risk as the product of probability and impact, we can see that some of the classic security rules in our world might need revision. For example, take the ancient rule that passwords should expire so that users have to periodically change them. It turns out that this rule doesn’t improve security, and may actually worsen it because users pick lousy passwords. There are lots of real-world counterparts to this situation, where an enforced rule actually leads to worse outcomes than not having a rule at all. You probably have IT rules in your organization that exist solely because they’ve been around a long time and no one looked at them to see if they still make sense. You may also have rules that have become counterproductive; for example, there are still organizations out there that require users to VPN into the corporate network to access Microsoft’s cloud services, so that their traffic travels from wherever they are to the corporate network and then back out to Microsoft (and then reverses that path for the round trip). Does that add any real security, or does it just add latency, complexity, and annoyance?
Things that are Bad Because You Can’t Enforce Them
Many, many organizations have acceptable-use policies that specify things users aren’t allowed to do on the corporate network or devices. In the main, these rules are enforced after the fact, often through auditing reviews. Sometimes they aren’t enforced at all, though. One key parenting truth that some parents learn the hard way: it does a lot of harm when you make rules that you do not or cannot enforce. It’s bad for the parent and bad for the child. The same is true for IT security. It is better to have a small set of clearly and vigorously enforced policies than to have a larger list of unenforceable rules that users learn can be broken with impunity.
IT Security and Rules Evolve
Nearly every citizen can point at their government (whether national, provincial, or local) and identify specific regulations or laws that are outdated or need reform. It’s worth taking the time to apply the same lens to your IT security rules and policies… not just what you have configured in various parts of the Microsoft admin centers, but also what rules you tell your users they have to follow. Clarify and streamline those rules, then add appropriate technical controls to back them up. Your organization will be more secure, and your users will benefit too.
