Research

About a year ago I first heard the dreaded acronym “MVC”. It was during a call about a potential project, and this contact kept namedropping it like Kanye or something – not that I knew what it meant at the time. I kept wondering how Model/View/Controller was so important to their deployment. Eventually I learned it stands for “Minimum Viable Cloud”. I want to take whichever consultant came up with that concept, dip them in chocolate, and toss them into a bear preserve. In the spring. Say around March or April. I’ve been hearing it more frequently since then, and here’s what it means, why I think it is a stupendously terrible idea, and a better alternative. Note that I don’t assume MVC is universally defined or understood – it seems to be more of a catchall term designed to assuage cloud fears while driving big consulting projects. The general consensus seems to be that you predefine and build your cloud environment, then shovel all your projects into it. Typically this is a single account (bye bye blasts radius management), with 1-3 virtual networks (dev/prod/???), and the full architecture built out like a single data center. All the security groups, subnets, and other major structures are predefined. These deployments are more likely to have a bunch of virtual appliance versions of the same tools used on-premise. There is a lot of complex work to set up and isolate subnets and such, some minimal cloud-level IAM and alerting, and a lot of baggage carried over from existing operations. It doesn’t work. Not for long. MVC fundamentally breaks agility and reinforces bad old habits. Even if you try to design a ‘friendlier’ MVC deployemnt, it doesn’t scale and doesn’t offer the security benefits of a cloud-native approach. With MVC everything you deploy has to fit an established pattern. Instead of fitting security to the project you are forced to fit the project to the security. Don’t interpret that statement as me saying security is a lower priority – it is an equal priority. The best security is when the parts are designed to cooperate and reinforce each other. You can’t do that with MVC. It is an anti-pattern. MVC also typically results in many assets of differing security contexts sharing the same virtual network and cloud account/subscription/project. It is often selected because, at the start it looks easier to manage, but in the long term it becomes harder, as you struggle to deal with all those conflicting contexts and isolate everything out in an environment not designed for that type of isolation. Instead follow the cloud-native pattern… which works for lift and shift as well as new builds. In this approach the application and security architecture teams work together and design in parallel (ideally – you could add in security later, just not too late). You fit the security to the application. At the start there is a lot of learning new things, but over time you learn and build a library of relatively standard design patterns. You deploy into a clean account/subscription/project each time if you can. This enables you to minimize the number of privileged users who need access to the cloud account and simplifies, overall, the configuration of the accounts. This approach helps you close in on immutable and indempotent deployments (for production – development environments are still more free-form). You now have an isolated environment working within very defined constraints/definitions. This reduces complexity and is a bit of a security dream. It does increase another kind of complexity: managing all these different environments. There are organizations managing thousands of cloud accounts today. Management shifts to automation, deployment pipelines, and maintaining security guardrails across accounts. The alternative is complexity within an account, often leading to conflicting and difficult-to-enforce security boundaries. And that’s the key. I don’t claim managing cloud-native deployments is necessarily easier, but it shifts management in a direction that improves inherent security. You gain stronger security boundaries and tighten control, but in exchange you need to adopt automation and new management techniques and tooling. MVC always fails over the long term. Always – you inevitably reach a point where too many things, across too many conflicting security contexts, are sharing a single implementation. It seems easier up front (and probably is, especially if you are new to the cloud), but sooner than you think you will need to make security compromises. It additionally inhibits your ability to properly design security for any individual project, because the applications are restricted to a pre-configured set of rules. MVC usage correlates highly with ‘monoclouds’: stuffing everything into a single account with a small number of virtual networks. We also see some MVC deployments where they create a standard template and then deploy it into multiple accounts. Those aren’t quite as bad, but you still cannot fit security to the application and deployment. This is a period of massive transition. Greater than corporate adoption of the Internet itself, because the cloud requires deeper reengineering of underlying architectures. This is an incredible opportunity to break out of constraints of the past which have inhibited security – especially backward-looking MVC and monoclouds. Focus on education, automation, and tooling. Instead of building an MVC take a cloud project (ideally a new one) and “right fit” its security. Then take those lessons and move onto the next project. You will trade off getting all your sh** into the cloud as quickly as possible, but gain security and be able to move even more quickly over the long term. Share:

