Category Archives: Security

Velocity Checking: One lesson everyone can learn from Tesco Bank

Like many credit and debit card acquirers, when Tesco Bank’s fraud system detects what it thinks is a fraudulent transaction on a cardholder’s account it sends the customer an SMS saying “please contact the bank”. It’s pretty obvious that it doesn’t have any sort of velocity checking on this function — which is why, on the weekend of 5-6 November, over 20,000 Tesco Bank customers received such a text message. Many reported spending a few hours on hold to the contact centre.

You can be sure that if you send out 20,000 SMS fraud alerts, a large percentage of those people will contact you — and Sunday morning is not when the contact centre is going to be fully staffed!

What went wrong

The fraud system should have not treated each fraudulent notification in isolation, but it should have also created a consolidated view across the entire system. As soon as the consolidated view noticed it had sent out an abnormal number of alerts in a 10-minute period then it should have:

  • Paused sending out alerts to customers
  • Sent an alert to the SOC saying “Help, I’ve seen fraud on 2,000 accounts in 10 minutes which is five times more than normal. I think we’re under attack and can you get more people in the call centre for tomorrow morning?”

Of course – the system could also have been clever enough to notice that all these alerts were caused by the same sort of abnormal transaction (in this case magnetic stripe contactless debit card transactions from outside of the UK) and the system could have also set this transaction type to auto-decline. This would have perhaps had the benefit of stopping the fraud continuing.

Lessons for everyone

It’s not uncommon for developers to think of a problem in isolation: “if X happens then assume this account is being attacked so do Y” but developers should also think of the system-wide view. There must be something in a system to address the question “is it just one account that’s being attacked, or is this part of a systemic attack?” Fixing this can be as simple as writing to a log that another process is monitoring — looking for patterns and abnormal velocities — which can then follow its own business rules to detect and respond to systemic attacks.

We can all learn this one lesson from Tesco Bank: think systemically. If you have a system that sends SMSs to customers asking them to call you, or something that locks accounts after ‘n’ bad attempts, how would your organisation respond if 20,000 people tried to call you at the same time?

Consider the OWASP AppSensor

There’s some great thinking about how to get applications to think on a system-wide basis in the OWASP AppSensor project.

Was Tesco Bank hacked?

I’ve read some pretty amazing articles and blogs in the last week that show quite a misunderstanding about how criminals steal money, how payments work and how the new General Data Protection Regulation would both punish Tesco Bank and simultaneously remedy all ills. Cyber security and financial crime is a complex subject and I thought I’d try to look at whether (or how) Tesco Bank was “hacked” a couple of weeks ago.

The short tl;dr version is:

  • No, I don’t think Tesco Bank was hacked – but I think someone else that has lots of Tesco Bank debit card numbers has suffered a breach of confidentiality.
  • Tesco Bank had a problem with how it authorised Magnetic-Stripe-Contactless transactions. That problem could have been misconfiguration, programming error or criminal control of the authorisation system.


If you’re interested in the long version …

I’m going to start with a quick review of the way that money can be taken from current accounts.

1. How criminals steal money from current accounts

Ignoring kinetic / analogue methods, there are two conceptual main ways for a criminal to extract money from customers’ current accounts:

  1. Push transactions – where the funds are pushed from the customer’s account to the criminal’s
  2. Pull transactions – where fund are pulled from the customer’s account.

1.1 Push Transactions

  1. The criminal can compromise the bank’s internal systems, and transfer money directly from multiple customer accounts to accounts owned by the criminals via faster payments / BACS.
  2. The criminal can gain access to the customer’s online banking credentials and then login to online banking, masquerading as the customer and initiate money transfers (faster payments/BACS) or standing orders to accounts owned by the criminals. Criminals can gain access to these credentials either by:
    1. Compromising the bank’s internal systems
    2. Tricking the customer into downloading / installing malware onto their machine which captures the banking details (or manipulates transactions within the browser) – e.g. the Zeus, Panda and Dyre banking trojans.
    3. Sending phishing emails to customers to encourage the customer to divulge their credentials to the criminal
    4. Where banks use simple authentication methods to manage login such as simple ID and password, criminals could re-use IDs and passwords captured from other sites.
  3. Compromising the bank’s webserver and deliver rogue JavaScript to the customer’s browser included in the online banking web page. The criminal JavaScript can then act as a browser-based key- or form-field logger.

