Research

As we resume posting Endpoint Detection and Response (D/R) selection criteria, let’s start with a focus on the Detection use case. Before we get too far into capabilities, we should clear up some semantics about the word ‘detection’. Referring back to our timeline in Prevention Selection Criteria, detection takes place during execution. You could make the case that detection of malicious activity is what triggers blocking, and so a pre-requisite to attack prevention – without detection, how could you know what to prevent?. But that’s too confusing. For simplicity let’s just say prevention means blocking an attack before it compromises a device, and can happen both prior to and during execution. Detection happens during and after execution, and implies a device was compromised because the attack was not prevented. Data Collection Modern detection requires significant analysis across a wide variety of telemetry sources from endpoints. Once telemetry is captured, a baseline of normal endpoint activity is established and used to look for anomalous behavior. Given the data-centric nature of endpoint detection, an advanced endpoint detection offering should aggregate and analyze the following types of data: Endpoint logs: Endpoints can generate a huge number of log entries, and an obvious reaction is to restrict the amount of log data ingested, but we recommend collecting as much log data from endpoint as possible. The more granular the better, given the sophistication of attackers and their ability to target anything on a device. If you do not collect the data on the endpoint, there is no way to get it when you need it to investigate later. Optimally, endpoint agents collect operating system activity alongside all available application logs. This includes identity activity such as new account creation and privilege escalation, process launching, and file system activity (key for detection ransomware). There is some nuance to how long you retain collected data because it can be voluminous and compute-intensive to process and analyze – both on devices and centrally. Processes: One of the more reliable ways to detect malicious behavior is by which OS processes are started and where they are launched from. This is especially critical when detecting scripting attacks because attackers love using legitimate system processes to launch malicious child processes. Network traffic: A compromised endpoint will inevitably connect to a command and control network for instructions and to download additional attack code. These actions can be detected by monitoring the endpoint’s network stack. An agent can also watch for connections to known malicious sites and for reconnaisance activity on the local network. Memory: Modern file-less attacks don’t store any malicious code in the file system, so modern advanced detection requires monitoring and analyzing activity within endpoint memory. Registry: As with memory-based attacks, attackers frequently store malicious code within the device registry to evade file system detection. So advanced detection agents need to monitor and analyze registry activity for signs of misuse. Configuration changes: It’s hard for attackers to totally obfuscate what is happening on an endpoint, so on-device configuration changes can indicate an attack. File integrity: Another long-standing method attack detection is monitoring changes to system files, because changes to such files outside administrative patching usually indicates something malicious. An advanced endpoint agent should collect this data and monitor for modified system files. Analytics As mentioned above, traditional endpoint detection relied heavily on simple file hashes and behavioral indicators. With today’s more sophisticated attacks, a more robust and scientific approach is required to distinguish legitimate from malicious activity. This more scientific approach is centered around machine learning techniques (advanced mathematics) to recognize the activity of adversaries before and during attacks. Modern detection products use huge amounts of endpoint telemetry (terabytes) to train mathematical models to detect anomalous activity and find commonalities between how attackers behave. These models then generate an attack score to prioritize alerts. Profiling applications: Detecting application misuse is predicated on understanding legitimate usage of the application, so the mathematical models analyze both legitimate and malicious usage of frequently targeted applications (browsers, office productivity suites, email clients, etc.). This is a similar approach to attack prevention, discussed in our Prevention Selection Criteria guide. Anomaly detection: With profiles in hand and a consistent stream of endpoint telemetry to analyze, the mathematical models attempt to identify abnormal device activity. When suspicion is high they trigger an alert, the device is marked suspicious, and an analyst determines whether the alert is legitimate. Tuning: To avoid wasting too much time on false positives, the detection function needs to constantly learn what is really an attack and what isn’t, based on the results of detection in your environment. In terms of process, you’ll want to ensure your feedback is captured by your detection offering, and used to constantly improve your models to keep detection precise and current. Risk scoring: We aren’t big fans of arbitrary risk scoring because the underlying math can be suspect. That said, there is a role for risk scoring in endpoint attack detection: prioritization. With dozens of alerts hitting daily – perhaps significantly more – it is important to weigh which alerts warrant immediate investigation, and a risk score should be able to tell you. Be sure to investigate the underlying scoring methodology, track scoring accuracy, and tune scoring to your environment. Data management: Given the analytics-centric nature of EDR, being able to handle and analyze large amounts of endpoint telemetry collected from endpoints is critical. Inevitably you’ll run into the big questions: where to store all the data, how to scale analytics to tens or hundreds of thousands of endpoints, and how to economically analyze all your security data. But ultimately your technology decision comes down to a few factors: Cost: Whether or not the cost of storage and analytics is included in the service (some vendors store all telemetry in a cloud instance) or you need to provision a compute cluster in your data center to perform the analysis, there is a cost to crunching all the numbers. Make sure hardware, storage, and networking costs (including management)

