Today I was part of a panel where we debated whether Clouds are compliant. The session was part of the BrightTalk online Cloud Computing Summit and was hosted by Peter Judge, UK Editor, eWeek Europe. I was joined by IBM's James Rendall, and Paul Roberts of The 451 Group and we participated in a lively session.
The questions we worked through were:
Q1. Do you trust the cloud?
Q2. Are clouds compliant?
Q3. Is compliant a barrier to adoption?
Q4. How should we make clouds compliant?
There was online polling of the audience with clear majority responses being as follows: Q1 – No; Q2 -No, and Q3 - Yes.
Question 4 was the most interesting for me. We actually debated two courses of action. First, "Change clouds to accommodate regulation". Alternatively, "Change regulations to accommodate clouds". A cheeky 25% of the audience voted for the latter! This is like raising the speed limit on the roads because it is impossible to stop motorists from speeding. Is this a good idea?
I cynically pointed out that the underlying context is not peculiar to cloud -- and is commonly observed in other computing architectures. IT is a business enabler – and businesses want to make profits. Once a profit making system is in place, it is only then that organizations get concerned about compliance and security issues. Alas, the elasticity and remote nature of cloud infrastructures make retro-fitting security devices (e.g. firewalls) nearly impossible. The only way to achieve the retrofitting of security into the cloud is if you can make the security technology ‘cloud hostable’ and have it inserted seamlessly into the underlying fabric. Perhaps a DataWall for the cloud – watch this space.
Wednesday 30 September 2009
Wednesday 23 September 2009
Why hack a database when the data is being given away!
Here at Secerno we spend all our time helping our customers protect databases to ensure that they keep their precious data safe. For an Internet Service Provider (ISP) like the U.K.’s Demon, precious data includes username and password information that their customers use to access services. Something certainly worth protecting!
Imagine my horror to learn that "Demon's director of customer service" has emailed 3,681 of their customers and attached the list of user details for the 3,681 customers. This is not an attack to steal data – this is an appalling example of a data leak caused by “human error”.
In the paperless office empowered by an IT world this sort of thing is so easy to do. Imagine “accidentally” stuffing printed client lists in a paper-based mail-out to customers in the good-old-days of paper systems. Unlikely. Let us wait and see if there is any legal action. The U.K. legal framework lacks the teeth to really bite.
Data security goes beyond defending against malicious attack – it also must defend well intentioned fools.
Imagine my horror to learn that "Demon's director of customer service" has emailed 3,681 of their customers and attached the list of user details for the 3,681 customers. This is not an attack to steal data – this is an appalling example of a data leak caused by “human error”.
In the paperless office empowered by an IT world this sort of thing is so easy to do. Imagine “accidentally” stuffing printed client lists in a paper-based mail-out to customers in the good-old-days of paper systems. Unlikely. Let us wait and see if there is any legal action. The U.K. legal framework lacks the teeth to really bite.
Data security goes beyond defending against malicious attack – it also must defend well intentioned fools.
Wednesday 16 September 2009
Data Breaches: The way to a corporation’s data-heart is through their applications-stomach
Again we learn, that like the old adage “the way to man’s heart is through his stomach”, “the way to a corporation’s data is through their applications”. A hacker announced that he was able to get through to the RBS WorldPay Database via a SQL Injection vulnerability in one of their web applications. This is nothing new.
Last week the CEO of Heartland Payment Systems, Robert Carr, highlighted that it is not just web applications that have the flaws. The breach, that ultimately had more than approximately 130 million card numbers leaked from Heartland’s payment systems, was actually initiated through an unrelated corporate application. This too, was exploited via SQL Injection, allowing the attacker to use the database to get a “position” on the network from which undetectable-malware delivered a sniffer that was installed to collect passing card numbers from the card payment system.
Heartland had many penetration testers and certified security auditors (including PCI QSAs) constantly crawling all over their systems – even after they had learned of the injection attack. They had been reassured that their card data was still safe for many months. Alas, history tells us that they had a false sense of security – until they went looking for the sniffer based on lessons learned in the Hannaford Brother's data breach.
Now – like Heartland – the initial claim of RBS (owners of WorldPay) is that no data was leaked in this recent exploit. How long will it be before we learn otherwise?
Last week the CEO of Heartland Payment Systems, Robert Carr, highlighted that it is not just web applications that have the flaws. The breach, that ultimately had more than approximately 130 million card numbers leaked from Heartland’s payment systems, was actually initiated through an unrelated corporate application. This too, was exploited via SQL Injection, allowing the attacker to use the database to get a “position” on the network from which undetectable-malware delivered a sniffer that was installed to collect passing card numbers from the card payment system.
Heartland had many penetration testers and certified security auditors (including PCI QSAs) constantly crawling all over their systems – even after they had learned of the injection attack. They had been reassured that their card data was still safe for many months. Alas, history tells us that they had a false sense of security – until they went looking for the sniffer based on lessons learned in the Hannaford Brother's data breach.
Now – like Heartland – the initial claim of RBS (owners of WorldPay) is that no data was leaked in this recent exploit. How long will it be before we learn otherwise?
Wednesday 9 September 2009
What’s in a number?
Today, the Ponemon Institute revealed that 67 percent of French organizations have been hit by a data breach incident over the past year, with 18 percent having more than five incidents. If this seems high, it is with reason. According to Ponemon, only 8 percent of these breaches were reported, so we never heard about the other 92 percent because there was no legal or regulatory mandate for reporting them.
The issue of reporting and disclosure is hotly contested, oftentimes pitting the rights of individuals against corporations that want to distance themselves from the bad publicity and associated liabilities. The United States, which has seen some of the largest data breaches in history, still does not have a single standard for data breach reporting or regulatory data protection requirements.
We can’t expect companies to willingly disclose data breach information – the consequences are too severe, even though the full disclosure will work to their benefit over time. What needs to happen is the same focus on transparency that is being heralded in the financial services industry should be applied to data breaches, with the primary goals being catching those responsible and informing those affected as soon as possible. This transparency will come, at the very least because certain industries will require it. In the meantime, we take solace in the 71 percent of the Ponemon respondents in France, who placed data protection as a critical component to their overall protection plan. These companies are not completely overlooking data protection but they are playing catch up (as are most companies these days) to very sophisticated hackers.
French cuisine may be famous for rich sauces. It is clear from this report that they are a rich data source too!
The issue of reporting and disclosure is hotly contested, oftentimes pitting the rights of individuals against corporations that want to distance themselves from the bad publicity and associated liabilities. The United States, which has seen some of the largest data breaches in history, still does not have a single standard for data breach reporting or regulatory data protection requirements.
We can’t expect companies to willingly disclose data breach information – the consequences are too severe, even though the full disclosure will work to their benefit over time. What needs to happen is the same focus on transparency that is being heralded in the financial services industry should be applied to data breaches, with the primary goals being catching those responsible and informing those affected as soon as possible. This transparency will come, at the very least because certain industries will require it. In the meantime, we take solace in the 71 percent of the Ponemon respondents in France, who placed data protection as a critical component to their overall protection plan. These companies are not completely overlooking data protection but they are playing catch up (as are most companies these days) to very sophisticated hackers.
French cuisine may be famous for rich sauces. It is clear from this report that they are a rich data source too!
Thursday 3 September 2009
Declaring war on easily attacked applications
Today is the 70th anniversary of Britain’s declaration of war that brought them into the Second World War. With news of yet another business application being poorly defended allowing its database to be attacked we should declare war on poorly written applications.
In the Sears.com case, it was very poor application design which made the attack possible. Foolishly, the functionality that is meant to protect the web-application was deployed in the least trustworthy of locations, the “customer’s” web browser. On the internet, “customers” and “attackers” are indistinguishable. As Sears.com has no control of the “attacker’s” browser it has not reason to trust that this inadequate security control mechanism will not be altered, tampered with or completely disabled.
Further poor practice meant that there was no independent monitoring or enforcement system that prevented or even alerted the strange behavior of a massive increase in certain functionality that allowed a “customer” to “stage a brute-force attack that could grab all valid, active Sears and Kmart gift cards from the company's database.”
What should organizations do?
1. Raise the level of software engineering so that secure development processes are embedded in all application development.
2. Test, test, test, test, and re-test the application for vulnerabilities. Remember, these are vulnerabilities that are in applications that your developers wrote – not just operating system or platform component vulnerabilities.
3. Put monitoring and enforcement systems in place to fully understand what normal usage patterns are for the application and ensure that real-time policies can prevent unwanted behaviors.
Finally, organizations should make an open declaration of war on poorly produced and operated applications!
In the Sears.com case, it was very poor application design which made the attack possible. Foolishly, the functionality that is meant to protect the web-application was deployed in the least trustworthy of locations, the “customer’s” web browser. On the internet, “customers” and “attackers” are indistinguishable. As Sears.com has no control of the “attacker’s” browser it has not reason to trust that this inadequate security control mechanism will not be altered, tampered with or completely disabled.
Further poor practice meant that there was no independent monitoring or enforcement system that prevented or even alerted the strange behavior of a massive increase in certain functionality that allowed a “customer” to “stage a brute-force attack that could grab all valid, active Sears and Kmart gift cards from the company's database.”
What should organizations do?
1. Raise the level of software engineering so that secure development processes are embedded in all application development.
2. Test, test, test, test, and re-test the application for vulnerabilities. Remember, these are vulnerabilities that are in applications that your developers wrote – not just operating system or platform component vulnerabilities.
3. Put monitoring and enforcement systems in place to fully understand what normal usage patterns are for the application and ensure that real-time policies can prevent unwanted behaviors.
Finally, organizations should make an open declaration of war on poorly produced and operated applications!
Subscribe to:
Posts (Atom)
