Opinions about ActiveBase webcast

I attended the ActiveBase webcast just now. The brief introduction of their product can be found here: link. Here's a quick summary of their product,

ActiveBase, currently support oracle and sql server, provides sql proxies based on query rewriting to dynamiclly anonymize data. There's no need of change to application and db. The product can be installed 1. on each database server. 2. dedicated app servers as proxies/firewall.

The protection solutions they provide: masks, scrambles, hides, audits, blocks fields. They adopt Role Based Access Aontrol to determine the anonymization methods and results returned to user.

Major concerns I have about their product:

- It seems the query rewritting technique needs a lot of manual effort, for each type of query. It is hard to automate for ad hoc queries. So there's big maintaince cost.

- They don't have any privacy guarantee on their solution. Specificly, they use the query proxy technique and dynamiclly rewrite each query and return answers. Will the attacker be able to design queries carefully, and get multi versions of the anonymized data, make comparisons and thus lead to information leakage?

- What's the usability of the anonymized dataset? For simple masking, the data doesn't have much usability after anonymization.

Anyway, I'm still glad to see privacy and anonymization are getting more and more attention, and new products being developed. An interesting future work would be: what are the special techniques needed to provide anonymity to no-sql databases and cloud db?

Data Protection general practices

Data Protection Layers:
- Application
- Database
- File System

Operation Cost Factors:
- Performance
- Storage: data storage requirements
- Security
- Transparency: change to applications, and supports to utilities.

Data Protection options:
- Clear: actual value

- Hash: unreadable, not reversible
keyed hash(HMAC) provides strong protection
Considerations: key rotation

- Encryption: unreadable, reversible
Considerations: storage type, transparency to applications, key rotation

- Format controlling encryption: unreadable, reversible
Considerations: key rotation.

- Replacement(tokens): unreadable, reversible
Proxy value created to replace original data.
Considertations: transparency for applications needing original data.

Continuous data protection:
- Automatically save a copy of every change made to the data. It allows the user or administrator to restore data to any point in time.

- Advantage: Most continuous data protection solutions save byte or block-level differences rather than file-level differences. So if the portion of write data is small, save only the write changes will require less space on backup media.

- Cost: introduce extra disk write operations and continuous network usage.

Failure Protection in Teradata

let's first look at Data Allocation in Teradata: Bacisally, OS recognize logical units(LUN), which is composed of slices(UNIX) or partitions(Windows/Linux) from each of the disk drives of a disk rank. Then the PDE translates the LUN into one or more pdisks. psdisks are then assigned to AMPs. All the logical disk spaces an AMP manages is called a vdisk. In general all pdisks from a rank will be assigned to the same AMP.

Failure protection in Teradata falls in the several different levels:

