NETSECURE BLOG
Monthly Security Challenge: Zero-Day Attacks

WHAT IS IT?
A zero-day attack occurs when hackers find software vulnerabilities that are new or unknown. They are called “zero day,” because they occur on or before the first or “zeroth” day of the developer’s awareness. Prior to this attack, the developer has not had any opportunity to distribute a security repair. They are unrecognizable, since they do not match earlier viruses, can modify themselves, or are previous threats that software developers have not yet fixed.
In September 2010, news headlines filled the Internet of a zero-day attack on Adobe Reader. A couple of months later, the industry dealt with another zero-day attack against Microsoft Internet Explorer 6, 7 and 8. In both cases, hackers discovered vulnerabilities to launch attacks.
WHAT DEFENSES NO LONGER WORK?
To combat such attacks, Microsoft releases security fixes the second Tuesday of every month, known as “Patch Tuesday,” but these fixes are reactive and unable to prevent the attacks at first. Similar to these security fixes, anti-virus software is no longer enough to protect you.
While both anti-virus software and the released security fixes provide a valuable function, it does not keep up with zero-day attacks. Every time new viruses, malware programs, or other security threats are created, the attack must be detected then de-constructed before a defense can be built, which leaves the unknown zero-day attack a major threat.
Security defenses, such as endpoint security, need to be leveraged in addition to anti-virus software to protect against zero-day attacks. Traditional SSL (Secure Socket Layer) has proven extremely effective at securely transferring sensitive data over the Internet. The one area that, until now, had been exposed to hackers and malicious software are the endpoints.
HOW CAN YOU SOLVE IT?
Dynamic SSL is a very effective solution to zero-day attacks. It works by ensuring that sensitive information is never present in the data stream until the point of encryption. Variables, rather than sensitive information, are inserted into a data stream at locations where the remote server is expecting. The data stream is then redirected to a secure location where the variables are replaced with the actual information and the data stream is then encrypted and sent to the remote server.
The data stream arrives in the standard SSL format expected and is decrypted with the same SSL keys used to protect the Web session. Since the sensitive information was not present in the data stream until the point of encryption, any attempt to intercept would be useless. Rather than obtaining pertinent information, only meaningless variables would be found.
