Cybersecurity briefing
/
The Drive Is Encrypted. Who Can Read the Files?
Disk encryption protects a stolen laptop, not files read by malicious software after sign-in. Learn how to test file-level access controls before buying.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
A laptop's disk encryption can be working exactly as intended while malicious software copies the files its user is allowed to read. Once the machine is running and the volume is unlocked, protection against someone removing the drive is answering a different question from protection against a process accessing a spreadsheet. Organizations evaluating stronger data security need to understand that distinction before buying another encryption product.
CyberMaxx's October 27 discussion of its third-quarter ransomware research provides a timely reason to revisit it. The report examines both ransomware and data extortion, with activity affecting manufacturing, healthcare, technology and other industries. Its observations describe the firm's research population, rather than a complete census of attacks, but the business concern is familiar: recovering systems and preventing disclosure are separate responsibilities.
A stolen laptop and a stolen file are different problems
Full-disk encryption is an essential control for devices that leave the office. It helps protect stored information when an unauthorized person obtains the hardware. Startup authentication adds a decision before the protected operating environment becomes available.
Those capabilities are established features across the market. BitLocker supports pre-boot authentication, including PIN-based configurations. WinMagic documents pre-boot authentication and management of Opal self-encrypting drives. Hardware encryption, AES-256 and a startup prompt do not, by themselves, explain why an organization should choose a different supplier.
The question changes after sign-in. A finance employee needs to open forecasts. A backup service needs to read documents. A malicious process running with sufficient access may also try to read those files. Disk encryption alone does not decide which of those requests serves a legitimate business purpose.
Consider a hypothetical employee who opens a malicious attachment while working with a locally stored acquisition folder. The drive remains encrypted at the storage layer. The immediate security question is whether the resulting process can read, alter or copy the folder's contents. Increasing the disk-encryption key length would not resolve that authorization problem.
Put a decision closer to the data
File-level protection adds a control at the point where information is accessed. The objective is to make a successful Windows sign-in insufficient, by itself, to authorize every subsequent request for sensitive files.
Cigent's Data Defense software addresses this layer separately from its encrypted SSDs and pre-boot products. Its policy documentation describes protection for selected folders and file types, with Dynamic and Always On modes. It also defines limits on the number of file accesses a user can pre-approve and how long that approval lasts.
For the acquisition folder, the relevant design is an additional authentication requirement at file access, governed by policy. An organization would test whether an unapproved request is stopped without the required authorization while the employee's intended work remains usable. That is a meaningful evaluation beyond checking whether the drive reports “encrypted.”
Cigent's Data Defense release history documents file reauthentication controls and BitLocker management. Its current console documentation also describes BitLocker policy and recovery-key administration. The proposition can therefore be additional protection around files alongside supported disk encryption, rather than an automatic requirement to replace BitLocker or purchase a particular SSD.
These are Data Defense capabilities. They should not be assumed to appear merely because an organization installs a Cigent encrypted drive. Product version, supported endpoints and configured policy determine the deployed protection.
An application exception is a security decision
Background services complicate file authentication. A backup application cannot reasonably ask an employee to approve every document it reads overnight.
Cigent's Safe Apps policy allows designated applications to access protected files without the additional authorization. The documentation identifies applications using certificates, with optional name or folder restrictions. That exception keeps legitimate automation working, but it also deserves close review.
A trusted application may itself be compromised or misused. Buyers should test that scenario explicitly instead of assuming that an approved program always performs approved work. Narrow exceptions where possible, retain their business rationale and revisit them when applications change.
Policy scope matters just as much. Protecting one folder leaves copies elsewhere to be assessed. Approval windows reduce interruptions but also define how much access remains available before another challenge. A control that responds to a detected threat has different dependencies from one enforced before the first suspicious event.
None of this makes file-level protection pointless. It makes the implementation consequential. The claimed benefit must survive the actual exceptions and workflows the organization needs.
Test access, not the encryption checkbox
A useful evaluation starts with a small collection of sensitive files and representative applications. Include ordinary editing, backup, synchronization, recovery and a controlled unauthorized-access test. Record which requests succeed, which require authentication and which fail.
Test after a fresh sign-in and during an existing approval window. Examine access through a trusted application, then check what happens when a protected file is copied to another location. Use test data and approved procedures so the exercise measures controls without risking production information.
Require evidence that explains the result. A blocked request should be traceable to the intended policy; an allowed request should have an understandable authorization path. Where a scenario remains unprotected, document the complementary control needed, whether endpoint detection, application restrictions, least privilege or data-loss prevention.
The purchasing question is straightforward: which sensitive-file access does the proposed deployment prevent that the current deployment permits? If the answer is only a different encryption logo or another startup prompt, the business case remains weak. If the organization can demonstrate an additional, workable access boundary around its important files, it has something concrete to evaluate.
