It has simply been one hell of a year. We've seen shocking vulnerabilities in technologies that are supposed to be the bedrock of our digital lives: the "Heartbleed" SSL vulnerability and the "Shellshock" bash bugs shook our confidence in any software's ability to keep its promises about security. We've seen a continuing and unabated string of high profile credit card breaches. There's a long list of companies falling like dominoes to online bad guys and yet this list includes companies you'd rightly expect to have the right combination of security people, process and technology to keep their names out of the papers. What the hell is going on?
"Our adversaries are out for the whole ball of wax: stealing the ball, setting fire to the wax factory and giving away forty billion free candles."
I've been in this business long enough to approach headline after headline with a degree of cynicism. There's more than enough hysteria to go around about the shifting threat landscape, and with each ever-more-breathless headline I've been shrugging it off with a few tried-and-true themes: "if they want you bad enough they are going to get you." "Retailers haven't been substantially harmed by decades of credit card breaches; they buy identity protection for those affected and they move on." "This is a very hard problem and there's no solving it with technology alone." "You don't have to run faster than the bear, just faster than your buddy." And so on.
Many -- and I do mean MANY -- companies are playing chess every day and don’t even realize it. They’re not playing a fun game where win-or-lose, nothing happens. They are playing a game where the stakes are high and the cost to win may not be quantifiable. You are probably thinking, “What is she talking about…?” Well, I’m talking about cybersecurity.
When your opponent gets in your network, they take over. They watch your every move and every time you see a glimpse of their moves, they change their plans and adjust their tactics. Just like a chess match, they are watching you and adjusting their strategy based on your reactions to their moves.
Here’s where things start to change: they are not necessarily looking for checkmate; in fact oftentimes, they are actively avoiding it. They want to ensure the game continues, so they can keep moving around silently and evade detection so valuable information like intellectual property and customer information can continue to be absconded.
I just got done reading the DTCC’s White Paper entitled Cyber Risk – A Global Systemic Threat (PDF). The white paper outlines seven recommendations for policymakers that they state will further an “aggressive agenda to combat cyber threats.” Four of the seven recommendations refer to information sharing between and among governments and businesses.
Information sharing is a fabulous idea, but is easier said than done. Everyone in my field of cybersecurity agrees that information sharing is a good thing. If you show me your signatures, then I’ll show you mine. If my NG firewall finds a new 0-day CryptoWall variant, then it would be helpful to share this with other companies so they don’t get hit by the same variant. Obviously, reciprocation of sharing is expected, or in actuality, hoped for with the myriad of SLAs and annual maintenance contracts organizations have with cloud-enabled security tools.
The list of vulnerabilities that are collectively known as Shellshock keeps growing. There are many parallels to Heartbleed that have been widely noted, including the memorable names that distinguish them from the classic CVE. And while we try to assess which has the bigger impact, there are a few key distinctions that are worth noting:
Announcement/Patch cycle: While some members of the security community were notified under embargo, the general announcement for Heartbleed was concurrent with the availability of the OpenSSL patch. This meant that the announcement started a frenzied patch cycle but for the most part, remedial activity was fairly focused. Shellshock, on the other hand, broke open without an upstream patch having been made available and even when the patch was released, it was clear early on that it was insufficient so the pervasive vulnerability persisted. This has been compounded by the series of other vulnerabilities that have been discovered in the days since.
Stealth: Remember that the exploits with Heartbleed, ranging from login credential theft to getting a server to cough up it’s private keys from memory, was achievable more or less silently, with no activity that would be noted or logged by the typical system. Shellshock is a classic remote exploit vulnerability. Whether it involves getting co-opted into a bot or a more sneaky backdoor, some amount of coverage for the secondary activity is achieved through robust security practices. For this reason alone, Heartbleed remains the scarier vulnerability in my books.
Surface Area: Heartbleed was a direct, frontal assault on OpenSSL. Shellshock affects a range of services with very little in common, other than the use of Bash. This will no doubt lead to an extended remediation cycle for Shellshock.
Ease of Use: The number of exploitation techniques for Shellshock has proliferated over the last few days and the first bot proof-of-concept code was published within hours of the vulnerability having been announced. Widespread familiarity with the utilities involved (Apache, Bash etc) has meant that there’s a lot of experimentation going on. Heartbleed exploits certainly evolved too but the deviation from the original POCs was limited.
This isn’t meant to be a comprehensive list but some differences in impact that are emerging even as we understand the full ramifications.
It’s 4 AM and the alarm reminds me that I’ve been awake for an hour or more after grabbing a couple hours of shuteye sometime after midnight. The realization of a 45-minute drive, with a stop off at the office to pick up equipment, breaks my intense contemplation of what it was like to have regular hours. I meet my fellow investigator at the office and we head to the train station. Some eight hours prior, we learned that a company had been hit with a very nasty malware attack sometime in the previous few days. The story was familiar and both I and my compadre could relate the basic details without even hearing them.
A number of employees received a phishing email designed to look like benign financial communications. The emails contained attachments purporting to be financial documents and were designed to look like they arrived from an innocuous sender. The emails were sophisticated and convincing enough to pass a quick skeptical glance and several employees opened the attachments. As it turned out, executed was probably a better description of what was done with the attachments. One of the employees was using a workstation vulnerable to the malware attachments and the malware did its job which resulted in a large number of important documents being rendered inaccessible. Therefore, the client decided to bring in outside consultation which brought me to rolling out of the rack at 0400.
At 6:30 AM, the sun is finally up as the train rolls out of the station. My partner and I luck out and get a decent workspace at the front of a car. We decide to make the most of the ride by going over what we know about the incident. Luckily, my MiFi works relatively well on the train. The client’s description of the incident provides plenty of fodder for research. As we discuss the details, I have to keep the investigator in me at bay. My instinct is to drop into the client site and deep dive into technical details in an attempt to fully understand the malicious activity and associated malware. Instead, the more practical approach is to determine what questions to ask and prepare to listen to what the client describes, and perhaps more importantly, listen for the outcome the client desires. This preparation time is crucial as it is nigh on impossible for my team to anticipate every type of incident and have a checklist or process guide to follow in every case. This particular incident involved crimeware.
I have a friend who is an executive in a small to medium sized company that operates in the technology sector and has a great deal of intellectual property invested in their software. They are very good at what they do and have an international presence. We have spoken at length about their IT security posture and what precautions they have taken to safeguard their network and software. This company is now in the process of being acquired. While most of the work through this acquisition is likely to focus on employee retention and payouts, this is a perilous time for both companies. As soon as they issue the inevitable press release, threat actors will start probing their networks -if they are not already there- looking for vulnerabilities to get in.
We have seen time and again during mergers and acquisitions, little to no thought is given to network security. Things like connectivity, email servers, file shares, etc. are all given priority over installing the proper safeguards. Given the great number of unknowns when bringing two companies together, it is imperative to slow down and ask some basic questions:
Have both networks gone through a breach assessment?
Do both companies have documentation showing assets, approved software programs, network diagrams, change management processes and other policies?
Is there a detailed and organized plan to bring the different networks online together?
Have the CISO and the CRO/CRMO talked about the specific cyber risks involved?
This is not a simple, get our IT guys together and figure it out exercise. There are likely two different sets of policies and organizational cultures coming together. It will take time to sort out these differences and unify the organizations. This is the perfect time for both IT teams to identify security gaps in their networks.