Security: Why attacks happen and how you can prevent them
- select the contributor at the end of the page -
History has plenty to teach us but above all, it reminds us that the past is repeatable and inevitable if we choose not to learn from our mistakes. Falling behind in security (meaning the risk assessment, evaluation, control updates and configuration management) can start a downward spiral that leaves a company open to attack and loss of confidential data.
First, a real world example
I'm reminded about an old attack, one that I dealt with that still haunts me and encourages me to keep my security practices in shape. You might have such an event as well, but let me share mine and how the event changed the security practices that many companies followed.
Back in July 2001, a UK-based customer was experiencing website defacing on their commerce sites. This was the start of the Code Red worm. While it was released a few days before, our security team hadn't caught the news about this worm and its impact to websites hosted on Microsoft IIS. With a team of engineers, I began the process of diagnosing and cleaning the worm off systems. It should be noted that Code Red affected all systems that had IIS installed, so a clear asset inventory was needed to ensure complete removal. We quickly discovered that many of our customers had not maintained their asset inventory, making a complete removal impossible until we performed another inventory to find all systems running Microsoft IIS (which was most of them).
"Code Red II" quickly followed up Code Red and on September 18, 2001, one of the most devastating worms—Nimda—was released using the exploit that Code Red opened. While Nimda had multiple attack vectors, it's entrance through Microsoft IIS-exposed systems (the ones that had been affected by Code Red) happened quickly, affecting operating systems Windows 95, 98, NT, and 2000. If the Code Red worm hadn't been completely cleaned from a network, you got infected with something far worse.
The most embarrassing part of this story is that the patch to prevent Code Red was released by Microsoft in June of 2001. In other words, if companies had updated their operating systems, they would not have been infected. Back in those days, IT teams were very slow to update anything.
Making the most of mistakes
Helping customers to get control of their environments after Code Red/Nimda was a great challenge, but there was an upside. Due to the financial loss many of those companies experienced, they actively created new security policies and procedures that prevented future attacks.
Take a moment to examine some of the lessons we learned during the event:
- Not informed in a timely manner of new attacks and exploitable vulnerabilities
- Outdated asset inventory delayed discovery and cleaning
- Delayed cleanup allowed additional attacks to occur, increasing downtime and financial loss
- Lack of updates that could have prevented the attack
Why security fails
Today, any certified security practitioner can outline the procedures and policies to harden a business and increase its security posture, but why are there still devastating failures? For one, falling behind in any one area leads to a breakdown in security.
In my cautionary tale, many of those companies that improved security posture found themselves once again experiencing major outages and losses a few years down the road. New security and administrative personnel combined with vastly growing networks began to lose control.
These companies also failed to:
- Maintain asset management
- Ensure updates in a timely fashion
- Perform risk assessment and management.
All those things that helped prevent attacks began to gradually slip behind, opening giant doors for future attacks. If your company has fallen behind, now is the time to get back in control.
Preventing future attacks
Even the best security teams get hacked in one way or another. It's not that you will prevent all worms, viruses and attacks, but rather that you detect, correct, and prevent future attacks. As an example, Juniper recently found a hack written into its source code, discovered during a code review. They quickly patched and repaired the problem. Other manufactures quickly began performing their own code reviews. Juno's quick response is an example of detecting and correcting an exploit, then evaluating how to better improve and prevent it in the future.
Sometimes the security exploit is self-induced. In other words, a mistake that the business intentionally makes, that creates an exploit. Dell, in an attempt to make it easier to get service tags of customer computers, installed a self-signed certificate (eDellRoot) on its laptops in the later part of 2015. The certificate private key was compromised, meaning a man-in-the-middle style of attack was not only possible, but had probably occurred. Dell did not discover the mistake; an outside programmer discovered and reported the problem. While Dell should be applauded for quickly releasing instructions on how to remove the certificate, it was publicly lambasted for not initially detecting and correcting the problem.
Evaluating your security
Has your company fallen behind in its security? Can you detect and correct new exploits and vulnerabilities? I ask myself these questions all the time so that I can evaluate my company's security posture. Here are some of the things I focus on that might also help you in your own evaluation:
- Are my security skills and knowledge up to date?
- Is my asset management up to date?
- Is my company following a good risk management process, including security assessments and configuration/change management?
- See item No. 1 again (you can never be too lax on keeping your security skills current).
History reminds me that staying proactive with my security practices avoids major outages and financial loss. Today, with so many attacks on our private information and confidential data, isn't it worth taking the time to ensure you’re doing everything possible to prevent the next attack?
