Teradata InfoSec Slides Defense in Depth Best Practices Pres December 2011 - FINAL

Defense in Depth
Best Practices
for
Securing a Teradata Data Warehouse
Les McMonagle (CISSP, CISA, ITIL)

Director – InfoSec COE
Information Security, Data Privacy and Regulatory Compliance COE
December 2011
Les McMonagle
Director - Information Security COE
• Les McMonagle is an information

security consultant leading the Teradata
InfoSec COE
• He has over 20 years of experience in
the development and implementation of
information security architectures
• During his career he has specialized in
computer training, E-Commerce
applications, IT Operations, information
security architecture, processes, audits
and Corporate Risk Management
• Les holds CISSP, CISA, ITIL and other
relevant industry certifications
• He has participated in the development
of the BITS Financial Institution Shared
Les McMonagle (CISSP, CISA, ITIL)
Mobile: (617) 501-7144
Assessment Program and delivered
Email: executive level presentations on Data
Les.McMonagle@Teradata.com Privacy and Security Technology
July 6, 2018 Teradata Confidential 2 2

Defense in Depth
A strategy for implementing multiple layers of

security defense mechanisms to ensure protection
of business critical information in the event that a
single mechanism fails or is compromised
> Security considerations include:

– Policies
– Process
– Personnel
– Training
– Physical and Logical Access Controls
– Identity Management
– Security Technology
– Regulatory Compliance
– Third Party Security Products, Tools, Utilities

Defense in Depth
Security Policies and Procedures

Auditing and Monitoring
Intrusion Detection/Prevention
Vulnerability Management
Database Security
Authentication
Access Rights
Encryption
Operating System Hardening
Physical Security
Network Security
Certification and Accreditation

Teradata Security Features
Authentication • Username/Password Authentication • TDP Authentication (External Security

• Enhanced Database Password Controls Manager Interface)
• Custom Password Dictionary Support • LDAP Authentication
• User-level Password Controls (Profiles) • Windows Kerberos Single Sign-on (SSO)
• Logon Encryption • Extensible User Authentication
• IP Filters (Restrict Logons by IP Address)
Authorization • Discretionary Access Control Policy • Directory-based Authorization (External

• Security Roles Roles)
and Access • Idle Session Abort
• Query Banding
Controls • Trusted Sessions • Mandatory Access Control (MAC)
Data • View-based Security (Row/Column) • Defiance DPS for Teradata

• Network Traffic Encryption (Column level Data Encryption)
Protection • Sun KMS BAR Tape Encryption
Auditing and • LogOnOff Log • Teradata Manager Audit Reports

• Access Log • SQL Query log (DBQL Tables)
Monitoring
Assurance • Common Criteria EAL4+ Evaluation • BITS Audit Program AUP & SIG v6.2
• ISO 27001 Certification • Safe Harbor (SaaS, DWaaS)
Environment • Operating System Hardening • Operating System Configuration -

• Customer Services Secure Support Services Change Detection Monitoring
Infrastructure
• Disk Scrubbing Service

Teradata Security Best Practices
07 • Security Policy 122 • Secure Zone
09
• Separation of Duties 126 • Operating System Security
12
• Data Classification 128 • Vulnerability Management
• User Identification 130

• Physical Security
17
• Password Controls • Security Process Audit
• Authorization / Access Control • Business Continuity Plans
26 • Role-based Access Control • Accreditation and Assurance
33 • Directory Integration
48 • Row and Column-level Security
64 • Mandatory Access Controls (MAC)
89 • Network Traffic Encryption
95 • In-Database Column-Level Encryption
• Backup Media Protection
• Residual Information Protection
111
• Auditing and Monitoring
Security Policy
• Develop and publish a security policy specific to the

data warehouse and ensure that all users understand
the policy
• Consider use of personal non-disclosure agreements
• Integrate data protection policy into IT outsourcing,

hosting and business partner agreements
• Apply Separation of Duties where applicable
• Data Classification

Security Policy
• Essential elements of a Data Warehouse Security Policy

> Approved and supported by senior management
> Explains principles, standards, and compliance
requirements
> Includes roles and responsibilities of users
> Defines acceptable use of data
> Outlines controls implemented to protect data and monitor
data access
> Specifies penalties for misuse of access privileges

Separation of Duties
A security principle dictating that no one person should

have sole responsibility for an entire area such as the
administration and security of the data warehouse
> Access Approver should be separate from Access Grantor

> System Administration should be separate from audit log
capture, review and analysis
> Application code development should be separate from
Production code management
> Designate an independent database security
administrator separate from system admin and DBA
functions to be responsible for granting and revoking
access, administration of security policy including
password controls, roles and profiles

Best Practice
• Separate security administration from database

administration
> Establish a Security Administrator user to perform security-
related tasks
– Establish and maintain users, roles, and profiles
– Establish and modify logon rules
– Establish and modify password controls
– Initiate auditing for users, objects, and Teradata SQL functions
– Coordinate security duties with the server security
administrator

Creating a Security Administrator
CREATE USER SECADMIN AS PASSWORD = xxx,

PERMANENT = xxx, SPOOL = xxx,
ACCOUNT = 'SecAdmin',
FALLBACK ;
GRANT USER ON SECADMIN TO SECADMIN /* maintain users */ ;

GRANT ROLE TO SECADMIN /* maintain roles */ ;
GRANT PROFILE TO SECADMIN /* maintain profiles */ ;
GRANT SELECT ON DBC TO SECADMIN /* select on dictionary tables */ ;
GRANT UPDATE ON DBC.SysSecDefaults TO SECADMIN /* password characteristics */ ;
GRANT EXECUTE ON DBC.LogonRule TO SECADMIN /* logon rules */ ;
GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN /* access logging */ ;
GRANT DELETE ON DBC.AccLogTbl TO SECADMIN /* delete audit entries */ ;
GRANT DELETE ON DBC.DeleteAccessLog TO SECADMIN /* delete audit entries */ ;
GRANT DELETE ON DBC.EventLog TO SECADMIN /* delete event log */ ;
BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule ;

Asset Classification and Control
Best Practice
• All major data assets within the data warehouse should

be accounted for to ensure that appropriate protection is
maintained and appropriate controls are assigned
> Inventory of data warehouse assets

– Identify and assess the relative value and importance of data
warehouse assets
– Provide levels of protection commensurate with the value and
importance of the assets
> Information classification

– Data warehouse assets should be classified according to the
security risk should those assets be compromised, corrupted,
lost or destroyed, or access be interrupted or misused

Information Classification
Confidentiality: ensuring that data

warehouse assets are accessible only
to those authorized to have access
> e.g., Highly Restricted, Restricted,
Confidentiality Proprietary, and Public
Integrity: safeguarding the accuracy

and completeness of data warehouse
assets and processing methods
Security > e.g., Assured, Controlled, and
Unconfirmed
Availability: ensuring that authorized

Integrity Availability users have access to data warehouse
assets when required
> e.g., Immediate Availability, High
Availability, Standard Availability,
and Non-Time Critical

Example - Confidentiality classifications

> Highly Restricted
– Inappropriate disclosure of information could lead to further
collateral damage
– Serious financial or legal loss
– Impairment to the delivery of customer service
– Financial errors
– Impairment of business operation
– Serious or long-term embarrassment, long-term loss of credibility,
reputation and trust
– Examples
» Passwords (could lead to further system compromise)
» Social Security Numbers or Tax IDs (could lead to identity theft)
» Credit card information
» Company financial results prior to announcement (could lead to
insider trading and other SEC violations)

Example - Confidentiality classifications (continued)

> Restricted
– Inappropriate disclosure of information is isolated
– Still may lead to significant financial or legal loss, significant
embarrassment or loss of credibility, reputation or trust
– Examples
» Customer account information (privacy protected under GLBA and
other regulations)
» Patient health information (privacy protected under HIPAA and other
regulations)
» Employee personal information

Example - Confidentiality classifications (continued)

> Proprietary Data
– May be freely disclosed within the company but requires
permission of the owner to disclose outside the company
– Inappropriate disclosure would lead to negligible or no loss, and at most
minor, short-term embarrassment
– Example
» Competitive data
> Public Data