As we continue documenting what you need to know to understand Endpoint Advanced Protection offerings, it’s time to delve into Detection and Response. Remember that before you are ready to pick anything, you need to understand the problem you are trying to solve. Detecting all endpoint attacks within microseconds and without false positives isn’t really achievable. You need to determine the key use cases most important to you, and make an honest assessment of your team and adversaries. Why is this introspection necessary? Nobody ever says they don’t want to detect active attacks and hunt for adversaries. It’s cool and it’s necessary. Nobody wants to be perpetually reacting to attacks. That said, if you don’t have enough staff to work through half the high-priority alerts from your security monitoring systems, how can you find time to proactively hunt for stuff your monitoring systems don’t catch? As another example, your team may consist of a bunch of entry-level security analysts struggling to figure out which events are actual device compromise, and which are false positives. Tasking these less sophisticated folks with advanced memory forensics to identify file-less malware may not be a good use of time. To procure effective advanced Endpoint Detection and Response (EDR) technology, you must match what you buy to your organization’s ability to use it. Of course you should be able to grow into a more advanced program and capability. But don’t pay for an Escalade when a Kia Sportage is what you need today. Over the next 5 days we will explain what you need to know about Detection and Response (D/R) to be an educated buyer of these solutions. We’ll start by helping you understand the key use cases for D/R, and then delve into the important capabilities for each use case, the underlying technologies which make it all work, and finally some key questions to ask vendors to understand their approaches to your problems. Planning for Compromise Before we get into specific use cases, we need to level-set regarding your situation, which we highlighted in our introduction to the Endpoint Advanced Protection Buyer’s Guide. For years there was little innovation in endpoint protection. Even worse, far too many organizations didn’t upgrade to the latest versions of their vendor’s offerings – meaning they were trying to detect 2016 attacks with 2011 technology. Inevitably that didn’t work out well. Now there are better alternatives for prevention, so where does that leave endpoint detection and response? In the same situation it has always been: a necessity. Regardless of how good your endpoint prevention strategy is, it’s not good enough. You will have devices which get compromised. So you must to be in position to detect compromise and respond to it effectively and efficiently. The good news is that in the absence of perfect (and often even effective) prevention options, many organizations have gone down this path, investing in better detection and response. They have been growing network-based detection and centralized security monitoring infrastructure (which drove the wave of security analytics offerings hitting the market now), and these organizations also invested in technologies to gather telemetry from endpoints and make sense of it. To be clear, we have always been able to analyze what happened on an endpoint after an attack, assuming some reasonable logging and a forensic image of the device. There are decent open source tools for advanced forensics, which have always been leveraged by forensicators who charge hundreds of dollars an hour. What you don’t have is enough people to perform that kind of response and forensic analysis. You hardly have enough people to work through your alert queue, right? This is where advanced Endpoint Detection and Response (EDR) tools can add real value to your security program. Facing a significant and critical skills gap, the technology needs to help your less experience folks by structuring their activities and making their next step somewhat intuitive. But if a tool can’t make your people better and faster, then why bother? But all vendors say that, right? They claim their tools find unknown attacks, and don’t create a bunch of makework wasted identifying or confirming false positives. And help you prioritize activities. The magic tools even find attacks before you know they are attacks, bundled with a side of unicorn dust. Our objective with these selection criteria is to make sure you understand how to dig deeper into the true capabilities of these products, and know what is real and what is marketing puffery. Understand whether a vendor understands the entire threat landscape, or is focused on a small subset of high-profile attack vectors, and whether they will be an effective partner as adversaries and their tactics inevitably change. But as we mentioned above, you need to focus your selection process on the problem you need to solve, which comes down to defining your main use cases for EDR. Key Use Cases Let’s be clear about use cases. There are three main functions you need these tools to perform, and quite a bit of overlap with technologies underlying endpoint prevention. Detection: When you are attacked it’s a race against time. Attackers are burrowing deeper into your environment and working toward their goal. The sooner you detect that something is amiss on an endpoint, the better your chance to contain the damage. Today’s challenge is not just detecting an attack on a single endpoint, but instead figuring out the extent of a coordinated campaign against many endpoints and devices within your environment. Response: Once you know you have been attacked you need to respond quickly and efficiently. This use case focuses on providing an analyst the ability to drill down, validate an attack, and determine the extent of the attacker’s actions across all affected device(s), while assessing potential damage. You also need to able to figure out effective workarounds and remediations to instruct the operations team how to prevent further outbreaks of the same attack. Don’t forget the need to make sure evidence is gathered in a way

