An innovative and well-designed software solution, such as the Elasticsearch search engine, can quickly become embedded in many business processes. For example, Elasticsearch is widely used today for searching data that ranges from network logs to highly sensitive documents.
Unfortunately, because Elasticsearch is easy to deploy, it’s also easy for people to either forget or not fully harden security features to restrict access and protect the data.
Kroll has witnessed a surge in firms experiencing data exposure due to nonexistent or insufficient security measures applied in Elasticsearch deployments. Compounding the problem is that an organization can be unaware of its exposure because the software was implemented by a third-party vendor with access to its data.
10 Recommendations for Hardening Elasticsearch Cybersecurity
Elasticsearch users have many options for strengthening cyber security. The following are some of Kroll’s recommendations, which should be customized for the organization, type/volume of data and operational priorities. As a rule of thumb, make sure your cluster is well-hidden deep within private networks and only accessible to your applications. Disable features you do not need and obscure your settings (e.g., default ports) and data structure or the very fact that you are using Elasticsearch.
- Deploy a “demilitarized zone” (DMZ) between the internet-facing systems and the corporate or private network. Configuration should limit the communication and interaction between the two, and logging should be enabled to assist and provide a method to identify possible malicious traffic and activity.
- Add private networking between Elasticsearch and client services. If a machine needs to access Elasticsearch, connect them via VPN or any other private network.
- Internet-facing servers should use a secure configuration.
- Unnecessary services, ports and/or accounts should be disabled or blocked where possible.
- Do not use default ports.
- Change and update default login credentials.
- Restrict access to administrative functions, APIs and/or panels.
- Utilize a reverse proxy or alternate type of service to restrict accessible URL paths to known legitimate URL paths.
- Enforce HTTPs via an HTTPs proxy, enable SSL and set up required certificates because the Elasticsearch HTTP API does not support TLS out of the box. (Potential effects on query times are minimal compared to the enterprise-wide disruption of a data breach).
- Implement least-privilege policies and access methods on the servers.
- Instruct Elasticsearch on what IPs to listen to, e.g., localhost, private IPs, public IPs or any combination of those.
- Use proxies to communicate with clients.
- If you have a single page application that needs to query Elasticsearch and get JSONs for display, pass it through a software façade that can filter requests, log audits, and most importantly, password-protect your data.
- Don’t expose your document and index structure by coupling your thin client with the data-store system serving it.
- Your clients should communicate with your server-side software, that will in turn transform all client-side requests to Elasticsearch DSL, execute the query and then selectively transform the response from Elasticsearch back to something your clients expect. Consider a solution such as NGINX, which was designed with a proxy role in mind.
- Put Elasticsearch on an isolated network. Even within your network, try isolating your clusters from other parts of your system as much as possible. For example, you can put the cluster in a VPC and then have two separate security groups: one for the whole cluster and one for the client nodes.
- Disable HTTP where you do not need it. Elasticsearch is best deployed in groups of servers, each serving a role: master-eligible, data and client nodes.
- Secure publicly available client nodes. There are still some cases where client nodes are publicly available to serve UIs like Kibana and Kopf. When at all possible, require a VPN to access the data. Otherwise, employ a proxy as described earlier. You can also use Elastic's Shield or plugins like SearchGuard to secure your cluster, and completely control access via client nodes.
- Disable Scripting (pre-5.x) and use the latest Elasticsearch version. Before Elasticsearch 2.x, there are many versions known to be insecure due to enabled dynamic scripting with non-sandboxed languages (mvel, groovy). If you are using a cluster with a 1.x or 0.x version, upgrade immediately. If you are using Elasticsearch 2.x, at a minimum, change your default scripting language to expression.
Understand Your Third-party Cyber Risk Exposure
Due to its popularity, Elasticsearch can be embedded in any number of vendor-provided technology solutions. It is imperative to know when and where it is deployed by third parties with access to your data, and more importantly, the security measures they have taken.
Of course, Elasticsearch is just one of many current and emerging software solutions that could potentially compromise your data via vendor-provided services. Our final recommendation is to consider implementing a third-party cyber risk management program. Experts like Kroll will examine and assess various aspects of your vendors’ data security handling, including IT system resources, personnel and cyber security policies. The findings can provide your organization with that extra layer of security vital in a world where vendors routinely have access to your most sensitive data.