– May be freely disclosed without permission
– Inappropriate disclosure leads to negligible or no loss
– Example
» Product brochures

User Identification / Password Controls
Best Practices
• Ensure that all users are uniquely identified

> Enables effective monitoring of user activities
> Supports forensic analysis to identify the source of a security
breach
> Ensures that users are held accountable for their actions
• Enforce use of strong passwords

> Passwords should be constructed using a combination of alpha,
numeric and special characters
> Passwords should not include user name
> Users should change passwords regularly and re-use should be
limited
• Create and assign profiles to enforce appropriate

password control policies for different classes of users

V12.0
Dictionary-based Password Checking
• Dictionary-based Password Checking

> Allows for a user password to be rejected if it contains a
dictionary word
> Default restricted dictionary words are added to the system
upon upgrade to Teradata Database 12.0
> Customers can add new restricted words (or delete existing
restricted words) as needed to meet policy requirements
> Dictionary-based password checking is enabled through

system default password policy or through the use of
profiles
– DBC.SysSecDefaults.PasswordRestrictWords
– MODIFY PROFILE … RESTRICTWORDS

V12.0
Dictionary-based Password Checking
• DBC.PasswordRestrictions Dictionary Table

> Contains restricted words that cannot be contained in a
password
> Default table includes ~2300 common English words and
names
• DBC.RestrictedWords[V] System View

V12.0
New Password Encryption/Hash Algorithm
• DBS Password Enhancement feature completes the

full implementation of the Secure Hashing Algorithm
(SHA) SHA-256 bit encryption for passwords
• Replaces 64-bit DES encryption algorithm
• Two forms of password encryption (from previous

releases), namely DES and SHA-256 truncated to 27
bytes will continue
• All passwords created on old releases will continue to

work and will be changed to full SHA-256 encryption
when next modified

New Password Controls in Teradata Database V2R6.1
PasswordSpecChar
N, n Y, y A, a B, b C, c D, d E, e F, f G, g H, h I, i J, j K, k L, l M, m O, o P, p R, r
SPECCHAR
Username Y Y Y Y Y Y Y Y Y N N N N N N N N N
Upper/Lower Case Y Y Y Y Y Y R R R Y Y Y Y Y Y R R R
Alpha Characters Y Y Y R R R R R R Y Y Y R R R R R R
Special Characters N Y R N Y R N Y R N Y R N Y R N Y R
KEY
N – Not Allowed
Y – Allowed, Not Required
R – Required

Recommended Default Password Control Policy
UPDATE DBC.SysSecDefaults SET

PasswordMinChar = 8, /* password must be at least 8 characters in length */
PasswordMaxChar = 30, /* password cannot exceed 30 characters */
PasswordDigits = ‘R', /* digits required */
PasswordSpecChar = ‘R', /* alpha, special, upper/lower case characters required */
MaxLogonAttempts = 3, /* user will be locked after 3 failed logons */
LockedUserExpire = 5, /* user will remain locked for 5 minutes */
ExpirePassword = 90, /* passwords will expire in 90 days */
PasswordReuse = 270 /* a password cannot be reused for 270 days */
;

Configuring Special Password Control Policies
CREATE PROFILE Batch_Profile AS PASSWORD ATTRIBUTES =

EXPIRE = 0, /* password does not expire */
MAXLOGONATTEMPTS = 1, /* user will be locked after 1 failed logon */
;
MODIFY USER Load_User AS PROFILE = Batch_Profile ;

Access Control Policy
Best Practice
• Practice the principle of least privilege by granting users

the minimum access rights and privileges required for
their job
> Reflect security requirements of individual business
applications
> Identify all information related to the business applications
> Enforce information access and authorization
– e.g., the need-to-know principle
– e.g., security levels and classification of information
> Provide consistency between the access control and
information classification policies with other systems
> Reflect relevant legislation and any contractual obligations
regarding protection of access to data or services
> Include standard user access profiles for common job roles

Access Control Policy
Information Access Restriction
• Users access databases that contain

only views and macros
• Table databases only contain tables
SELECT, EXECUTE
INQ_PROFILE • Extend access rights at the database or
the user level
INQ_USER_1 INQ_USER_2
INQ SELECT, GRANT
VIEWS &
MACROS
TABLE
SELECT DATABASE
EXECUTE UPD VIEWS,
MACROS, & DROP/CREATE TABLE
STORED SELECT, INSERT, CHECKPOINT, DUMP,
PROCEDURES DELETE, UPDATE, RESTORE, SELECT,
GRANT EXECUTE,
EXECUTE INSERT, DELETE,
INSERT, DELETE UPDATE
UPDATE
UPD_PROFILE MAINT_PROF
UPD_USER_1 UPD_USER_2 MAINT_1 MAINT_2

Role Based Access Control (RBAC)
Best Practice
• Use role-based access controls to manage database

access rights by job description or responsibility
> Reduces the complexity and cost of security administration

in large data warehouse environments
> Allows for security management at a level that more closely

corresponds to an organization’s structure
> Align with organizational roles
> Leverage existing roles in LDAP or AD Directory Services

Security Roles
• Role
A set of database access rights granted to a group of users
> Allows access rights to be managed by job function or job

responsibility
> Simplifies the management of access rights by enabling

grants and revokes of multiple rights with a single grant
> Reduces the number of access rights in the

DBC.AccessRights dictionary table
– Reduces disk space usage
– Improves performance and reduces dictionary contention

Using Security Roles
• Granting Access Rights to a Role

> Use the CREATE ROLE statement to create a security role
CREATE ROLE role_name;
> The newly created role does not have any associated access
rights
> GRANT (or REVOKE) statements are used to assign (or take
away) access rights to (or from) a role
GRANT access_rights ON database.object TO role_name;

• Granting a Role to a User

> Use the GRANT ROLE statement to grant a security role to a
user
GRANT ROLE role_name TO user_name [WITH ADMIN OPTION];
> WITH ADMIN OPTION gives the user the right to GRANT or
DROP the role
> Users may be granted multiple roles
> Roles can also be granted to other roles (nested roles)
> Assign default role for user

MODIFY USER user_name AS DEFAULT ROLE = role_name;

Nested Security Roles
• Nested Roles
> Security roles can be nested one level deep
> Example:
GRANT Role_A TO Role_AB; GRANT Role_A TO Role_AB;

GRANT Role_A TO Role_AC; GRANT Role_AB TO Role_ABC; <FAILS>
GRANT Role_B TO Role_AB;
GRANT Role_C TO Role_AC;
GRANT Role_C TO Role_CD; Role_A
GRANT Role_D TO Role_CD;
Role_A Role_B Role_C Role_D Role_AB
X
Role_AB Role_AC Role_CD Role_ABC

• Current Role
> The active (or enabled) role plus any nested roles
> Use the SELECT ROLE statement to display the current role
> At logon, the current role is determined by the DEFAULT
ROLE assignment for the user
> A user may change roles by using the SET ROLE statement
SET ROLE role_name ;
SET ROLE ALL ;

Organizational Roles
HR Consultant
HR Consultant Employee
HR
Data
HR Consultant
Financial
Financial
Analyst Finance
Data
Financial
Analyst
Sales
Customer
Specialist Sales
Data
Sales
Specialist
Sales
Specialist
USERS USER ROLES DATA ROLES VIEWS BASE TABLES

Directory Integration
Best Practice
• Integrate Teradata data warehouse security with

corporate LDAP-based authentication and authorization
infrastructures
> Allows for centralized management of database users

consistent with management of users for other systems and
applications
> Allows for additional segregation of duties since control of

database user authentication and authorization can be
managed separately by a corporate security organization

LDAP Authentication
• LDAP Authentication
> User logs on to Teradata Database
using directory user identifier and
password
Teradata Database
– User identifier can be a simple user

LOGON
name, a user principal name, or a
authcid/ password fully qualified distinguished name
LAN Users
> Users authenticated by Teradata

