In one of our air-gapped environments we've recently observed some firewall logs pointing to cloud.security.elastic.co. To me, it smells a lot like artifacts.security.elastic.co, so it would be a pretty important whitelist to create, but due to internal policies I'd actually need to clearly identify the role of that endpoint before possibly whitelisting it.
There does not seem to be any trace of this cloud subdomain in the official documentation: is it a recent addition? Is there any documentation page where all FQDNs contacted by Elastic Agent are listed, so I can take a look for whitelisting? I could only find referenced to the artifacts subdomain in documentation pages related to air-gapped setups.
This URL endpoint is used to suppress false positive alerts, based on file hash. FP detected on this cloud service are used to make updates to our security artifacts to eliminate the FP in the first place. If you don't want Endpoint "calling home" to suppress those FP you can control that via advanced policy option windows.advanced.alerts.cloud_lookup.
It is similar in functionality to the "Reputation service", but the reputation cloud endpoint receive anonymized alert to make it's decision, whilst the cloud lookup just get the hash of the file.
Everything clear, just one question on this matter, with one premise: in our air-gapped environment we have a lot of custom-built software. Some of this software does pretty nasty stuff with memory, which used to trigger Elastic's memory protection algorithm a lot (and 100% rightfully so) and required a good number of exceptions in order to function properly.
Aren't we risking sweking your results and statistics by sharing all those "dirty" hashes with your service? Or am I misunderstanding everything, as it is a read-only thing per which an agent may decide to contact the cloud service to receive feedback about a specific hash, and that's a piece of information that only the agent will end up using?
Don't worry about it, I'm sure our service was built with scalability in mind. Actually, I really don't know how it's implemented, but I assume it's the other way around, if I were developing it, I'd make a fast key value store to quickly return malicious/non-malicious reputation verification if it's already known from XDR, and I'd queue unknown hashes for background queries with some que size quota and priority boost for the most queried hashes.
Anyway, maybe someone from the actual team who maintain it will comment on the implementation. I'm Elastic Defend developer.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.