Defense in Depth: Best Practices for Securing a Teradata Data Warehouse

Database
The Teradata Database channel includes discussions around advanced Teradata features such as high-performance parallel database technology, the optimizer, mixed workload management solutions, and other related technologies.
Teradata Employee

Defense in Depth: Best Practices for Securing a Teradata Data Warehouse

“The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable.”

The Art of War - General Sun Tzu

If you lived in a house that was located in a neighborhood that had a high level of crime, you would take steps to secure your home in a manner that would deter a break in, prevent future attempts and track those who have trespassed to collect evidence for prosecution. This would require multiple layers of security as only one system would not be effective in thwarting additional break ins and identifying criminals. The first level of added security might be signs or decals on the windows that communicate that the house has a security system. Additional layers might include glass-break sensors, motion and heat detectors and cameras. Lastly sirens and flashing lights would be set off if certain events transpired. This would all be tied into a central system that would collect, analyze and send data to specified authorities. In a similar manner, defense in depth is a strategy that involves implementing multiple layers of security defense mechanisms to protect critical business data.  The idea is that if a single layer or mechanism fails or is compromised,  there will be other layers and mechanisms in place to ensure the security of the data.

It is important to note that these security layers actually take multiple forms.  Security layers will necessarily include your security policies and standards.  They will include the procedures you implement regarding who has access to the data and how that data is accessed.  Physical access controls always provide an important security function.  And, of course, much of what we discuss will be implemented as technological controls - software features and configuration of the database and underlying operating systems.

 Referring to the diagram below, there are many dimensions to this strategy - ranging from the technological controls implemented to secure the database, operating system, server, and network access to the security procedures around managing vulnerabilities, and the auditing and monitoring of the system.  And, of course, the security policies and those processes used to certify and maintain the secure configuration are also included.

 

Ultimately, a defense in depth strategy is intended to protect the data warehouse from specific security threats

First and foremost, whether we like it or not, the most significant threat to your system is misuse or abuse from people inside your organization that have legitimate access to the data.  And, unfortunately, that threat may well be the hardest to protect against. There are many reported instances within the industry where people have abused legitimate access to misuse sensitive information.

Unfortunately most organizations do not concern themselves enough with the unauthorized information disclosure or modification of data resulting from a system breach by someone who does not have legitimate access to the data - particularly by someone from outside the organization.All complex software systems contain security vulnerabilities.  To the extent that such vulnerabilities are well-known within the industry, systems that have not had appropriate fixes applied or taken other measures of protection are subject to exploits that can easily result in the compromise of data within the system.

Some examples include:

Network snooping

Network snooping involves the use of some device attached to a network to monitor the communication traffic across that network.  These devices are commonly referred to as “sniffers”.  Malicious persons will use these devices to look for sensitive information that may be transmitted over that network without proper security controls.

Denial-of-service

A denial-of-service attack is simply a type of attack that is intended to either crash the system or to consume system resources such that legitimate access is adversely affected.  In many cases, bugs in software that cause the system or database to fail can readily be exploited by a malicious person to create a denial of service.

Database protocol

Database protocol attacks are less common but no less of a threat.  With this type of attack, a malicious person will send specially constructed messages to the database using the underlying proprietary messaging protocol that is used for communications between a client and the server.  The intent is to find and exploit some end case condition within the software that would allow for the insertion and execution of code provided by the malicious user.  If a user is able to cause such code to be executed, then he or she could effectively take control of the system.

SQL injection attacks

SQL injection attacks involve applications that construct queries to the database based upon input data from users.  If the application does not fully check and validate the syntax and content of the input data, then a malicious user might be able to manipulate the data in such a way that the query to the database returns unintended information.

Worms and viruses

Most worms and viruses have really targeted operating systems rather than database systems.  But, this is very likely to change over time as databases become richer targets for such attacks.  An example of this was the SQL Slammer worm from a few years ago.  This worm attacked Microsoft SQL Server databases and, for several days, caused significant problems for corporate networks around the world.  Virus writers will inevitably turn their attention to database systems at some time in the future.