LDAP Database through a SASL DIGEST-
MD5 bind, Simple bind or TLS/SSL
Directory Server
LDAPv3
bind to external LDAP-compliant
directory
SASL DIGEST-MD5

Windows Network Authentication

V12.0
Windows SSO / Kerberos Authentication
• Windows Network Authentication

> Teradata 12.0 adds support for Kerberos-based SSO for
Teradata on MP-RAS v3.03 and Linux SLES-10* platforms
> Allows users to access the Teradata Database based on a
valid Windows domain-authenticated session
– Authentication via Kerberos where Active Directory serves as
the Kerberos key distribution center (KDC)
• Kerberos Authentication
> Sign-on As
> Allows users to access the Teradata Database based on a
valid Windows username and password*
* Not available for SLES-9, not yet available for Non-Windows Clients (Feb 2010)
Kerberos-based Authentication

Kerberos-based Delegation

Supported Directories
Teradata Database Teradata Database Teradata Database Teradata Database

Windows 2000 Server Windows Server 2003 UNIX SVR4 MP-RAS SUSE Linux
Active Directory
N Y Y Y
Appl. Mode (ADAM)
Active Directory
Y Y Y Y
Windows Server 2003
Sun Java System
N Y Y Y
Directory Server
OpenLDAP Directory N Y Y Y
Novell eDirectory N Y Y Y
• Directory Integration Enhancements

> Support for the DIGEST-MD5 authentication method
> Support for Simple Binds and SSL/TLS Binds (in v6.2+)
> Support for the LDAP “WHO AM I?” extended operation
> DNS SRV Resource Records
> Pre-binds using a Service ID

Directory User
• Directory User
A database user that is authenticated and authorized through an
external LDAP directory or Microsoft Active Directory or ADAM
> Two types of directory users

– Users mapped to permanent Teradata Database users
– Users not mapped to permanent Teradata Database users

Directory User
• Directory User (cont)
1. Directory user mapped to permanent Teradata Database

user
– Assumes permanent user’s SPOOL and TEMP space
allocation
– Inherits access rights, roles, and profile settings from the
permanent user
– Can be assigned a profile and external roles in addition to
those inherited
– Directory-assigned profiles and roles are enabled at logon and
take precedence over those inherited
– Must use the SET ROLE statement to enable the roles inherited
from a permanent user

Directory User
• Directory User (cont)

2. Directory user not mapped to permanent Teradata
Database user
– Assumes the database privileges of the system-defined
default directory user EXTUSER
– No default database, PERM space, default role, or profile
– May set the default database using a SET SESSION DATABASE statement
– May be assigned a profile to define a default database and SPOOL and
TEMP space limits
– Access rights can be assigned through external roles
– No default role
– All external roles assigned to a directory user are active

External Roles
• External Roles
> Security roles created in the database and assigned to users
defined in an external directory *
CREATE EXTERNAL ROLE role_name;
DROP EXTERNAL ROLE role_name;
> Creator must have been granted CREATE ROLE and DROP ROLE
privileges
– Cannot include WITH ADMIN option
> External roles cannot be granted to a database user
– Must be assigned directly to directory users
> External roles are mapped to security groups
– Directory users that are members of a group have access to all roles
assigned to that group
* There is a limit of 15 Roles that can be assigned via an external directory

Teradata Directory Information Tree Schema
dc=acme,
dc=com
ou=people ou=groups ou=tdat
uid=duser1 uid=duser2 cn=dgrp1 cn=dgrp2 cn=dbc1 cn=dbc2
cn=users cn=roles cn=profiles
cn=tuser1 cn=tuser2 cn=trole1 cn=trole2 cn=tprof1 cn=tprof2

Object Mappings
Directory Server Teradata Database

Teradata DIT
duser1 tuser1 tuser1
duser1 tprof1 tprof1
dgrp1 trole1 trole1

LDAP Authentication Only Option
• LDAP Authentication Only
> Introduced in Teradata Database V2R6.1
> Allows any directory user with a Username that matches a

Username stored in the database to log on to the database
and assume the privileges of the matching database User
– No directory schema changes required

– Requires that the LDAP ‘AuthorizationSupported’ property be
set to ‘No’
– Cannot have some users authenticated only while others being
both authenticated and authorized
– Database User must be granted LOGON WITH NULL PASSWORD

V13.0
Directory Integration Enhancements
• Directory Integration enhancements added to v13.0

> Support for mixed use of External (Directory Managed)
Roles and Internal (Teradata Managed) Role Memberships

V13.10
Directory Integration Enhancements
• Directory Integration enhancements added to v13.10

> LDAP style authorizations available with Kerberos
– Role memberships from LDAP with Kerberos Authentication
> SPNEGO (Service Provider NEGOtiate) for .NET support
• Official Support for OpenLDAP
• Schema-less LDAP Authorizations (Role memberships)

> TDAT root, system and container nodes can be an
Organizational Unit (OU) rather than a CN
(no schema extensions required)

Row and Column Level Security
Best Practice
• Enforce row and column-level access controls through

the use of security Views and Macros
> Views
– Limit user access to only selected columns of the base table
CLS - (Column-Level Security)
– Provide value-based security for the information in a table
RLS (Row-Level Security)
> Macros and Stored Procedures

– Can be used to limit the types of actions a user can perform on
rows and columns
– Access controlled by granting user EXECUTE privilege on the
macro or stored procedure (not the underlying View or Table)
– Limits access to privileged commands to controlled method

Views, Joins and Macros used to enforce security
Routine
Application
Single-Row Access DBA/System

Standard Administrator
View Consumer Access Macro
Analytic
User/Application
Database
Infrastructure
Anonymized Views Macros

View
…. Data Protection
Marketing Privacy
Application Infrastructure Security Admin
Officer
Customer Base Tables
Opt-out
View
Databases/Tables
Views, Macros
User Profiles
Disclosure Logs
Application Audit Reports
Opt-out/
Anonymized
View

Role Level Security Options

Semantic Layer Security
Different types or combinations

of Views can be applied to limit
access to only required data

V12.0
Query Banding
• Provides the ability to apply a unique user identifier to a

session or statement while utilizing a shared application
ID for authentication to EDW
• Teradata Active System Management (TASM) and

Teradata Dynamic Workload Manager (TDWM) can
leverage Query Banding to apply End-User specific task
prioritization.
• Not designed specifically as a security feature

V13.0
Trusted Sessions
• Provides the capability to authorize a limited trust model

that allows middle-tier applications to assert User
identities and roles for use in access rights checking and
auditing of queries without establishing a logon session
for the User
> Improves performance, scalability, and support for large
numbers of users by eliminating the need to authenticate
(re-authenticate) Users connecting through a middle-tier
> Enables greater granularity of access rights enforcement
based upon End-User identity
> Enables auditing of access based upon End-User identity
> Preserves the security model commonly used by middle-tier
(and web-based) application systems

Trusted Sessions V13.0
High-level Usage
0 Middle-tier creates session pool authenticating itself to

the Teradata Database.
Teradata Database 1 Client authenticates itself to the middle-tier and

requests a service requiring query to Teradata
Middle-tier Database.
Application Server
0
Middle-tier sets active session identity and role for the
client User.
1
2
Users Teradata Database verifies that client User has been
granted proxy access through the middle-tier.
2 Middle-tier submits query to Teradata Database on

behalf of proxy user.
Teradata Database verifies access rights for the query

External based upon proxy User’s rights and active role.
Authentication Server
Teradata Database records proxy user’s identity in any
records inserted into Access Log.

High-level Usage
• CTCONTROL Access Right

> New privilege required for an administrative user to define
and manage trusted sessions
> Administrative user must also have DROP USER rights for any
trusted user for which proxy connections can be granted
GRANT CTCONTROL TO admin_user [WITH GRANT OPTION];
REVOKE [GRANT OPTION FOR] CTCONTROL FROM admin_user;

High-level Usage
• Grant Connect through a Trusted User
GRANT CONNECT THROUGH trusted_user_name

TO PERMANENT perm_user_name [, perm_user_name]
WITH ROLE role_name [, role_name] | WITHOUT ROLE;
GRANT CONNECT THROUGH trusted_user_name

