Application Architecture and Ransomware
Application Architecture and Ransomware
Ransomware has existed for nearly 40 years now. What can be done to help prevent these attacks before they happen?
Join the DZone community and get the full member experience.Join For Free
Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required
Protecting Data from Cryptolocker and Variants
Ransomware and Cryptolocker
Ransomware is an increasing threat to many organizations—I recently had a conversation with a (non-IT) friend whose employer had been affected, which is why I’m writing this. These are attacks where a system or data is made inaccessible until a ransom is paid. This form of extortion actually dates back to the 1980s but recent variants, such as Crytolocker, are very dangerous and destructive on modern networks.
Often the initial infection is via a phishing email that contains a link to a website, that if clicked, will download the malware. This will scan all files that the user has access to and starts encrypting them. Once the files are encrypted, the user will be sent a message telling them of the infection and offering to decrypt in return for payment (usually in bitcoins). Of course, the user has no guarantee that their files will be decrypted even if the ransom is paid.
Applications and Processes
If an individual's machine is infected then they might lose all their personal documents. If they are using remote drives and shares, which have multiple users, then the infection may also lock other people's files. If a user has access to a large number of files across an organization then this could be devastating.
These are all files that a person has access to. This includes any files used by applications along with documents, etc. Therefore if a developer or operational user becomes infected then the systems files they have access to can be affected. It’s very common for technical employees to have access to the files of production servers in order to make issue resolution easy. For example: log files, configuration files, data exports/imports, etc.
If the technical users have write access to a mapped drive on a production server then it is trivial for the malware to encrypt these files. This may take down the service (if runtime files are affected) or even destroy the data making the service impossible to run even after a reinstall. Remember that your databases will ultimately have their data stored in files on a disk somewhere.
If people with elevated privileges are infected, you can lose entire systems as well as that person's individual files.
I won't give advice here on Endpoint Protection (antiviruses etc.) as that is out-of-scope for this blog but there are many data-related actions you should consider with respect to your applications.
Many of you will be reading this and thinking well, we don't allow access as you've described here but technical staff will set up systems to make their jobs easier. Has your organization ever performed a data audit and classification? Do you know what files, shares, and sections of your network each user has access to? If you haven't, then I'd strongly advise you do so—you may be surprised at what you find. There are many commercial and free tools to assist you in doing this.
Restrict User Access
You should define your users, what groups they are in, and what data they have access to. This is good practice anyway (for reasons of privacy, data loss prevention, etc.) but if you reduce the total number of files accessible then any infection will have less effect.
If someone really needs access to files, do they require write access? Log files and configuration files are a perfect example. A user shouldn't be writing to a log file and if they want to change some configuration then they should go through your normal release process rather than hacking it in manually. If you can't release configuration quickly enough, then your release process may be your real issue...
Don't Share Users Between People and Applications
A person shouldn't be using an account used by an application and the applications shouldn't be using personal accounts. Again you may claim this isn't happening but technical users often take shortcuts like this to release quickly (or get around approval processes). A good audit should pick up on this.
Don't Use the Same User for All Applications (or Use Root!)
It's tempting (for ease of management) to create a single account and get all applications to run as this account. If this account is compromised then all data for all applications are vulnerable. Use specific accounts for applications to reduce lateral movement between systems.
Don't Give Administration Permissions to Interactive Accounts
If a login account is used to run a web browser or email then it should have restricted permissions. Likewise, any administrative account should not be able to run a web browser or email. Separate the concerns!
Analyze Your Backup Policy
How do you backup your data? If you are using online backups, that are accessible to an infected user, then all your backups may get corrupted too! Maybe you should consider using WORM (write once read many) technology or at least use separate processes to move and permission backups appropriately once they have been taken.Some malware may be stealthy and stay on your system for a long time before making itself known. Therefore incremental backups can be corrupted far back in time. Make sure you regularly test your restoration processes too.
It's important to remember that your data is the most important part of your application and valuable to your organization. If something has value then nefarious parties can seek to take advantage of this. It's hard to stop some attacks but you can minimize the damage if you are attacked.
The architecture of a system should take into account where data is stored, how it is permissioned, and who/what has access to it. It's very easy to become obsessed with the latest design patterns but basic data management is important and shouldn't be forgotten.
Published at DZone with permission of Robert Annett , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.