Unless you’ve shunned modern society or are under the age of five, there is a good chance you’ve heard of a very public organization or company being hacked or breached. Home Depot, Target, Blue Cross, Marriot and the DNC are just a few examples of some big names going through the unfortunate process of having to clean up a technological mess.
Sometimes the breaches are huge, spilling out millions of people’s sensitive data and sometimes they’re small and easy to fix. Whatever the size and impact of the breach, businesses still must attend to them.
How should businesses who suspect a possible breach respond or act in this situation? Let’s find out!
The Cybersecurity Way to Handle This
In my world, there are very specific protocols that need to be followed to confirm a breach or hack and how it’s handled. We’re going to touch on a few major points that cybersecurity professionals face when dealing with a situation like some of the companies above faced. However, let’s make a few things clear first!
To begin, the term “breach” is something a cybersecurity professional would never use when first investigating a situation. A “breach” has a very specific meaning that comes with legal obligations attached to it, such as disclosures to governing bodies, customers and even the public, depending on the compliance law in play.
Before a breach is confirmed it’s actually an “incident.” Incidents don’t need to be disclosed since they’re in the discovery phase and, once concluded, will be classified as a breach or not.
With this in mind, let’s look at two possible scenarios for our fictitious and very well-known megacorporation, let’s call them Zorg Industries (Zorg for short), and how a breach can be properly handled if they were, in fact, hacked.
Scenario 1: Zorg Suspects a Breach
Assuming we get an immediate call from Zorg saying they’ve been breached, we would immediately counsel them to stop saying “breach” and start saying “incident” (see above). Once everyone is clear on the correct legal terminology, we begin the process of understanding what all of the available evidence is that points to an incident.
We interview employees and the dedicated IT staff (if there is any), then begin to compile evidence via server and infrastructure logs as well as install our equipment to monitor the situation and analyze any live traffic that may also be a factor. If the evidence immediately points to a breach-level event, then we may advise Zorg to immediately cut off internet connections to stop any kind of data transfer.
With all of this in place and the internet cut off, we have now determined that a hacker, or hackers if Zorg is large enough to warrant a team effort, has indeed penetrated the network and is slowly uploading files to a rogue server somewhere.
Hackers almost never heavily use bandwidth when they’re discreetly transferring files offsite as an impact in internet performance may alert employees or IT that something is going on with the network.
With the internet disconnected, we will assess three major points (though there are also minor points as well):
- What exactly was stolen?
- How did the hackers get in?
- Did the hackers leave behind malware or utilities that could harm us in the future?
These points may sound easy, but they can become very complex very quickly and often, even with cybersecurity utilities and hardware, this can be akin to searching for a virtual needle in a technical haystack. During this phase, we are also looking to remove malware and also close the gaps in the defense or even build a new cybersecurity infrastructure from scratch if it’s determined the current infrastructure in place is wholly inadequate.
With these questions answered, we can then make the determination if a disclosure is needed. Maybe the only data stolen was a staffer’s dry cleaning list or something that has no relevance to anyone in the public eye. Maybe the hackers stole every client’s credit card information and the compliance standard of PCI DSS was violated.
Many breaches do not need disclosure and to determine what is correct in the situation usually involves legal counsel. In the case where damaging information is made public by the hacker, and it has been confirmed as valid, then the ethical course of action is to publicly disclose that a breach has occurred.
It’s reputation-damaging, yes, but it’s more so if Zorg was found to have known about the breach and did nothing to warn its customers about their own potential personal liabilities. No one that deals with Zorg would want their credit card information leaked to the general population let alone personal addresses and email.
Scenario 2: Zorg has been Unknowingly Breached and Data is Made Public
From a cybersecurity standpoint, the horse is out of the barn. Once information is public, there is no getting it back.
People who believe we can delete all records from a breach off of the Internet or simply shut off portions of the Internet to quell its spreading really don’t understand just how fast data replicates worldwide. Or how we can’t really shutdown large swaths of the Internet easily, as much as some governments may try.
There are few things we can and will do after the fact. First and foremost is damage control. I’m not talking about spinning the breach to the press. Rather, I’m talking about taking the Zorg infrastructure offline because while Zorg’s stolen data may be a large amount of data to be leaked, odds are the organization has way more that could still be uploading to a rogue server for a future major release by the hacker, or possibly ransomed for money.
Second, we do what we did in the first scenario, though, it’s much more retroactive. We determine if more data was stolen, assuming the first released batch is actually from Zorg to begin with, look for malware and malicious utilities on the network and then build a new cybersecurity policy (possibly with new equipment). Once we know the infrastructure is clean and secure we allow it back online and into normal operation.
What both scenarios really underscore is the need for an IT team that is focused heavily on cybersecurity, especially if the organization is incredibly public. When breaches like this happen in real life, all too often it’s the IT personnel that became lax and left something open in the configuration that allowed the hackers easy access.
Unfortunately, it is also this IT staff that the leaders of a company like Zorg turn to when an incident is first discovered or reported. Having a third party that focuses on cybersecurity and is also neutral to situations (“I don’t care how it happened, I just want to find the issue and kill it”) goes a very long way to more effectively finding and stopping a breach.
This is also why we constantly reinforce the message of vigilance to any IT staff we train or consult with. Changes need to be recorded and security updated to reflect an unpredictable IT landscape. Leaving older configurations in place unchecked is a recipe for disaster.
Hack or Not, Stay Informed by Getting the Full Picture
Ultimately, it’s up to the organization to keep themselves up to date. It becomes increasingly more important as we, the public, are inundated with information by media outlets vying for our time and attention to look at a Zorg-type breach as a marketable opportunity.
A situation like an incident or breach, something I am very familiar with, tends to be a very fluid situation but becomes more and more damaging to the reputation of an organization like Zorg as time goes on. Because the media loves to make these kinds of stories public, Zorg Industries has to formulate the proper response to quell possible panic and also deliver correct, but guarded, information to the public via the media outlets seeking out more information to publish.
New information is discovered constantly as we scramble to assess the damage and determine the security vulnerabilities. Proving data theft can be time-consuming and thus can add to the confusion the public may have as media outlets rush to publish information.
LOCK DOWN YOUR NETWORK
FREE PENETRATION TESTING COURSE
- Social engineering
- Port scanning
- SQL injecting
- Anti-virus evading
- Client side attacking