There are plenty of obvious questions you could ask an endpoint security vendor. But most won’t really help you understand the nuances of their approach, so we decided to distill the selection criteria down to a couple of key points. We’ll provide not just the questions, but the rationale behind them. Q1 If your prevention capabilities rely on machine learning, how and how often are your machine learning models retrained? An explanation here should provide some perspective on the vendor’s approach to math and the ‘half-life’ of their models, which indicates how quickly they believe malware attack behaviors change. Some espouse continuous retraining, while others maintain that very little changes daily, so it’s sufficient to retrain weekly or monthly. You’ll also want to understand whether model updates disrupt the end-user experience with significant downloads, restarts, or other intrusions on normal user activity. Q2 How do your machine learning models factor in false positives and minimize them? If a vendor claims they don’t have false positives, run away – quickly. Customer feedback and awareness of false positives are critical to keeping the products current, so get a sense of how they update their protection, models, and whitelists based on what doesn’t work in the field. Q3 Does your agent work in user or kernel mode? Do you protect the OS kernel? The answer is typically both, because some activities aren’t accessible from either user mode and others from kernel mode. For monitoring and EDR it’s possible to stay in user mode but if attacks need to be blocked there is a requirement for some kind of kernel access. This question enables you to get at how an EDR vendor has developed their offering to provide broader prevention. Q4 Can you block an attack before it loads into memory? If so, how? This digs into the vendor’s ability to block a file-less attack, a critical aspect of stopping advanced attacks. Q5 How do you prevent an attacker from gaining root access to the device? You are trying to understand the exploit prevention/blocking capability of the product; at some point to control the machine, an attacker will need root-level access. Q6 How is threat intelligence integrated into the prevention agent? This answer should be about more than getting patterns for the latest indicators of compromise. It should include the ability to block known bad IP addresses at the network layer, as well as cloud-based sandbox integration. Q7 How often and how large are agent updates? How do you age out old signatures to conserve space? How are updates distributed? Attacks change and machine learning models are imperfect, so agents need to be updated. Especially given that what’s old becomes new again, and care needs to be taken when specific signatures or behavioral models are no longer on endpoint agents. This question enables you to assess how the vendor distributes work between the agents and the cloud. It also gets at whether the vendor has a cloud-native management option, which wouldn’t require an on-premise aggregation point. Q8 How does the product integrate with other enterprise security solutions, including SIEM and/or EDR? If the vendor offers a full EDR capability use this question to figure out whether it’s a common agent between prevention and EDR, and the level of management integration. You can dig a bit into how the endpoint prevention product sends data to/from a SIEM, incident response, and network-based controls. Q9 Does the product support automation? If so, how? Given that you likely don’t have enough people to do what needs to be done, you’ll need to automate some functions as the only way to scale up your security operation. Some tools integrate with automation platforms (typically for incident response), while offering some auto-remediation for common problems (make sure you can control what gets done by the machine and what just sends an alert to a console). Q10 Does the product support application control to lock down some devices? How are exceptions to the white list handled? Can you lock down USB ports? For some devices it’s easier and safer to just lock them down and prevent unauthorized executables from running. This won’t work on all devices but having the option provides flexibility in designing endpoint controls. Likewise, locking down USB ports prevents a common mechanism of data leakage. We could ask another couple hundred questions, but these ten should provide a lot of the insight you need to differentiate between vendors. Next week we’ll post a similar set of criteria for Detection/Response. Enjoy the weekend! Share:

