We talked about the vulnerability of presidential campaigns in March. We talked about the reality of election threats in September. And now, after almost a full year of discussion, we’re dealing with the aftermath—the FBI and CIA agree that Russia hacked pieces of our election to put Donald Trump in office!
So, what happened? Did a massive state-sponsored attack manipulate our voting machines? Did Russian super spies use their hacking skills to derail the Clinton campaign?
No. Our election was impacted by a basic phishing attack—an age-old issue that now has global consequences.
The DNC email hack was (and continues to be) an important part of the 2016 election narrative. But that’s not what we’re talking about right now.
The most recent discoveries of Russia’s election hacking are related to a March 19, 2016 hack of John Podesta, Hillary Clinton’s campaign chair.
Podesta received a suspicious email claiming that he had to click a link to reset his Gmail password immediately. He did the right thing and contacted his IT team after noticing that something wasn’t quite right.
But the IT team told Podesta that the email was legitimate! IT leaders instructed Podesta to reset his password immediately and enable two-factor authentication (which wasn’t configured at the time). They provided a safe link to reset the password, but something got lost in translation and Podesta clicked the malicious link in the email.
This phishing attack gave Russian hackers a presence in the Clinton campaign’s email servers. They evaded detection from March through October when Podesta’s emails started popping up on WikiLeaks.
Reports note that Podesta’s emails were irrelevant to the Clinton campaign, but the media coverage of email hacking became a major point in the election race nonetheless.
News outlets will continue to debate the impact these hacks had on the election, but let’s look beyond politics. What do the Russian election hacks say about the state of cybersecurity?
How many times do we have to read that human error is the leading cause of data breaches before we do something about it?
Yet again, this year’s Verizon Data Breach Investigation Report found that human error (resulting in successful phishing attacks, unpatched/vulnerable systems and more) is the primary way that attackers take advantage of our networks.
In the Podesta scenario, human error was on full display. But not just on the employee’s (Podesta’s) part—on the part of the IT team! Not only that, but attackers persisted in the email servers for over 6 months and the only reason they were detected seems to be that emails were released to the public. This just can’t happen under today’s cybersecurity pressures.
We say it again and again, but greater network visibility is critical to overcome these age-old human error and detection problems. There will always be human error—people aren’t perfect. But these attackers are too smart for us to think they won’t find the dark corners of our networks.
Design a connectivity strategy that ensures all the data is passed to your monitoring and security tools. After all, your tools are only as good as the data they receive. If you’re still relying on SPAN ports for network monitoring and visibility, you are dropping packets and your tools are not providing you the visibility required to trigger alerts based on aberrant behaviors.
How do you know what is aberrant behavior?
As we’ve seen, network breaches have implications beyond remediation costs. For each industry or sector – the outcome varies – maybe it’s to change public perception, maybe it’s to hold a patient information hostage, or maybe it’s for a quick few bitcoins.
Knowing your baseline traffic is not a one and done exercise. This is an ongoing process, that each year needs a refresh.
Start now with downloading our free white paper, How to See Your Baseline Traffic.
If the inline security tool goes off-line, the TAP will bypass the tool and automatically keep the link flowing. The Bypass TAP does this by sending heartbeat packets to the inline security tool. As long as the inline security tool is on-line, the heartbeat packets will be returned to the TAP, and the link traffic will continue to flow through the inline security tool.
If the heartbeat packets are not returned to the TAP (indicating that the inline security tool has gone off-line), the TAP will automatically 'bypass' the inline security tool and keep the link traffic flowing. The TAP also removes the heartbeat packets before sending the network traffic back onto the critical link.
While the TAP is in bypass mode, it continues to send heartbeat packets out to the inline security tool so that once the tool is back on-line, it will begin returning the heartbeat packets back to the TAP indicating that the tool is ready to go back to work. The TAP will then direct the network traffic back through the inline security tool along with the heartbeat packets placing the tool back inline.
Some of you may have noticed a flaw in the logic behind this solution! You say, “What if the TAP should fail because it is also in-line? Then the link will also fail!” The TAP would now be considered a point of failure. That is a good catch – but in our blog on Bypass vs. Failsafe, I explained that if a TAP were to fail or lose power, it must provide failsafe protection to the link it is attached to. So our network TAP will go into Failsafe mode keeping the link flowing.
Single point of failure: a risk to an IT network if one part of the system brings down a larger part of the entire system.
Heartbeat packet: a soft detection technology that monitors the health of inline appliances. Read the heartbeat packet blog here.
Critical link: the connection between two or more network devices or appliances that if the connection fails then the network is disrupted.