As we previewed in the Introduction to our Endpoint Advanced Protection Buyer’s Guide, the first step to selecting an endpoint security product is figuring out what problem you are trying to solve. Then figure out which capabilities are most important to solve those problems. Only then can you start trying to find a vendor who meets those requirements. This is what we call establishing *selection criteria. In the Introduction we also explained how organizations need both prevention and detection/response to fully protect endpoints. But these two capabilities do not need to be bought or deployed together – the technologies can come from different vendors if their agents play nicely together, and not every endpoint needs extensive forensics capabilities. So these two main functions need to be treated differently. Though, to put a nice big caveat on that statement, there is value in leveraging prevention and detection/response from the same vendor. There is also value in having network security controls that work tightly with the endpoint security in place. Is that enough to drive you to a single vendor for everything? As usual it depends, and we’ll work through the decision points. Over the next 5 days, we will explain the main Prevention capabilities you need to understand to select and evaluate these solutions. We’ll start by explaining the latest categories of attacks because many demand new and innovative defenses. Then we’ll dig into the capabilities that can prevent these attacks. Finally we will dig into and explain how the foundational technologies underlying these new endpoint security platforms work. There are nuances to how each vendor implements these technologies, and they’ll be sure to tell you how and why their approach is better. But without a clear understanding of what they are talking about, you cannot really discern the differences between vendors. Attacks There are many types of attacks, which all have one thing in common: compromise of the endpoint device. To avoid exploding your cranium by trying to cram in infinite possibilities, we will categorize and describe the major attack techniques, which provide the basis for figuring out your best protection strategy. But before we get there, we will intentionally conflate the delivery of malware with device compromise. We do this because companies in this space describe their capabilities in terms of attacks – not necessarily by the means of defense. To illuminate a bit, consider that some malware may be delivered by a phishing message and then use a known vulnerability to compromise the device. Is that different than the same attack was delivered via a drive-by download in your browser? Of course not – stopping the attack on the vulnerability is all that matters, not the delivery method. But, alas, security industry marketing machinery prefers to describe these as two totally different attacks. File-based Attacks In the first attack bucket, an unsuspecting user executes a compromised file which executes malicious code to compromise the device. This is basically traditional malware, and protecting against these attacks is the basis of the endpoint protection business we know today. In these first two categories, files are allowed onto the machine by the device ‘owner’. This can happen via email or a legitimate web browsing session, or when a user allows a download onto their device (possibly through social engineering). In any case, the file shows up on the device and must be evaluated. Known files (classic AV): Someone has seen this file before, and we know it’s malicious. The file’s hash is in a database somewhere, and the endpoint security tool checks to see if each file is recognized as bad before it allows execution. The challenge with using a blacklist of malicious files is scale. There are billions of files known to be bad, and keeping a comprehensive list on each endpoint is not feasible. It’s also not efficient to check every file against the entire blacklist prior to execution. Unknown files Otherwise known as zero-day malware, these files have not yet been seen and hashed as malware, so any defenses based on matching file hashes will be unable to recognize the files or detect the attacks. The challenge in detecting this type of attack is that it’s very easy to change the complexion of a malware file (using a file packer or other technique to change its hash), which means the file won’t show up on blacklists. Additionally, adversaries have sophisticated labs to test their malware against common endpoint prevention offerings, further challenging today’s solutions. The next attacks are a bit more obfuscated and require different tactics for prevention and detection: Document/macro attacks: In this kind of attack malicious code is hidden within a known file type like PDF or Microsoft Office, typically as a macro. The content is the attack vector and requires interpretation by the user’s application, but the attack is not an executable binary program. When opening or performing some kind of activity with the file, its code will execute to compromise the device. These attacks also get around traditional signature-based defenses because the file is a legitimate document – it’s the (invisible) contents which are malicious. Legitimate software: Yet another way to deliver malicious code to a device is to hide it within legitimate software. This typically happens with common applications (like Adobe Reader), system files, and multimedia files. Unsuspecting users can click a link within a legitimate search engine and download what they think is a legitimate app, but it might not be. With this type of attack everything looks kosher. It’s a familiar app and looks like something the user wants. To protect against these attacks we need to focus more on what the file does instead of what it looks like. File-less Attacks Over the past decade savvy attackers realized the entire endpoint protection business was based on attacks leveraging files on the compromised device to store malicious code. But if they could deliver malware without storing it in files, their attacks would be much harder to detect. And they were right.