Top 5 reasons to upgrade Elastic Security

Let’s start with assurances that we’re not here to heap anxiety on anyone’s fear of missing out. That being said, we do want to make sure you’re aware of all the goodness that is available in Elastic Security, especially if you’re on an older version. It can be hard to find time to dig into every new release, to see what new features might be available, or check on ways to stretch your budget in order to pick up all the logs you might be missing.

Elastic® releases new versions fairly quickly, driven by new features, user submitted enhancement requests, and of course, the occasional bug fix. It can be challenging to schedule upgrades for every new release, particularly when we’re talking about a SIEM platform that needs to be running 24/7/365, let alone adding in Elastic Agent deployments, Defend endpoint security, and all the logging and alert pipelines that are often involved.

In this blog, we’re going to take a look at my top five reasons for upgrading Elastic Security and the value you can expect from the effort. At the end, we’ll talk about some upgrade planning considerations for minimizing risk and maximizing the value you can get out of an upgrade.

It's not always about detection. If you are using Elastic Security for extended detection and response (XDR), the addition of multiple response actions makes for another compelling reason to upgrade. Isolating compromised hosts, suspending suspicious processes, downloading files, uploading files, and running commands remotely are all available actions in our latest response console (8.11) to make remediating threats as fast, effective, and controlled as possible. Download Elastic Defend to get started.

I love the cloud, and some days I love Kubernetes too. Other days (usually when something isn’t working like I think it should) I loathe them. This happens most often when something that would take me 2.5 seconds to deal with in the physical world takes me two days to troubleshoot due to some new cloud console feature or a Kubernetes update I wasn’t really paying attention to.

From a security perspective, it's worse. Keeping up with all the settings, options, identities, and roles in a dynamic environment is a challenge. Elastic Security added Kubernetes (7.x) and Cloud Security Posture Management (CSPM) (AWS in 8.7 and GCP in 8.10, with Azure Beta in 8.11) to routinely evaluate your environments against the Center for Internet Security (CIS) benchmarks. Elastic security posture management is a great way to monitor for a baseline security configuration in these environments.

I often see that one of the most important drivers to reducing metrics like MTTD/R is the organizational knowledge that analysts build up over time. Given the current challenges with finding and retaining experienced security analysts, anything we can do to help codify that organizational knowledge is a good thing. 

Dynamic investigations enable your experienced analysts to easily configure rules with built in, organization specific investigation timelines to help new hires and novices achieve efficiency as quickly and easily as possible. 

In the example below, I’ve configured a CSPM storage rule that alerts on an open S3 bucket (1). Clicking on the Dynamic Investigation link (2) in the alert brings me to a timeline with all of the logs and alerts related to the bucket in question. This reveals everything I need to determine the impact of the misconfiguration, as well as identifying the user who needs remedial training on S3 bucket configuration. All of this happens with just one click, regardless of an analyst's experience or knowledge of the environment.

Perhaps you’ve heard of this thing called generative artificial intelligence. Need to look it up? I’ll give you a minute while I do my remedial S3 security training (I’ll be back). 

All skynet jokes aside, generative AI is everywhere! But it's not a silver bullet to put down the security werewolves we deal with every day. I’ve found it to be exceptionally useful for doing all sorts of menial and repetitive things quickly, as well as gathering context about alerts and threats. 

Elastic’s AI Assistant provides assistance in numerous ways, and we’re finding more all the time. It started with providing suggestions for using Elastic Security, writing detection rules from natural language queries, and getting suggestions for settings and configurations. Experienced analysts can use it to bolster contextual information in cases, while novice analysts use it to help assess impact or correlate alerts across complex behaviors.

This feature was introduced in 8.10 and is arguably the most powerful reason to upgrade your Elastic Security solution! For more information, check out the Elastic AI Assistant blog.

Nobody wants to learn a new query language if they can avoid it, and Elasticsearch Query Language (ES|QL 8.11) makes it easy for anyone with SQL or SPL experience to quickly transition to Elastic Security. ES|QL brings a familiar piped query language to Elastic Security — combining all the speed benefits of schema-on-write with the capabilities of a dynamic schema-on-read query engine. 

ES|QL makes it easier than ever to write complex detection rules while enhancing and condensing investigation workflows with the ability to create visualizations, calculations, and aggregations directly from one screen. Check out all the capabilities of ES|QL.

While the benefits we’ve covered are just the tip of the iceberg, we all know jumping into the latest and greatest release can be a little risky. As hard as we try to minimize bugs with thorough QA testing, it’s impossible to test every one of the infinite permutations of cloud, container, OS, and software combinations in use today.

To be blunt, there will be bugs. While I’ve consistently been impressed with how fast Elastic moves to address issues with new releases, that may not help you as soon as we’d like. Here are four ways to reduce the risk of any upgrade:

• Peruse the Elastic Security release notes every release and pay close attention to known issues and breaking changes. At this point, I compare what new features and enhancements would be beneficial against known issues, breaking changes, and the effort required to upgrade.
• If you have a dev cluster, you can test and vet new versions as often as makes sense for your organization. Start by checking the results of the upgrade assistant in Stack Management and make sure there are no critical issues. Plan your upgrades with the business in mind, aiming for every 2–5 dot releases. The exception to this cycle would be a specific feature that would significantly reduce organization risk, better optimize costs, or address a known issue.
• If you don’t have a test cluster, you’re likely going to want to be more conservative in your upgrade planning. I recommend skipping any new major upgrades (e.g., 8.0) until at least the x.1 or x.2 release. This should get you the new features of interest shortly after they are released, with a significantly lower risk of negatively impacting your security operations. For the interim dot releases, I would balance the benefits of any given release with the impact those new capabilities will have on your security operations — but it doesn’t hurt to skip minor releases. 

Don’t forget! Upgrades can be done live, with little to no impact on any components configured for high availability (typically everything but cold and frozen tiers).

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.