A Multilevel Approach to Protecting Against Cybersecurity Breaches

When security breaches happen, the effect on your organization can range from minor to catastrophic, depending in part on the motivation of the attacker and the duration of time before the attack is detected in your system. The motivation for network penetrations has changed over the years. Where once it was just an intellectual challenge, the primary motive these days is to monetize the attack. The majority of attackers aren’t really interested in your business data; their interest is in how much you are willing to pay to get it back.

In this article we will focus on ransomware, which has become an epidemic, with cyberthieves estimated to have grossed over $1 billion in 2016.¹ Ransomware is a form of malware that has existed since at least 1989. Its current popularity is due to the convergence of a number of factors, including the emergence of smartphones, the creation of viable forms of electronic currency such as bitcoin, and the emergence of Ransomware as a Service (RaaS). Without the ease with which bitcoin has made monetary transactions nearly untraceable, combined with how easy RaaS has made ransomware to use, ransomware would still be a problem, but it would be much less significant than the epidemic it is today. Why is it called ransomware? That answer, at least, is easy. It’s called ransomware because once it infects your system, it literally encrypts all your data files and holds them for ransom. If you want your data back, you must pay a ransom to obtain the key to decrypt your data. Usually, if you pay the ransom, they’ll send you the key . . . but sometimes not. To increase the psychological pressure and to attempt to trigger a kneejerk reaction, the software usually will display a message that if you don’t pay the ransom within a specified time period, either the amount of ransom demanded will increase or they’ll start deleting files at random.

How would you like to deal with that scenario? The answer is that you wouldn’t. The time to make these decisions is before you are infected. Since there is always a chance that your data will be locked away from you, you must sit down and carefully evaluate how much the data is worth to you. Or in another way of putting it, how much are you willing to spend to get it back before you just write it off as a loss? That way, you can make if not a calm decision at least a calculated one while you are not under that type of pressure.

Don’t misunderstand—I’m not counseling you to make a payoff to support a criminal enterprise; only you can decide whether the data is valuable enough to you to pay the ransom demanded. In any case, paying should be a last resort, as there are few ways for you to be certain that the data has not been altered, either deliberately or inadvertently, by the cybercriminals.

While information technology (IT) personnel are usually considered the ones responsible for your system’s security, the reality is that everyone has a role to play. Many white papers and other documents are available on the web regarding how to avoid or recover from a ransomware attack. Most start with the rather obvious statement that preventing a ransomware infection is much better than trying to recover from one and that defending against infection requires a multilevel approach, but there does seem to be a common thread running through many of the resources. Unfortunately, some of their recommendations, generally resembling those in the accompanying sidebar, run counter to good informatics practices.

Your part in item 1 is working with IT to ensure that this is both actually being done and that they frequently test that they can restore data from these backups. Usually not mentioned is how long you should store these backups. That is negotiable, but keep in mind that if the attack has been going on for some time, an encrypted backup file doesn’t do you any good.

If you work in a regulated environment, item 5 might be a problem, as any changes to the application or operating system typically require the system to be revalidated. A casual conversation including someone from IT and the regulating agency might help clarify your actual needs, as I’ve found that different agencies tend to interpret the implementation of their regulations differently.

Item 6 should always be done, and I’ve never understood why it is allowed to default to off. Leaving it off makes files like “ransomware.pdf.exe” look like a much less threatening “ransomware.pdf.”

While I’m sure you noticed that a number of these recommendations appear to be a function of the IT group, it might not be as obvious that this means you need to develop a good working relationship with them, establish good communication lines, and use them! If you don’t keep a continuous conversation going with IT, you may discover that they’ve inadvertently developed IT policies that make it very difficult for you and your people to perform your jobs effectively. This tends to encourage people to bypass proper procedures, potentially increasing the risk of infection.

While the general policy issued may not change significantly, IT can at least take your needs into account during implementation in order to minimize the policy’s impact. As a practical example, since email attachments are one of the major vectors for ransomware infection, some IT groups configure their email systems to automatically strip off any attachments. If your operations require the frequent exchange of attachments, these systems can be configured so that these attachments are quarantined but can easily be made accessible.

Similarly, as another major source of infection is a “drive by” infection from visiting an infected website while using a browser that has not been patched against the exploits that the ransomware takes advantage of, some IT groups routinely block access to sites that are not on their approved “white list.” Depending on the type of operation that you are managing, this can be very frustrating, as it is very unlikely that they would include websites for computer viruses on their default white list, even though your support or research activities require access to those types of sites. A good working relationship with the IT group will usually result in having new sites added to this list more quickly.

While the IT group should have a response manual in place covering how to deal with all the intrusion scenarios they can imagine,² it is prudent for you to develop a response manual for your specific group as well. This can serve as both a response and a training manual for your group, with a focus on the things you can do. In the middle of an intrusion is not the time to figure out what to do. Your plan should be developed with input from the IT group regarding the immediate response that they would prefer your group take. For example, would they prefer your group disconnect the infected computer from the network and shut it off, or would they prefer you put it into hibernate mode? The latter can make subsequent forensic analysis of the attack much easier. However, if this is their preferred option, your manual should describe in detail how to do this, as most users won’t even know what the term means.

A critical part of this manual is educating your people on the best practices that they can follow to minimize the risk of infecting their system.³ Most attacks rely on social engineering. Basically, this comes down to carefully wording documents or other communications in such a way as to put users at ease and make them feel that bypassing the written procedure is the appropriate thing to do, in this instance generally opening a specific attachment or enabling the execution of Microsoft Office macros. Some of these messages are so well crafted that they will occasionally even suck in a seasoned IT professional. While the result of this can be that users become the major vector of infections, when properly trained, users can also be the organization’s first line of defense, as they are likely to be the first to detect an infection. So, in addition to training your people on how to identify a potential infection (which generally means that they receive an error message when attempting to open files that they normally should be able to), the response manual should also include how to react to the infection to minimize the damage done and whom to contact in IT who is trained to respond to such an attack. While it is important to identify how the infection penetrated the system and the particular type and version of the ransomware used as quickly as possible so that it can be contained, this should not be used as an excuse for a witch hunt. Recent surveys indicate that 45 percent of IT professionals disregard their own written security policies on occasion.

Since social engineering is such a critical part of the infection process, user training to recognize these attempts should be in-depth and serious, not just a casual annual presentation over lunch in the cafeteria. The training also needs to be repeated on a frequent basis, both because people tend to easily fall back into bad habits and because the nature and methods of attack are constantly changing. I’ve found that it is also useful to explain specifically why a given rule exists and what its purpose is, as opposed to just saying “Do it this way.” If people understand why they should do things a certain way and what it accomplishes, they are much more likely to do it on a continuing basis!

References

1. Cisco, Inside Ransomware, 2016. https://hosteddocs.ittoolbox.com/cisco_inside_ransomware_120916.pdf (accessed February 1, 2017)

2. Absolute Software, IT Confidential, The State of Security Confidence, 2016. http://resources.idgenterprise.com/original/AST-0174907_it-confidential-us.pdf  (accessed January 13, 2017)

3. IBM INCIDENT RESPONSE SERVICES, Ransomware Response Guide, 2016. https://hosteddocs.ittoolbox.com/ransomware_response.pdf  (accessed January 7, 2017)