Disk drive level: RAID
RAID: Redundant Array of Independent(or Inexpensive) Disks.
The various designs of RAID systems involve two key goals: increase data reliability and increase input/output performance. There are six different designs RAID 1 to RAID 6 that provides fault tolerance (There's also so called RAID 0 which has no fault tolerance, and RAID 10 TBD.)

Teradata supports RAID 1 and RAID 5.
- RAID 1(mirroring without parity): Data is fully replicated in mirror disk(s). Read blocks from the 1st available disk. Besides failure protection it also provides great performance benefit.

- RAID 5(block-level striping with distributed parity): Data is striped across a rank of disks one segment at a time. Parity is also striped all disk drives, interleaved with data. When a disk fails, data is reconstructed on the fly using existing data and parity.

RAID 1 is faster than RAID 5, as the two(or more) disks are read parallelly, and no parity computation.

AMP level: Fallback tables
Storing a 2nd copy of each row of a table on a different AMP in the same cluster. Specified during table creation. Fallback will cause twict I/O on data modifications.

Obviously the highest level of protection is RAID 1 with Fallback protection.

Componenet/Process Level: Journal
Journals are used for specific types of data or process recovery.
Recovery Journals: maintained by system automatically. Two different types:
- transient journal: keeps "before image" of changed rows so data can be restored to previous state in case of an interrupted transaction. Happens in each AMP.
- down AMP recovery journal: log write changes to data on the failed AMP by other AMPs in the cluster. Then applying changes to the recovered AMP.

Permanet Journals: optional, user specifies at table level, and can store before images or after images to provide full-table recovery to a specific point in time.

Database Object Level: Locks
Applied at 3 different levels: Database/Table/Row Hash
4 types:
- Exclusive: at db/table level, used for DDL, blocks all other locks
- Write: ensures data consistency while writing, only allow access locks
- Read: ensures data consistency while reading, allows read/access locks
- Access: allows table update only for small single-row changes, blocks exclusive locks.
Local deadlocks are checked at AMP level, and global deadlocks are coordinated by PE on a timed basis.

Top 10 Database Security Threats

Here's a brief digest of the docs from Imperva Inc. Due to copy right I won't post the original pdf here, but can easily search for it online.

- Threat 1 - Excessive Privilege Abuse:
When users (or applications) are granted database access privileges that exceed the requirements of their job function, these privileges may be abused for malicious purpose.
> Prevension - Query-Level Access Control
* restricts database privileges to minimum-required SQL operations (SELECT, UPDATE, etc.) and data.
* most database has some level of query-level access control (triggers, row-level security, etc), but too time consuming to do manually.

- Threat 2 - Legitimate Privilege Abuse
Users may also abuse legitimate database privileges for unauthorized purposes.
> Prevension: Understanding the Context of Database Access
Enforcing policy for client applications, time of day, location, etc., identify users access in a suspicious manner.

- Threat 3 - Privilege Elevation
Attackers may take advantage of database platform software vulnerabilities to convert access privileges from those of an ordinary user to those of an administrator. Vulnerabilities may be found in stored procedures, built-in functions, protocol implementations, and even SQL statements.
> Prevension: Intrusion prevention systems(IPS) and Query Level Access Control
IPS inspects database traffic to identify patterns which correspond to known vulnerabilities.
(pls report back to DB venders and get patched if you find such)

- Threat 4 - Platform Vulnerabilities
Vulnerabilities in underlying operating systems (Windows 2000, UNIX, etc.) and additional services installed on a database server may lead to unauthorized access, data corruption, or denial of service.
> Prevension: Software Updates and Intrusion Prevention

- Threat 5 - SQL Injection
When a perpetrator inserts (or injects) unauthorized database statements into a vulnerable SQL data channel.
> prevention: Three techniques can be combined to effectively combat SQL injection: intrusion prevention (IPS), query-level access control, and event correlation.

- Threat 6 - Weak Audit Trail
Weakness may come from several aspects:
Lack of User Accountability when users access via web apps; degrading system performance; limited granularity etc.
> prevension: Increase performance; Separation of duty, audit duties should ideally be separate from both database administrators and the database server platform; Cross-platform auditing. Network-based audit appliances can help all these.

- Threat 7 - Denial of Service
Access to network applications or data is denied to intended users. Resource overload is particularly common in database environments.
> Prevension:requires protections at multiple levels. In this database-specific context, deployment of connection rate control, IPS, query access control, and response timing control are recommended.

- Threat 8 - Database Communications Protocol Vulnerabilities
> prevention: Protocol validation: parses (disassembles) database traffic and compares it to expectations. In

- Threat 9 - Weak Authentication
Stealing or otherwise obtaining login credentials by means of: brute force, social engineering, credential theft.
> prevention: strong authentication (in practice strong password); directory integration, use single set of login across enterprise.

- Threat 10 - Backup Data Exposure
> prevention: database backups should be encrypted.(addition: should apply the same security constraints as the original data)

In short, I will classify them into 4 categories:
- Bugs in access control(privilege design/assignment)
- software/hardware/network vulnerabilities and attacks
- User Accountability
- Backup data explosure