TO app_user_name [, app_user_name]
WITH ROLE role_name [, role_name];
REVOKE CONNECT THROUGH trusted_user_name

FROM PERMANENT perm_user_name [,perm_user_name]
[WITH ROLE role_name [, role_name]];
REVOKE CONNECT THROUGH trusted_user_name

FROM app_user_name [, app_user_name]
[WITH ROLE role_name [,role_name]];

High-level Usage
• Set Proxy User/Role for the Active Session
SET QUERY_BAND = ‘PROXYUSER = user_name; PROXYROLE = role_name;’

[ UPDATE ] FOR SESSION | TRANSACTION;
SET QUERY_BAND = NONE FOR SESSION | TRANSACTION;
• New Teradata Built-in Functions

> CURRENT_USER
> CURRENT_ROLE

V13.0
GRANT/REVOKE Column-level Security
• Adds support for GRANT/REVOKE of additional column-

level access rights
> SELECT
> INSERT
GRANT SELECT(column_list) ON table_name

TO user_name | role_name ...;
GRANT INSERT(column_list) ON table_name

TO user_name | role_name ...;
REVOKE SELECT(column_list) ON table_name

FROM user_name | role_name ...;
REVOKE INSERT(column_list) ON table_name

FROM user_name | role_name ...;

V13.0
Enhanced Access Rights for Stored Procedures
• Enables specification of access rights checking during

execution of a stored procedure to be based upon the
rights of the Owner, Creator, Definer, or Invoker of the
procedure
• Addresses security issue where dynamic SQL used by
any user calling the SP can access any or all objects
granted to the owning database
CREATE | REPLACE PROCEDURE procedure_name()

SQL SECURITY OWNER | CREATOR | DEFINER | INVOKER
begin
procedure_text;
end;

Example – Column-level Security
Employee Table
EmpNumber LastName FirstName Phone JobTitle DeptNumber HireDate BirthDate Sex Salary
21769 Hinson Ken 1340 Programmer 4216 02-Apr-88 26-Aug-68 M 56240.00
21838 Bolton Caroline 1715 Manager 4216 21-Oct-90 22-Sep-58 F 72351.00
22041 Nelson Carrie 5056 Product Manager 3856 26-Apr-92 01-Sep-66 F 48771.00
22399 Sutton Annie 6228 Admin 4216 19-Jun-95 05-May-70 F 28990.00
22410 Hill Marion 2133 Programmer 4216 30-May-97 30-May-72 F 47621.00
22569 Lewis Ben 4869 Product Manager 3856 13-Apr-98 28-Jul-75 M 46354.00
22890 Cothran Mark 4702 Manager 3245 19-Mar-00 02-Dec-71 M 69433.00
23450 Payton Jessica 4991 Marketing Specialist 3245 20-Aug-02 09-Mar-77 F 48221.00
24108 Shaw Josh 5205 Programmer 4216 18-Feb-03 10-Jun-82 M 41295.00
24569 Cureton Frank 9394 Marketing Specialist 3245 21-Nov-04 14-Jan-82 M 44566.00
CREATE VIEW Phone AS

SELECT LastName, FirstName, Phone, JobTitle, DeptNumber
FROM Employee;
__________
SELECT * FROM Phone;

LastName FirstName Phone JobTitle DeptNumber
Hinson Ken 1340 Programmer 4216
Bolton Caroline 1715 Manager 4216
Nelson Carrie 5056 Product Manager 3856
Sutton Annie 6228 Admin 4216
Hill Marion 2133 Programmer 4216
Lewis Ben 4869 Product Manager 3856
Cothran Mark 4702 Manager 3245
Payton Jessica 4991 Marketing Specialist 3245
Shaw Josh 5205 Programmer 4216
Cureton Frank 9394 Marketing Specialist 3245

Example – Row-level Security
Employee Table
CREATE VIEW EngDept AS

SELECT * FROM Employee
WHERE DeptNumber = 4216;
_______
SELECT * FROM EngDept

ORDER BY 1;

Example – Row-level Security
Employee Table
Security Table
UserName Dept
cbolton 4216
CREATE VIEW Department AS
mcothran 3245
WHERE DeptNumber IN
(SELECT Dept FROM Security WHERE UserName = USER);
________
SELECT * FROM Department

ORDER BY 1;

Example - Macro
• Using a macro to restrict access to a table

> Restricts access to performing a single function
> Does not require that user have access to base table
CREATE MACRO NewEmployee

