In most organisations data is the primary source of value. Wether that data is the source code to the next big breakthrough, a list of opportunities and sales tactics, or a more traditional data set such as a back catalogue of music, how it is managed is critical to modern businesses and losing that data brings major consequences.
This post in a series on Security at all levels focuses on the security of data. I’ll look at how data can be protect in three states; At Rest (Store), In Transit (Move), and In Use (Access), and in three ways; Encryption, Permissions, Resiliency.
When thinking about data security it’s important to firstly understand how and why you classify your data. Being able to categorise data will then allow you to understand which security control need to be in place. Often security is lax because it is seen as over burdensome, especially when looking at data. As a result the “anyone can ready anything, just in case” is often the fallback position to avoid extra complexity, cost, or delay. Being able to determine which controls are needed ensures that only the “barriers” that are needed are implemented.
So I like to think of my storage technologies as a self-storage facility for my data. For some data I have self-service location similar to shipping containers cheap and dirty. For my crown jewels of data such as PII or IP, I use a regulated and bonded storage facility. For everything else there are grades in between each with different characteristics and force me to do things in a particular way.
Storage
Where and how you store data has a huge impact on how secure it can be. A file on a EBS volume can be managed differently to one on an EFS share or in an S3 bucket. However, the same principles can be applied and should hold true for which ever technology you choose, on-premises or in the cloud.
Storage Encryption
Do I encrypt the storage or the data?
The best answer is normally both. Storage-level encryption protects the underlying volume, file system, database or object store if media, snapshots or replicas are exposed. Data-level encryption protects selected fields or files before they are written and can preserve confidentiality as data moves between services. These controls should use approved algorithms and centrally governed keys, with separation between permission to read the data and permission to decrypt it. Key ownership, rotation, recovery and deletion must follow the data classification and retention policy.
While they are related but not interchangeable. Encrypting a disk does not protect a sensitive record once an authorised application has opened it, while encrypting only selected records may leave filenames, indexes, logs and temporary files exposed. The design should therefore identify what is encrypted, where decryption occurs, who can use the key and what happens if the key is unavailable or compromised.
Storage Permissions
Storage should be private by default and opened only through explicit, reviewed grants. Human and workload identities should receive the minimum read, write, delete and administration rights needed for their role, at the time and method they need it. Data access should be seperated from key administration duties, along with the avoidance of shared credentials. Where feasable, direct public access to data should be avoided, and the use of resource policies, identity policies, and network policies to enforce boundaries should be considered. All access should be time-bound where practical and logged so that unusual reads, bulk downloads, policy changes and deletion attempts can be detected and investigated.
Storage Resiliency
A secure data store must also remain available and recoverable. Data should be assessed so that the correct replication, versioning, and backup controls can be applied from the business recovery time and recovery point objectives rather than from convenience. Backups should be protected with the same classification, encryption and access controls as the source, but keep recovery copies sufficiently isolated so that one compromised administrator, account or region cannot destroy both. Immutability or retention controls can reduce ransomware risk, while regular restore tests prove that data, encryption keys, configuration and dependent services can be recovered together.
Transit
Data in transit is data crossing a boundary: between a user and an application, between services, between cloud and on-premises environments, or between regions and organisations. Like a highway, the route matters as much as the cargo. Each hop, intermediary, protocol conversion and termination point should be known, approved and monitored.
Transit Encryption
Every traffic flow should be encrypted by default using current, approved protocols such as TLS for application traffic, SSH for administration and IPsec or MACsec where network-layer protection is required. Encryption must provide both integrity as well as confidentiality, so traffic cannot be silently changed along it’s path. Certificates and trust stores need clear ownership, automated renewal and revocation to ensure that they are both trusted and operational. Where inspection requires TLS termination, decrypt only at approved control points, protect the plaintext segment, restrict access to it and re-encrypt immediately. In addition ensure that different segments do not share the same authentication credentials.
Transit Permissions
A protected connection should authenticate both the requester and, where appropriate, the service it is calling. Authorisation should be evaluated at the destination and not inferred merely because traffic arrived from a trusted network. Service identities, short-lived credentials, private endpoints, allow-listed routes and policy enforcement points reduce opportunities for interception or lateral movement. Logs should link the identity, source, destination, protocol and decision so that data movement is attributable.
In addition data paths should be controlled and managed. Segmenting traffic and restricting the path it can follow ensures security is maintained end to end. Paths should be blocked by default, with approved flows allowed to traverse the correct path.
Transit Resiliency
Secure transport must tolerate failures without falling back to insecure behaviour. Provide redundant paths, endpoints, certificate services and inspection controls where the business impact requires them, while keeping policy consistent across each path. Set sensible time-outs, retries and circuit breakers to avoid duplicate processing or cascading failure. Monitor certificate expiry, handshake errors, packet loss and route changes, and test failover to confirm that encryption, authentication and logging remain effective during an outage.
Assumption should be that if the fall back path is used for any length of time it is as also secure as the primary path. While some controls such as segmentation might be reduced, features such as encryption, authentication, and end to end controls should remain independant of the path taken.
Usage
Data in use is the moment when an application or person can actually read, change or act upon it. This is where storage and transport safeguards hand control to the workload, so identity, application design and operational discipline become critical. The objective is not simply to let an authorised user in, but to limit what each identity can see, what it can do and for how long.
Access Encryption
Most systems must decrypt data before processing it, so protection should minimise where plaintext exists and how long it remains available. Decrypt only inside the authorised workload, keep keys outside application code and logs, and avoid writing plaintext to caches, temporary files, crash dumps or telemetry. For the most sensitive workloads, consider field-level encryption, tokenisation, masking or isolated execution environments such as Nitro Enclaves,so the application can perform its task while exposing less of the original data to external services.
Access Permissions
Systems should ensure that least privilege at the level the data is consumed: application, API, database, table, row, column, record or function. There should be separated human and workload identities, each with strong authentication, short-lived sessions and explicit approval for privileged or emergency access. Duties should also be segregated so that no single identity can grant access, decrypt data and suppress the audit trail. Key to this enforcement is the reviewing of entitlements on a regular bases, and the use contextual controls such as device health, location, risk and purpose where the classification justifies them.
Access Resiliency
Access controls must remain dependable during both failure and attack. Identity providers, authorisation services, secrets stores and key services should be designed to meet the workload’s availability needs, with tested recovery procedures and tightly controlled emergency access. Decide deliberately whether a failed dependency should fail closed or permit a restricted mode. For example sensitive operations should normally stop rather than bypass security controls. In addition it is critical to preserve audit evidence, reconcile delayed events after recovery, and test that failover does not reintroduce stale accounts, excessive permissions or unprotected data.
As you can see data security is not as simple as one control in one location. Broadly speaking there are at least 9 areas to focus on. In addition there is no one answer for an organisation or solution. Within each solution or services the way these 9 areas the requirements will determin a different implementaiton of security.
comments powered by Disqus