At Siren, we build a platform used for “investigative intelligence” in Law Enforcement, Intelligence, and Financial Fraud. Investigative intelligence is a specialisation of data analytics that serves the needs of those that are typically hunting for bad actors. Such investigations are the primary focus of law enforcement and intelligence, but are also critical to uncovering financial crime activities and for threat hunting in cybersecurity.

Let’s talk visibility for a moment. Security visibility is a data-at-scale problem. Searching, analyzing, and processing across all your relevant data at speed is critical to the success of your team’s ability to stop threats at scale. Elastic Security can help you drive holistic visibility for your security team, and operationalize that visibility to solve SIEM use cases, strengthen your threat hunting practice with machine learning and automated detection, and more.

Machine learning pipelines have evolved tremendously in the past several years. With a wide variety of tools and frameworks out there to simplify building, training, and deployment, the turnaround time on machine learning model development has improved drastically. However, even with all these simplifications, there is still a steep learning curve associated with a lot of these tools. But not with Elastic.

Elastic Cloud on Kubernetes (ECK) is the official operator for provisioning Elastic Stack deployments in Kubernetes. It orchestrates not only day-one provisioning, but also has the processes and best practices for day-two management and maintenance baked in. If you want to run your own Elastic Stack deployment on Kubernetes, then look no further than ECK!

Machine learning in the Elastic Stack provides you with an intuitive way to detect anomalies in vast data sets. But even the most sophisticated anomaly detection job might not reveal the root cause of anomalous behavior. After an anomaly is detected, you may need to dive into further analysis, review multiple corresponding metrics, and investigate how they relate to the anomalous spike.

Trends in the infrastructure and software space have changed the way we build and run software. As a result, we have started treating our infrastructure as code, which has helped us lower costs and get our products to market more quickly. These new architectures also give us the ability to test our software faster in production-like deployments, and generally deliver more stable and reproducible deployments.

In our previous two blogs, we provided an overview of the architecture and design of the Elasticsearch Go client and explored how to configure and customize the client. In doing so, we pointed to a number of examples available in the GitHub repository. The goal of these examples is to provide executable "scripts" for common operations, so it's a good idea to look there whenever you're trying to solve a specific problem with the client.

In this two-part blog post, we’ll use Elastic Observability to monitor a sample Java application. In the first blog post, we started by looking at how Elastic Observability monitors Java applications. We built and instrumented a sample Java Spring application composed of a data-access microservice supported by a MySQL backend. In this part, we’ll use Java ECS logging and APM log correlation to link transactions with their logs.

For public IPs, it is possible to create tables that will specify which city specific ranges of IPs belong to. However, a big portion of the internet is different. There are company private networks with IP addresses of the form 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 scattered in every country in the world. These IP addresses tend to have no real information for the geographic locations.