The problems involved securing a file
|Security: a human as well as a technical problem|
This note is a rumination on security that just shows that absolute security is unattainable. Some of the complexities of achieving a high level of security are presented. This level of security is only needed for highly sensitive documents and part of the ask of a secure systems architect must be to establish the level of security needed and determine whether the necessary hindrance of work is justified.
It is not suggested that this is a definitive list of the issues involved in securing a single file, let alone a system, more a consciousness raising effort.
Please consider supporting this blog financially. The money will be used to fund research and the cost of maintenance. You can use paypal via the button below
A file can be considered secure if
- CRUD (Create, Read, Update, Delete) access is available only to authorised users (Humans or processes)
- Only authorised users may modify a user's CRUD access
- As a corollary attackers may not deny authorised users access.
- Authorised users cannot compromise file security
The last condition is probably impossible to fulfil: anyone with a key to a safe can get at the contents of the safe.
I will have two scenarios in mind.
- The file is on a device (laptop, phone etc) to which a user has direct access.
- The file is on a server and accessible via a web service or web application.
Here the file is open to anyone who can access the device or the web application. Generally this means they need a password and username. This can be made more difficult by requiring a token or using biometrics ( and the pain of trying to register say fingerprints makes this option unattractive).
But if an attacker has physical access to the device all bets are off.
Password cracking is hard especially if there is a lockout after too many attempts. Shoulder snooping a legitimate user or using malware to install a key logger is possible but as much a matter of luck as skill. Of course the defenders may have installed a key logger to monitor access and malware may be able to get hold of those records.
But removing the hard disc, making a bit level copy and scraping all files off the copy is much easier. It also has the added bonus of getting all the files of the disc, with any valuable information they might contain.
Alternatively an attacker, having identified the location of the file could change the content on the original disc or make the fill unusable.
So why not hide the file itself on a secure server and only allow remote access? As long as no local copies can be made (for example in a browser cache) the content is secure, right? The user still needs an ID and password but extra security like a VPN tunnel and/or using the latest secure transport protocol plus two factor authentication should be enough?
The problem here is that you have to be sure the application is secure. Web Applications are not easy to secure properly, and just one flaw in the security protocol could let an attacker get hold of the data, for example via a directory traversal attack. At the worst text could be scraped from a browser screen.
To prevent man in the middle attacks you also need to ensure the file is encrypted in transit using TLS (Transport layer security) or ssh for internal access and ensure the user needs to submit a password before getting access. And make sure no plain text copies are left lying around.
The bottom line is that perimeter security, like a cylinder lock, deters only honest people. The measures here make it harder to breach security but the more valuable the data the harder attackers will try to get to it. The goal of security is to make the cost of getting the data more than the value of the data to the attacker.
Encrypting the file is an obvious next step. Legitimate users will be able to view the contents and the device can be shared with others not authorised to see the content. This is like having a locked cabinet marked “Top Secret” in the middle of an office. It tells attackers where to look for the gold.
Problems with encryption include back doors and insecure implementations not to mention ensuring the password is not inadvertently compromised (The more secure the password the more likely it is to be written down. Few people can remember passwords like sASks1029”))”!, and the problem gets worse the more such passwords people need to remember. Secure password wallets simply concentrate all passwords in a single weak spot.
For really sensitive material two users could be needed to unlock the file, each having half the password. But then backup users need to be available in case one person is ill or on vacation. And the more people know the parts of the password the more likely a breach will occur
Encryption is a useful aid to security then, but not a silver bullet. You need to be sure the algorithm is correct and securely implemented (no local copies in plain text in obscure directories) and that the users can remember the password.
Granting or denying users access is a different kettle of fish. In a role based access system this can be delegated to users in a special administrator role and access, and the right to control access can be granted or removed by an administrator. As before there should be at least two administrators and ideally changes in access control would need second administrator approval. The question of who can create the special administrators raises the spectre of an infinite regress. This is a problem that has to be solved organisationally, though technology may help.
This has just scratched the surface of the problems involved in the apparently simple task of securing a file. It turns out that perimeter security deters only the honest, physical access lets attackers do whatever they want and encryption has its own minefield of problems. Finally the problems of granting and denying access need to be solved organisationally rather then technically. For really sensitive content a “four eyes” principle whereby two users must collaborate to access the content will minimise the risk of rogue users giving the content to unauthorised recipients.
The bottom line here is that total security is impossible and the amount of effort devoted to securing a document should be proportional to the value of the content and the cost of losing it or having it leaked to the wrong people. One should always have the hierarchy of secrecy in mind: Restricted, Confidential, Secret, Top Secret, List Access Only and Embarrassing and assigning content to one of these before deciding the effort needed to keep it secret.