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 ON table/columns ON [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