(EmpNo (INTEGER),
Lname (VARCHAR(20),
Fname (VARCHAR(20),
Ph (INTEGER),
Job (VARCHAR(20),
Dept (INTEGER),
Hdate (DATE),
Bdate (DATE),
Sx (CHARACTER(1)),
Sal (FLOAT) )
AS (INSERT INTO Employee (EmpNumber,LastName,FirstName,Phone,JobTitle,DeptNumber,
HireDate,BirthDate,Sex,Salary)
VALUES (:EmpNo,:Lname,:Fname,:Ph,:Job,:Dept,:Hdate,:Bdate,:Sx,:Sal); );

V14.0
Mandatory Access Controls (MAC)
Used to apply Row Level Security (RLS)
• Description
> Provides the capability to create and assign sensitivity
labels to database tables/rows and users, and to control
access to data based upon the labels.
– Only rows that a user is allowed to access are visible.
> New security policies are written in constraint UDFs for
greater flexibility and modification.
• Benefit
> Simpler and easier to maintain than the current
workaround of using complex views.
> Meet Govt Mandatory Access Control (MAC) requirement. *
– Added security over Discretionary Access Control (DAC) model
• Considerations
> Row Level Security is a separate optional feature.
> There may be a small performance cost from the addition
of constraints to DML statements.
* Not NSA Labeled Security Protection Profile (LPSS) Compliant which is for OS not database
July 6, 2018 Teradata Confidential 65
Row-Level Security BEFORE <V14.0
Simple Example
Employee Table
Security Table
UserName Dept
cbolton 4216
CREATE VIEW Department AS mcothran 3245
WHERE DeptNumber IN
(SELECT Dept FROM Security WHERE UserName = USER);
________
SELECT * FROM Department

ORDER BY 1;

Row-level Security BEFORE <V14.0
Complex Example using Multiple Security Tables
Joining to security tables in views may be inefficient. Joining to Security Tables

can cause significant overhead especially when ad hoc access is allowed and the Security
Table(s) must be joined to every Table in every view. For example, if a User selects the
member, group, and claims Tables in an ad hoc query, each View joins to the Security Table(s),
resulting in three accesses of the Security Tables. In above example, the Security Tables
include three Tables, so the simple three Table join must access nine Security Tables.

V14.0
Mandatory Access Control (MAC)
• Security Labels
> Associated with subjects (users) and objects (tables, rows)
> Two parts
– Classification - a single, hierarchical level
– e.g.: TOP SECRET, SECRET, CONFIDENTIAL, UNCLASSIFIED
– Compartments – (optional) nonhierarchical - represent distinct
areas of information
Label Users Rows (Data) Label

SECRET [HR]
SECRET [HR] CONFIDENTIAL [HR]
CONFIDENTIAL [HR, FIN]
SECRET [FIN]
CONFIDENTIAL [FIN]
TOP SECRET [HR]

V14.0
Mandatory Access Control (MAC) Policy
A means of restricting access to objects based on the sensitivity

(as represented by a label) of the information contained in the
objects and the formal authorization (i.e. clearance) of
subjects to access information of such sensitivity. *
• No Read Up
> Read access is allowed if the subject’s label dominates the object’s label
– The subject’s classification must be >= the object’s classification
– Subject’s label must include all compartments in the object’s label
• No Write Down
> Write access is allowed if the object’s label dominates the subject’s label
– The object’s classification must be >= the subject’s classification
– The object’s label must include all compartments included in the
subject’s label
* DoD Trusted Computer System Evaluation Criteria

V14.0
Teradata Row Level Security
• New Security CONSTRAINT Object

> Defines a security constraint on the relationship between tables
and users
> Constraints include a list of allowed name/value pairs and one or
more specifications of functions that enforce the policies for the
constraint on a type of SQL statement
– SELECT, INSERT, UPDATE, DELETE
> Constraints can be applied to a user either by direct assignment or

through assignment to a profile
> Any defined constraint can be associated with a table
– Results in a new column added to the table with the name of
the constraint object

V14.0
Two Types of Constraints
CREATE CONSTRAINT <name> AS SMALLINT | BYTE(n),…
non-set (hierarchical, vertical)

e.g. “MAC Classification”
one value per constraint column
constraint values: 1 - 10000
set (non-hierarchical, horizontal)

e.g. “MAC Compartments”
multiple values per constraint column
constraint values: 1 - 256 (32x8)
n = 1 - 32

V14.0
Row Level Security Example
• Define two CONSTRAINT objects which together comprise a MAC

security label

V14.0
Row Level Security Example (continued)
• Assign CONSTRAINT objects to a user
> Or, assign CONSTRAINT objects to a user via a profile

V14.0
• Associate CONSTRAINT objects with a table

V14.0
• ReadClassification UDF Definition

V14.0
Row Level Security Policies
• Security policies are enforced using UDFs named in CONSTRAINT object
> UDF calls automatically added as predicates to SQL DML statements

– Predicates added to the search conditions of SELECT, UPDATE,
and DELETE statements
We do an all-AMPs RETRIEVE step from CIA.Weapons by way of an

all-rows scan with a condition of (“
((SYSLIB.READCLASSIFICATION(3,CIA.Weapons.Classification))='T') AND
((SYSLIB.READCOMPARTMENT(2,CIA.Weapons.Compartment))=‘200’XB)") into …
> INSERT and UPDATE UDFs return values to be stored in constraint

columns
explain insert Aircrafts

(‘Iran’, ‘SU-30’, 20, ‘Ahmadi’,‘29 5 57 N 51 2 7 E’, ,);
We do an INSERT into CIA.Aircrafts constrained by Session
(CIA.Aircrafts.Level = SYSLIB.INSERTLEVEL (4)), values
(CIA.Aircrafts.Allies = SYSLIB.INSERTALLIES (‘6000'XB))

V14.0
Other Insert Considerations
• Compound statements, INSERT-SELECT, MERGE INTO:

> Constraint values must come from source table.
CT t1 (c1 INT, Levels CONSTRAINT);
CT t2 (c1 INT, Levels CONSTRAINT);
INSERT t1 SELECT * FROM t2; <- legal
INSERT t1 SELECT c1, Levels-1 FROM t2; <- illegal
• OVERRIDE INSERT CONSTRAINT privilege allows any valid constraint

value to be inserted.
GRANT OVERRIDE INSERT CONSTRAINT ON Aircrafts TO Admin;
INSERT INTO Aircrafts
VALUES(‘Iran’, /* country */
‘SU-30’, /* aircraft type */
20, /* aircraft count */
‘Ahmadi’, /* air base */
‘29 5 57 N 51 2 7 E’ /* coordinates */
4, /* allow access to level 4 and 5 */
‘6000’xb); /* allow access to USA and UK */

V14.0
Constraint UDF Requirements
• UDFs must be defined with specific parameters and return specific

elements.
UDF Required Input Parameter

Type CURRENT_SESSION INPUT_ROW Must Return
Select a a ‘T’ or ‘F’
value for
Insert a constraint column
value for
Update a a constraint column
Delete a ‘T’ or ‘F’

V14.0
Security Policy Examples
User Row
Allow read if: Level Allies Level Allies
Select 1) user Level >= row Level 5 01100000 4 10000000 deny
2) user Allies is superset of row Allies
5 11111100 4 10000000 grant
User Row
insert user’s session constraint value
Insert into column
Level Allies Level Allies
3 10000000  3 10000000
User Row
Allow delete if row Level is Level Allies Level Allies
Delete Unclassified (1) 3 11110000 1 10000000 grant
3 11110000 1 00000100 deny
3 10000000 2 10000000 deny
User Row
If user Level >= row Level then Level Allies Level Allies
Update
update row Level to user Level 2 10000000  2 10000000

V14.0
New Privileges
• Two new system access rights control definition of constraint objects

and assignment of those objects to users, profiles and tables
> CONSTRAINT DEFINITION
> CONSTRAINT ASSIGNMENT
• Six new system access rights allow execution of SQL statements

which bypass execution of the security policy for a row constraint
> OVERRIDE INSERT
> OVERRIDE UPDATE
> OVERRIDE DELETE
> OVERRIDE SELECT
> OVERRIDE DUMP
> OVERRIDE RESTORE
GRANT OVERRIDE UPDATE CONSTRAINT ON Fact_Table TO Admin;

V14.0
MAC – RLS Supporting Slides

V14.0
New System Objects
New System Table New System View

DBC.SecConstraints DBC.SecConstraintsV[X]
DBC.ConstraintFunctions DBC.ConstraintFunctionsV
DBC.ConstraintValues DBC.ConstraintValuesV
DBC.AsgdSecConstraints DBC.UsrAsgdSecConstraintsV[X]
DBC.ProfileAsgdSecConstraintsV[X]

V14.0
Error Logging, Auditing
• Extension to existing CREATE TABLE syntax
CREATE ERROR TABLE FOR t [NO RLS];

NO RLS = error table is unprotected
• Extensions to existing Auditing syntax

Auditing examples:
BEGIN LOGGING ON EACH ALL FOR CONSTRAINT <constraint name>;
BEGIN LOGGING ON EACH ALL FOR CONSTRAINT <constraint name>

BY <user name> ON DATABASE <db name>;
BEGIN LOGGING ON EACH INSERT BY <user name>

ON DATABASE <db name>;
BEGIN LOGGING ON EACH ALL FOR CONSTRAINT <constraint name>

BY <user name>
ON TABLE <db name>.<table name>;

V14.0
Restrictions, Feature Access
• Partitioning expression for a table cannot contain an RLS

constraint column.
• A trigger statement cannot reference an RLS table
• An RLS table cannot be part of a replication group
• Can’t COPY an RLS table
• Purchased separately, enabled through DBSControl

> Internal flag ‘RLS Purchased’ (#233)

V14.0
Create Constraint Syntax
CREATE CONSTRAINT <name> AS SMALLINT|BYTE(n), [NOT NULL],

VALUES (valuename_1:value_1, ....., valuename_n:value_n)
INSERT SYSLIB.<UDF_name>,
SELECT SYSLIB.<UDF_name>,
UPDATE SYSLIB.<UDF_name>,
DELETE SYSLIB.<UDF_name>;
ALTER CONSTRAINT <name> AS

{ VALUES (valuename_1:value_1, ....., valuename n:value n)
| FUNCTION ADD|DROP|REPLACE
INSERT|SELECT|UPDATE|DELETE SYSLIB.<UDF_name>};
DROP CONSTRAINT <name>;
SHOW CONSTRAINT <name>;

V14.0
Syntax
CREATE|MODIFY USER|PROFILE … AS
CONSTRAINT=<name_1>(valuename_1,
.....,
valuename_n),
Max 5 non-set constraints
CONSTRAINT=<name_2>(valuename_1, or 2 set constraints
.....,
valuename_n);
CREATE TABLE <table name> (<column name> <datatype,

.....,
Max 5 constraints. <constraint name> CONSTRAINT,
Constraint column .....,
cannot be part of PI. <constraint name> CONSTRAINT);
SET SESSION CONSTRAINT = <name>(valuename);
HELP SESSION CONSTRAINT;

V14.0
Constraint not applied if there is OVERRIDE privilege
If no operation specified,
override granted for all
operations.
GRANT OVERRIDE [INSERT|SELECT|UPDATE|DELETE|DUMP|RESTORE]

CONSTRAINT ON <object name> TO <user name>;
Database,
Table or
Column

V14.0
Row Level Security
Customer Scenario/UPDATE Example
EXPLAIN UPDATE Aircrafts SET Aircraft_Count=25 WHERE

Country='Iran';
*** Help information returned. 10 rows.

*** Total elapsed time was 1 second.
Explanation
---------------------------------------------------------------------------
1) First, we do a single-AMP UPDATE constrained by
(RGATES.Aircrafts.Classification_Level =
SYSLIB.UPDATELEVEL (5,RGATES.Aircrafts.Classification_Level)),
(RGATES.Aircrafts.Allies =
SYSLIB.UPDATEALLIES ('FC00'XB, RGATES.Aircrafts.Allies)) from
RGATES.Aircrafts by way of the primary index
"RGATES.Aircrafts.Country = 'Iran '" with a residual condition ("
((SYSLIB.SELECTLEVEL (5, RGATES.Aircrafts.Classification_Level)) =
'T') AND
((SYSLIB.SELECTALLIES ('FC00'XB RGATES.Aircrafts.Allies ))= 'T')").
-> No rows are returned to the user as the result of statement 1.

V14.0
Row Level Security
Customer Scenario/DELETE Example
EXPLAIN DELETE FROM Aircrafts WHERE Air_Base='Ahmadi';
*** Help information returned. 16 rows.

*** Total elapsed time was 1 second.
Explanation
---------------------------------------------------------------------------
1) First, we lock a distinct RGATES."pseudo table" for write on a
RowHash to prevent global deadlock for RGATES.Aircrafts.
2) Next, we lock RGATES.Aircrafts for write.
3) We do an all-AMPs DELETE from RGATES.Aircrafts by way of an
all-rows scan with a condition of (“
(((((SYSLIB.SELECTALLIES ('FC00'XB, RGATES.Aircrafts.Allies ))= 'T') AND
((SYSLIB.DELETEALLIES (RGATES.Aircrafts.Allies ))= 'T')) AND
((SYSLIB.SELECTLEVEL (5, RGATES.Aircrafts.Classification_Level ))=
'T')) AND (RGATES.Aircrafts.Air_Base = 'Ahmadi ')) AND
((SYSLIB.DELETELEVEL (RGATES.Aircrafts.Classification_Level ))=
'T')"). The size is estimated with no confidence to be 1 row.

Network Traffic Encryption
Best Practice
• Enable encryption to protect the confidentiality of

sensitive data when transmitted over non-secure
networks
> Encrypt any database sessions for which clients are

connecting over non-secure networks
> Use programmatic controls to selectively enable encryption

within the session only when transmitting sensitive data to
minimize the performance impacts of high traffic operations
(such as load or export tasks)

• Network Traffic Encryption

> Provides confidentiality for sensitive data when transmitted
over non-secure networks
– Personal information (e.g., identification numbers)
– Financial information (e.g., credit card numbers)
– Corporate data (e.g., highly classified)
> Protects against compromise by network sniffers
> Built into the Teradata client/server protocol

> Strong encryption
– Symmetric cryptographic algorithms (128-bit+ keys)
– Secure key negotiation algorithm

Logon String Encryption
• Logon String Encryption

> Logon string (including password) is always encrypted
> Functionality cannot be disabled
• By default, Teradata Database gateway will reject any

unencrypted logon attempts
> gtwcontrol can be configured to allow unencrypted logons
to enable connections by pre-TTU v7.1 clients
– Set the ALLOW DEPRECATED LOGONS switch to YES
– Only possible when using pre-TTU v7.1 clients

Tools and Utilities
• Teradata Tools and Utilities client interfaces are

encryption aware
> Configuration Controls

– Allows for a client interface or tool to be configured to encrypt
database sessions
> Programmatic Controls

– Allows for dynamic enabling and disabling of encryption within
a database session

Configuration Controls
CLIv2 System Parameter Block
Teradata ODBC Driver Options

Programmatic Controls
FastLoad
BTEQ

In-Database, Column-Level Encryption
(Data-at-Rest)
• Selectively encrypt sensitive data when stored in

database tables (data-at-rest) to meet policy, legislated,
and regulatory requirements
> Important Considerations

– Performance
– Large data sets, complex queries, indexes, joins, WHERE predicates, …
– Data Size
– Impacted by block-level encryption, Format Preserving Encryption (FPE)
– Encryption Key Security

– Secure, random key generation
– Keys must be securely maintained and periodically refreshed or rotated
– User/Application Transparency
– Particularly important for middle-tier applications
> Optional Third Party Technology Partner products

– Protegrity, Voltage
DPS for Teradata and Protegrity Suite
• Centralized Security Policy Manager

> Create and administer security policy across the enterprise
• Centralized Auditing and Reporting

> Centrally monitor and report on security events
> Compliance and management reporting
> Alerting
> Detailed, Tamper-Proof Audit Trail of all access to protected data
• Data Protection Points

> Cross platform/database support
– Teradata, Oracle, MS-SQL, Open systems, zSeries, iSeries
> File protection for files in transit and files at rest
> Application security integration using available API’s
> Web application security

DPS Architecture for Teradata
•Data protector resides at the
•Thin java client •Houses security policy Nodes database/node level at each
•Runs on a Windows box information
database
•Creates and maintains policies •Houses encryption keys
•Audit log retrieval •Houses audit data
•Provides column level
encryption
ALL STORED ENCRYPTED
•Provides separation of duties. If
not in policy the DBA user will
see encrypted data.
•DataProtector
ESA •UDF
DB User
Security User Server
Views
Policy & Log
Repository
Views
Security Manager •DataProtector
(Security Reporter) •UDF
Log Service
Views
Event •Creates view on top of database

Repository table
•DataProtector •DB user calls the view vs the
•UDF
table making encryption
Defiance Enterprise transparent to the DB user and
Components application

DPS for Teradata
Components
Security Manager
• Thin client for
enterprise-wide policy
management
> One application for all
targets on all platforms
> System configuration
> Security administration
> Policy deployment, and
implementation

DPS for Teradata
Components
SQL Director
• Key user tool for policy
deployment at the
database level
• Selects tables and
columns to encrypt
• Applies encryption rules
• Builds required SQL Code

DPS for Teradata
Components
SQL Director
• Launched from Security Manager
• Generates migration scripts
• Support for all target databases
• ODBC for connectivity
• Supports SQL features
> Identifiers
> Views
> Triggers
• Option to set no-access value for users not having access
to protected data

DPS for Teradata
Components
ESA Server (Hub Controller)

• Central point for system and
policy administration
• Central repository for
> Configuration
> Policy metadata
> Encryption keys
• Key Creation
• Policy Distribution
• Run on dedicated host or VM

DPS for Teradata
Components
Teradata DataProtector
• Applies policy through UDFs
• Handles runtime policy and
policy changes
• Policy distribution through
shared memory
• Local policy cache for
standalone operation
• Enforces Policy
> User Rights, Time of Day, Audit Trail
• Uploads Access Logs to ESA

DPS for Teradata
Components
User-defined Functions (UDF)

Teradata Nodes Views
DB User
In-memory UDFs
Policy • Policy check
• Encrypt/decrypt
DataProtector
• Performs access control

> Validates the user against policy, regarding allowed
operation, and allowed time of access
• Functions for encrypting and decrypting data
• Performs auditing -- who, what, and when?
DPS for Teradata
Components
User-defined Functions (UDF)
• Support for encryption/decryption of CHAR, VARCHAR,

INTEGER, FLOAT, DECIMAL, and DATE data types
• High-performance component integrated in the database
• Installed in the Teradata SYSLIB database
• Used in views or called directly
• Multiple platform and target database deployment

Residual Information Protection
Best Practice
• Storage devices containing classified information should be

physically destroyed or securely wiped prior to disposal or re-
use
> Disks should be wiped using secure, multiple pass algorithms that
incorporate random characters, complements of characters, and
random data streams
> e.g.,
– DoD 5220-22.M Short (3 passes)
– DoD 5220-22.M Medium (7 passes)
– Gutmann (35 passes)
> Latest US Gov requirements for fixed disks is degaussing or

complete destruction for classified data storage media.
• See document isl_2007_01_oct_11_2007_final_agreement.pdf (2007)
> Section 54. DSS Clearing and Sanitization Matrix (5-704, 5-705, 8-103f, 8-301)
• See document NSA_CSS_Storage_Device_Declassification_Manual.pdf (2008 ?)
• See document nispom2006-5220.pdf (2006)
• See also NIST 800-53 (Media Sanitization) and 80-60 (Data Classification or impact level)

Best Practices
• Enable Teradata Database Access Logging to provide an

audit trail of database events that can be used to detect
security violations
• Establish procedures for regular monitoring of all audit
logs
> Ensures that users are only performing activities that have been explicitly
authorized
> Frequency of audit log reviews should be determined by risk factors
– the criticality of the data warehouse to business operations
– the value, sensitivity or criticality of the information stored in the data warehouse
– the past experience of system compromise or misuse
– the extent to which the system is accessible via non-secure networks
• Periodically archive audit logs for use in security

investigations and access control monitoring

Teradata Database Access Log
• Teradata Database Access Log

> Audit database events to detect security violations
– Potential break-ins
– Attempts to gain unauthorized access to database resources
– Attempts to alter the behavior of Teradata auditing facilities
> Capture information about access requests

– Type of access
– Type of request
– Requesting user
– Referenced object
– Frequency of access or attempted access

• Teradata Database Access Log

> Access logging is controlled through the use of the BEGIN
LOGGING and END LOGGING statements
– The DIPACC script must have been run to create the special
security macro DBC.AccLogRule
– The system must be reset to initialize the logging software
– The Security Administrator must have been granted the
privilege to EXECUTE the DBC.AccLogRule macro

• Minimum Teradata Access Logging Guidelines

> Audit all attempts to access the security administrator macros
> Audit attempts to change status of a Teradata Database object
> Audit denied attempts to access users DBC, SYSADMIN, SECADMIN,
...
BEGIN LOGGING WITH TEXT ON EACH ALL

ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule ;
BEGIN LOGGING WITH TEXT ON EACH

USER, DATABASE, TABLE, VIEW, MACRO, PROCEDURE, GRANT ;
BEGIN LOGGING DENIALS WITH TEXT ON EACH ALL ON USER DBC ;

BEGIN LOGGING DENIALS WITH TEXT ON EACH ALL ON USER SYSADMIN ;
BEGIN LOGGING DENIALS WITH TEXT ON EACH ALL ON USER SECADMIN ;

Audit Reports via Teradata Manager

Teradata Database LogOnOff Log
• Teradata Database LogOnOff Log

> The Teradata Database automatically audits all user logon
and logoff activity through the session event log table
(DBC.EventLog)
> Audit information can be used to detect

– Failed logon attempts
– Possible indication that an attacker is trying to compromise a user login
through a brute force password attack
– Non-typical access periods
– Possible indication that an attacker has compromised a user login
– Non-typical logon source
– Possible indication that an attacker has compromised a user login
(particularly for batch or application logins)

Data Dictionary Tables and Views
The Data Dictionary is a complete database composed of Tables, Views, and

Macros that reside in system user DBC. The Data Dictionary contains information
about the entire database. Use the Data Dictionary to obtain useful information
about everything in your system.
Data Dictionary Overview

Data Dictionary (Log) Tables are created when you install the Teradata software.
The system references some of the Data Dictionary tables directly with SQL
requests. Other Tables are used only for system or data recovery.
The system also uses Data Dictionary Views and Macros that access or manage
information in the Data Dictionary tables. Views and Macros are created by
running DIP scripts.
Managing the size of Data Dictionary Tables (sometimes called logs) can help
improve performance. Teradata Database does not delete system data on its own
so you must manage the logs and tables yourself. Determine what you should
archive and what you should delete as needed for your site.
Refer to the Data Dictionary Quick Reference v??.xx.pdf (for your version of
Teradata) for a listing of all Data Dictionary Log Tables, Views and Macros

Managing System Logs
Purging the System Logs

Teradata does not automatically purge Log Tables underlying Views such as the
AccessLogV, LogOnOffV, and Software_Event_LogV views.
Teradata recommends copying data off the DBC Tables into a separate database or
archive the data as required then delete information from the DBC tables.
Some DBC objects to consider purging include:
• Resource usage (ResUsage) tables that have logging enabled.
• DBQL logs, which include all DBQL tables that have logging enabled.
(The tables DBC.DBQLRuleTbl and DBC.DBQLRuleCountTbl are not part of the log maintenance list.
These tables are automatically maintained by the Teradata SQL BEGIN/END QUERY LOGGING statements
An error is returned if you attempt to delete their contents.)
• DBC.SW_Event_Log

Managing System Logs
Purging the System Logs

• QCD.DataDemographics.
(If you use Query Capture Facility [QCF] with the SQL COLLECT DEMOGRAPHICS statement, you need to explicitly
delete rows from this table, DataDemographics, in your user-defined QCD databases.)
Note: Entries in DataDemographics are deleted automatically when you use the INSERT
EXPLAIN WITH STATISTICS AND DEMOGRAPHICS statement. For more
information, see "Query Capture Facility" in SQL Request and Transaction Processing and
"COLLECT DEMOGRAPHICS" in SQL Data Manipulation Language.
For a full list of other tables to consider purging, see “Cleaning Out Frequently Updated
Logs” in the appropriate version Security Administrator Guide.
Also, the security administrator should purge the logs associated with access logging as
well as any other security-related views as needed.
In addition to maintaining the size of system tables and logs, you can reduce log file sizes as follows:
• Use only DBC.ResUsageSpma instead of activating logging on multiple ResUsage tables.
ResUsageSpma may provide all the information you need.
• Use roles to manage privileges which help reduce the size of DBC.AccessRights.
For other tips on reducing the size of the DBC.AccessRights table, see “Housekeeping on an Ad-Hoc
Basis” section of Security Administrator Guide.
• Track only the information you need for DBQL. The DBQLogTbl may provide required information.
• Track only the information you need for accounting.
• Use active row filter mode where possible for ResUsage tables.

User-Restricted Views (X Views)
System View names followed by an X indicate a User-restricted View.
The contents shown by the View apply only to the User submitting the query that
acts upon the View.
User-restricted Views, or “X” Views, report only a subset of the available

information because they are defined with a WHERE User=username clause,
They return information only on objects the requesting User owns or on which
the User has privileges.
Restricted Views have the same columns as non-X Views with the exception that
because the definition for the restricted view has a WHERE clause, the User can
only view objects he or she owns, is associated with, has been granted privileges
on, or is assigned a Role which has required privileges.

Unicode Views (V Views)
Unicode Views (V Views)

System View names followed by a “V” appended to the ViewName indicate the
Unicode version of the View (or VX if you are using user-restricted Unicode
views).
The Data Dictionary defaults to storing object names in Unicode so that the same
set of characters are available with the same length restrictions regardless of the
character set of a client.
Note: The Data Dictionary functions the same whether or not Japanese
Language support mode is enabled.
Also, object names with multi-byte character sets can be shared between non-
Japanese session character sets.
For more information, see International Character Set Support.
Teradata also recommends that if you add any new Views to database DBC, add
a V suffix to the View name. For more information, see "Unicode System Views"
in Data Dictionary.

Secure Zone
Best Practice
• Restrict network access to and from the Teradata data

warehouse using appropriate network perimeter security
controls
> Firewalls, Routers, Switches (logical or physical boundaries)
> Gateways with Access Control Lists
> Virtual Private Networks (VPNs)
> IPFilter (restrict connections to specific client IP address)

Secure Zone
Teradata Network
Source Data
Corporate
TD Support Servers
Network
ETL Server
Backup Server
TD Firewall
TD VPN
Application / OLAP / Query Servers

Public
Network
WAN-to-LAN
Firewall Firewall
Firewall
Customer LAN
Production
Data Warehouse
Firewall
Development
AWS Test
Support LAN Private LANs
Teradata DMZ
Teradata ServiceLink Security
Access List Reference Table
Windows AWS
TCP 20,21 (FTP)
Support TCP 22 (SSH)
TCP 23 (Telnet)
(Traffic from Teradata TCP 3389 (Terminal Services)
to your site)
TCP 8443 (SSL for Parallel Upgrade Tool (PUT))
TCP 8080, 9000 to 9010 (PUT)
TCP 22 (SSH)
Linux OS TCP 1025 (ODBC)
Support TCP 7060 (JDBC)
TCP 5801 (GUI Admin)
TCP 5901-5902 (VNC)
(Traffic from Teradata
to your site) TCP 8443 (SSL for Parallel Upgrade Tool (PUT))
TCP 8080, 9000 to 9010 (PUT)
Some or all ports may be required depending on the specific Teradata installation.
Custom ports can be used for customer specific toolsets if required.

Teradata ServiceLink Security
Access List Reference Table
TCP 3389 (Terminal Services) – Windows

BAR Support
TCP 22 (SSH) - Linux
(Traffic from Teradata TCP 5801 (GUI Admin) - Linux
to your site)
TCP 5901-5902 (VNC) - Linux
Fault TCP 22 (SSH) for TVI installations

Reporting
Teradata prefers that fault reporting traffic be routed through the Internet, not
through the VPN.
(Traffic from your Fault reports are encrypted and do not contain information from the data
site to Teradata) warehouse.
Patch Updates TCP 22 (SSH)

or
and Memory TCP 20,21 (FTP) - optional
Dump Analysis
This traffic is routed through the Internet, not through the VPN.
(Traffic from your
site to Teradata)
Some or all ports may be required depending on the specific Teradata installation.
Custom ports can be used for customer specific toolsets if required.

Operating System Security
Best Practices
• Properly secure the underlying server operating system

to include
> Securing system and user accounts
> Securing file/directory permissions and ownership
> Minimizing system and network services
> Enabling system auditing and logging
> Sudo configuration
• Restrict operating system access to only those users

required for administration, maintenance, support, or
monitoring of the server
• Use secure protocols for remote access to the Teradata
Database server
> VPN remote connectivity, Secure Shell (SSH), Secure FTP (SFTP)

V13.0
Enhanced Security Using AppArmor Profiles
• AppArmor
> Novell SUSE Linux Enterprise Server 10 (SLES 10) immunization
technology
> Provides host intrusion prevention and mandatory access controls
for applications
>
• Teradata 13.0 includes a set of AppArmor profiles
for Teradata executable processes
> Profiles enforce tighter restrictions on access to files and
administrative system calls
> Protects systems and networks from possible security vulnerability
exploits of database processes running with root privileges
> Profiles can be enabled/disabled using new tdapparmor utility
– Teradata AppArmor profiles are enabled by default

Vulnerability Management
Best Practices
• Ensure that processes are in place to monitor for vulnerabilities

and apply required security patches
> Only install patches/hotfixes/e-fixes that are certified and
provided by Teradata
• Install and maintain anti-virus software on any Windows-based

AWS or Teradata Database server
• Regularly run vulnerability

assessment and scanning
tools to verify and maintain
the secure configuration of the
server and database

Security Threats
• Database Security Threats

> Misuse of information and
privilege abuse by authorized
users
> Unauthorized information
disclosure or modification
> Vulnerability exploits
> Network snooping
> Denial-of-service attacks
> Database protocol attacks
> SQL injection attacks
> Database worms
> Non-secured backups
> Data destruction

Physical Security
Best Practice
Restrict physical access to the Teradata data warehouse
> Maintain the Teradata data warehouse in a secured data center
> Restrict access to the data center to authorized personnel only
> Periodically review data center access list and keep it current
> Maintain a log of all persons entering the data center
> Ensure that all visitors to the data center are supervised
> Challenge any unknown/unauthorized person in the data center
> Store any media containing sensitive data in a controlled area

Security Process Audit
Best Practice
• Periodically audit the data warehouse environment to

ensure that all required security controls are in place and
that the policies and processes reflect current business
requirements
> Periodic audits allow for the data sensitivity and risk to be
reviewed and security controls revised if necessary
> Demonstrates due diligence in applying and enforcing

stated policy

Business Continuity Plans
Best Practice
• Develop and implement business continuity plans to

enable recovery from security incidents
> Plans should consider business risks and impacts resulting
from a security incident
> Controls should be implemented to reduce risks, limit
exposure to incidents, and ensure that business operations
can be resumed in a timely manner
> Plans should include all necessary data and software back-
up and recovery procedures
> Processes should be developed for regular testing of the
plans
> Plans should be periodically reviewed and updated to reflect
changes in business operations or associated risks

CS - Secure Remote Support Portfolio
Advanced or
Warehouse Security Custom / PS •Custom Security Needs
•File change detection

Change •Sensitive file audit
Tier 3 •Customer Selected files
Detection
•Changes delivered to
customer
Non Root Access •No root / admin access

Tier 2 (command restricting)
w/ Logging
•Command Logging
•Customer managed accounts

Tier 1 User & Access •Access approval process
Management •Automated password changes
•User maintenance menus
•Fewer Ports
•Some Logging Capability
Foundation
ServiceLink ServiceLink •2 Factor Authentication
•Strong Encryption


Teradata InfoSec Slides Defense in Depth Best Practices Pres December 2011 - FINAL

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Teradata InfoSec Slides Defense in Depth Best Practices Pres December 2011 - FINAL

Încărcat de

Drepturi de autor:

Formate disponibile

Defense in Depth

Les McMonagle (CISSP, CISA, ITIL)

• Les McMonagle is an information

July 6, 2018 Teradata Confidential 2 2

A strategy for implementing multiple layers of

> Security considerations include:

July 6, 2018 Teradata Confidential 3 3

Security Policies and Procedures

Operating System Hardening

Certification and Accreditation

July 6, 2018 Teradata Confidential 4 4

Authentication • Username/Password Authentication • TDP Authentication (External Security

Authorization • Discretionary Access Control Policy • Directory-based Authorization (External

Data • View-based Security (Row/Column) • Defiance DPS for Teradata

Auditing and • LogOnOff Log • Teradata Manager Audit Reports

Environment • Operating System Hardening • Operating System Configuration -

July 6, 2018 Teradata Confidential 5 5

07 • Security Policy 122 • Secure Zone

• User Identification 130

• Develop and publish a security policy specific to the

• Consider use of personal non-disclosure agreements

• Integrate data protection policy into IT outsourcing,

• Apply Separation of Duties where applicable

July 6, 2018 Teradata Confidential 7 7

• Essential elements of a Data Warehouse Security Policy

July 6, 2018 Teradata Confidential 8 8

A security principle dictating that no one person should

> Access Approver should be separate from Access Grantor

July 6, 2018 Teradata Confidential 9 9

• Separate security administration from database

July 6, 2018 Teradata Confidential 10 10

CREATE USER SECADMIN AS PASSWORD = xxx,

GRANT USER ON SECADMIN TO SECADMIN /* maintain users */ ;

July 6, 2018 Teradata Confidential 11 11

• All major data assets within the data warehouse should

> Inventory of data warehouse assets

> Information classification

July 6, 2018 Teradata Confidential 12 12

Confidentiality: ensuring that data

Integrity: safeguarding the accuracy

Availability: ensuring that authorized

July 6, 2018 Teradata Confidential 13 13

Example - Confidentiality classifications

July 6, 2018 Teradata Confidential 14 14

Example - Confidentiality classifications (continued)

July 6, 2018 Teradata Confidential 15 15

Example - Confidentiality classifications (continued)

> Public Data

July 6, 2018 Teradata Confidential 16 16

• Ensure that all users are uniquely identified

• Enforce use of strong passwords

• Create and assign profiles to enforce appropriate

July 6, 2018 Teradata Confidential 17 17

• Dictionary-based Password Checking

> Dictionary-based password checking is enabled through

July 6, 2018 Teradata Confidential 18 18

• DBC.PasswordRestrictions Dictionary Table

• DBC.RestrictedWords[V] System View

July 6, 2018 Teradata Confidential 19 19

• DBS Password Enhancement feature completes the

• Replaces 64-bit DES encryption algorithm

• Two forms of password encryption (from previous

• All passwords created on old releases will continue to