4 ms·
It appears your organization left an elasticsearch database exposed to the internet. This happens frequently due to poor configuration. You're either going to
by service_bus 6y ago
It appears your organization left an elasticsearch database exposed to the internet. This happens frequently due to poor configuration.
You're either going to have logs pointing to an IP that the individual used to siphon your data, or nothing.
With an exposed elasticsearch database, you possibly had the data being siphoned by many parties, and are only aware now because of this particular incident.
If you have any operations regarding customers in Europe, you need to notify your relevant Data Protection Authority
https://edpb.europa.eu/about-edpb/board/members_en https://edpb.europa.eu/about-edpb/board/members_en
You should also sign your engineers up for this course:
https://www.elastic.co/training/specializations/elastic-stack-management/fundamentals-of-securing-elasticsearch https://www.elastic.co/training/specializations/elastic-stac...
- the_mitsuhiko 6y ago> If you have any operations regarding customers in Europe, you need to notify your relevant Data Protection Authority The entire company is in the EU. The need to reach out to their DPA ASAP.
- michaelcampbell 6y agoAs of this writing, I don't think it's been determined yet whose organization this data came from, has it? All we have so far is a similarity in data format/structure.
- polote 6y agoAlmost all their employees have their emails in the breach : https://covve.com/about https://covve.com/about email format is <first_character_firstname>.<lastname>@covve.com
- outworlder 6y ago> It appears your organization left an elasticsearch database exposed to the internet. This happens frequently due to poor configuration. sigh Why is everything being deployed publicly accessible? If one is relying on their database configuration as their only protection, they are one fuckup away from disaster. Layers, people, layers. If this is on a cloud provider, put it on a private VPC/subnet. Add a load balancer or similar serving traffic only to the instances you need traffic routed to(which are unlikely to be databases themselves, more likely web servers). Configure firewalls accordingly. And of course, configure the servers properly.