## Security

### Security
- Goals:
- Confidentiality (protection from unauthorized disclosure)
- Integrity (only authorized users modify data)
- Availability
- Database design:
- consider possible attacks
- Consider risks for data
- Classes of users
- Without access: No access
- With access: Not performing actions

### Security: Measures
- Restrict physical location
- Data encryption
- Authentication (verify users identity)
- Audit trails (log actions, check report)
- Access control / authorization (verify security policy)

### Access Control: Access policy + limitation
- Access control policy: If/how can users access data and transfer of rights
- Closed system: explicit access
- Open system: not explicitly forbidden access
- Multi-level protection system: Classification levels
- Access limitation
- Minimum privilege policy (overly restrictive, „need-to-know-policy“)
- Maximum privilege policy (maximum sharing)
- Administration of ACP:
- Centralized: DBA
- Decentralized: different DBAs
- Cooperative: Agreement
- Based on ownership
- Access control types
- Discretionary AC
- Mandatory AC
- Role-based AC

#### Access Control: Granularity + Practice
- Granularity of access control:
- Database
- Relations (subset, individual)
- Records (subset, individual)
- Attributes (subset, individual)
- Restricting granularity: View (vertically + horizontally)
- Commercial DBMS
- Flat namespace = Unique table names
- Database login name = username
- Table/view name prepended with username

#### DAC
- Define rules for each user and for each database object the privileges
- Users can grant/revoke rights (discretionary)
- Granted access propagable
- GRANT <privileges> ON table/columns ON <grantees> [WITH GRANT OPTION]
- WGO: Permit propagation (grantees: PUBLIC possible)
- Checking: Authorization matrix (rows: users, column: database object, field: privilege)
- Extend with predicates
- Data-dependent: Constraint on data
- Time-dependent: Constraint on time
- Context-dependent: E.g. read allowed, join prohibited
- History-dependent: E.g. dependency on previous access

##### DAC: Problems
- Problem: Revocation
- After revoking: Privileges should automatically be revoked
- Complex decision
- Situation: User granted by two different users, one revokes
- Problem: Flow of information
- Data flow not controlled by DAC
- User copies data to own table
- Solution: Flow controls
- Prevent explicit (copy) and implicit (via intermediate) flow

#### MAC
- Map objects onto classification level / sensitivity
- All data must be classified
- Users get clearance level
- Access: Compare requester level with item level
- Security level: <classification, set of categories>
- Subjects: Active elements
- Bell-LaPadula: Archives secrecy, unauthorized modification possible
- Biba model: Bell-LaPadula for data integrity
- Dion model: Bell-LaPadula + Biba
	- SeaView security model: Adapt for RDBMS
- Advantage: Suitability to environments (user/objects classified)
- Disadvantage: Overly strict

##### MAC: Axioms
- Must hold for secrecy
- Simple security property (no read-up)
- Subject clearance level must dominate object clearance level iff access
- *-property (no write-down, flow control)
- Untrusted subject may have
- Append access: SL(object) >= SL(subject)
- Write access: SL(object) = SL(subject)
- Read access: SL(object) <= SL(subject)
- Discretionary security property
- Every access must be present in access matrix
- Tranquility principle: No subject can modify classification of active object.

#### Role-based access control
- Operations with meaning in the organization
- User is granted/revoked roles
- Example role „bank clerk“
- Fine grained operations

### SQL Injection
- Directly insert user input into query
- Attacks: Authentication, delete tables, capture system
- Prevention: Sanitize input, escape input, cast input, prepared statements
- Workflow: Discover vulnerability, enter control char, guess structure

### Anonymization
- Anonymizing data not trivial
- Cross-matching via public sources
- Proper data anonymization is very important
- How to protect private content, preserve useful context?
- Bad: Remove personal identifiers, remove data details
- Approach: Privacy Preservation
- Fight data mining (modify until no rules found)
- Probabilistic
- Statistical approach (content blocks)
- But: Frequency analysis, short pattern matching

### Statistical security
- DB offers statistics (AVG, COUNT, MAX, …)
- Problem: Statistical inference (reengineering)
- Statistical filter
- Permit only statistical queries
- Problem: Inference still possible
- Statistical database
- positively compromised (indiv. Has value)
- Negatively compromised (indiv. Has not value)
- Anonymization does not suffice

### Inference protection
- Major techniques
- Conceptual
- Restriction-based
- Perturbation-based

#### Inference protection: Conceptual
- Lattice model
- Model of attributes/aggregates in tables
- Harmful statistic: n-respondent, k%-dominance criterion
- N of fewer records represent more than k% of the population
- Permit statistic iff individual is not identified by some parent table

#### Inference protection: Restricttion-based
- Restrict queries that compromise database.
- Simple: Restrict queries with result size k < |R| < |DB| - k
- Problem: Tracker-based attack (Ai=x) + (Ai=x AND NOT Aj=y AND NOT Ak=z)
- Solution: Check all possible combination (restriction not possible)

#### Inference protection: Perturbation-based
- First: Data swapping (statistics correct, new DB != old DB)
- Second: Random sample queries on random DB samples
- Third: Result rounding (perturb response, round values to some base)
- Attacks
- Frequency of attribute known