Non-secured backups

Non-secured backups are a significant threat to corporate data.  There have been many instances over the past couple of years where backups containing very sensitive information have been lost or stolen resulting in legitimate concern over the possibility of data from those backups being used maliciously - for example, for identity theft.

Destruction of data

The destruction of data - either by a malicious person or as the result of some man-made or natural disaster - is also a significant security threat.

Best Practices

A Teradata security best practice is to develop and publish a security policy specific to the data warehouse and ensure that all users understand the policy.  Most  companies have well-defined security policies and, in principle, those policies are applicable to your data warehouse.  However, it is much less common to find policies written specifically for the data warehouse.  This is important because users often cannot correlate your higher-level corporate policies specifically to how security should be applied to the data warehouse.  Having a separate, more specific, policy is something that users will be better able to relate with.

 A data warehouse security policy, approved by management, helps users understand the rules and controls regarding the use of data in the data warehouse, their responsibilities for protecting that data, and the penalties for misuse of their access privileges.

 Also, if your data warehouse contains personally identifying information - things like social security numbers, tax identifiers, credit card information, personal health information - most anything that could be used for identity theft, then the use of personal non-disclosure agreements can be a powerful deterrent to misuse of that sensitive information.

Data warehouse security policy must haves:

1. First and foremost, the policy must be approved and supported by your management.  If your management does not take the policy seriously, then there is little reason for you users to take it seriously.

2. The policy should explain the principles, standards, and compliance requirements that apply to the data warehouse and it should define the specific roles and responsibilities of users.

3. The policy must define the acceptable use of data.  Just because a user has access to sensitive information, that does not mean that he or she can do anything they want with the data.  There are always limits to how that information can be legitimately used.

4. The policy should describe the specific security controls implemented to protect data and to monitor data access and it should specify the penalties for misuse of access privileges.  This helps serve as a deterrent against abuse by users that do have legitimate access to the system.

 A well-written and well-understood security policy coupled with effective auditing and monitoring is your best protection against the threat of malicious activity or abuse of privileges by someone within your organization.

Separation of Duties

Separation of Duties is a security principle that dictates that no one person should have complete responsibility for the administration and security of the data warehouse.  Segregation of these responsibilities provides a system of checks and balances that helps to reduce the risk of system misuse.Those responsible specifically for security administration are responsible for the protection of your information assets and for the management of database security processes.  These responsibilities should be consistent with your company’s security policy regarding the allocation of security roles and responsibilities within your organization.You should designate a database security administrator to take overall responsibility for the development and implementation of security and to support the identification of controls.

The company should establish a security administrator role – separate from your database administrator – for performing various security-related tasks.  The Teradata Database security features allow privileges associated with security administration to be assigned solely to a security administrator.  Minimally, the security administrator should be responsible for creating and maintaining users, roles, and profiles, for establishing and modifying logon rules and password controls, and configuring auditing for users, database objects, and SQL functions.

Additionally, the database security administrator should coordinate closely with whoever is doing security administration for the underlying Teradata server.

The Teradata Database Security Administration reference manual provides specific guidelines and instructions for the definition and creation of a Security Administrator.

Data classification

In the area of data classification, the best practice is to account for all major data assets within the data warehouse to ensure that appropriate protection is maintained and appropriate controls are assigned.When applied to a data warehouse, the objective would be to implement policies and procedures to ensure appropriate protection of the data assets.  These procedures would cover inventory and classification of those assets.  This really is the foundation that is to be used for defining and establishing the controls that should be implemented to protect different kinds of assets. “Inventory” should be defined as the identification and assessment of the relative value and importance of your data warehouse assets.  Only with that understanding can you effectively determine and provide appropriate levels of protection.The major data warehouse assets should be classified according to the security risk of those assets being compromised, corrupted, lost or destroyed, or in having access to them interrupted or misused.

 Safeguards should be implemented based upon these classifications.  Appropriate safeguards could include encryption of the data (either in the database or when transferred over a network), very restrictive access controls, or allowing access to only sanitized or anonymized views of the data.