Every year, as I travel the security conference circuit, hallway conversations always turn to, “See anything interesting?”. To be honest, I can’t remember the last time I was excited about an honestly cool security technology (which I didn’t create myself, but let’s not go there today). I see plenty of cloud innovation, and plenty of security evolution, but not a lot of revolution. A week ago I picked up my iPhone X. Although I received a background brief on Face ID a couple weeks earlier, I hadn’t gotten my hands on it until then. And, really, didn’t get to play with it until the next day after spending 5 hours restoring my data (all 200 GB of it). Face ID is the most compelling security advance I have seen in a very long time. It’s game-changing not merely due to technology, but also thanks to design and implementation. Apple has created a new authentication modality. First things first: Face ID nails nearly every criteria I came up with to evaluate it. The false positive rate, within certain genetic constraints, is 1 in a million compared, to 1 in 50,000. The inherent security architecture doesn’t look quite as tied to hardware as Touch ID (because the phone needs the sensor package for other capabilities), but does appear to be either as strong (including the software implementation) or close enough in practical circumstances. Watch enough videos of journalists buying masks of their own faces, and it’s clear Face ID is more expensive to circumvent than Touch ID. We haven’t actually seen a public crack yet, but I always assume it will happen eventually. Because history. Apple sometimes has a weak spot underestimating adversaries in their threat models, but they did a good job on this one. In my pre-release article I wrote: Face ID doesn’t need to be the same as Touch ID – it just needs to work reasonably equivalently in real-world use. In my personal experience, and with every user I’ve talked with and in every article I’ve read, Face ID’s core usability is equal to or greater than Touch ID’s. For example, it doesn’t work as well at many angles you could touch your phone from, but it works better in the kitchen and after a shower/workout. I’ve tested it in all sorts of lighting conditions and haven’t found one that trips it up yet. The only downside is I can’t register my wife’s face, and we were become accustomed to using Touch ID on each other’s devices. I do believe it’s slower at actual recognition, but it’s nearly impossible to notice due to the implementation. Face ID is tightly bound to activity, which masks its latency. For example, the time to swipe your fingers is long enough to unlock, where with Touch ID recognition and unlocking were the same action, which made the latency more visible. But I think it’s time to justify that hyperbolic headline. Apple didn’t just throw a facial recognition sensor into the iPhone and replace a fingerprint sensor – they enabled a new security modality. I call this “continuous authentication”. When you use an iPhone you look at the iPhone (some calls and music listening excepted). Instead of unlocking your iPhone once and opening up everything, or requiring you to put your finger on the sensor when an app or feature wants to re-authenticate, the phone can quickly scan your face on demand. And the iPhone does this constantly. Here are the examples I’ve discovered so far: It’s already been widely reported that notification, by default, don’t show details on the lock screen until you look at the iPhone. This is my favorite new feature because it improves security with effectively zero usability impact. I always disabled Control Center on the lock screen for security reasons, but like notifications, just looking at my phone unlocks it. It’s just too bad my thumb can’t reach that upper right corner. Safari now (optionally) uses Face ID before filling in passwords on web sites. Previously, even with Touch ID, they filled in automatically when the phone was unlocked. Apple Pay and the App Store now authenticate with your face without separate authentication actions. Apps can authenticate as you open them. This is where I notice that Face ID is a likely bit slower, but because I don’t need to take another action it feels faster. The lock screen and Safari passwords are, to my knowledge, legitimately new modalities. The others are evolutions of previous use cases. Face ID allows your iPhone to authenticate you under nearly every circumstance you would use your phone and need to authenticate, but without requiring any user action. I think we are just scratching the surface of what’s possible here. Yes, we’ve used tools like Yubikeys plugged into devices to keep sessions open, but I think it’s clear how this is different. This is just the first generation of Face ID. Imagine the use cases once it evolves and can, for example, register multiple users. My Xbox Kinect (may it rest in peace) already does this pretty well, so we know it’s possible (Kinect’s implementation is as secure, and it’s a lot bigger). One of the biggest problems in healthcare security is quickly authenticating to shared workstations in clinical environments… I could see a future version of Face ID significantly addressing that problem. I previously said that Touch ID enables you to use a strong password with the convenience of no password at all. Face ID not only exceeds that mark, it may be the ultimate expression of it, by deeply integrating effortless authentication throughout the user experience without requiring new behaviors. That, my friends, is the power of security design, not just security engineering. Share:

