Protecting Your Data—How Much Security Is Enough?

When working with organizations, one area we help our clients with is thinking about the types of data they have throughout their organization. Examples include customer information, financial information (accounts receivable/ accounts payable), inventory, human resource information, and so forth.

Once you’ve taken inventory of the data retained throughout your organization, the first consideration is whether the data falls under any laws or regulations that impose specific security requirements. Obvious examples include credit cards that fall under the requirements of the Payment Card Industry’s Data Security Standard (PCI DSS); financial data that falls under BASEL III, the Gramm-Leach-Bliley Act (GLBA), Sarbanes-Oxley Act (SOX), or the Japanese version (J-SOX); as well as private data that falls under Personal Information Protection and Electronic Documents Act (PIPEDA), the Companies Bill, or U.S. state breach notification laws.

Many of these laws and regulations have specific data security requirements, so it can be fairly easy to determine at least the minimum amount of security and the types of action one needs to take to protect this type of data. For example, PCI DSS has specific requirements for what credit card information can be stored and the fact that it must be transmitted and stored encrypted.

But are the security requirements stipulated in these laws and regulations always sufficient to protect data? No. Some laws and regulations stipulate that the data must be secured but provide no specific guidance or requirements for the exact steps you need to take to secure the data. So how do you determine how much is enough in these cases? The answer is to look at the intent of what is trying to be accomplished.

Take SOX for example. The intent of this U.S. law is to ensure that the financial information of the company is accurate and can be relied upon. What does this mean in terms of security? At a minimum, that the access control settings of the databases containing financial data (along with any other data that directly feeds into the financials) enforce the appropriate role-based access. That is, those roles that have responsibility to update the financial data be allowed to do so, while all other roles have read-only or are denied access altogether.

On the surface, this may seem like an easy and obvious task. Only provide access to the application to the users of that application and customize—by role—what tasks users are allowed to perform within the application. That’s one step. The other step is to make sure that the access rights to the database where the data is stored are set properly. Many application providers and security administrators ignore this step, leaving data directly accessible via ODBC or FTP connections by users without a business need to access the data.

Depending on the access control setting, these users may be able to just read the data. But some application providers and internal developers leave the access set such that users have the ability to modify the data or delete records. An access control setting that allows users to modify or delete data from outside of the application’s logic is a clear and obvious violation of many laws and regulations.

This setting needs to be corrected—not only to come into compliance with these laws and regulations, but also to ensure the data is sufficiently protected so that your organization can rely on the integrity of the data.

When determining how much security is enough, the next consideration is the value of the data to the organization.

This consideration is often overlooked and therefore valuable data is often left with inadequate or non-existent protection. Most organizations fail to consider how valuable their data is to the overall organization.

Consider some examples: a specialty retailer whose vendor list, in the hands of their competitors, would eliminate the uniqueness of their inventory; a non-profit organization whose mission is “politically incorrect” has their donor list stolen and names are published on the internet; sales data upon which commissions and bonuses are calculated is modified by an unscrupulous employee; pricing information is sold to a competitor in a business whose margins are extremely thin.

The data in these examples doesn’t fall directly under any law or regulation yet it needs to be protected as the valuable asset that it is.

Laws and regulations require some types of data be kept confidential—healthcare information and credit card numbers are obvious examples. This requirement demands that, if you do nothing else, the default access control setting on the files and directories containing this information is set to “deny by default.”

It also makes sense that some non-regulated data—bank account, Social Security, and Social Insurance numbers, for example—also be kept confidential or private. But don’t stop with the obvious.

Think through the other data retained by your organization. You may want to keep financial information restricted to only selected employees prior to a buyout or takeover. Or, some organizations don’t share sales quotas or pricing information between regions. The bottom line is that the appropriate access controls will ensure that data is only available to the approved users.

Data integrity is often overlooked when considering how much security is enough. Consider how the results of queries or data warehouse analysis is part of your business processes. Orders are placed for additional supplies based on inventory numbers. Forecasts are made based on sales trends. Bonuses are calculated based on sales.

If the numbers used in these formulas aren’t accurate, payouts will be off. But worse, significant business decisions could be made based on inaccurate data that affects the bottom line of your organization.

Not all data is confidential and needs to be secured with an access control of “deny by default.” However, having access control settings that ensure the integrity of the data (at most “read only”) on the databases and directories where data is stored should be a fundamental tenet of all organizations.

Otherwise, the accuracy of the data upon which business decisions are made cannot be assured.

Finally, the appropriate access control settings can contribute to the availability—or not—of the organization’s data. If, from outside of the protection of application logic, the default access control setting or the users’ permissions to the database files allows modification of data, removal of records, or the clearing or deletion of files, the data may not be available for use.

Take, for example, an analyst who downloads data to spreadsheets. One day they accidentally press the wrong icon and data from last month’s analysis is uploaded to the production database. The production database is now out-of-date and has to be restored from backup and recent transactions re-entered.

Or, the root directory is shared and users are automatically reconnected to the share. They open Windows Explorer and see libraries that shouldn’t be on their PC. Not realizing that they are acting on libraries on the system rather than their individual PC, they drag and drop production libraries to the trash.

Think these are madeup examples? Think again.

Actions like these are unintentional and non-malicious. But regardless of motive, the result is an outage and a very preventable one at that. When users are given only the permission they need to perform their job functions, outages such as these are prevented.

Once you’ve determined the value of the data to your organization, you may choose to apply multiple layers of security. For example, you may have data that does not fall under any formal compliance requirements. However, it is so valuable to your organization or the cost to your organization would be so great if it were lost, that you decide to not only set the permissions on the database to be “deny by default” but you also encrypt the information.

Or, perhaps you decide to add biometric authentication so that only certain users can perform certain functions within the application.

While some regulations such as PCI DSS do require multiple layers of defense, most do not. Therefore, the number of layers implemented will be determined by your organization’s requirements. The more risk-averse your organization is, the more layers of defense you’ll apply to ensure the data is protected.

If the data falls under regulatory compliance requirements, you have some idea of how much security is enough. But whether the compliance requirements are enough will be up to your organization to determine.

Of course, if the data does not fall under regulatory requirements, the value of the data to your organization will determine how much security is enough. Regardless, numerous benefits are realized by answering the question, “how much security is enough?” and securing an organization’s data appropriately.

Here are just a few:

Compliance with regulatory requirements: Data that is secured according to the laws and regulations under which it falls will not suffer from the potential fines, audit findings, legal issues, and negative publicity associated with non-compliance.

Integrity of data: Properly secured data can be relied upon to be accurate. That is, it can be assured that only those roles that should be allowed to modify data are able to do so and all others are denied or are read-only.

Privacy and confidentiality of data: Some data should not only be updated by selected roles but should also only be viewed by selected roles. If data is set to be “deny by default”, the confidentiality and privacy of the data can be assured.

Availability of data: If the access control settings of data allows any user to modify or delete records or files, the availability of the data cannot be assured.