back to article Lawyers harrumph at TalkTalk's 'no obligation to encrypt' blurt

Lawyers have taken issue with claims by TalkTalk boss Dido Harding that the telco was under no legal obligation to encrypt customers' sensitive data. Harding's comments came on Sunday, three days after TalkTalk admitted a breach on its systems that may have exposed the personal details, including bank information, of up to …

Page:

  1. Awil Onmearse
    Boffin

    Jesus H Christ. Security is hard, but It's fucking trivial to store data in encrypted format. Hang them.

    1. Velv
      Boffin

      Security is hard. It's hard because there is no single solution and it must be implemented in layers.

      Encryption is completely useless against a straightforward extract using the correct credentials. A bulk export to clear text is a (relatively) trivial query, which is where other layers of protection are required. And since we don't yet know what has been taken or how, there is no way of knowing if encryption would have made any difference.

      But you're right, encryption is one of the simple and powerful layers to implement and there's no excuse for not doing it.

      1. Dazed and Confused
        Flame

        Broken by design

        > Encryption is completely useless against a straightforward extract using the correct credentials.

        The simple fact of the matter is that the front end web servers shouldn't have unrestricted access to sensitive customer data. It should not be possible to issue a query from those systems that can retrieve full credit card and bank account details. Sure it makes life bloody easy for the website developers to be able to issue a simple SQL query to the back end and pull out the data, but so long as that is possible then these breaches will happen. Only by stopping the data being there to be hacked are you going to stop it being hacked. In the case of the card number the most that the web server should be able to see would be a bolloxed version with the middle full of stars.

        Like the way that password are handled, the system doesn't store the plain text password, it stores a hash. When the user logs in then you hash what they type and compare the resulting garbage. In the case of the card numbers the user should say which card they want to use and then either the list id number (she chose card 3) or the full card should be sent to the back end system to do the financial transaction. There should be no unrestricted access from the webserver to the backend box. There should be no other access to the backend box from the any of the public facing machines.

        If it was possible to get access to the banking/credit details from the webserver then the whole management team should be doing time and the there should be massive fines plus liability to customers who lose out. Only by sticking the boot in like this will companies start to take security seriously.

      2. LucreLout

        @Velv

        Encryption is completely useless against a straightforward extract using the correct credentials. A bulk export to clear text is a (relatively) trivial query, which is where other layers of protection are required.

        Agree completely, however, the immediate answer to questions surrounding a breach like this should always always be "Yes, the data was stored in an encrypted format". Obviously on its own that won't be enough, but its fairly trivial to do, and is one of the foundations/cornerstones of data protection.

        If the CEO has to resort to statements like "well, we don't really know because we have millions of lines of code, but its possible some of it might have been", well, what you've got there is a company that has no business retaining or otherwise handling customer information.

        *cough* erm, like my company... but that really isn't for want of flagging this to the powers that be.

      3. itzman

        By definition..

        Hacking is not 'using the correct credentials;'

        I have implemented several websites that store sensitive information, The scripts that allow 'correct credentials' to extract pertinent information do NOT allow global access to all information. Because the strictly limited SQL queries are built into the scripts., And the keys are stored outside the scripts themselves so that even if the scripts are compromised, they cannot be run successfully on another machine against a stolen encrypted database.

        In order to extract data from a database encrypted in this way you need all three elements to be accessible - the database, the scripts showing how the keys are used to decrypt it, and the keys themselves.

        To get all three you need to root the machine,. SQL injection will not help.

        1. John Smith 19 Gold badge
          Unhappy

          @itzman

          "I have implemented several websites that store sensitive information, The scripts that allow 'correct credentials' to extract pertinent information do NOT allow global access to all information. Because the strictly limited SQL queries are built into the scripts., And the keys are stored outside the scripts themselves so that even if the scripts are compromised, they cannot be run successfully on another machine against a stolen encrypted database."

          I understood your description in about 30 seconds.

          I don't really understand what is so hard about implementing this process.

    2. Anonymous Coward
      Anonymous Coward

      I've been working with web servers for about 10 years.

      I've yet to come across an encrypted one.

      I've worked with both Apache/Linux/MySQL stacks and Windows/IIS/SQL Server stacks...all without encryption.

      Instead they have good security in the web application side of things. Encrypted https connections, hashed passwords, no direct SQL to the database, locked down databases and regular security checks, not to mention very good physical security - for which you pay a high price to good hosts.

      I will say for the most part these haven't been the most interesting of databases and all payments would have been held with a third party processing company.

      I'm not entirely sure of the point of encrypting the database which so many seem to be advocating here in order to prevent an attack of this sort. If you've got past the web security side of things then chances are you can find the keys that the web service uses to access the database (unless they're write only access). Encryptions only really going to help if someone steals the server(s) and plugs it in elsewhere. Which hopefully they're not going to be able to do because of the physical security.

      As for trivial... I'm not so sure it is. Obviously anyone can create a true-crypt container or the likes and stick something in it. However encrypting a SQL Server database correctly requires for example SQL Server Enterprise - which to my limited and slight dated understanding is licensed per core at some extortionate rate beyond many small-medium size businesses capability...not to mention some more specialist understanding than your average web developer might have. Maybe for a business the size of talk talk this shouldn't be a problem... but is it the right solution or just a rubber stamp people are looking for? I'm curious to understand others opinions here.

      1. itzman

        Re: I've yet to come across an encrypted one.

        Well all you are saying is the average level of security on most sites is total pants.

        I've written several that are, simply because of certain isues pertaining to those sites that made it possible that entire databases might be stolen by e.g. sysdadmjns responsible for the server infrastructure, or in one case where a portable database was carried around on a ;laptop. In the latter case we split the database from the application using a USB drive so that even if the laptop went AWOL with the encryption keys, the database would not. And vuice versa.

        Given that SQL injectins is something that no competent programmer should have left the possibility for, in this case encrypted data clearly would have prevented critical information from becoming public.

        Those that have suggested that encryption would not have helped seem to have no idea how a website built over a database actually works, or what sql injection is.

    3. Stretch

      Security is hard

      And understanding it even harder. This data was retrieved via the application, which of course would have the encryption keys, and would handily decrypt the data for you.

      1. Anonymous Coward
        Anonymous Coward

        Re: Security is hard

        That's not hard to understand. It's not so much that security is hard. It's more that most of us don't know the inner workings of today's web-faced IT systems. Including, it seems, the management of TalkTalk (dumb name that, btw).

      2. LucreLout

        Re: Security is hard

        @Stretch

        This data was retrieved via the application, which of course would have the encryption keys, and would handily decrypt the data for you.

        Yes, yes it would. Any developer still building web sites that are vulnerable to SqlInjection has literally no business building web sites at all. Ever.

        This is just another reason why we need an industry regulator with the power to authorise people to work in the IT industry, or prohibit them due to lack of skill or care.

      3. itzman

        Re: Security is hard

        SQL injection actually is rertieving data NOT by the applications as it was designed to run, but via a flaw in it. That flaw would not have invoked the decryption if that had been present.

        That is if you manage to tack onto a form variable that is not checked for it the string '; select * from credit_cards' you make get the entire credit card database, but not in an unencrypted form.

        You are assuming that the encryption is somehow inside of the SQL server. It shouldn't be there. It should be in the application, so that direct access to the database does not return unencrypted data. Encrypting a database but having sql return an unencrypted format is not security, its lunacy.

        1. LucreLout

          Re: Security is hard

          @Itzman

          You are assuming that the encryption is somehow inside of the SQL server. It shouldn't be there. It should be in the application, so that direct access to the database does not return unencrypted data.

          Yes, correct. And that takes about 5 minutes to implement and should be so standard throughout the enterprise that the CEO can confidently declare "Yep, the data was encrypted". The application should not execute arbitrary statements and should have access to return only that which is required for the operation it is supposed to be executing.

          Anyone building web sites that does not know about parameter binding and Sql Injection should be stopped from building web sites. That they cannot be stopped does not reflect well on our industry.

        2. Anonymous Coward
          Anonymous Coward

          Re: Security is hard

          @Itzman

          OK so if I'm getting you right you're saying encrypt the data that goes into the database rather than the database itself.

          Which you can do with things like payment data if you actually process that yourself... and I get that. That makes sense.

          However you can't encrypt things like customers names, addresses, emails etc in that way.

          If you did you wouldn't be able to do a customer look up by name for example without decrypting every name in the database first.

          Assuming your website also has some kind of call centre/admin login that's a fairly simple piece of functionality that you're going to have?

      4. alain williams Silver badge

        Re: Security is hard

        It is not hard to put the really sensitive information in a separate table. Then not allow direct access to that table and provide some SQL functions to do the jobs needed: CheckThisPassword, UpdateThePassword, ... like that the web application can only pass in a candidate password or a new one to be set, ... it does not see the stored password, encrypted or not.

        No, not perfect but it makes it harder to grab everything. Security is about belts and braces, assume that one will break and that the other(s) will keep you safe.

  2. Ben Tasker

    Legality (and common sense) aside, the one position you don't want to be in is one of, just after apologising to 4 million people who's data you've lost, having to justify why you hadn't encrypted that data.

    I'm surprised Harding was allowed to approach it in quite the manner she did. You'd think someone would have forewarned her.

    I'd have more sympathy if she'd had to explain to a group of idiots (as I'm sure we've all had to, even if only hypothetically) that the data was encrypted, but they got the keys because the web service needs to be able to decrypt the data to use it.

    But to say we didn't implement a simple measure because we weren't legally compelled to

    1. Doctor Syntax Silver badge

      "I'd have more sympathy if she'd had to explain to a group of idiots (as I'm sure we've all had to, even if only hypothetically) that the data was encrypted, but they got the keys because the web service needs to be able to decrypt the data to use it."

      Maybe that's how someone explained it to her.

      1. itzman

        How would someone get the keys

        by SQL injection?

        Unless they were - gasp - stored in the database...

        I was feeling pretty contemptuous of Talktalks management until I read the plethora of ignorance in these posts here.

        It seems that virtually no one in the IT business understands how to make a website secure, either.

        1. Ben Tasker

          Re: How would someone get the keys

          by SQL injection?

          Unless they were - gasp - stored in the database...

          Sadly I've seen exactly that more than a few times. Along with one idiot who had debug on, so, amongst other things, the decrypt key was in the response headers. Which idiot thought doing that, even in debug mode was a good idea I don't know, but I told him he needed to migrate off that CMS or at the very least have a full code audit urgently.

          But, I was actually thinking of more skilled/thorough compromises where the attacker has managed to nab a copy of the service from the filesystem too (which might jnclude something as stupid as leaving an old backup in a web accessible location).

          People think encryption is a panacea, but it's not. It's something you should be doing, but there are still a lot of attack profiles where it makes no difference. Doesn't mean there isn't a benefit to closing off the others though.

    2. streaky

      As I was saying to somebody earlier, my understanding is one of the main rules of PR is you shouldn't try to pass yourself off as a lawyer. She did and failed miserably.

      The law isn't clear - but one would assume the test would be what a reasonable (competent) person would do; if they're found wanting they could be up shit creek.

      Crypto or otherwise - a reasonable developer wouldn't have SQL injection flaws everywhere (they're a bit 2006) and a reasonable person may set their systems up with crypto for various aspects of their data. Even if they're about as useful as a paper bag and don't fully secure you and maybe wouldn't have kept customer data safe because a reasonable competent person would have done it you could end up being liable under the law.

      1. Chemist

        "my understanding is one of the main rules of PR is you shouldn't try to pass yourself off as a lawyer"

        More generally : "my understanding is one of the main rules of PR is you shouldn't try to pass yourself off as an expert"

        There's been an awful lot of that around recently.

        1. Anonymous Coward
          Anonymous Coward

          I worked for a firm who had a very nice CEO who understood that if you don't know something don't try and bluff it. Then he left and his replacement didn’t understand this. Basically a building firm down the road had cut cables supplying the building with connectivity by accident. He addressed a large meeting of staff and said our downtime couldn't happen again because of technical measures he'd implemented after the incident. So his technical measures was just a decision that as our contract was up we'd switch to a new supplier, who obviously (well to the rest of us) were going to be using the same cables He'd been told that this wasn't a solution before the meeting but for some reason decided to spout crap that convinced nobody.

          1. streaky

            said our downtime couldn't happen again because of technical measures he'd implemented after the incident

            Oh I love it when management people do that. Pride before the fall and whatnot.

      2. KeithR

        "The law isn't clear"

        Actually, both the letter and the spirit of the applicable law (DPA 7th Principle) are CRYSTAL clear.

        The letter: "you do whatever is reasonable to ensure that the personal data in your charge is secure".

        The spirit: "That means ENCRYPT IT".

  3. Dan 55 Silver badge

    In their info for business and government customers they also say they are ISO 27001 compliant which requires encryption for data at rest. So, if someone asks them this question (Go Reg), either they're not actually ISO 27001 compliant or they've got to come out and say they don't care about consumer accounts. And if it's the second, can they be 27001 compliant and non-compliant at the same time on the same infrastructure?

    1. Chris Miller

      I think you may be conflating 27001 with PCI-DSS (which is based directly on it and does mandate encryption for certain credit card related data). Hardly any actual security measure is mandated by 27001, it provides a list of over 100 security controls (including encryption) which are set out in ISO 27002, and if you choose (after due consideration by those responsible for the security management process) not to implement them, you must justify your decision.

      Note that claiming you're 27001 compliant means precisely zilch - it's only certification that matters.

    2. Anonymous Coward
      Anonymous Coward

      they are ISO 27001 compliant

      Well, that's one of those things that has been pissing me off for quite some time. ISO 27001 is basically confirming you have some system to manage the security policy you should have in place (known as an Information Security Management System, in the world of IT naturally turned into an acronym ISMS), on the pretext that without it you'd be very disorganised. But it still just confirms you have a system, it is not really looking at the quality of what you actually do - which is ISO 27002. In short, the ISO 27001 cert is based on presumption rather than on the presence and execution of the very policies it's supposed to manage, and only those actually ensure controls are in place.

      I much rather deal with an organisation that seeks to work according to ISO 27002 than one that shows me an ISO 27001 cert, and if I were to review such an organisation, it's their approach (read: policies) what interest me, also because a smaller outfit can be compliant without spending big $$$ on consultants to give it the ISO 27001 accreditation, and thus be secure by default without doing it just to get a tick in the box.

      I see ISO 27001 certs as consultant food and mainly focused on avoiding liability. If you are genuinely concerned about security you review ISO 27002 deployment, and I suspect you would probably find problems at TalkTalk...

      1. Chris Miller

        I think your experience with 27001 is a bit out of date. What you describe may have been true many years ago (a bit like the old joke about ISO 9000 and 'concrete life-jackets' - as long as your documentations says "we provide concrete life-jackets" and you provide them, you've passed!), but you've got to produce a (public - and you'd be well advised to examine it if you're assessing the security posture of a potential business partner) document setting out for each of those 100+ 27002 controls, whether it's applicable to your activities, and (if so) how you've implemented it.

        An external assessment (mandatory and normally every 6 months) will focus on any controls that you've excluded (there'll normally be a handful at most) and examine your justification for doing so. There'll then be a detailed examination of a sample of the remaining controls, to check that you're actually implementing them as you say.

        Just like ISO 9000 in regard to quality, gaining ISO 27001 certification is not proof that you've achieved a certain level of security - it's that you have management systems in place that should allow your organisation to deliver the required or contracted level of security.

        [Disclaimer: I'm a 27001 consultant (how did you guess?) so this may not be completely unbiased. OTOH I'm freelance so will try to avoid the 'baffling the bastards with bullshit' that certain larger consultancies may occasionally indulge in.]

  4. Anonymous Coward
    Anonymous Coward

    She's doing a good job...

    Shares down 31.5%

    1. Anonymous Coward
      Anonymous Coward

      Re: She's doing a good job...

      Sadly its shares are down 31.5p NOT 31.5%. Its actually 12.5%.

      However there's always tomorrow.

  5. Anonymous Coward
    Anonymous Coward

    Maybe they did encrypt it....

    .... But left the key under the flowerpot by the front door.

  6. Anonymous Coward
    Anonymous Coward

    Change the law then?

    Surely with hacking becoming a common occurrence then the 1998 law should be changed so that ANY personal information MUST be encrypted?

    1. Anonymous Coward
      Anonymous Coward

      Re: Change the law then?

      A country that did that may potentially have opened itself to a future lawsuit for loss of profits, due to increased development costs or reduced sales opportunities within that country, if and when TPP takes effect.

      1. Doctor Syntax Silver badge

        Re: Change the law then?

        @A/C

        TPP stands for Trans-Pacific Partnership. I'm not sure which is the Pacific coast of the UK.

        1. BlartVersenwaldIII
          Black Helicopters

          Re: Change the law then?

          > I'm not sure which is the Pacific coast of the UK.

          Such details remain classified until the treaty is signed.

          1. Ben Tasker

            Re: Change the law then?

            >> I'm not sure which is the Pacific coast of the UK.

            >Such details remain classified until the treaty is signed.

            To reduce businesses advertising costs, the treaty will mandate that all countries relocate so that they have a pacific coast. That way all times can be advertised in PST. We also need to consider USD legal tender, and start understanding Jay Leno references.

            In reciprocation, we will be given the privilege of acquiring overpriced tat from US companies, with the bonus benefit of more US style reality TV gracing our screens.

        2. Anonymous Coward
          Anonymous Coward

          Re: Change the law then?

          What's in a name? Some believe the UK should join it.

          https://secure.marketwatch.com/story/why-the-uk-should-join-the-trans-pacific-partnership-2015-10-07

    2. Velv

      Re: Change the law then?

      Encryption only protects agains certain types of loss, and anyone with the right credentials can export the data. Taking "sufficient measures to protect data" therefore might include encryption, but requires other measures to also be implemented. Making encryption a legal requirement would make companies believe that's all they need to do.

      1. itzman

        Re: Encryption only protects agains certain types of loss (was Change the law then?)

        And SQL injection is one of those types of loss. It protects against the loss of raw database data.

        Unless the decryption is carried out, not by the application, but by the database itself, there is no way an SQL injection attack can reveal the plain text of encrypted data.

        Those that say in a silly hand wavy way that 'because the application can decrypt the data, and the attack used the application, therefore encryption is useless' betray an alarming depth of ignorance into how such applications and attacks work.

    3. Anonymous Coward
      Anonymous Coward

      Re: Change the law then?

      What must be encrypted?

  7. Commswonk

    Am I the only person who thinks...

    "Harry Enfield" when seeing some pictures of the Dear Leader?

    Perhaps it's the "Loadsamoney" association; well for now, anyway. But for how much longer...

    1. wolfetone Silver badge

      Re: Am I the only person who thinks...

      You mean Tim Nice But Dim surely?

      1. Commswonk

        Re: Am I the only person who thinks...

        Probably both, but not at the same time, and for different reasons.

  8. Bronek Kozicki

    Encryption wouldn't have helped. Since this was SQL injection attack, it must have been performed under credentials of the authorized web application, one which would have access to decrypted data. When talking about database encryption, it is usually the database file which is protected, but once an engine connects/attaches/opens it and starts sending queries, the data must be decrypted on the flight, usually at the filesystem level.

    Yes, SQL injection attacks are nasty, which is why I spoke about them on security conferences in the previous century. They are also easy to protect against, assuming the company has coherent IT strategy. Which, apparently, Talk Talk does not. And the last thing : it is CTO or CIO whose jobs should hang on balance here, not "chief security officer" (who cannot act against company's IT strategy) or CEO (who does not have a clue about technology and does not need to - if CIO is competent)

    1. Anonymous Coward
      Anonymous Coward

      it is CTO or CIO whose jobs should hang on balance here

      But isn't the CEO the person primarily responsible for hiring these other people? If they bring muppets in that jeopardize the company, then doesn't that say rather a lot about their competence as CEO.

      1. Bronek Kozicki

        Re: it is CTO or CIO whose jobs should hang on balance here

        I think there might be also board of directors involved at hiring at this level.

        1. Commswonk

          Re: it is CTO or CIO whose jobs should hang on balance here

          There is also the post of Data Controller to consider, although it would not necessarily require a "techie" to occupy the post; is not the Data Controller the person with overall responsibility for the proper management of the data held?

          I wonder if it was a situation where different people were squabbling over "who does what" (an old fashioned turf war) leaving the proper protection of the data to fall between the cracks.

    2. Bronek Kozicki

      ... and just to preempt comments : although it must be said that clueless CEO is a bit of a ... dummy.

    3. Anonymous Coward
      Anonymous Coward

      "not "chief security officer" (who cannot act against company's IT strategy)"

      The head of security should be able to veto a dangerous IT strategy in exactly the same way as a Chief Safety Officer can veto a factory process, irrespective of what the Chief Operations Officer, Production Manager or Board of Directors want to do.

      The Health & Safety Executive and associated legislation set all the precedents needed to deal with stuff like this decades ago - it just needs to be adopted.

    4. Anonymous Coward
      Anonymous Coward

      Re Bronek

      I agree with almost everything you put except this bit:

      And the last thing : it is CTO or CIO whose jobs should hang on balance here, not "chief security officer" (who cannot act against company's IT strategy) or CEO (who does not have a clue about technology and does not need to - if CIO is competent)

      If the Chief Security Officer is a C-Level Exec then surely it should be just as hard for the CTO/CIO to act against the companies security strategy as it would be for the CSO to act against the IT strategy?

      Part of the problem is when organisations make infosec subservient to CTO/CIO objectives. In these organisations there is no real Chief Security Officer.

      Also, the reality is any decisions which have led to this problem will have stemmed from every C-level exec. Budgets will have been set, goals established, risks taken. When the money comes in, every exec takes credit so now the monster has bitten, they all need to feel the pain.

      Senior execs often get praise for their "high risk" strategies when it generates profits, but risk always carries the chance of it going wrong. It has, so now they must make amends for years of underfunding security.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like