Even if security policies that provide for the classification of data are already in place, a "best practice" is to assign classification levels to the information and to the associated information processing services. A great way to look at this is in the context of something called the CIA triad. Data should be classified based upon an understanding of the need for confidentiality, integrity, and availability.

Confidentiality means ensuring that data warehouse assets are accessible only to those users authorized to have access.  Some examples of possible Confidentiality levels might include Highly Restricted, Restricted, Proprietary, and Public. 

Integrity is about safeguarding the accuracy and completeness of your data warehouse assets.  Examples of Integrity levels might include classifications such as Assured, Controlled, and Unconfirmed – each representing levels of confidence in the accuracy or completeness of the data.

Finally, Availability classifications relate to ensuring that authorized users have access to the data warehouse assets when access is required.  Appropriate Availability classifications might include Immediate Availability, High Availability, Standard Availability, and Non-Time Critical.

The data classification of Highly Restricted might be reserved for situations where inappropriate disclosure of information could lead to further "collateral" or "cascading" damage.  For example, the disclosure of users’ passwords could potentially provide the information necessary to compromise data maintained in the data warehouse.  This kind of compromise could lead to serious financial or legal loss; or, it could impair the delivery of customer service, it might inhibit your ability to conduct business, or it could result in serious or long-term embarrassment, or long-term loss of credibility, reputation and trust.Examples of data that might fit into this classification include Passwords (could lead to further system compromise), Social Security Numbers or Tax IDs (could lead to identity theft), Credit card information (could lead to theft or financial abuse), and Company financial results prior to announcement (which could lead to things like insider trading and other SEC violations).

 Another example of data classification is a classification reserved for situations where inappropriate disclosure of information may still lead to significant financial or legal loss or significant loss of credibility or trust.  However, the distinction in this case is that such disclosure would be considered an incident isolated onto itself.  For example, the disclosure of a data element identified as employee salary, while serious in itself, does not really lead to any “collateral” or “cascading” damage.  In the event that an individual's salary information was inappropriately disclosed, this might impact the credibility or trust of the company, and it certainly could be a significant embarrassment to everyone involved.  However, it does not provide information needed to inflict further damage to the company.

Examples of data that might fit into this classification include things like Customer account information (privacy protected under GLBA or other regulations), Patient health information (privacy may be protected under HIPAA), or as I previously noted, Employee personal information.  This kind of data certainly warrants a focus on identifying and implementing appropriate security controls.

Proprietary and Public classification examples

Data you might classify as Proprietary would be things that might be freely disclosed within the company but would require permission of the owner to disclose outside of the company.  Disclosure of this class of information would lead to negligible or no loss, and at most minor, short-term embarrassment.

An example might be information about, or comparisons to, competitive products.

The Public data classification might be applied to information that can be freely disclosed without permission.  This would be information that is intended for public consumption such as that that might be readily found in company publications or perhaps on your company’s web site.  Inappropriate disclosure of this type of information would likely lead to no loss at all.  A good example might be any kind of publicly available information about your products.

For the most part, the classification made in the source systems should just “follow” the data to the data warehouse. For each defined classification level, you can establish an appropriate set of security controls that should be applied and determine the best way to use the controls available to properly secure the data.

 Subsequent best practices articles will cover topics such as Authentication and Access controls ( LDAP, SSO), Row- and Column-level Security, Network Traffic Encryption, Data Encryption (Protegrity), Backup Media Protection, Auditing and Monitoring, Operating System Security and other relevant topics.

2 REPLIES

Re: Defense in Depth: Best Practices for Securing a Teradata Data Warehouse

Something to say? Add your comment here.
N/A

Re: Defense in Depth: Best Practices for Securing a Teradata Data Warehouse

Hi,

Are there any best practices in DB2DB security? Eg. Select access on one database to another.

Please clarify.

Regards,

SD.