After exploring prevention approaches, you should understand some common technologies which are foundational to endpoint advanced prevention offerings. Machine Learning Machine learning is a catch-all term to indicate that the endpoint protection vendor uses sophisticated mathematical analysis on a large set of data to generate models for detecting malicious files or activity on devices. There are a couple mathematical algorithms which can improve malware prevention. Static file analysis: With upwards of a billion malicious file samples in circulation, mathematical analysis of malware can pinpoint commonalities across malicious files. With a model of what malware looks like, advanced prevention products then Share:

As the velocity of technology infrastructure change continues to increase, it is putting serious stress on Security Operations (SecOps). This has forced security folks to face the fact that operations has never really been our forte. That’s a bit harsh, but denial never helps address serious problems. The case is fairly strong that most organizations are pretty bad at security operations. How many high-profile breaches could have been avoided if one of many alerts was acted upon? How many attacks were made possible by not having properly patched servers or infrastructure? How many successful compromises resulted from human error? If your answer to any of those questions was greater than zero, there is room for improvement. But there is no cavalry off in the distance to magically address operational issues. If anything, SecOps is going to get harder for five reasons: Adversary innovation: Our adversaries are innovating and finding ways to compromise devices using both old and new tactics. They follow the path of least resistance to achieve their mission with focus and persistence. Infrastructure complexity and velocity: With the advent of SaaS and the public cloud, technology infrastructure is getting more complicated and changes happen much faster than before. Data ends up in environments you don’t control and can’t really monitor, yet you still have to protect it. More devices, more places: It seems every employee nowadays has multiple devices which need to connect to sensitive stuff, and they want to access corporate systems from wherever they are. What could possibly go wrong with that? Compounding the issue are IoT and other embedded devices connecting to networks, dramatically increasing where you can be attacked. Maintaining visibility into and understanding of your attack surface and security posture continue to get harder. Hunters hunt: For a long time security folks could be blissfully unaware of the stuff they didn’t find. If the monitor missed it, what could they do besides clean up the mess afterwards? Now organizations proactively look for signs of active adversaries, and these hunters are good at what they do. So in additional to all those alerts, you need have to handle the stuff the hunters find. Skills gap: We’ve been talking about a serious security skills gap for a long time. But it’s not getting any better. There just aren’t enough security people to meet demand, and the problem gets more acute each day. Progress But the news isn’t all bad. By understanding the attacks which may be coming at you through more effective use of threat intelligence, you can benefit from the misfortune of others. You don’t need to wait until you experience an attack and then configure your monitoring environment to look for it. Additionally, enhanced security analytics makes it easier to wade through all the noise to find patterns of attacks, and to pinpoint anomalous behavior which may indicat malicious activity. Integration of threat intelligence and security analytics provides Security Decision Support. It is a key lever for scaling and improving the effectiveness of a security team. We will flesh out these ideas in detail in a blog series. But even with more actionable and prioritized alerts, someone still has to do something. You know: security operations. In many case, this is where everything falls apart. To illustrate, the security teams involved in two of the highest-profile breaches of the last few years (Target and Equifax) were alerted to adversary activity more than once before the breaches became apparent. They just didn’t execute on a strategy to stop either attack before it became a catastrophe. To be fair, it’s easy criticize organizations after they’ve suffered a massive breach. That’s not the point. We bring them up as reminders of a concept we have been talking about for more than a decade: Respond Faster and Better. That’s what it’s all about. As an industry we need to figure out how to more effectively operationalize world-class security practices, quickly and effectively. And yes, we do understand this is much easier to say than to do. But why is this so hard? Let’s examine what security operations tends to do with their time. Those of you with backgrounds in manufacturing probably remember time and motion studies performed to improve productivity of factory workers. Security is far from a factory floor, but the concept applies. Can SecOps be streamlined by figuring out and optimizing whatever takes up a lot of time? We believe the answer is a resounding yes. A lot of security operational tasks involve updates, policy changes, compliance reporting, and other tedious and rote tasks. Certainly there are periods of intense activity, such as triaging a new attack or trying to figure out an effective workaround to an attack. But there is plenty of time spent on distinctly unsexy things. This also causes unmet expectations for people entering the security field. Most entrants have dreams of being a l33t haXor or a threat hunter. Very few wake up excited to tackle change control for a list of firewall changes, or to reimage endpoints after the CEO clicked one of those links. Again. And even if you could find people who get excited about security operations, they would still be human. Which basically means they make errors. But when you need every update and every change to be done right, for fear of opening a hole in your environment large enough to drive a truck (or all your proprietary data – or all your customer data) through, perfection needs to be the goal – even though people are not perfect, no matter how hard they work. Behind the 8 Ball So SecOps is behind the 8 ball, by definition. The deck is stacked against us. The attack surface is growing, the adversaries are getting better, and all we have is ingenuity, a metric crap ton of alerts, and too few humans to get things done. Yep, it sounds like Mission: Impossible. So what? Do we give up? Just pack it in and take a job at a

