Unveiling the Cloud: A Deep Dive into DataDog Cloud Breach 2016.

Hi Guys, I trust you are all doing well? Today, I will be taking a deep dive into a cloud-related data breach, the Data-Dog Cloud breach of 2016. Of course, before I set the ball rolling, I will give a short note of some keywords, namely:

What is a Cloud-related Data breach?

Who is Data-Dog and what do they do?

What is a Cloud-related Data breach?

According to our usual friend who knows all, “a Cloud-related data breach refers to a security incident where unauthorised individuals gain access to sensitive information stored on Cloud Computing platforms or services.” In simple words, a Cloud-related data breach is a type of breach that happens on Cloud Computing platforms like AWS, Azure and GCP. Unlike the traditional data breaches that occur in conventional Data Centres that have physical locations, A Cloud Data breach happens in the Cloud through well-known Cloud platforms.

Who is Data-Dog and what do they do?

Datadog, Inc. is a Software company that provides an observability and security SaaS (Software as a Service) platform for cloud applications. The platform helps corporations monitor servers, databases, software tools, and infrastructure services. The software is a monitoring and analytics tool for IT and DevOps teams that can be used to determine performance metrics as well as Event monitoring for infrastructure and cloud services. The software can monitor services such as servers, databases and tools. Check out their website for more info on DATADOG WEBSITE.

Now, the big question you have been waiting for, is WHAT REALLY WENT WRONG?!!!

DataDog experienced a security compromise in July of 2016. According to a statement from DataDog, the attacker obtained access by leaking the SSH private key and AWS access key that was utilized by their automated release and provisioning processes. Unauthorized access to three of their AWS EC2 instances and a portion of their AWS S3 buckets was made possible by the combined use of both keys. User credentials for DataDogs services, service information, and credentials for third-party integrations were among the compromised resources.

After placing the impacted instances under quarantine, DataDog sent an email alerting users to the data breach and requesting that they change their passwords. Additionally, administrators were asked to rotate or remove any credentials that were kept on file within the DataDog system.

Key things to note:

As we mentioned earlier, Cloud-related breaches occur on a Cloud Computing platform, and the platform in view here is, you guessed right, Amazon Web Service, commonly known as AWS.

1. The breach stemmed from an attacker targeting production infrastructure servers and a database that stores user credentials.
2. The attacker gained access through the leak of an AWS access key and an SSH private key that were used by their automated provisioning and release systems.
3. AWS Access keys are set of security credentials used to authenticate access to AWS resources.
4. SSH private keys are cryptographic keys used for secure communication between a client and a server.
5. The automated Release and Provisioning system is designed to handle the deployment and provisioning of software applications and infrastructure resources.

I am sure we are getting bored at this point but no isshhhh, we gat you. We know pictures an diagrams speak thousands of words, so we made an hypothetical scenario of how the breach could have occurred. Feel free to go through and understand better.

Our hypothetical scenario

I am confident we have a better picture of how the breach happened. Moving forward, I took my time to list some possible security controls that were missing, which most likely could have prevented the event from happening or reducing the impact to a very great extent. They are:

1. Endpoint Protection
2. Strong Access Control Policy
3. Encryption
4. Intrusion Detection and Prevention System
5. SIEM solution; Logging and Monitoring.
6. DLP solution.

For readers that have probably come across this type of incident either in their organisation or personally, it is important to eventually conduct a POST-INCIDENT RESPONSE activity. Although many organisations (I can say for those that take Cybersecurity seriously) have this included in their Incident Response Plan (IRP), for the sake of the newbies reading this, the following is an excerpt for a Post-Incident Response activity:

1. Conduct a comprehensive analysis and investigation of the incident to understand its root causes, impact, and implications by reviewing logs, and evidence collected during the incident response process.
2. Analyze the effectiveness of incident response procedures, tools, and controls, and identify areas for improvement
3. Document all aspects of the incident response process, including incident details, timeline of events, response actions taken, findings from the investigation, and recommendations for improvement
4. Implement remediation measures and corrective actions based on the findings and recommendations from the incident analysis. This may include patching vulnerabilities, updating security controls, improving monitoring and detection capabilities, revising incident response procedures, and providing additional training to staff.

As I come close to finishing up this article, thank you for getting to this point with me and I look forward to you anticipating our next release. Do not forget to share this with your loved ones (even your not-so-friendly friends, if you know what I mean) because everyone deserves to be Cyber-Aware.

Kindly let me know if there are particular topics of interest you will like me to write on.

Thank you and have a nice life on this Planet Earth.