Risky Thinking
August 2015
Michael Z. Bell
www.RiskyThinking.com

Risky Thinking is a free newsletter providing essays, analysis, insights, and oddities related to Business Continuity, Disaster Recovery, and Risk Management.

To subscribe, visit: http://www.RiskyThinking.com/newsletter/

For more information and articles, visit the RiskyThinking website at
http://www.RiskyThinking.com/.


In This Issue
  • Why hotels are dangerous in Business Continuity Plans
  • Business Continuity Plan Review
  • 2015: The Year of the Data Breach
  • Does Everyone Know What to Do in an Emergency?
  • News: Hurricanes, Fire, Flood and Power
  • Risk Assessment Toolkit
  • Administrivia, Subscribing and Unsubscribing

Why Hotels are Dangerous in Business Continuity Plans

If you've reviewed a few business continuity plans, you may have noticed how often teams are expected to assemble and work from a nearby hotel. Here's why that may not be a good idea.

It's sounds easy, doesn't it.

In the event of an incident rendering the building unusable, the Customer Service team will rent rooms at the nearby Main Street Hotel to continue working. They will plug their laptops into the hotel's internet connection to continue operations using the cloud server, and use soft VoIP phones and headsets to handle incoming and outgoing customer calls.

This plan has the merit of being very cheap. We just have to equip our Customer Service team with laptops. headsets, and soft phones, and give them a credit card to make a hotel reservation. Just to be on the safe side, we could even set up a credit account with the hotel so the credit cards aren't needed.

However, it's a plan which is quite likely to fail. Let's look at the reasons why:

  • The disaster has to be just the right size. It has to be just big enough to render our building unusable. Any smaller, and we can just relocate the team to an alternate room. Too big, and any other companies affected with the same idea will also try and book their staff into the same hotel. There might be enough room, but there might not.
  • It assumes that the hotel will remain in operation. Depending upon how far away the hotel is, it may also be evacuated or closed down. Think earthquakes, major storms, area flooding,and widespread power outages.
  • If the local transport system is shut down, (e.g. due to a major storm), staff may not be able to reach the hotel.
  • If any substantial number of people require temporary accommodation after an incident, emergency services may requisition the hotel for emergency use.
  • Depending upon the design of the hotel, there may or may not be enough suitable desks and seats for everyone to use.
  • Hotel networks typically aren't designed with intensive business use in mind. They are designed to let hotel guests check email and watch YouTube videos. They are therefore typically under-provisioned for intensive use. They aren't designed to provide the low-jitter needed for a voice-over-IP connection, nor are they designed to prioritize more urgent traffic. If a large number of guests are "trapped" in the hotel with little to do, the network performance is likely to drop significantly. The result will be unusable voice connections and very slow computer response.

Equipping Customer Service teams with laptops, headsets, and soft phones is a good idea. Giving them a laptop and headset which they can use from home if they can't make it into the office is also a good idea. But assuming that they will all be able to relocate to a nearby hotel in an emergency is just wishful thinking.


Business Continuity Plan Review

It's often difficult to see your Business Continuity / Disaster Recovery Plans from a different perspective. Is it realistic? Does it miss something obvious? An external pair of eyes can often see problems or solutions which you can't.

We can provide you with an external review of your business continuity plan. We will review documentation, interview key staff, and prepare a confidential written report identifying the strengths and any weaknesses we can see in your current plan.

Contact us for further details
http://www.RiskyThinking.com/


2015: The Year of the Data Breach

I don't know who coined the term "data breach", but the vision of data leaking from a company like water from a burst dam seems particularly appropriate this year.

