The Massachusetts data privacy standard 201 CMR 17 was put into effect March of this year. Unlike previous state privacy laws, 201 CMR 17 pushes security requirements to a whole new level, requiring that companies understand threats specifically relevant to their operations. It's the first law to require more than encrypted data communications, and the legislation challenges organizations to look at both the data and systems that manage data. One of the unspoken facts is that Social Security numbers, driver's license numbers, passwords and other sensitive personal information is being stored in relational databases. The database is the container around which security and usage controls are being applied.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Database security policies
Database activity monitoring captures activity against a database, and quite specifically, captures and analyzes 'Select' statements used to query information from the database. This is important as database auditing tools typically only capture changes to data, not access to data. Great, but now what? Mass 201 CMR 17 compliance regulations do not mandate specific policies; you have to figure that out. The vendor is going to say, "Don't worry": it has thousands of policies, out of the box, for all sorts of regulatory requirements. But are any of them useful? Maybe not.
Count on having to turn monitoring on to observe what is going on with your database. And we are not just talking about failed logins, but users trying to download all customer data, administrative activity, queries from outside your organization or any other form of inappropriate use by credentialed users. To catch unwanted behavior, you need to use DAM with a combination of policies your vendor provided and several that you will need to write. After all, you cannot expect the database monitoring vendor to understand appropriate use cases for your environment. They will not know the behavioral profile of your workers, how your administrator roles are defined, where your arbitrary line for "too much data being viewed" is, and they certainly will not assign the same criticality to events that you do.
Policies and policy review is specific to each and every organization. Even with specific regulatory controls, how you achieve compliance will vary from firm to firm, so expect a lot of tweaking and additions to the standard policies that come with the product.
The goal of the Massachusetts law is to detect data misuse, which includes data theft. The real question is: What's bad behavior? What does data theft look like? What kind of activity are you looking for, how does it differ from normal business activity, and what type of analysis needs to be conducted? Most activity monitors look purely at query attributes: time of day, location, user name, application and so on. Some look at the query response, trying to detect large amounts of data being returned, which is helpful. But for data privacy, you need behavior monitoring to determine what normal behavior looks like, and then flag significant deviations. Not all vendors will provide this option.
Data retention & analysis
Eighteen months from now, your team suspects a breach occurred. Do you have the logs? Can you go back and look at activity? DAM platforms don't keep archives for long periods, rather purge data after 30 days and assume you kept a backup. Two serious issues here: Most firms forget to archive and store DAM backups, and DAM products often fail when trying to recover data for forensic analysis. As database activity monitoring is considered a real time analysis and response, many customers seem to forget that the activity is also an audit trail, and they don't record events onto long-term storage. Further, most customers never test recovery capabilities; when they need to restore old archives for analysis, they find the backups incompatible with DAM system updates or unreadable. Test recovery and forensic analysis as part of your response plan so there are no nasty surprises when you need the data.
Database activity monitoring tools are good for monitoring, but they are very bad at data discovery. What I mean is that they see transactions, but they do not discover what types of data you have stored, or find where that data is located. To create your security plan, you need to know what data you need to monitor and protect. Despite advertisements to the contrary, DAM does not perform discovery. You need an active assessment that scans the database structures to catalog database data. This can be done manually, or is provided by the database vendor's tool suite. It can also be acquired from database assessment vendors.
Remember, the Massachusetts standard requires that you evaluate risks, specify protections relevant to your organization, and document your plan of action. You don't get this from a canned set of reports and vendor supplied policies. Database activity monitoring is an effective tool, but you're not going to install a piece of software and magically create a data security plan. You'll first have to get a handle on where your sensitive data resides, what type of data needs to be protected and what kinds of threats you should be worried about. You then have to create the policies, deploy the product, and integrate within your existing systems. DAM offers promise, but there is a lot of hard work that you need to do.
Join us on LinkedIn.