1.2 Pull Transactions

  1. The criminal can submit false direct debit instructions.
  2. Where customers have a debit card associated with a current account the criminal can submit a false debit card transaction to the bank. This allows the criminal to get cash, or goods which they then can resell for cash. This transaction could be one of eight types.
    1. A magnetic stripe transaction with PIN to withdraw cash from a non-chip enabled ATM
    2. A magnetic stripe transaction without PIN to purchase physical goods (that the criminal can resell to get cash) from a retailer (in a non-chip and PIN region)
    3. A magnetic stripe equivalent contactless transaction in pre-chip markets (such as the USA)
    4. A Chip and PIN transaction to withdraw cash from an ATM using the cardholder’s card
    5. A Chip and PIN transaction to purchase physical goods from a merchant using the cardholder’s card.
    6. A chip-based contactless transaction (as used in Europe)
    7. An online, e-commerce transaction to purchase physical or digital goods from a retailer
    8. An on-line e-commerce transaction to top up a pre-paid card or pay off a credit card balance – effectively using the debit card to transfer cash to another type of account.

2. What we know

Tesco Bank has reported that about 9,000 accounts were affected and that £2.5 million had been taken from current account customers.

In the immediate aftermath on the morning of Monday 7 November the Bank initially suggested that 20,000 accounts were affected, and that it had stopped potentially fraudulent transactions on 20,000 more.

2.1 What transactions were blocked?

The Bank has been very careful not to use the word hacked. Initially the Chief Executive used the phrase “a systematic, sophisticated attack” and on the Bank’s update page it answers the question

    “Should I change all of my online banking and personal details that you hold?”

with this:

“Tesco Bank has not been subject to a security compromise and it is not necessary for customers to change their login or password details.”

This statement rules out Push methods 1,2 and 3 above as if the online banking system or Tesco Bank’s systems that control this had been compromised, users would have been forced to change their credentials.

Looking at both Tesco Bank’s own online forums and those of Money Saving Expert , it is possible to conclude that the “sophisticated attack” was a pull-type attack using debit cards. The following posts are from Tesco Bank representatives (with my emphasis) on the Tesco Bank community forum:

“Yesterday evening, we identified some suspicious activity in a small proportion of our customer’s current accounts. We have taken steps to protect these account holders and are contacting affected customers by text message. We can reassure our customers that they will not lose out as a result.

All of our customers can continue to access their accounts through online banking and can make chip and pin transactions.”

“We have taken the decision today to temporarily stop online transactions from current accounts. This will only affect current account customers. While online transactions will not be available, current account customers will still be able to use their cards for cash withdrawals, chip and pin payments, and all existing bill payments and direct debits will continue as normal.”

“Hi @TescoBank, does the section above refer to online card payments to retailers, or to Faster Payments I want to make from my account online, or both?
Hi @xxxxx, this refers to online payments to retailers. You should be able to make a Faster Payment as normal from your account by logging into online banking.”

“Hi @xxx, your card has been cancelled but rather than place a full block on the account you are still able to use the card at an ATM and for chip and pin transactions. You’ll be unable to process contactless or online transactions.”

“If you’ve received this text then we will need to have a new card issued to you. Whilst you’re waiting on this you should still be able to use your current card for chip and pin and ATM transactions but not online or contactless ones. Please continue to monitor your account over the next 7 – 10 working days for any suspicious activity and if you notice anything please get in touch.”

These statements rule out the pull method 1 and pull methods using chip-based debit card transactions described above although there is an apparent inconsistency in allowing chip and PIN but blocking a contactless transaction (as contactless in the UK uses the chip as part of the transaction).

2.2 Unused cards compromised?