Some notable recent data breaches have included:

  • Ashley Madison / Avid Life Media. If you run a service to assist cheating spouses, confidentiality has to be the name of the game.
    It's not clear whether any customer data was stolen, but enough data about the internal operations was leaked to suggest that customer data was insecure and to cause the company serious problems. The motivation appears to have been blackmail of Avid Life Media, with threats to release customer data unless the company shuts down various websites. It's been suggested (without any evidence) that this may have been an inside job, but personally I would be looking for a betrayed spouse.
  • Office of Personnel Management. In two "separate but related incidents" (if that's indeed possible), personnel data on 4.2 million current and former federal government employees was stolen, as well as background investigation records of about 20 million current, former, and prospective government employees and contractors. It has been suggested that this may have been the work of Chinese military intelligence.
  • LastPass. The maker of widely used password manager, had the email addresses and lost password questions of its customers stolen. Although user passwords were not apparently stolen, the combination of email address and possible password reset question answers might be useful in penetrating other systems.
  • mSpy. A mobile spyware maker, its database of email addresses and passwords was stolen, among "hundreds of gigabytes of data". Discussion on darknet forums suggest that the stolen login credentials may be used to hijack accounts where naive users have re-used their passwords.
  • Trump Hotels, Hershey Park, Sally Beauthy, Harbtouch plus many others. Credit and debit card data stolen from point of sale transactions. The data was / is being used to make fraudulent online purchases, or to create fake credit cards for offline fraud.
  • Hacking Team. The spyware company's source code, customer list, emails, and other information were made available on the internet. The information revealed contracts with some questionable regimes, deals to buy software vulnerabilities, usernames, passwords, etc. It allowed software vendors to plug the security holes being exploited by its products and anti-virus companies to build detectors for its spyware.
  • Gamma International. The spyware company's source code, and some 40GBytes of internal documents were published on the internet. This enabled detection of its FinFisher spyware, as well as identification of some of its less savory customers.
  • ICANN. This non-profit company which is ultimately responsible for the domain name system (that's the mapping of names such as www.example.com onto IP addresses) and is effectively the domain registrar's registrar. It lost a set of email addresses and hashed passwords for domain registrars.
  • Saudi Aramco. Although the attack is quite old, some details are only now being published. The politically motivated attackers succeeded in wiping the disk drives of 35,000 computers.

When examining the risks of deliberate (as opposed to accidental) incidents, we need to look at the motivations of potential perpetrators. These can give us both an idea of the type of attacks to expect and the amount of effort a potential attacker may go to in order to extract data. It also gives us an idea of what the attacker might do with the data and the harm it may cause. If we examine the incidents above, the motivations seem to fall into a number of categories:

Money

Attackers with this objective are mostly interested in directly monetizing the data they can steal. A primary objective here is frequently the theft of large numbers of credit card details. These will typically be resold for cash on the black market: others will use them to make fraudulent purchases.

Also of value to this type of attacker is the collection of the personal information needed to impersonate someone. Once again there is a black market for the data: the attacker will typically resell the data to others who will use it to fraudulently apply for loans and credit.

On a different scale, there may also be targeted attacks against individuals in a company with access to banking and payment systems: the company's bank accounts can be drained with fraudulent transfers, employees added to a payroll, or suppliers paid for non-existent deliveries. Any fraud which could be committed by an insider may also be possible by an outsider with stolen credentials.

Means to an End

Even if the only IT in our company is a website devoted to the exchange of knitting patterns, we may be at significant risk of attack, although the victims are likely to be our customers or clients. Password re-use is common by naive system users. This means that Jane's knitting site password may also be her banking password, her PayPal password, and her Google play store password. While our company may not lose directly if this data is stolen, it can quickly lose reputation and customers. There are simple encryption techniques which can be used to minimize the value of this sort of data if it is stolen: even if all you own is a list of the login credentials of knitting enthusiasts, it is important that they be applied.

Stolen credentials can also be a target. Some of the recent attacks on corporate point of sales systems were enabled by first attacking contractors and vendors who had legitimate access to the target network. Once inside a company's network, attackers can launch attacks as privileged insiders rather than outsiders.

Another class of means to an end attack, is the "watering hole" attack. If you want to steal credentials from bank managers, why not attack a company with a large number of bank managers as customers? Attack or control places where your targets hang out, and attack them from a direction that they may assume is safe.

Whistleblowing and Hacktivisim

If your company is doing things that some people find morally repugnant, then it may be the target of whistleblowing (from inside) or hacktivism (from outside). The objective here is to expose the corporate behavior to the wider world. Targets here may include email messages, customer records, meeting minutes, etc. Whereas a single document may be dismissed as a forgery or a lapse of judgement, a mass release of data showing repeated patterns of questionable behavior and attempts at concealment is generally enough to convince the public at large of the genuineness of the data.

A secondary objective may be to punish the company: by publishing trade secrets and revealing customer identities it may be possible to destroy or severely curtail the company's business operations.

Blackmail

While the motives of whistleblowers and hacktivists are altruistic, a blackmailer may wish to steal the same classes of data for purely financial reasons. Instead of simply leaking the data to the public, the blackmailer will try and extort money, goods, or services from a company by not publishing the data he or she holds.

Intelligence Gathering

Spies, whether corporate or government, are in the business of obtaining information and access to information.

Information on current negotiations, proposals, customer lists, and customer agreements may be of interest to a competitor. Design, performance,and production information may of interest to a foreign government.

Also of interest is any information that enables the spies to identify people with access to useful information, as well as (obviously) any information that can be used to persuade an individual to assist them in their work.

Revenge

If an employee, prospective employee, or customer becomes sufficiently slighted by a company or its staff, then their thoughts might turn to revenge. The objectives here are to cause disruption or destruction, without any concern as to whether the actions make money for the perpetrator or are in the public interest.

Once again, any embarrassing or important collection of information may be the target for exposure, as can collections of private customer data which would damage the business if revealed. The wholesale disruption or corruption of data is also a possibility.

After Effects

If your company experiences a data breach, what can it expect?

Once class of effects is purely financial. Disclosing credit card information may result in fines from financial institutions. And, although not strictly in the same class as a data breach, any internal banking credentials stolen may lead to theft of money from corporate bank accounts.

A second effect may be disclosure of trade secrets. Some companies (but far fewer than most people think) depend upon the confidentiality of trade secrets. Disclosure may render these secrets worthless, or at a minimum enable competitors to replicate costly research. The two spyware companies listed above are cases in point.

However, the main effect of a data breach is likely to be a significant loss of trust in the company.

Will people still wish to become our customers still if there is a risk that the relationship might be disclosed? If that is the case, disclosure of a customer list may be enough to put you almost completely out of business. Will customers still wish to deal with us after they have been subjected to credit card fraud or had their bank account hijacked due to a data breach at our company? Will clients and vendors still trust us if they can see the email discussions we had about them? Will employees still wish to work for us if their personal details and emails are published for all to see? Or what if they see what managers and other employees are saying about them?

Reducing the Risks

The methods of reducing the risks are all well-known (if not always practiced) in IT circles. They include:

  • Principle of least access / minimum privilege.
    Only allow people or systems the minimum access required to do their job. Development staff do not need access to production systems, the staff in sales do not need access to the personnel database, the public web server does not need access to the personnel database, etc. It's sometimes inconvenient and tricky to maintain, but this is one of the first lines of defense.
  • Use firewalls and physically distinct networks.
    Assuming that an internal system is "owned" by an attacker, limit its usefulness by restricting what other systems could be attacked at a physical / hardware level.
  • Split responsibilities
    It's a basic fraud prevention principle in accounting, and it extends here too. Don't put everything under one person's control. If a person can give themselves permission to access everything, there is little to stop them (or somebody impersonating them) doing everything.
  • Use logging and intrusion detection systems
    When a member of staff plugs in that "found USB drive" to see what is on it a nd gets their computer "owned", it's important to be able to detect the attempts to find and "own" other computers as soon as possible, before too much damage has been done. It's also important to be able to figure out what happened after the event, otherwise there's little to stop the same thing happening again.
  • Don't store un-salted or simply encrypted passwords
    Assume that an attacker has been able to steal your database of simply encrypted user passwords due to website vulnerability. (A surprisingly common scenario). An attacker can do two things: they can determine if two users have the same password by simple inspection; they can try guessing user passwords for all users at the same time. And if you are using a simple encryption algorithm rather than a properly designed password hashing algorithm, they can search for the right password very fast. Indeed, they may even have a list of the encrypted value of the million most common passwords they can use to look up the passwords. Password salting throws a random per-user value into the mix, which makes it impossible to simply compare encrypted passwords or to search for all user passwords simultaneously. A password hashing algorithm is designed to run slowly enough that searching through a long list of possible passwords becomes infeasible.
  • Enforce strong passwords or pass phrases and discourage password re-use.
    If you read the announcements of data breaches by hackers, you will know that a constant source of amusement is poorly chosen passwords by system administrators. These are passwords that would have been impossible to guess if properly chosen, but were trivial. Often they were also re-used across multiple systems, making the attacker's job even easier. "Clever" passwords are often easy to guess. (Here is how to come up with passwords that even the NSA couldn't guess.). And if you have more than a few passwords to remember, use a good password manager such as STRIP instead of re-using passwords. (No relationship, just a fan.)

And Finally…

… never do anything as a company that you would be ashamed of if it was revealed. That's not just a case of protection from hackers, but also one of protection from legal discovery and eternal damnation too!


Does everyone know what to do in an emergency?

We're currently nearing completion of Plan424, a system which distributes emergency response plans to employees' mobile phones. Most business continuity plans aren't readily available at the time and place where they are needed: the place where an incident occurs. They are also often too complex to be used by someone who is not completely familiar with the plan.

Plan424 puts a simple emergency response plan on everyone's phone, making sure your staff know what to do when something happens. It features pre-written procedures for many situations which can be easily adapted to meet your exact needs.

If you're interested, please sign up to be kept informed at
http://www.riskythinking.com/plan424/


News: Data Insecurity

In this issue we take a look at some of the recent news items relating to hacking and data breaches. Even if you aren't directly responsible for IT security, it's worth asking whether risks are being addressed and what plans your organization should have if a major IT security breach occurs.


Inside the Aftermath of The Saudi Aramco Breach
This is an interesting write-up of the response and aftermath of the 2012 cyberattack against Saudi Aramco, which resulted in the hard drives of 35,000 computers being deleted.
http://www.darkreading.com/attacks-breaches/inside-the-aftermath-of-the-saudi-aramco-breach/d/d-id/1321676?_mc=sm_dr&hootPostID=714c5080846c14de326410ea68ffe715


Carphone Warehouse loses 90,000 (encrypted) credit cards
As well as customer data on up to 2.5 million customers. Attacks like this are now so frequent that they rarely make major headlines.
http://www.theregister.co.uk/2015/08/08/carphone_warehouse_data_breach/


The Hacking Team Android Malware
The recent disclosure of Hacking Team's source code has allowed some interesting analysis both of how spyware can be placed on a device, and the capabilities of the spyware when it gets there. The Android ecosystem is rarely updated (it would require telephone carriers to care about existing phones, instead of trying to sell you new ones). Hence the vulnerabilities described here are unlikely to be patched except on recent or high end phones.
http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-rcsandroid-spying-tool-listens-to-calls-roots-devices-to-get-in/


The Hacking Team and iPhone Malware
Here's an interesting twist. The Hacking Team simply applied for and received an Apple Enterprise Certificate which allowed them to install any software they wanted on Apple's iPhones. The certificate has since been revoked. This is a problem with all public key certificate systems where trust can be delegated. You have to trust not just the issuer of a trusted certificate, but every organization they delegate authority to, any organization that organization delegates authority to, and so on...
https://blog.lookout.com/blog/2015/07/10/hacking-team/


Dealing with the aftermath: Medical Informatics Engineering 
Here's a story you don't want to read about your own company. 200 health care providers and 3.9 million patients were affected by a data breach at Medical Informatics Engineering in May. One of those health care providers was Franciscan St. Francis Health, which uses Medical Informatics Engineering to manage its process records. When they notified their patients, things started to go badly wrong. Some important lessons here about notifying customers. Also note that Franciscan St. Francis Health's IT security wasn't the problem: the breach was at their SaaS supplier.
http://www.dailyjournal.net/view/local_story/Patience-thin-in-data-breach_1439166319


Is that email really from your CEO?
Brian Krebs has an interesting story about a case of "CEO fraud" in which attackers impersonate senior executives to cause fraudulent payments to be made. In this case Ubiquiti transferred $46.7million to the attacker's accounts. Readers may remember that an executive impersonation scam was also one of the enabling techniques in the hack which effectively destroyed HBGary Federal.
http://krebsonsecurity.com/2015/08/tech-firm-ubiquiti-suffers-46m-cyberheist/
https://en.wikipedia.org/wiki/HBGary


Is there a security issue with your products?
Chrysler recalled 1.4 million Jeeps after hackers demonstrated a vulnerability which allowed control of a Jeep's transmission using vulnerabilities to remotely reflash the car's firmware. This isn't an everyday hack: it's doubtful it would ever be found in the wild. But it did cost Chrysler millions in car recalls. And if it had happened in 1997 it would have given the Lady Diana Spencer conspiracy theorists something extra to work with.
http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
https://www.youtube.com/watch?v=b4meFC1ee7Q (Best Lady Diana conspiracy theory video ever)


Where is your rifle actually aiming?
It's hacker season in Las Vegas at the moment, with the Blackhat and Defcon conferences taking place. This will undoubtedly lead to hacking stories ranging from the impressive and impractical to the mundane but downright scary. In the former camp is a hack of a smart rifle so that the bullets go somewhere other than where the shooter thinks he is aiming. It's not a real world attack (the rifle is well-designed and requires too much co-operation from the user for a practical attack), but it does demonstrate how anything with a remote connection may now be a target.
http://www.pcmag.com/article2/0,2817,2489247,00.asp


Risk Assessment Toolkit

Our Risk Assessment Toolkit is designed to assist you in creating and maintaining a Risk Register and Business Impact Analysis by modeling dependencies, simulating disruptions, and calculating potential losses. An evaluation copy is available.

For more information:
http://www.riskythinking.com/risk_assessment_toolkit/


Administrivia, Subscribing, and Unsubscribing

RISKY THINKING is a free newsletter providing essays, analysis, insights, and oddities related to Business Continuity, Disaster Recovery, and Risk Management. You can subscribe on the web at http://www.RiskyThinking.com/newsletter/.

Please feel free to forward RISKY THINKING to colleagues or friends who will find it valuable. You may reprint this newsletter provided it is reprinted in its entirety.