Tag Archives: SQL Injection

TalkTalk – The case for a Chief Security Officer


unnamed-1While the importance of the Chief Information Security Officer has been in constant growth over the past few years, organisations that employ a CISO/CSO are still far too few.

As the latest breach at broadband provider TalkTalk descends slowly into farce, the perils of relying on the CEO to fill these shoes become apparent. Almost one week on from the initial attack many important questions still remain unanswered or answered in unacceptably vague or contradictory terms.

The “significant and sustained” attack against TalkTalk was initially characterised as a Distributed Denial of Service attack. Commentators rightly pointed out that a DDoS in itself does not lead to information theft and that there must have been another element to it. Later reports appear to confirm that the theft was the result of a simple SQL injection attack. At a technology company! Affecting 4m people! In 2015!

TalkTalk are still unable to confirm which and how much data was encrypted. In addition to personal information including name, address, date of birth and email address, the breach also exposed financial data. The CEO initially said that they “didn’t know” if this data was encrypted or not (How can this be the case?). Now, it appears that “only” the first and last digits of credit card data may have been exposed. Of course this still carries risk, think how often those “last four digits” are requested as verification data. Since then Baroness Harding has even gone as far as the last refuge of the wicked, legislation, claiming in an interview with The Sunday Times (paywalled) that TalkTalk is under no obligation to encrypt credit card data. Really? I think that the PCI-DSS may well dispute that point with you, not to mention your customers.

Ah yes, the customers… Those four million people who will now be finding that their names, addresses, contact information and dates of birth are far more difficult to change than their credit card details (or their broadband provider) and that a year of free credit-monitoring involves entrusting yet another corporate with all their extremely sensitive information.

The handling of the breach illustrates that the role of the CISO is never a purely technical one; the CISO also owns the breach response plan, an important aspect of which has nothing to do with technology and everything to do with communications. How do you inform your customers and when? How do you engage law enforcement or forensics? What information do you need always to have to hand about the care and sensitivity with which you treat the information that has been entrusted to your organisation and how do you sensitively, accurately and promptly convey this?

Rule 1: It’s not all about you. To say, “I’m a customer myself of TalkTalk. I’ve been a victim of this attack” is crass and insensitive in the extreme. To include an assertion in your FAQ that you have not breached the Data Protection Act is both short-sighted and ill-informed, as I addressed in this piece for The Guardian.

This apparent lack of plan, this visible lack of any senior Information Security management team could well be the eventual downfall of TalkTalk, time, the markets, the regulators and their customers will decide. We could be watching the first major corporate disintegration as a result of data breach. Welcome to the future.

So, assuming you have or are planning to hire a CISO, to whom should they report? In too many organisations the CISO is still reporting to the CIO despite the frequent pitfalls. This reporting structure can be counter-productive. The question of reporting lines is often a source of friction and can really only be answered if you have managed to effectively differentiate and delineate your CIO and CISO roles.

Job descriptions are slippery amorphous things, so in the interest of impartiality I’ll use Wikipedia’s definition. CIO is “a job title commonly given to the most senior executive in an enterprise responsible for the information technology and computer systems that support enterprise goals”, whereas CISO “is the senior-level executive within an organization responsible for establishing and maintaining the enterprise vision, strategy and program to ensure information assets are adequately protected”.

When put this simply, the conflict of interest in having a CISO report to a CIO becomes very clear. The person responsible for ensuring organisational information security can not be subordinated to the person responsible for technology selection and implementation. Rather the two should operate as a team, driving operational and information security up the boardroom agenda. An effective CIO/CISO team will take board level strategic directions and translate them into technological and process requirements for the organisation. The CIO ensures that best of breed technologies are selected and architected in the most operationally beneficial manner, the CISO ensuring that those technologies meet the security requirements of the business on an ongoing basis; neither one being able to pull rank on the other.

In the case of a conflict arising between the two, which cannot be resolved through discussion the final say must comes down to business risk and operations, requiring the involvement of COO, CRO or even CEO depending on the organisational structure.

Security should be a regular boardroom agenda item and it is only through the checks and balances of the independent CIO and CISO that it can be effectively addressed.

5 Security Questions for your SaaS provider

used by permission from ky_olsen's Flickr stream

