The US Federal Aviation Administration (FAA) was recently in “stormy weather” because of a major computer system failure. As per BBC News: “US air safety officials say that the glitch that led to travel chaos at airports last week was actually caused by a contractor deleting files on a crucial computer server used by pilots.”
Late last year, LastPass, the password management service, was hacked by an unknown threat actor. They gained access to a third-party cloud-based storage service, which LastPass uses to store archived backups of their production data. The threat actor managed to gain access by targeting a LastPass employee and obtaining their credentials and decryption keys.
These stories bring another slant on the safety of our business critical data and adds additional risk on top of ransomware attacks and other data breaches.
Part of the problem is that the data layer of our organizations tends to be much larger and more complex than it needs to be. Every application we use introduces more fragmentation to our business functionality and creates data silos. Every data silo brings its own vulnerabilities and the older the application or silo the more exposed it tends to be.
We can simplify the data layer and reduce fragmentation of our business data if we virtualize the UX and CRUD functionality and migrate as much data as possible into a Data Agnostic Storage Service (DASS).
The DASS encompasses all types of record data, logs, files, etc. It sits on its own servers and access can be restricted to a very few trusted users with MFA and JIT authentication from at least one other trusted user. The DASS can be hardened to the strictest level and automated so the trusted users have few reasons to access the DASS internals.
When a user interacting with a client wants to access data in the DASS, they do so through a small set of entry points (in our case via APIs.) The user authenticates from the client and passes an AccountID to the DASS. NOTE: the user’s credentials are assumed to be compromised and are not passed, or used by the DASS. Based on the AccountID, the user is assigned a UserID/SessionID by the DASS. The user’s access can be immediately terminated by the DASS if the SessionID is revoked.
All access to DASS data is then mediated by the UserID/SessionID pair which is revalidated on every API call. Users must be granted access to each row of data, or file, in order to read it – only data that the user is authorized see by the DASS is ever returned to the client. User’s must have permission to delete any object – and then only if the state of the object and the role or the user allows it. Every update, to every record, is version controlled, and audited. We can also add logging and intelligence to the API to detect abnormal usage and terminate the UserID/SessionID.
As well as securing your business critical data, separating the DASS from the clients using an API also means that the DASS becomes technology independent. We can upgrade the DASS technology as new threats, or capabilities, emerge without having to re-implement our clients, or business functionality.