Security and AccessControl

  1. Is ElasticSearch PCI DSS compliant?

  2. What is the recommended strategy for access control? Is it fail-safe?

Thanks,
Nick

--

TheOutlander wrote:

  1. Is Elasticsearch PCI DSS compliant?

  2. What is the recommended strategy for access control? Is it
    fail-safe?

ES is currently not secure in any way. It is meant to be a highly
available, low-level data store. You should hide it in your
infrastructure behind something that complies with your security
model.

If you'd like a modest level of access control for the REST
endpoints, have a look at the Jetty plugin:

GitHub - sonian/elasticsearch-jetty

And by modest I mean really modest. It only adds basic auth to the
HTTP interface (by replacing the Netty HTTP layer). Someone could
still speak directly to internal transport channels if the cluster
wasn't protected.

Improving this story is something that's on the radar for ES,
although I don't know of any timeline for it.

-Drew

--

Thanks! I'm going to check their security standards documentationhttps://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf,
but does anyone know if that means we will fail a PCI DSS audit?

-Nick

On Thursday, October 4, 2012 9:03:32 AM UTC-7, Drew Raines wrote:

TheOutlander wrote:

  1. Is Elasticsearch PCI DSS compliant?

  2. What is the recommended strategy for access control? Is it
    fail-safe?

ES is currently not secure in any way. It is meant to be a highly
available, low-level data store. You should hide it in your
infrastructure behind something that complies with your security
model.

If you'd like a modest level of access control for the REST
endpoints, have a look at the Jetty plugin:

GitHub - sonian/elasticsearch-jetty

And by modest I mean really modest. It only adds basic auth to the
HTTP interface (by replacing the Netty HTTP layer). Someone could
still speak directly to internal transport channels if the cluster
wasn't protected.

Improving this story is something that's on the radar for ES,
although I don't know of any timeline for it.

-Drew

--

There is no security/authorization/authentication in Elasticsearch, so I
would assume it will fail most types of audits. The HTTP/REST protocol is
plain-text and the Java/binary protocol is not encrypted in anyway. Storage
is in the Lucene format, which also has no security.

That said, Elasticsearch is working just fine at numerous companies. The
cluster should live behind a firewall, and if REST is needed, a proxy can
be used to filter requests.

--
Ivan

On Fri, Oct 5, 2012 at 3:28 AM, TheOutlander theoutlander@gmail.com wrote:

Thanks! I'm going to check their security standards documentationhttps://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf,
but does anyone know if that means we will fail a PCI DSS audit?

-Nick

On Thursday, October 4, 2012 9:03:32 AM UTC-7, Drew Raines wrote:

TheOutlander wrote:

  1. Is Elasticsearch PCI DSS compliant?

  2. What is the recommended strategy for access control? Is it
    fail-safe?

ES is currently not secure in any way. It is meant to be a highly
available, low-level data store. You should hide it in your
infrastructure behind something that complies with your security
model.

If you'd like a modest level of access control for the REST
endpoints, have a look at the Jetty plugin:

https://github.com/sonian/**elasticsearch-jettyhttps://github.com/sonian/elasticsearch-jetty

And by modest I mean really modest. It only adds basic auth to the
HTTP interface (by replacing the Netty HTTP layer). Someone could
still speak directly to internal transport channels if the cluster
wasn't protected.

Improving this story is something that's on the radar for ES,
although I don't know of any timeline for it.

-Drew

--

--

There is no easy answer to this - like everything, these answer is 'maybe'.

It will depend on who your QSA is, how elasticsearch is configured, how you
are using it, and where it resides in your network. For example, if it is
located outside of your 'card holder environment', then your auditor will
be far more lenient about restrictions.

PCI DSS also allows for 'compensating controls' - so it's not always the
case that everything has to be followed to the letter. For example,
elasticsearch operates over unsecured, plain-text protocols - but you can
use firewalls to mitigate various risks, and you could build your own
secure service layer through which the elasticsearch API is accessed
indirectly.

So... there are no easy answers to this question, and I can only suggest
you consult your QSA. Sorry :slight_smile:

On Thursday, October 4, 2012 4:30:21 PM UTC+1, TheOutlander wrote:

  1. Is Elasticsearch PCI DSS compliant?

  2. What is the recommended strategy for access control? Is it fail-safe?

Thanks,
Nick

--

Thanks for your response. It's certainly helpful.

It sounds like it is possible to make the infrastructure around ES more
secure and be compliant. We plan on getting it audited externally. For now,
we plan on using Mongo for that particular project.

Thanks,
Nick

On Friday, October 12, 2012 4:09:04 AM UTC-7, cocowalla wrote:

There is no easy answer to this - like everything, these answer is 'maybe'.

It will depend on who your QSA is, how elasticsearch is configured, how
you are using it, and where it resides in your network. For example, if it
is located outside of your 'card holder environment', then your auditor
will be far more lenient about restrictions.

PCI DSS also allows for 'compensating controls' - so it's not always the
case that everything has to be followed to the letter. For example,
elasticsearch operates over unsecured, plain-text protocols - but you can
use firewalls to mitigate various risks, and you could build your own
secure service layer through which the elasticsearch API is accessed
indirectly.

So... there are no easy answers to this question, and I can only suggest
you consult your QSA. Sorry :slight_smile:

On Thursday, October 4, 2012 4:30:21 PM UTC+1, TheOutlander wrote:

  1. Is Elasticsearch PCI DSS compliant?

  2. What is the recommended strategy for access control? Is it fail-safe?

Thanks,
Nick

--