The latest trend in cybercrime appears to be trying to crack into the websites belonging to companies that are in the business of stopping cybercrime.
Two weekends ago, a Romanian hacker going by the handle Unu first blogged about using a SQL injection attack to gain access to Kaspersky Lab's U.S. support website. Then, he chronicled a successful infiltration of F-Secure and BitDefender.
In none of the cases was any sensitive data exposed. It's difficult to say whether that is because the hacker stopped short of doing this because he merely was trying to demonstrate the insecurity of these sites -- or because he simply was not sophisticated enough.
Either way, his point was well taken. Because of the amount of code used to build today's flashy and information-filled websites, pages are going to be insecure. And while Kaspersky, for good reason, expressed shame and disappointment over the hack, situations like this are going to happen.
After all, if a determined hacker wants to find a way in, chances are, he will.
I was speaking recently to the owner of a security consulting firm who said he was absolutely sure that, sooner than later, hackers were going to compromise his site. Just to prove they could do it. He could run the latest and greatest to stop them, but an attack was inevitable.
So how does he sleep at night, knowing the phone might ring at 3 a.m. (sorry, Hillary), telling him that his site was illegally accessed?
By doing the most important thing one can do: Mitigating the threat by limiting the amount of sensitive data that resides in database servers serving public-facing websites.
This should be a best practice that not only applies to SQL databases but across enterprise networks. If you don't need it, don't keep it.
The worst-case scenario, my source told me, was that the thieves would get some email addresses.
Sounds a lot better to me than names, Socials and credit card numbers.
Two weekends ago, a Romanian hacker going by the handle Unu first blogged about using a SQL injection attack to gain access to Kaspersky Lab's U.S. support website. Then, he chronicled a successful infiltration of F-Secure and BitDefender.
In none of the cases was any sensitive data exposed. It's difficult to say whether that is because the hacker stopped short of doing this because he merely was trying to demonstrate the insecurity of these sites -- or because he simply was not sophisticated enough.
Either way, his point was well taken. Because of the amount of code used to build today's flashy and information-filled websites, pages are going to be insecure. And while Kaspersky, for good reason, expressed shame and disappointment over the hack, situations like this are going to happen.
After all, if a determined hacker wants to find a way in, chances are, he will.
I was speaking recently to the owner of a security consulting firm who said he was absolutely sure that, sooner than later, hackers were going to compromise his site. Just to prove they could do it. He could run the latest and greatest to stop them, but an attack was inevitable.
So how does he sleep at night, knowing the phone might ring at 3 a.m. (sorry, Hillary), telling him that his site was illegally accessed?
By doing the most important thing one can do: Mitigating the threat by limiting the amount of sensitive data that resides in database servers serving public-facing websites.
This should be a best practice that not only applies to SQL databases but across enterprise networks. If you don't need it, don't keep it.
The worst-case scenario, my source told me, was that the thieves would get some email addresses.
Sounds a lot better to me than names, Socials and credit card numbers.
