Data-centric Security

The technical foundation of data-centric security is a file format that carries its protection conditions inside the file itself. This page describes that format and how files are verified and recovered.

01

Limits of existing approaches

01

Classification labels easily removed or changed

Conventional classification labels are written in document properties or file names, where they can easily be removed or changed.

02

Repository encryption that decrypts everything at once

With full-disk or repository-level encryption, all stored files are decrypted as soon as access is granted.

03

Tampering that is hard to detect

When attributes exist only in document metadata, changes made with an editing tool are hard to tell apart.

02

Comparison with existing approaches

Item
Perimeter DLP
Document DRM
Data-centric security
Where protection applies
Network and endpoint exits
Document files
Document files
Files exported outside the perimeter
Protection not maintained
Permissions on a policy server
Security attributes contained in the file
Classification scheme
Detection rules
Permission levels defined by each product
Level, compartment, and distribution control, mapped to standard classification schemes
Tamper detection
Not applicable
Varies by product
Verified by digital signature
Damage during saving
Not applicable
Varies by product
Recovered from spare information in the file

This summarizes general tendencies and may differ for individual products.

03

Self-protecting file format

A protected file holds the encrypted content, security attributes such as level, compartment, and distribution control, and integrity information together in a single file.

Because the security attributes are not looked up in a separate database or storage location, they are not separated from the content even when the file is copied or sent outside.

04

File-level encryption separated from access rights

The key that encrypts the content is released only when the user's clearance satisfies the file's security attributes.

File possession and access rights are separated, so even if a file leaks, its content is not revealed to anyone without clearance.

05

Signature-based integrity verification

The issuer's digital signature is recorded with the security attributes and the content. When a file is opened, the signature is verified to identify files whose level was lowered without authorization or whose content was altered.

Large files are verified in parts, so changes can be detected without re-verifying the whole file.

06

Self-recovery from damage

A power loss or an interrupted write during saving can damage part of a file.

A protected file keeps spare recovery information inside itself, and when damage is detected, it uses that information to return to a readable state.

How it differsWith many encrypted files, even slight damage to the header makes the whole file impossible to open.
07

Assurances

Protection maintained outside the secure area
Only users with matching clearance can open files
Detection of level downgrades and content tampering
Recovery from damage during saving
Uses NIST CMVP-validated cryptographic modules (FIPS 140)
Security attributes mapped to standard classification schemes
08

Alignment with the Zero Trust Data pillar

Addresses the Data pillar among the seven pillars of the US Department of Defense Zero Trust Strategy.

Classification, marking, and access control at the data level are handled within the file format.