STEALTHbits Technologies - STEALTHbits Technologies, Inc.

While researching data breach incidences within Universities and places of higher education, I stumbled upon the Privacy Rights Clearinghouse; an organization dedicated to consumer privacy and “raising awareness of how technology affects personal privacy”. According to the Privacy Rights Clearinghouse (www.privacyrights.org/data-breach/new), over 3,500 data breaches have been made public in US universities and educational institutions alone since 2005; equating to over 600,000,000 compromised records.

But why universities? Are hackers and data thieves targeting the science department’s proprietary research? Well, maybe sometimes, but in almost all instances, they’re stealing the same type of data; Student and Faculty Social Security Numbers, Birth Dates, Addresses, Bank Account Numbers, and other personally identifiable information (PII) that cost the universities, their staff, their students, and even their student’s families monetary loss, emotional stress, and daily disruptions.

The good news is that there are solutions like enterprise Data Loss Prevention (DLP) products designed to help mitigate these types of events. That said, however, the vast majority of the currently available products designed to thwart attacks on sensitive data are incredibility expensive, costly and difficult to implement and maintain, and are rarely found inside the walls of our educational institutions as a result.

The cost prohibitive nature of enterprise class DLP solutions coupled with the historically limited IT budgets and high administrative turnover found in educational institutions have made places of higher education a target for easy access to some of the most sensitive data that exists within any organization.

So what can educational institutions do to protect themselves against data breach without breaking the bank?

Our contention is that many of the data breach events that have occurred in recent times could have been prevented through simple, proactive identification of where data exists, who has access to data, and what type of data exists within the file systems of networked computers – workstations, laptops, and servers – otherwise known as “data-at-rest”. Had the universities that have been victim to data breach events known that sensitive, private student and faculty data existed and was unprotected, it’s a pretty safe assumption to say they wouldn’t have allowed it to remain in such a state. The fact of the matter is that they simply don’t know what they don’t know.

A less costly and more pragmatic approach for universities (or any organization with limited funds and resources to prevent data breach events) is to proactively identify where their risk is, consolidate their sensitive data, and lock it down tightly.

A great place to start is to locate file shares that are open to large audiences. These data repositories are notoriously difficult to control due to the number of people performing file transactions, the lack of assigned ownership and governance over the data that exists there, and the complicated weave of access rights that are just as difficult to understand as they are to assign.

After the areas of highest risk are identified, point-and-shoot, low-cost sensitive data identification solutions like StealthSEEK can begin to search for Social Security Numbers, Credit Cards, Bank Accounts, Health Records, and other sensitive and proprietary pieces of data that are buried deep within the files themselves.

As a last step, all documents containing sensitive data can be reviewed, consolidated, and locked down, limiting the number of people who have access to the most sensitive information and also who knows where that data lives.

Endpoint and Data-in-Motion DLP solutions are no doubt valuable assets for organizations that can afford them, but the true “blocking and tackling” of data loss prevention is knowing where sensitive data is and who has access to it, especially for the data that already exists within the environment.

This is reposted from an earlier post but seems as relevant as ever. If you're thinking about monitoring Active Directory events, you'll no doubt consider what's involved in leveraging native event logging and how that relates to tools that are designed for AD event monitoring. In that context, below, we describe a few of the steps involved in setting up native event logging for Active Directory.

---

Determine Which Events You Need 

First, you need to understand which events you need to keep track of, and the associated event IDs. Complicating this task is that the event ID numbering is different between versions of Windows. For example, in Server 2008, four digit event IDs are introduced along with audit subcategories on the main audit categories. There are many events that look similar to each other, so you really need to know what you're looking at, and often a single act will generate numerous events in the log. 

The subcategories can be useful because you can enable auditing on some events but not others, which is a step in the right direction for Microsoft auditing, albeit a baby step. For example, instead of treating all Account Management events the same, you can enable audit on Security group management but disable audit on Distribution group management. You have to use a command line tool to apply audit settings via subcategories and you don't get advanced filtering such as the ability to alert on changes to high-risk groups (something STEALTHbits can easily do), but it's better than the Server 2003 capabilities. 

Complicating matters further is that there are Account Management audit events and Directory Service Access audit events which overlap. So, if both are enabled, you may see even more duplicate events with some confusion about where to find the best event data. And "before" and "after" values are written to different events. So, in some cases, you'll need to correlate multiple events in order to get the answers you seek. 

Enable Auditing on Desired Objects 

Once you have the set of events that you want enabled, you also have to enable auditing on the objects themselves. In other words, if you enable auditing on security groups, you still need to ensure that auditing is enabled on those security groups. Typically, enabling audit on directory objects is as simple as enabling "Audit Account Management" in the appropriate GPO but keep in mind that audit settings differ slightly in various versions of Windows, so if you have a mixed environment, be sure to consult each versions' documentation for appropriate audit settings. And be sure that the GPO is configured appropriately on each Active Directory Domain Controller. 

Additionally, you can utilize ADSIEdit to apply a "don't audit" flag on attributes that you'd like to have filtered out of auditing. Note that this removes ALL auditing of that attribute for ALL objects. You cannot distinguish, for example, between administrative user accounts and other accounts (again, something that's easy for STEALTHbits). 

Configure Event Log Settings 

The third step is to configure log settings. You need to set appropriate access permissions so that advanced users looking to cover their tracks cannot clear logs which may hold vital evidence. If the log security policy is not enabled, all authenticated users would have access to write & clear application logs. System and Security logs can be cleared by system software or administrators. 

You also need to set maximum log size and retention rules. These settings enable you to control how large the log files will grow and what happens when they reach their maximum. This is critical because logs need to be efficiently handled by log collection systems. 

Conclusion 

There's no ON switch for Windows auditing. There's a number of steps and methods by which to implement auditing. There is even a TechNet article on the complexity of determining the effective audit policy in Windows 2008. The author makes the point that "you should not trust any of the Group Policy reporting tools when it comes to audit settings." If you love Windows event logs and have a complete mastery of how they work (you know who you are), that's great. If not, I would think twice before making a decision to rely on Windows event logging. I certainly wouldn't go down that path with the expectation that it's the easy way. It's clearly not.