Additionally a number of customers complained about debit card transactions using cards that had “never been used” (it seems from forum posts that a number of people used their account as a savings vehicle rather than a traditional current account, given the 3% interest paid).

“I have not used this card in a card machine or used it online”

“Given that both myself and my daughter received the suspicious activity text message for cards which arrived in sealed envelopes and have NEVER BEEN USED there is no doubt that Tesco security is sadly lacking.”

“I received both text messages however, what concerns me more is the fact I’ve never used my Tesco Bank card (online, in-store etc). It is still attached to the welcome letter.”

“I have never used any of my cards at any time and never ever done an online transaction using this account, it’s been purely used as a savings vehicle.”

2.3 Contactless fraud report

On the 13th November, the Sunday Times (and Sun) reported that:

“The money was stolen from Tesco Bank accounts by a criminal gang purchasing thousands of low-priced goods using contactless mobile phone payments at retailers in the US and Brazil, including Best Buy.”

So it appears that there have been fraudulent online debit card transactions (and if the Times story is true, contactless debit card transactions) attempted against somewhere between 9,000 and 40,000 Tesco Bank accounts, which were successful against 9,000 accounts. Given the amounts that have been quoted in the forums by account holders (£20.63, £9.33, £827.30, £533.00, £549.31, £28.50 etc) these were not fraudulent ATM transactions as the amounts reported do not appear to translate to round-number values (in GBP or USD), so the transactions look like they happened in a retail environment.

3. Ways to make fraudulent debit card transactions

To make a fraudulent e-commerce retail transaction a criminal would need a combination of the customer’s debit card number (the 16-digit primary account number or PAN), the card holder name, card expiration date and CVV2 security code I say ‘a combination’ because it depends on how much information Tesco Bank requires to authorise a transaction, and how much information the merchant captures at an e-commerce sale.

It is also possible to use the debit card number, expiration date and CVV2 in a normal merchant terminal if the data is keyed into the system using the keypad in a face-to-face environment such as a store (normally used when the chip/mag stripe fails or to process a mail-order/telephone order transaction).

3.1 The contactless conundrum

It’s interesting that both the Times and Tesco Bank themselves mentioned contactless. I was confused when the post on Tesco’s online form said “you should still be able to use your current card for chip and pin and ATM transactions but not online or contactless ones” because in the UK a contactless transaction uses the same security as Chip and PIN; the contactless transaction uses the chip which actually digitally signs the transaction, making fraud really hard because you can’t just steal data and make a clone chip card.

However, the Times reports that the fraudulent transactions occurred in the US and were reported as “contactless mobile phone payments”. If this is true (and I’ve not been able to verify this from a second source) it narrows down the way that the criminals worked because Tesco Bank does not support the two common ways of making contactless debit card transactions: ApplePay and AndroidPay for its Visa debit cards (only ApplePay is supported on the Tesco Bank MasterCard credit card). Given the way that cards are loaded into ApplePay and Android pay, that’s not something the criminals can forge (as far as I am aware) because it requires the active participation of the issuing bank. So if the Times is correct then here’s what I suspect has happened.