Software as a Service is seeing sustained growth and sustained adoption in both enterprise and in the home. According to a Gartner release in July 2011, Software as a Service revenue reached $10 billion in 2010 and is still growing. In fact Gartner estimate growth of over 20% 10 $12.1 billion on 2011.
The Gartner definition of Software as a Service is software that is “owned, delivered and managed remotely by one or more providers. The provider delivers an application based on a single set of common code and data definitions, which is consumed in a one-to-many model by all contracted customers anytime on a pay-for-use basis, or as a subscription based on use metrics”. The example that is cited in almost every article and presentation on the subject is Salesforce.com, and while they are a major provider in the SaaS arena it is important to recognise that SaaS comes in many different flavours. Customer Relationship Management, Human Resource Management, Cloud backup, Collaboration platforms, accounting platforms, helpdesk management, managed services and web or email filtering to name but a few.
The economic benefits, to providers and customers alike are relatively obvious to spot, the cost of user provisioning (the SaaS model) when compared to the cost of application acquisition, licensing and rollout (the on-premise model) is extremely attractive. The SaaS provider is able to more quickly and easily update and manage the software and service due to its centralised nature, application improvements are easier to make as a result of the visibility the provider has of customer usage patterns and the scalability and pay-per-use is attractive for both customer and provider. In addition the possibilities for integration and open interfaces are greater, with many SaaS providers already offering social media-like collaboration functions or open interfaces (APIs).
While SaaS may offer a flexible and cost-effective alternative to a traditional application environment, it is not without risk. By moving to a hosted platform, as opposed to in-house, enterprises must necessarily sacrifice a large element of control over parts of their operating environment. With SaaS in particular, almost the only choice you have is whether you upload certain data or not, the rest is largely out of your hands. You do of course retain the legal and regulatory accountability for the security of your data.
The risks in a SaaS environment are many, and largely related to the benefits offered. As I mentioned previously, your provider has access to your usage habits of the platform, normally through some kind of web analytics, they also have the capability of accessing all of your data and this in itself presents the risk of unauthorised access or monitoring by an insider.
The centralised nature of the system and the “one configuration fits many” model of the multi-tenanted environment means that, should a vulnerability affect one customer, there is a strong possibility that other customers will be equally affected. The Epsilon breach is one of the more recent examples and it affected many Fortune 500 companies using the same SaaS provider. The scope for exploits of vulnerabilities is wide. Common protocols and the software stack are used by most SaaS providers (HTTP, XML/SOAP, JSON, CSS and JavaScript) and these are readily and regularly exploited if not correctly engineered, implemented or configured. Additionally, the more scope a platform offers for customisation and external integration (a key selling point for SaaS vendors), the more chance there is that some other customer will introduce a vulnerability from which another may suffer the consequences. Such is the nature of a multi-tenanted environment.
5 Key security questions to ask your SaaS provider:
1 – Penetration testing – How is the environment pen tested, how often and do you have the ability to independently pen test your own part of the environment? Without regular, in-depth pen testing you have no visibility of your current security posture.
2 – Data Security – How is data encrypted in storage and in transit across the shared resources of the SaaS provider data centre? Who has access to the keys? Is separation of duties and separation of keys and data maintained? Can the provider offer you a SAS 70 report?
3 – Multi-tenancy – Is there an option that provides for single tenant hosting? Also explore whether this single tenancy comprises simply the application or also the data storage?
4 –Disaster Recovery – In the event of catastrophic failure, or external intrusion and data loss what backup and recovery procedures are in place? Where is backed up data stored (and encrypted again) and how is it effectively restored?
5 – User Authentication – What is the sign on procedure for the SaaS application? Are multiple factors in use? Is it possible to integrate sign-on with authentication structures already in use by the customer?

Symantec hacked? Full disk and database access?

hack-o-rama by Al Corr

hack-o-rama by Al Corr


Back in February of this year, the Romanian hacker Unu found a SQL injection vulnerability in a Kaspersky tech support portal server based in the USA. That vulnerability when exploited allowed full access to all the database tables, exposing things such as usernames and activation codes.


Well, Unu strikes again and this time Symantec is the unlucky recipient of his attentions, and certainly at first glance it looks worse than the Kaspersky breach. In a new posting on Unu’s blog he details a blind SQL injection-based attack against a Symantec server, the server appears to be responsible for tech support through “Norton PC Expert from PC-Doctor Co Ltd” in Japan.


According to Unu, by exploiting the vulnerability he is able to access a lot of very sensitive information including personal details and product keys (from the symantecstore database table). More worryingly, the screenshots appear to indicate that the attackers is able to browse the entire contents of the server hard drives at will. Unu also notes that both user and employee passwords are available in clear text which, if true, represents a serious oversight, passwords should always be stored encrypted or with a salted hash. It should be noted though that there is no evidence of this particular data other than Unu’s own typed report, no screen shots of this data have been posted.


Although commentators have not always agreed on the accuracy of Unu’s claims, as in the recent claimed compromise of the Barack Obama Donations site; as ever, Unu insists that his activities are only done to warn and raise awareness without saving or otherwise stealing any proprietary information.


If you remember, in February, Kaspersky faced with a sql injection. Then they had the courage to admit vulnerability, why have my admiration. There was fair play, they quickly secured vulnerable parameter, and even if at first they were very angry at me, finally understood that I did not extract, I saved nothing, I have not abused in any way by the data found. My goal was, what is still, to warn. To call attention.

That being said, expect the curious reaction from Symantec.”


I have made sure Symantec UK and Japan are aware of this information and I am sure they are investigating as I type,  but it’s never a bad idea to restate a few best practices for securing web applications:

  • Keep them patched.
  • NEVER store sensitive data in clear text.
  • Get them regularly vulnerability scanned from the inside as well as the outside.
  • Use strong authentication (2 factor) if you are only serving a limited user population or if the data you are holding is particularly sensitive. Cookies can lead to session hijacking…
  • Bounds checking of input data helps to avoid buffer overflows and SQL injection type attacks.
  • Provide access to information on a Need to Know basis and always provide it with Least Privilege.
  • Don’t provide detailed error information to browsers, you don’t expect your customers to debug your application, so don’t give up that error message.