Traditional application security concerns are shifting, responding to disruptive technologies and development frameworks. Cloud services, containerization, orchestration platforms, and automated build pipelines – to name just a few – all change the way we build and deploy applications. Each effects security a different way. One of the new application security challenges is to provision machines, applications, and services with the credentials they need at runtime. When you remove humans from the process things move much faster – but knowing how and when to automatically provide passwords, authentication tokens, and certificates is not an easy problem. This secrets management problem is not new, but
The gang almost makes it through half the episode before dropping some inappropriate language as they summarize 2017. Rather than focusing on the big news, we spend time reflecting on the big trends and how little has changed, other than the pace of change. How the biggest breaches of the year stemmed from the oldest of old issues, to the newest of new. And last we want to thank all of you for all your amazing support over the years. Securosis has been running as a company for a decade now, which likely scares all of you even more than us.
This week Mike and Rich address the recent spate of operational fails leading to massive security breaches. This isn’t yet another blame the victim rant, but a frank discussion of why these issues are so persistent and so difficult to actually manage. We also discuss the rising role of automation and its potential to reduce these all-too-human errors. Watch or listen:
The first post in this series, Behind the 8 Ball, raised a number of key challenges practicing security in our current environment. These include continual advancement and innovation by attackers seeking new ways to compromise devices and exfiltrate data, increasing complexity of technology infrastructure, frequent changes to said infrastructure, and finally the systemic skills shortage which limits our resources available to handle all the challenges created by the other issues. Basically, practitioners are behind the 8-ball in getting their job done and protecting corporate data. As we discussed in that earlier post, thinking differently about security entails you changing things up
There are plenty of obvious questions you could ask each endpoint security vendor. But they don’t really help you understand the nuances of their approach, so we decided to distill the selection criteria down to a few key points. We will provide both the questions and the reasons behind them. Q1: Where do you draw the line between prevention and EDR? The clear trend is towards an integrated advanced endpoint protection capability addressing prevention, detection, response, and hunting. That said, it may not be the right answer for any specific organization, depending on the adversaries they face and the
Now let’s dig into some key EDR technologies which appear across all the use cases: detection, response, and hunting. Agent The agent is deployed to each monitored endpoint, so you be sensitive to its size and its performance hit on devices. A main complaint regarding older endpoint protection was performance impact on devices. The smaller the better, and the less performance impact the better (duh!), but just as important is agent deployability and maintainability. Full capture versus metadata: There are differing strong opinions on how much telemetry to capture and store from each device. Similar to the question of
The next set of key Endpoint Detection and Response (EDR) capabilities we will discuss is focused on response and hunting. Response Response begins after the attack has happened. Basically, Pandora’s Box is open and an active adversary is on your endpoints, probably stealing your stuff. So you need to understand the depth of the attack, and to focus on containment and returning the environment to a known safe state as quickly as possible. Understand that detection and response are considered different use cases when evaluating endpoint security vendors, but you aren’t really going to buy detection without buying
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
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.
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