Protecting your game against Data Breaches

Culture: Everyone should be Responsible for Security

While you may have dedicated security professionals whose primary responsibility is in fact security, every employee, regardless of role, should be responsible for ensuring that security is an integral component of every facet of the business, and security is referred to early and often. Every employee should know how to report a security issue, and they should be empowered to escalate security issues to the highest levels if needed. It should be ingrained in your culture that security is a top priority. People should be made accountable for resolving any open issues.

Protecting against Data Breaches

If you are watching the headlines, you can’t escape the fact that companies experiencing data breaches is a rising trend. According to Verizon’s Data Breach Investigations Reports, there was a 96% rise in data breaches reported from 2019 (2013) to 2020 (3950). 86% of breaches were financially motivated, 45% of breaches featured hacking, 22% involved phishing and 17% involved malware. Securing information is important no matter if you’re storing it in a cloud or on-premises.

The best approach for security breaches is actually to work on it from multiple fronts. 70% of all reported data breaches were perpetrated by external threat actors, making it an obvious first area of concern. (Source: Verizon DBIR 2020) Unfortunately, it also means that 30% of data breaches involved internal threat actors so we also need to take this into account.

That is why, you will want to put in place strategies to protect your data from unauthorized access from external entities but also act as if a data breach was inevitable and design your architecture to limit the blast radius as much as possible so that the least amount of data possible could be exfiltrated. Before going any further, let’s start by defining what is personal data also known as personally identifiable information (PII). According to the European Union’s General Data Protection Regulation (GDPR), PII is “any information which [is] related to an identified or identifiable natural person”.

A pro tip to limit blast radius is to never collect personal data, if you don’t have an actual use for it. People can’t steal information you don’t have. If you absolutely need to collect personal information, think about storing it in at least one other database for PII. You might also want to tokenise it in databases which have multiple users – especially where some of them might need the full data in a row whereas others can make do with partial row data.

Although from a security standpoint no data at all would be the ultimate protection against data breaches, in the information age, it is not realistic from a business standpoint. We need data to help us take better informed business decisions through functions like business intelligence and data analytics. For that purpose, when you collect such information, to facilitate GDPR compliance, you will want to anonymize at collection time, de-identify after collection or pseudonymize (replacing personal identifiers with temporary information) when using it during analytics. If your data analytics ever got compromised, they could see trends in the data, but it would make it much more difficult to map the data back to any specific user. Obviously, if your data set is ultra specific, there could be some data that when cross-referenced could permit user identification just like in a survey if your data sample is small and you have questions that single out some users. You need to have this in mind when you are building out your data set.

To conduct business, some people and services will need to access your data. For that, make sure to only allow access to data on a need to know basis for both people and services, revoke access when no longer needed, and review access permissions regularly.

There is no reason to offer malicious actors free candies. Always make sure to encrypt data both at rest and in transit.

37% of breaches involve stolen or re-used credentials (Source: Verizon DBIR 2020), that is why you want to make sure that you are enforcing multi-factor authentication (MFA) for all your user accounts so that no credential can give access by itself. MFA will ensure that if some users got their credentials stolen or re-used their credentials across multiple organizations either on their personal or professional accounts, a malicious actor would need another authentication mechanism to be able to use those credentials.

To limit the blast radius, use multiple AWS accounts and Organization OUs to separate workloads and workload stages such as production and testing. That way, any compromised workload cannot get access to other workloads’ data. For more information, see also https://docs.thinkwithwp.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html.

Use mechanisms to keep people away from data by providing them with secured and automated ways to query and access (and filter) data and track all those data accesses. Through use of automated tools and mechanisms, you will be able to find unusual trends that might raise flags for your security team to investigate.

Ensure you have an incident response (IR) plan. Your organization needs to implement mechanisms to respond to and mitigate the potential impact of security incidents. Your preparation strongly affects the ability of your teams to operate effectively during an incident, to isolate, contain and perform forensics on issues, and to restore operations to a known good state. Putting in place the tools and access ahead of a security incident, then routinely practicing incident response through game days, helps ensure that you can recover while minimizing business disruption.

If you want to improve your incident response capability, we suggest you have a look at AWS Incident Response Playbook Samples. They should be customized by administrators working with AWS to suit their particular needs, risks, available tools and work processes. Please note, that these guides are not official AWS documentation and are provided as-is to customers

In-depth information about designing cloud architectures with security in mind

You want to take security and data protection into account when you are designing the architecture of your systems. For this purpose, you can refer yourself to the Security Pillar of our AWS Well-Architected Framework and we highly recommend that you take time to go through it so that you will understand AWS current recommendations and strategies to use when designing AWS architectures with security in mind. This paper doesn’t provide implementation details or architectural patterns but does include references to appropriate resources for this information. By adopting the practices in this paper and its references, you can build architectures that protect your data and systems, control access, and respond automatically to multiple kinds of security events.

Takeaways

• Build a strong security culture, make it important, and include everyone in your organization.

• Data threats are both internal and external, you need to work on it on all fronts.

• Limit blast radius of an eventual data breach by not collecting PII you don’t need, by anonymizing data collection where possible and de-identifying or pseudonymizing data when access doesn’t require PII

• Develop and disseminate a set of security expectations for your organization. Get humans away from data and systems. Automate everything that can be automated, letting your security professionals focus on what humans do best: assess risk and add value to the business’ objectives.