Let’s resume our discussion of endpoint attack prevention approaches with the options available once an attack actually begins to execute, or once it has already executed on a device. During Execution (Runtime) Once malicious code begin to execute, prevention of compromise requires recognizing bad behavior and blocking it before the attack can take control of the device. The first decision point is whether you want the protection to run in user mode (within the operating system and leveraging operating system protections) or kernel mode (at a lower level on the device, with access to everything – including interactions between the kernel and CPU). Many attacks exploit the operating system and applications which run within the OS, so it’s reasonable to protect in user mode. But you cannot preclude adversaries from attacking the kernel directly, so as so often, the best answer is often both. You need OS and application specific protections, but to comprehensively protect devices you need to monitor and protect the kernel as well. Otherwise you cannot defend against privileged processes and kernel-level rootkits. Exploit prevention: This is a large bucket of many techniques, designed to prevent exploits from compromising devices. Many advanced endpoint products use most (or even all) these techniques, and due to constant innovation by attackers they add new preventions on an ongoing basis. So understand this is a dynamic list.Exploit pathway blocking: This approach is driven by threat research, profiling behaviors observed when malware compromises devices and watching for those patterns in real time. It turns out there are a couple dozen ways to gain control of a machine (of course the actual number is up for debate), and if you make sure none of those patterns scenarios can be completed on a device you have a high level of protection. But be careful to monitor both false positives and resource consumption, because evaluating every function at the kernel level can have unintended consequences, starting with the predictable performance drain. This is a similar approach to HIPS (Host Intrusion Prevention), but detection is focused on device compromise at a much deeper device level. Memory protection: To detect the memory attacks described in our previous post (file-less malware), the memory usage of the operating system and applications need to be profiled; and memory must be monitored for abnormal memory activity which could indicate memory injection, encrypted memory, or hidden modules. Once again, this has driven an emphasis on endpoint threat research because profiling memory usage requires deep understanding of endpoint operating systems and how attackers manipulate devices. Macro protection: To protect against rogue macros, advanced endpoint prevention requires the ability to block unauthorized and potentially malicious macros. Similar to exploit pathway blocking and memory protection, threat research profiles legitimate macro behavior and malicious macros to develop a model for what macros can and should do. Anything that doesn’t fit into this model is blocked. Once again, this technique highlights the importance of threat research to ensure profiles are accurate and current. Script protection: The key to protecting against rogue scripts is to ensure that the logical chain of events makes sense. For instance a browser probably shouldn’t be launching a PowerShell script to execute command-line actions. If a device sees that behavior, block it. Likewise, a profile of legitimate scripting activity can be developed to detect and protect against malicious scripts. Registry protection: To maintain persistence adversaries increasingly store malware within the device registry. To prevent these attacks the registry needs to be profiled and monitored to prevent unauthorized changes, and if necessary to roll back undesired changes. Privilege escalation: At some point during an endpoint attack, the adversary will need to elevate privileges on the device to run the malware. The advanced endpoint agent can look for privilege escalation and new account creation as strong indicators of device compromise. Pros: You cannot really stop advanced exploits without protecting devices against these techniques, so it’s not really a question of whether to include these features or not. It’s about understanding how a vendor develops the models they use to distinguish legitimate behavior from illegitimate. Cons: These preventions require models of appropriate behavior, so false positives are always a concern, which comes down to opportunity cost. Whenever you need to spend time chasing down things that aren’t real issues, you aren’t doing something more useful. Ensuring that any agent provides granularity in terms of what gets blocked versus generating an alert is absolutely critical. Be aware of application impersonation, where a malicious application spoofs a legitimate one to access its privileges. Also consider differences between operating systems, in terms of ability to detect kernel activity or privilege escalation. Isolation: Another common technique is isolation within the operating system to shield critical system resources (such as memory, storage, and networking) from direct access by executables running on the system. This abstraction layer between applications and system services enables monitoring of system calls and blocking of abnormal behavior.Pros: Isolation is a time-honored approach to making sure a problem in one area of the environment doesn’t spread anywhere else. Abstracting operating system services and blocking malicious behavior before it can spread provides resilience to the device and prevents full compromise. Cons: Isolation of operating system functions is very complicated and resource-intensive on the device. This approach requires high-powered devices and considerable testing before rollout, to ensure it doesn’t break applications and impair employee productivity. Endpoint sandbox/emulation: A few years ago network-based malware sandboxes were all the rage. Files coming across ingress networks could be analyzed and unrecognized files would be executed inside the sandbox to see what it did. If a file showed malware characteristics it would be blocked at the perimeter. These devices worked great… until malware writers figured out how to evade them, at which point effectiveness took a hit, although there is still value in this approach and some prevention products detonate any unknown files in a sandbox on the endpoint to look for malicious characteristics. We’ll discuss this in more detail below, including integration with