In the US a technology was developed called LoopPay (https://www.looppay.com/) which used an electromagnetic field to make an old-fashioned magnetic stripe transaction on a non-contactless terminal. The consumer ‘loaded’ their card details into LoopPay and it could be used with any magnetic-stripe reading terminal by just holding the device near the terminal. The LoopPay system generated an electromagnetic field to ‘give’ the data that would be on the magnetic stripe to the old-fashioned card reader.

This technology was bought by Samsung and the hardware to generate the magnetic field is built into the latest Samsung phones. Although using the Tesco Bank debit card is not officially supported by SamsungPay, it would be possible for a criminal to have used the technology to just load Tesco Bank card details into a Samsung phone by writing their own software. When I worked at Visa Europe we were very sceptical about this technology because it doesn’t allow the merchant to validate the signature and all the security features on the physical card (there’s a reason the whole industry spent fortunes on holograms to stop people making fake cards). So that’s one option if mobile phones were used – I’m going to call this ‘electromagnetic magnetic stripe emulation’ or EMSE.

There’s also another possibility: in the US there’s an old-fashioned sort of contactless transaction that pretends to be a magnetic stripe, it was developed before the chip (EMV) version of contactless which is what we use in Europe was deployed. It isn’t as secure as the chip version and wasn’t widely supported in the US – but it could also be that the criminals worked out how to load a Tesco Bank card into an Android phone which emulated the US Magnetic Stripe Contactless (MSC) type of transaction. If the Times story is true then my instinct is that the attack would have used either EMSE or MSC.

Even then the criminal would need more than just the card number – there’s a secret card verification value (CVV) encoded on the magnetic stripe alongside the account number that the card issuer (i.e. Tesco Bank) should validate when it approves a magnetic stripe transaction.

4. Two key questions

There are two key questions to be answered:

  1. Where did the criminals get the data from that they used to make fraudulent debit card transactions?
  2. How did they make those transactions in a way that they would be authorised by Tesco bank, and not identified as fraudulent transactions and rejected?

4.1 Data

Firstly then as there were fraudulent transactions made against (let’s say) 20,000 Tesco Bank current accounts – where did the criminals get the card data from?

There are six possible options:

  1. They stole it from another online retailer.
    I’m going to suggest this as the least favourite option because the attack was just against a Tesco Bank. If the criminals stole this much debit card data from another retailer, then lots of banks would have been attacked, because if the criminal got the details of 20,000 accounts out of Tesco Bank’s 130,000 accounts it means they have lots more HSBC, Lloyds and Barclays to use. And given that Tesco Bank only has 130,000 accounts out of a UK population of around 30 million debit cards, the only place that a criminal would be able to get say 20,000 would be a retailer taking something like 90 million card payments a year. Of course this could have happened, and the criminals only targeted Tesco Bank, or every bank was targeted and only Tesco Bank had a ‘problem’ with how it authorised transactions. But if this were the case I think we’d have heard about it. If this has happened, there’s a very big data breach from a retailer hiding in the wings.
  2. They aggregated it from lots of other online breaches over the past few months because they were particularly targeting Tesco Bank as they were aware it had a problem with how it authorised online/magnetic stripe transactions and so would provide a way of extracting cash that they couldn’t do from the other UK banks. Again, because of the small number of Tesco Bank cards in circulation, this seems to be unlikely.
  3. They obtained the card data from on-line banking attacks against the customers through phishing or malware on the customer’s machine. Tesco Bank was the subject of several high-volume phishing attacks earlier this year. However this is unlikely given that the Bank has made the assertion that customers need not change their passwords.
  4. They stole it from Tesco Bank.
    I’m going to suggest this is unlikely. Given that the public statement that “Tesco Bank has not been subject to a security compromise” and given the way that the Bank handled its press incident response this week, I’d be astounded if the bank was lying about this and would risk the enhanced regulatory wrath that a deliberately misleading public statement would generate.
  5. They stole it from another part of the Tesco group (such as Clubcard accounts) that has access to Tesco Bank debit card numbers or Tesco retail stores where Tesco Bank debit cards would be more highly utilized.
  6. They stole it from a third party — such as the company that made the cards or one of the third-party processors that Tesco Bank uses. This is not impossible as it is well-known that Tesco Bank outsources many of its core banking systems. But again I come back to Tesco Bank’s own statement that the bank hasn’t been subject to a security compromise and again I’d be surprised, given how closely the regulator will look at this incident, if this was weasel-speak to cover up a third party breach. I’m also aware of the security audits (from Visa etc) that the card manufacture and personalisation companies have to go through and I’m going to say this is an outside possibility.

Made up random card numbers?
There’s also another (improbable) option, that the criminals didn’t steal the debit card data, they just made Tesco Bank debit card numbers up at random, and tried them!

The numbers of all Tesco Bank debit cards will start with the same first six digits – this is known as the Bank Identification Number or BIN. For an example let’s assume this is 468738 – the criminal could guess a valid card number would be 4687 3800 0000 0008 (because of the way the checksum works with card numbers, this is the first valid card number that would begin with 4387 38 – the next one is 4687 3800 0000 0016). So the criminal can generate many thousands of valid card numbers and perhaps this technique — combined with some aggregated data from other cards to help them narrow the range of cards down — would give them data that they could use to try to get transactions authorised.

This is relatively unlikely (moreover it isn’t a very “sophisticated” attack), but until we know more it must be considered a theoretically feasible attack. However, given the comments in the Times suggesting that the fraudulent transactions happened in retail stores, an attack based on generating ‘random’ valid card numbers seems highly unlikely because the chance of success of randomly generating a valid issued card number is so low, a criminal wouldn’t waste this on a cash-out-mule who puts themselves at some degree of risk by making an in-store physical transaction.

4.2 Authorisation

The Tesco Bank authorisation systems authorised transactions that they shouldn’t have. There are a few reasons this may have been so.

  1. They were not set up to properly validate the CVV2 value for an e-commerce transaction.
  2. They were not set up to properly validate the CVV for a magnetic stripe transaction.
  3. They had never been configured to recognise a magnetic-stripe-contactless transaction and so these transactions bypassed the normal authorisation route.
  4. A criminal had gained unauthorised access to the debit card authorisation system and had re-configured it to permit rather than decline these type of transactions.

5. My Hypothesis

My best guess at the moment is that the criminals secured a large batch of real Tesco Bank debit card numbers; I think it’s most probable that it came from a leak from a third party or related company. Given the number of cards used, a merchant breach (or an aggregation a number of previous breaches from merchants) seems unlikely. Additionally this does not correlate with the customers’ claims not to have ever used their cards on the Bank’s forum.

The criminals then used this data to make online and physical electromagnetic magnetic stripe emulation contactless or the US magnetic stripe contactless transactions.

But remember both a magnetic stripe transaction and an e-commerce transaction generally need more than just the account number for the transaction to complete. The magnetic stripe contactless needs the card verification value (CVV) which is encoded in the magnetic stripe and the e-commerce transaction the card verification value 2 (CVV2) which is normally printed on the reverse of the card. This data is transmitted along with the account number and expiration date to the card issuer (in the case Tesco Bank) so it can validate that the real card has been used.

So either

  • the data for the CVV and CVV2 came from the third party that would have had both the account number and these numbers – which could only be one of just a couple of Tesco Bank’s core outsourcing partners; OR
  • Tesco Bank didn’t recognise the ‘magnetic stripe contactless’ transaction type and therefore did not validate the CVV when the Bank authorised the transaction, and the criminals just submitted ‘random’ CVV values.

Given that it is currently reported that both fraudulent Magnetic Stripe and E-commerce transactions were made the only place a criminal could have got the data elements to make both those types of transaction (account number, CVV from the mag stripe and CVV2 from the back of the card) would be one of the Bank’s core processors (either the company that personalised the debit cards, or the company that authorises transactions). I’m really sceptical of a data breach at one of these two core processors (although it would be William of Occam’s preferred explanation).

My guess is that the authorisation systems at Tesco Bank, which should have spotted that these transactions were fraudulent, were either misconfigured, or were in the control of a criminal and therefore didn’t validate the CVV or CVV2 values when faced with a ‘magnetic-stripe-contactless’ transaction.

6. What action might be taken against Tesco Bank?

Some commentators have suggested that the Information Commissioner’s Office, through the Data Protection Act (and its successor the General Data Protect Regulation) would have cause to take action against Tesco Bank. The ICO is the least of Tesco Bank’s worries – even if there was a contributory breach at a third party service provider to Tesco Bank. The Bank is regulated by the Financial Conduct Authority and the Prudential Regulatory Authority (part of the Bank of England). Both bodies have the capabilities to levy unlimited fines, replace management and — in the worst case — remove Tesco’s banking license. The FCA and BoE do not like to see bank security problems on the front page of a newspaper — they are concerned about the effect that this has on the general public’s trust in the banking system. If it turns out that the fraud was enabled by a misconfiguration or criminal attack on Tesco Bank’s debit card transaction authorisation system, then their financial regulator will question whether the Bank had adequate systems and controls in place to prevent financial crime and will take the appropriate action.

Additionally, as the fraud was committed on Visa debit cards, I assume my ex-colleagues in Visa Europe will have some strong words with Tesco Bank!

Notes and sources

I’ve prepared this analysis from public news reports, statements from Tesco Bank and from information in public forums found on the Internet. My good friend and ex-colleague, Colin Whittaker of Informed Risk Decisions, helped with the analysis of the possible options.

Webcast on Thursday 11th August

On Thursday 11th August at 6pm London (or 10am if you’re in San Francisco) I’ll be giving a webcast of my popular RSA Conference presentation, “How to Explain Cybersecurity to the Board Using the Simple Metaphor of fire”. You can register here:

https://www.rsaconference.com/videos/webcast-how-to-explain-cybersecurity-to-the-board-using-a-simple-metaphor-fire

I presented this on the first day of RSA Conference in February and I assumed that because it was the Monday before the conference proper started not many people would come. I was really wrong. The room was full and I understand some people couldn’t get in. Some of the feedback I had afterwards included:

Speaker provided clear and constructive recommendations to facilitate discussion of technical subjects with non-subject matter experts. Very enjoyable.

This was a fantastic presentation and provided a great insight on a different way of thinking about presenting security with a publicly recognizable twist. Will definitely use his analogies in the future.

So if you’d like to find a simple way to explain some of the cyber security principles to colleagues and your C-suite this webcast may be useful. If you can’t attend in real-time I understand that a recording will appear on the RSA Conference website afterwards.

Is your employees’ privacy one of the first casualties in the battle to secure your information systems?

I’m speaking about the trade off between network security and employee privacy at the International Association of Privacy Professionals (IAPP) European Data Protection Congress in Brussels on the 2nd December.

In the face of modern cyber-threats, communication monitoring and surveillance are essential for the protection of corporate information. But monitoring technology is often intrusive of the privacy of system users and, ironically, the capabilities of modern cyber-solutions can bring increasing privacy risks for system users. What are the threats to user privacy of IT monitoring and surveillance tools that allow network communications to be retained for subsequent analysis and replay? What are the legitimate expectations of privacy in the workplace? How can the tensions be reconciled? Here, we will examine the threats presented to the privacy of system users by latest-generation monitoring technologies. We will explore the challenges involved in reconciling the need for robust system security with legal obligations to respect the privacy of system users. We will also consider strategies for managing these challenges and associated legal risks, including PIA and security risk assessments.

What you’ll take away:

  • An understanding of the privacy risks posed by latest-generation monitoring technologies.
  • Strategies for minimising privacy risks, including an appreciation of the role of consent in programmes of workplace surveillance both now and under the draft GDPR.

I’m really pleased to be co-presenting with Heledd Lloyd-Jones, a specialist privacy lawyer with Bird & Bird. Heledd sparked my interest in the intersection of privacy and information security seven years ago when I attended her brilliant ISEB Protection training course.

There are lots of other really interesting sessions at the conference, I’m really looking forward to The Ten Million Dollar Question: Managing Privacy Risks in Your Supply Chain and Cloud Privacy: How Do International Certification Standards Fit with the Proposed EU Regulation?

Registration for the conference is open now.

The future of privacy talk at ORG


Bruce Schneier spoke on the subject of The Future of Privacy at the Open Rights Group on Friday. The ORG is the ‘UK equivalent’ of the EFF and I’m proud to be one of its founder members. I’ve heard Bruce speak a few times, most recently at WEIS 09, and I’ve always been impressed at his relaxed presentation style. This was a great event and ORG will be posting has posted a video of the event on its web site. I’d recommend watching the both the presentation and the Q&A afterwards.

UPDATED: Here are the links to the presentation and the Q&A.

A few highlights (with comments):

  • In relation to large government databases, built to facilitate data mining techniques for suspicious activities, Bruce commented that if you’re looking for a needle in a haystack, it doesn’t seem very sensible to add more hay!
  • On CCTV he posited that we’re living in a unique time. Ten years ago there were no cameras, now there are hundreds of cameras and we can see them all, in ten year’s time there will be many hundreds of cameras, but we won’t be able to see any of them.
  • When ‘life recorders’ become widely used (and they’d only need about 1TB a year to record your entire life) he could see that not having an active life recorder would be seen as suspicious — much like leaving or turning off your mobile phone is now presented as “evidence” that you were up to no good.
  • Ephemeral conversation is dying.
  • The real dichotomy is not security v privacy, but liberty v control. He argued that privacy increases power, and openness decreases power. So citizens need privacy and governments need to be open for a balanced democracy to prosper.
  • The death of privacy has been predicted for centuries (for instance, see Warren and Brandeis’ The Right to Privacy published in 1890). Without a doubt privacy is changing and this is a natural process — but it isn’t inevitable. Our challenge is to either accept this, or to reset the balance between privacy and the mass of identity-based data gathered for commercial gain and state security. Laws are the prime way to reset that balance.
  • When asked the one thing he’d like to change, he replied it would be to implement European style data protection legislation (like our own Data Protection Act) in the US.

New data security law book launched

On Monday I had the pleasure of attending the launch of Stewart Room’s new book ‘Butterworths Data Security Law and Practice’. Stewart wrote the definitive guide to the Data Protection Act for techies, the equally snappily-named Data Protection and Compliance in Context. This is also the course book for the ISEB Practitioner-level certificate in Data Protection.

Stewart’s new book is – as he admitted – elephantine in its size and coverage  (for comparison it’s physically larger than Ross Anderson’s Security Engineering). It is the first book that addresses infosec and law and I’m really looking forward to getting hold of a copy. I had a chance to browse one of the display copies at the launch and it looks really useful.

With probably about a hundred infosec and law professionals in the same room the conversations were really engaging. There was a lot of talk about the prominence of breaches in the news, especially after last week’s T-Mobile revelations along with the ongoing consultation on the Information Commissioner’s new powers. A few of the people I spoke to were curious to see what changes there would be in non-financial services companies once the Commissioner had levied his first sizable fine.

Yet another meaning for C, I and A

Yesterday I heard Andy Smith, the Chief Security Architect for the Identity and Passport Service (IPS) speak at the BCS Central London branch meeting about the security behind the new National Identity Register which supports the National Identity Card.

On one slide he highlighted what he considered the three biggest threats to Information Security:

  • Complacency
  • Apathy
  • Inattention (Andy called it Human Error, but I hope he’ll excuse my re-wording to fit into the familiar triad)

So now there’s three security meanings for C, I and A.

  1. Confidentiality, Integrity and Availability : The original
  2. Common Sense, Intent and Application : Plan on doing sensible things well, and keep doing them
  3. Complacency, Inattention and Apathy : It is really hard for humans to do security things 100% of the time

Andy’s presentation was really interesting and I’m glad to have had the opportunity of hearing his views, but in my view the session failed to address the publicised topic of “ID Cards: The end of the Private Citizen – or good corporate ID management?” There wasn’t a speaker to address whether this was the “end of the Private Citizen” and questioners were discouraged from being “too political”. As IT professionals it is really important we participate in the debate about state-wide databases and the consequences of insecurity and secondary uses. That’s not a political discussion, but a socio-technical discussion about the future application of technology. The UK chapter of the ISSA held a similar event in July this year which included former home secretary David Blunkett, a speaker from the Home Office, Pete Bradwell from Demos along side many technical presentations. Perhaps it was the table I was sat on but our discussion ranged widely through technology, security and ethical issues.

At last night’s BCS event I’d have like to have heard Andy talk more about the technical details of how his team resolved some of the many interesting challenges they will have faced over the past few year, especially the architectural solutions and processes devised to maintain separation of duties within the IPS.

As a root identity provider the ID card and the NIR are attractive, however I can’t help thinking of Bruce Schneier’s 2007 essay on The Risks of Data Reuse which ended:

“History will record what we, here in the early decades of the information age, did to foster freedom, liberty and democracy. Did we build information technologies that protected people’s freedoms even during times when society tried to subvert them? Or did we build technologies that could easily be modified to watch and control? It’s bad civic hygiene to build an infrastructure that can be used to facilitate a police state.”

The Other C, I and A of Information Security

Ask anyone who works in Information Security what the initials CIA mean and they will say “Confidentiality, Integrity and Availability”. These are the three measures used to assess the impact that an unwelcome event would have on an asset.

When I train people, I talk about another more important Information Security meaning of CIA: Common Sense, Intent and Application.

Common Sense

Good Information Security requires everyone to use their common sense. Have you ever wondered why some people have common sense and others do not? Why some users remember strong passwords, and others would think it is OK to use their cat’s name and then write it down on a post-it?

This common-sense-imbalance used to worry me until the day I heard Ira Winkler give a presentation where he argued that “there’s no common sense without common knowledge” and you know, he’s absolutely right.

When users (and sometimes security professionals) do something that’s as far from common sense as can be, I’ve found it’s generally because we don’t share a common knowledge. For instance:

I know it is wrong to write your password down because it allows someone to easily logon to a system and perhaps do bad things while pretending to be you – that’s common sense:
they don’t understand why anyone would ever want to do this.

I know that writing the password to an encrypted file on the CD holding the file devalues the encryption – that’s common sense:
they don’t understand why the data needed to be encrypted in the first place and what encryption means, and decided that the password was less likely to get lost if they wrote it on the CD.

In Information Security we are all guilty of assuming that everyone understands threats and vulnerabilities in the same way that we do; but they don’t, which is why their common sense doesn’t match ours. To develop an instinct for good common sense, you need common knowledge – which means proper education for your users and for the whole of your Information Security team.

Intent

My dad used to have a phrase that really annoyed me when I was a kid. He’d say “If a job’s worth doing it’s worth doing well”—especially when my homework came back with C grades. I’m reminded of this whenever people talk about doing projects or initiatives in Information Security.

My experience is that it is a waste of time to be half-hearted about security. Worse still, it can have the opposite effect to the one you intended.

Take any simple control that’s documented in a process or a policy. If people see it’s not enforced, or has a variable implementation based on someone’s position in the organisation chart, then it sends the message that all controls are optional.

It is better to do a few things well, than lots of things poorly.

Implement security with a positive intent to do it well. If you know you’re going to make a half-baked attempt at a project, pick a simpler project you know you’ll do well.

Application

Much in of what we do in Information Security is dull. Checking, maintaining, documenting, cleaning, auditing, testing – just making sure that what needs to be done is done and done well.

My observation is that people – and especially technical people – get more excited about playing with new things than they do about keeping the old things going. Sure, they might not describe it as ‘playing’ and use works like ‘evaluating’, ‘installing’ or ‘configuring’ but at the end of the day it is the challenge and excitement of learning the new that excites them.

Good security though isn’t always about the new. It’s about doing the tedious stuff well and paying attention to it. It is about:

  • Checking the logs on a regular basis
  • Making sure that the roles defined in the role-based access are correct
  • Doing the lessons learned from an incident and following up the action points until they’re all completed
  • Updating the DR documentation when you change a server configuration
  • Cleaning the backup tape heads and verifying the backup worked properly
  • Filling out the visitor book for the server room
  • Writing the documentation for X before moving on to Y
  • Chasing the last person who didn’t complete the Data Protection training course

It takes application from everyone in the team to keep on top of these and hundreds of other little tasks. It takes application from management to make sure it happens.

So there you have it. My alternative exposition of the CIA triad:

Common Sense: Invest in the security education of users and the IT team

Intent: Plan on doing each security project or initiative well

Application: Keep doing  the dull things