This article is part of the series "Data Security Compliance and DatAdvantage". Check out the rest:
Over the last few years, I’ve written about many different data security standards, data laws, and regulations. So I feel comfortable in saying there are some similarities in the EU’s General Data Protection Regulation, the US’s HIPAA rules, PCI DSS, NIST’s 800 family of controls and others as well.
I’m really standing on the shoulders of giants, in particular the friendly security standards folks over at the National Institute of Standards and Technology (NIST), in understanding the inter-connectedness. They’re the go-to people for our government’s own data security standards: for both internal agencies (NIST 800-53) and outside contractors (NIST 800-171). And through its voluntary Critical Infrastructure Security Framework, NIST is also influencing data security ideas in the private sector as well.
Get the Free Essential Guide to US Data Protection Compliance and Regulations
One of their big ideas is to divide security controls, which every standard and regulation has in one form or another, into five functional areas: Identify, Protect, Detect, Respond, and Recover. In short, give me a data standard and you can map their controls into one of these categories.
The idea of commonality led me to start this series of posts about how our own products, principally Varonis DatAdvantage, though not targeted at any specific data standard or law, in fact can help meet many of the key controls and legal requirements. In fact, the out-of-the-box reporting feature in DatAdvantage is a great place to start to see how all this works.
In this first blog post, we’ll focus on DA reporting functions that roughly cover the identify category. This is a fairly large area in itself, taking in asset identification, governance, and risk assessment.
Assets: Users, Files, and More
For DatAdvatange, users, groups, and folders are the raw building blocks used in all its reporting. However, if you wanted to view pure file system asset information, you can go to the following three key reports in DatAdvantage.
The 3a report gives IT staff a listing of Active Directory group membership. For starters, you could run the report on the all-encompassing Domain Users group to get a global user list (below). You can also populate the report with any AD property associated with a user (email, managers, department, location, etc.)
For folders, report 4f provides access paths, size, number of subfolder, and the share path.
Beyond a vanilla list of folders, IT security staff usually wants to dig a little deeper into the file structure in order to identify sensitive or critical data. What is critical will vary by organization, but generally they’re looking for personally identifiable information (PII), such as social security numbers, email addresses, and account numbers, as well as intellectual property (proprietary code, important legal documents, sales lists).
With DatAdvantage’s 4g report, Varonis lets security staff zoom into folders containing sensitive PII data, which is often scattered across huge corporate file systems. Behind the scenes, the Varonis classification engine has scanned files using PII filters for different laws and regulations, and rated the files based on the number of hits — for example, number of US social security numbers or Canadian driver’s license numbers.
The 4g report lists these sensitive files from highest to lowest “hit” count. By the way, this is the report our customers often run first and find very eye-opening —especially if they were under the impression that there’s ‘no way millions of credit card numbers could be found in plaintext’.
Assessing the Risks
We’ve just seen how to view nuts-and-bolts asset information, but the larger point is to use the file asset inventory to help security pros discover where an organization’s particular risks are located.
In other words, it’s the beginning of a formal risk assessment.
Of course, the other major part of assessment is to look (continuously) at the threat environment and then be on the hunt for specific vulnerabilities and exploits. We’ll get to that in a future post.
Now let’s use DatAdvantage for risk assessments, starting with users.
Stale user accounts are an overlooked scenario that has lots of potential risk. Essentially, user accounts are often not disabled or removed when an employee leaves the company or a contractor’s temporary assignment is over.
For the proverbially disgruntled employee, it’s not unusual for this former insider to still have access to his account. Or for hackers to gain access to a no-longer used third-party contractor’s account and then leverage that to hop into their real target.
In DatAdvantage’s 3a report, we can produce a list of stale users accounts based on the last logon time that’s maintained by Active Directory.
The sensitive data report that we saw earlier is the basis for another risk assessment report. We just have to filter on folders that have “everyone” permissions.
Security pros know from the current threat environment that phishing or SQL injection attacks allow an outsider to get the credentials of an insider. With no special permissions, a hacker would then have automatic access to folders with global permissions.
Therefore there’s a significant risk in having sensitive data in these open folders (assuming there’s no other compensating controls).
DatAdvantage’s 4a report nicely shows where these files are.
Let’s take a breath.
In the next post, we’ll continue our journey through DatAdvantage by finishing up with the risk assessment area and then focusing on the Protect and Defend categories.
For those compliance-oriented IT pros and other legal-istas, here’s a short list of regulations and standards (based on our customers requests) that the above reports help support:
- NIST 800-53: IA-2,CM-8
- NIST 800-171: 3.51
- HIPAA: 45 CFR 164.308(a)(1)(ii)(A)
- GLBA: FTC Safeguards Rule (16 CFR 314.4)
- PCI DSS 3.x: 12.2
- ISO 27001: A.7.1.1
- New York State DFS Cybersecurity Regulations: 500.02
- EU GDPR: Records of Processing (Article 30), Security of Processing (Article 32) and Impact Assessments (Article 35)