We discussed specific attacks in our last post, so it’s time to examine approaches which can prevent them. But first let’s look at the general life cycle of an attack. Prevention Timeline As we dig into how to actually prevent the attacks described in the last post, the key principle is to avoid single points of failure, and then to ensure you have resilience so you can respond and restore normal operations as quickly as possible. You want multiple opportunities to block any attack. The most effective way to plan this out is to think about the attack on a timeline. We want an opportunity to prevent damage before execution, as early as possible during execution, and again in the worst case after execution. The earlier you can prevent an attack, the better, of course. In a perfect world you stop every attack before it gets anywhere. But, as we all discover seemingly every day, we don’t always get a chance to stop an attack before it starts. Even so, we still need to minimize damage, prevent data loss, and eliminate any attacker beachheads before they can move deeper into our systems. We focus on making sure you have numerous opportunities to determine whether code on a device is acting maliciously, and then block it. This timeline approach helps us provide failsafes and defense in depth, acknowledging that malware is very sophisticated and combines multiple attack types, which can change depending on the defenses in place on an endpoint. Let’s work through the techniques you can use to prevent attacks at every stage. We will describe each technique, and then go enumerate its pros and cons. Pre-execution The best time to prevent an attack is before it starts, and there are multiple ways to evaluate code about to run on a device to determine whether it’s malicious. Hygiene: This is a catch-all term to indicate proper strong configurations implemented on devices. Many organizations don’t consider these endpoint security controls, but the fact is that if you can block attacks by not leaving vulnerabilities on devices, that is pre-execution prevention.Patching: Keeping devices updated with the most recent patches prevents attackers from taking advantage of known vulnerabilities. Strong configurations: Each device should also be built from a strong configuration which disables unnecessary services and provides the device user with the minimum privilege to perform their job. Host firewall: Each device should have an operational firewall to prevent network attacks, blocking both non-standard protocols and traffic to known bad destinations. Host Intrusion Prevention: The firewall is to ensure unauthorized sites cannot communicate with the device (access control), and HIPS is about looking for attack patterns within the endpoint’s network stack. This is especially important for detecting reconnaissance and lateral movement. Device control: Finally, devices should be configured to disable capabilities such as USB storage to prevent introduction of malicious code via physical mechanisms. Pros: Hygiene is all about reducing device attack surface and removing low-hanging fruit to make things difficult for attackers. If by patching a system you can make their job harder, do that. If by shutting down USB ports you can prevent a social engineer from installing malware on a device via physical media, do that. Cons: Hygiene is a very low bar for protection. Even though you reduce attack surface, adversaries still have plenty of tactics available to compromise devices. Endpoint hygiene is necessary but not sufficient. File signatures: The most traditional endpoint defense involves a blacklist of known malicious file hashes and determining whether any file is on that list before allowing execution on a device. With billions of malicious files in circulation, it’s impractical to store all those file hashes on every device, or to search all those hashes every time a file executes, so integrating with a threat intelligence service to check file hashes which aren’t in the local cache is critical.Pros: Fool me once, shame on you. Fool me twice… File signatures are still used because it’s pathetic to be compromised by something you know is malicious and have seen before. The challenge is to leverage signatures efficiently, given the sheer number of items that need to be on any blacklist. Cons: It’s trivial to change the file hash of a malicious file. So the effectiveness of signature matching is abysmal, which is why every endpoint prevention offering uses additional techniques. Static analysis: Malicious files can have file attributes which indicate they are bad. These attributes include whether a file packer has been used (to change the hash), header details, embedded resources, inconsistent file metadata, etc. Static file analysis examines each file before execution, searching for these indicators. Endpoint prevention vendors typically use machine learning to analyze billions of malware files, searching for attributes which likely indicate malicious files. We will discuss machine learning later in this Buyer’s Guide.Pros: Static analysis is cheap and easy. Each endpoint prevention agent has a set of attributes to look for, and can quickly scan every file for those attributes before execution. Cons: As sophisticated as the machine learning models are which identify attributes likely to indicate a malicious file, this approach can have a high false positive rate. Static analysis is generally a coarse filter, used to determine whether a file warrants further analysis to determine whether it’s malicious. Whitelisting: The last pre-execution approach to mention is whitelisting. This entails assembling a list of all authorized files which can run on a device, and blocking anything not on the list. Malware is inherently unauthorized, so this is a good way to ensure only legitimate software runs.Pros: For devices without much variation in which applications run (such as customer support workstations and kiosks), whitelisting is a very powerful approach and can significantly reduce attack surface. Modern attacks involve downloading additional executables once the device is compromised, so even if a device is initially compromised an attacker should be unable to get additional malware files to run. Some solutions also enlist whitelisting as a supplementary technique to reduce the number of

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.