At the end of last year, I heard from a long-time enterprise contact that had a major security concern. The company had installed three layers of security and just completed an audit. It showed that since thIey\u2019d finished their installation they\u2019d had five security incidents, and all of them had originated inside their security perimeter, bypassing most of their protection.\nTheir question was what they did wrong and how they could fix it.\nWhat this company experienced is far from rare, and the source of their problems and the paths to correction are far from easy.\nWe tend to think of security as a goal we can achieve with a simple toolkit. Not so. Security is the state you achieve by dealing with all likely threats, and every threat has to be addressed in its own unique way. Problems can come from hackers gaining access to an application or database from the outside, through things like stealing credentials or exploiting weak authentication.\nThey can also come from exploits, where faults in a program (application, middleware, or operating system) can be used to trigger malicious behavior. Finally, they can come from malware that is introduced in some way. Combinations of the three are increasingly common. Enterprises have tended to focus, as my contact did, on perimeter security as a defense against the first of these security problems. They\u2019ve overlooked, or maybe I should say underthought, the last two.\nFixing those other two problems doesn\u2019t mean abandoning perimeter security, it means addressing all the possible problem sources, and the issues my contact reported offer some insight on rules to sharpen security focus.\nRule One is that building a wall is useless if you keep the gate open. Most companies are way too lax in securing employee devices, and in the majority of my contact\u2019s security incidents, the problem was created by an infected laptop. In their case, work-from-home meant that they extended company VPN access to devices that were not only not secured, but not even inspected. Where possible, work devices shouldn\u2019t be used for private purposes, and vice versa.\nRule Two is learn Latin, or at least the critical Latin phrase \u201cQuis custodiet ipsos custodes\u201d. Freely translated, this means \u201cWho will watch the guards themselves?\u201d\u00a0 Monitoring, management, and even security tools often have privileged access to resources and applications, and in just the last six months we\u2019ve had two major security problems associated with contamination of one of these tools\u2014the SolarWinds breach and Log4j. These issues prove that things we need to run our networks, applications, and data centers can bite us, so we have to pay special attention to them, keeping them updated and watching for maverick behaviors.\nKeeping software updated is key to applying both these rules, and unfortunately that\u2019s often a problem for enterprises. Desktop software, particularly with WFH, is always a challenge to update, but a combination of centralized software management and a scheduled review of software versions on home systems can help. For operations tools, don\u2019t be tempted to skip versions in open source tools just because they seem to happen a lot. It\u2019s smart to include a version review of critical operations software as part of your overall program of software management and take a close look at new versions at least every six months.\nEven with all of this, it\u2019s unrealistic to assume that an enterprise can anticipate all the possible threats posed by all the possible bad actors. Preventing disease is best, but treating it once symptoms arise is essential, too. The most underused security principle is that preventing bad behavior means understanding good behavior.\u00a0 Whatever the source of a security problem, it almost always means that something is doing something it shouldn\u2019t be. How can we know that? By watching for different patterns of behavior. That\u2019s what Zero Trust, another vastly misused security term, should be all about. Sometimes it is; often it\u2019s not.\nWhat Zero Trust really means\nThere\u2019s nothing easier than slapping a label on a product or service. If you look at exactly what a zero-trust solution is, you\u2019ll see that we don\u2019t really even have consensus on the meaning of the concept. How can you trust a meaningless or multi-meaning term?\u00a0 What we want from Zero Trust is behavior monitoring and control.\nI asked my contact how many applications an average worker could access, and the company wasn\u2019t able to get the answer. How, then, could the company know if the worker, or someone working through the worker\u2019s laptop, was stealing data or contaminating operations? They didn\u2019t know what was permitted, so they couldn\u2019t spot what was unauthorized, and that\u2019s where Zero Trust comes in.\nA zero-trust system should assume that there is no implied right of connection to anything.\u00a0 Connection rights are explicit, not permissive, and that\u2019s the property that\u2019s both critical to Zero Trust security and critiical to behavior monitoring and control.\nNobody questions the challenge associated with defining not only the allowed connectivity for each worker, but also the connection requirements for management and operations software, middleware, and more. These difficulties are why enterprises often fail to accept true Zero Trust security and why vendors may make the claim without delivering the needed capabilities. Yes, Zero Trust,\u00a0 is more work, but no, you can\u2019t avoid it and be truly secure.\nEven meeting the challenge of defining permitted connectivity doesn\u2019t end the hurt.\u00a0 A Zero Trust system has to recognize and journal attempts to make unauthorized connections. In fact, it\u2019s that feature that makes Zero Trust so important. Almost all of the inside-the-perimeter attacks will explore connectivity and resources looking for something interesting, and in a good Zero Trust system these explorations will be detected and journaled, which alerts the company to the fact that something is wrong. Prompt action can then save the day.\nThe best way to validate a Zero Trust system some vendor is proposing is to look at how to apply it. It\u2019s good to support a hierarchical framework for assigning connection rights to things, because all workers in accounting, for example, and all accounting software are likely to have common connection permissions.\nIt\u2019s good to have the journaled exceptions stored in a way that traditional analytics and even AI tools can examine them and look for patterns.\nFinally, it\u2019s good if this seems like a bit of work, because products that don\u2019t require much of you are likely to deliver little in return.\u00a0 Creating connection permissions and exception journals are essential to security, so don\u2019t compromise these capabilities just to have an easy time. Security is hard, but recovering from security problems is harder.