Posts Tagged ‘Security’


November 17, 2011 Leave a comment

One of the nice things about being in a senior position within a small company is that, every so often, you come across a situation that happens so rarely that no documentation nor process exists, and it’s entirely your responsibility to work out from scratch what needs to be done.

Being the most experienced within the company on our infrastructure and security, it fell to me to write the procedure for ensuring that any individual leaving the company is locked out as securely as possible. As I write this, less than a day away from leaving my job at Acme, the person leaving the company – the person who needs to be locked out – is myself.

The standard technical parts are easy enough: change all admin passwords, change every single password in the Password Database (Yes, it will take a while. Yes, I did advise against it. No, I can’t help. Because then you’d have to tell me the new passwords!). But two major unknowns exist; one legal, one social.

Legal Lockdown

The legal part is relatively simple: make it clear to the soon-to-be-ex employee (STBEE) that they are no longer entitled to access the company’s systems by spelling out, in as much detail as required, that their access is revoked to:

  • Any company system
  • Any system run by the company on behalf of a client
  • Any system run by a client whose access has previously been a privileged right of the company

except for those rights granted to any other anonymous or generic individual; this allows, for example, a STBEE to visit a former client’s website, but not to use any security credentials on that site that may have been supplied as a part of their employment.

It may be advantageous to get the STBEE to sign a document agreeing to the above, just to ensure their understanding is complete.

Social Networking

The social part is where the rabbit hole opens, and specifically social engineering. A company can spend all its time locking an individual out, but there is always the risk (depending upon the nature of the departure) of the user contacting third parties claiming to be acting on behalf of the company.

  • How do you protect against a email being sent to your hosting provider, designed to match the style of your infrastructure manager but cancelling a client’s service?
  • How can you stop a rogue employee contacting the IT department of your biggest client and creating a new account that acts as their backdoor?

The only chance that a company has to counter this is to make sure that the other usage of social is taken into account: communication.

  • Ensure that all employees, clients and suppliers are aware that the individual is no longer an employee.
  • Ask that any supplier always confirm any out-of-the-ordinary request, either by email or phone.
  • Ensure that any change to any configuration or payment is fully understood.

It’s not perfect; time after time, social engineering has been shown to be one of the most dangerous types of hacking in existence and at the same time the most difficult to protect against. But through communication there is still at least a chance.


The Suitcase Clinic

August 31, 2011 Leave a comment

The Suitcase Clinic are a “humanitarian student organization and volunteer community offering free health and social services to under-served populations since 1989” (their words, not mine), based in San Francisco on the West Coast of the USA. They operate under the domain ‘’.

Most of the time.

I own a domain that is very similar to theirs. I registered this domain in 1996 for my own personal use, with no intention of ever using it for passing myself off as any other organisation. Unfortunately, every so often I get emails destined for The Suitcase Clinic, often from staff members themselves forgetting what their own domain name is. I have notified these individuals each time, but the message has not sunk in.

A week ago, following on from another incident, I notified their Advisory Board (who I would imagine being in a more senior position) that this was an ongoing issue, and said that if I heard nothing from them within 24 hours I would speak out. Needless to say, I have heard nothing and as a result am going public.

Looking back through my mailbox, back in June 2010 (not the first, but my history stops there) I received an email from the Suitcase Clinic themselves,

Hey Everyone!

Here are the applications for the 2010 Summer Training so far. We should be receiving more applications because the deadline has been extended to midnight.The applications are numbered to match the google doc. Have fun reading!

– The CCs

“The applications” were around 40 CVs of individuals who applied for internships at the Suitcase Clinic. This is personal data, all shipped nicely outside of the United States and therefore potentially breaching Safe Harbor laws. Needless to say, I notified all individuals immediately.

I did receive an apology:

Thank you for your notification. We were unaware that there was an active address after we realized we made the mistake yesterday. If its possible please delete those files. We will update everyone to make sure that they correctly input outgoing email addresses.
I want to apologize again on behalf of our organization for spamming your email. Once again thank you very much for taking time to let us know and have a great day!

A month later …

Hey Clinic Coords!

Summer trainees will begin shadowing at your clinics throughout the next three weeks. The class coordinators are requiring the trainees to shadow experienced caseworkers at least two times throughout the upcoming 3 weeks. In addition to the shadowing requirement, trainees are required to attend at least 1 S.H.A.R.E. discussion. In the spreadsheet (included at the bottom of this email as a link) you will notice that there is a list of all of our summer trainees in alphabetical order. In addition to their names, we have included the dates for clinic for the next three weeks. If a trainee attends clinic, it would be best for the class coords if clinic coords can indicate that a trainee attended their clinic (and stayed through debriefing) by placing an “x” into the column. At the bottom of the list, we have color coded each clinic, so in addition to indicating that the trainee attended clinic, please color code which clinic the trainee attended. If you would rather hand in a hard copy of your attendance sheet to the class coords, then you are more than welcome to do so, but please give it to us promptly. If you find that trainees are inadequately prepared or that something else could have been improved, then we would love your feedback to help us improve summer training. Thank you for your time and cooperation. We hope you like our summer trainees as much as we do.

My complaint about this was ignored.

Late September 2010, someone – I suspect a client – emails me with a rambling email appearing to describe incidents of racial discrimination. I notify Suitcase Clinic, and get the following (which I don’t believe was intended for my viewing):

Who gets forwarded emails from the Advisory@[redacted]?? (no one right?)
Just concerned that he’s forwarding someone unknown all these emails… haha.

Hilarious. I think I just split my sides.

March 2011, a further email. This one was from an attendee of the clinic; it could have been a mistake, or they were given my domain instead of the Clinic’s.

Finally, late August 2011 I get a notification email from Gmail (not the first, but I don’t have the other to hand):

You have requested to add pr@[redacted] to your Gmail account. Confirmation code: [redacted]Before you can send mail from pr@[redacted] using your Gmail account ([redacted], please click the link below to confirm your request:

If you click the link and it appears to be broken, please copy and paste it into a new browser window. If you aren’t able to access the link, please log in to your Gmail account, and click ‘Settings’ at the top of any page. Open the ‘Accounts’ tab, and locate the email address you’d like to add in the ‘Send mail as:’ section. Then, click ‘Verify,’ and enter your confirmation
code: [redacted]

Yes, this time someone at the clinic has decided they want the ability to send email from my domain (the gmail account was one that is closely linked to the Clinic). Again, I am promised that this will not happen again. I don’t hold out much hope.

Read more…

Categories: Security Tags: ,

HSBC: Security vs. Usability

August 29, 2011 1 comment

Earlier this year, HSBC informed all its customers that it would be providing them with ‘upgraded’ security in the form of the HSBC Secure Key, a hardware device that generates a number upon each use; this number can then be used to log into the HSBC website. Unfortunately, they forgot to ask the customers if they wanted them.

HSBC Secure KeyThose familiar with the concept of security will have heard of the three factors of authentication, which can be broken down into simple concepts:

  • Something you know
    • A password, or a favourite colour.
  • Something you have
    • A phyical token or smart card.
  • Something you are
    • A measurable biometric, such as a finger or voice print.

It’s generally accepted that the more factors you have, the more secure your system is, and HSBC’s move was from single factor (digits from a known number preset by the individual) to two separate factors (a known answer to a preselected question, and the secure key itself).

The factor that they missed was usability, and quite frankly they have rolled out a very poor implementation. The ‘credit card sized’ key turns out to be the thickness of five credit cards, and is required for all access (even checking account balances). Some of HSBC’s competitors, going down a similar two-factor route, only require their devices for actions where the additional security would be welcomed, e.g. balance transfers.

My personal final straw was the advert for the keys themselves, which can be seen at The elderly gentleman is shown happily typing into his secure key like it was a 1980’s calculator and getting a code to use on the HSBC website.

This part, more than anything else, is a lie: any elderly gentlemen trying to use the key in that manner will break their fingers. The HSBC key is the most unmalleable device I have ever come across, and to switch it on and type in the required PIN requires each digit to literally be squeezed between thumb and forefinger one at a time.

Like so many other security measures, this is yet another organisation deciding to go their own way. Some banks already provide devices that read unique data from the chip on the card; quite often, one bank’s device can be used by another bank’s card. Make these ubiquitious, and you immediately cut down on the need to have one device per bank, you cut down on people having to always carry the single device capable of accessing their account around with them, and yet you get to keep your second factor.

HSBC has stated that they are already looking at replacing their system:

This first version of Secure Key is not the final one – although we have designed it to be light and portable in comparison with our competitors’ bulky card reader devices. We are already exploring options for version two that might be virtual. But we have a duty to strike the right balance between ease of use and the highest level of security our customers demand of us.

Computing magazine, 24th August 2011

Too little. And quite possibly too late.

Not even remotely secure

Who has access to your network? More importantly, who else do they give that access to, and how do they check their authorisation?

A few weeks ago, I was given the task of installing a piece of software onto a client’s server. Initially it was suggested that I drive to their office – two hours each way with no guarantee that I would have access to the resources I required. Thankfully, the day beforehand I discovered that they had a support contract with a local IT firm who had remote access directly to their server.

The next ten minutes were, from a security viewpoint, possibly the scariest I’ve had in my career so far.

To their credit, the support company were very accommodating. Their first suggestion was that they assign our mutual client’s account over to us; when that suggestion was rejected as impractical they set up an VNC-like service instead. Logged in as the system administrator, I was able to install all the software I required, even those elements that we had written ourselves.

There was just one, very minor, concern.

At that point in time, our client still thought I was visiting in person, so hadn’t notified the support company. This company, based on nothing more than me supplying them with the name of one of their clients, had effectively signed over full ownership of that company’s network to an unknown individual on the end of a phone line.

Scared? You should be.

Categories: Security Tags: , , ,

Publicising your Password Policy

I raised the following situation recently on Twitter, and from the feedback gained it appears that there are a lot of different viewpoints as to the ‘right way’ and ‘wrong way’ to handle password policies. 140 characters is never enough to explain the different sides fully, therefore here is a longer justification of the view that I put forward.

It’s fair to say that different sites have different password policies. This in itself is not a problem, as individuals have differing ideas on what constitutes a ‘secure password’, whether that relates to minimum and maximum lengths, requiring a certain combination of different character types, or only allowing the password to be made up of A-Z and 0-9

Having such a policy should be second nature for any organisation, however I’m finding an increasing trend of these policies only being displayed when either:

  • Setting a password, or
  • Re-entering a password having been told that the password you attempted to use didn’t meet the policy.

The one place that policies never appear to be specified is when a user is actually trying to log in, and is an issue I’ve specifically noticed on one of the banking ‘3D secure verification’ IFRAMEs that appear (which in themselves are a security issue, as others have documented in the past). As a result, several times now I have ended up in the following situation:

  • I enter what I believe my password is, which happens to be 11 characters.
  • It is rejected, as it does not match the password stored. A reset is obviously needed.
  • I go through the reset process, entering various personal information, and also provide a new password.
  • I am told that my password does not meet the requirements, which involve a maximum length of 10 characters.

Now, at this point, I suddenly remember what my password is; but look at the process I’ve had to go through in order to reach that stage. It has slowed me down significantly, it has frustrated what should be a simple process and it has lowed my opinion of the organisation providing that service. Other people may have simply given up, and thus a sale is lost

So – can someone tell me why a company should not publicise its password policy? Considering that they are often freely given on ‘sign up’ pages, why – user interface issues aside – can they not be displayed on sign-in as well?

Cyber WarGames

March 15, 2011 Leave a comment

Every computer hobbiest of a certain age remembers fondly the second-greatest film of 1983: WarGames. Matthew Broderick, at the time a mere 21 years of age, unknowingly discovers a back door into NORAD’s computer systems and, having been invited for a quick game of Global Thermonuclear War, almost triggers World War III. Star Wars VI may have made more money, but WarGames had a much deeper impact in certain areas of society.

In the last few years, the concept of ‘cyber warfare’ has taken on a newer meaning. With Stuxnet apparently targetted at industrial control equipment,  and funded at least partially with Government money, it has turned from a hacker’s hobby into big business.

The term ‘cyberwar’ is an ambiguous one, as admitted by the former US Secretary for Homeland Security, Michael Chertoff, and former director of the National Security Agency Mike McConnell:

“When it comes to defining cyberwar, Chertoff and McConnell say espionage and information theft don’t qualify, but destruction of data or systems do. Designating the latter as an act of war, however, would still depend on the scale and genesis of the attack.”

The definition of ‘attack’ in the first place is also ambiguous, in my view. The release of the Wikileaks cables could have been seen as an ‘attack’, or simply a misunderstanding of the difference between ‘freedom of information’ and ‘protection of the state’.

Governments cannnot handle these threats on their own; although they are powerful, they don’t necessarily have the reach to get enough people interested. As a result, third parties are stepping forward.

“‘We need the help of [the IT] industry because cyber security is a team sport that brings together government, industry and international allies,’ General Keith Alexander, commander of US Cyber Command told RSA Conference 2011.”

One element that may help are the various Cyber Security Challenges being set up around the world. The US Cyber Challenge freely admits that they are looking for 10,000 talented individuals to help both the Government and US businesses with the challenges ahead, whilst the UK Cyber Security Challenge is more focused on driving interested parties towards IT security career paths.

I was recently honoured to be invited to attend the ceremony for the first UK awards, and in the process met a number of very interesting individuals. Some worked within certain Government agencies or in security roles for large corporations, whilst others were students finishing off their degrees with no particular career path planned.

Over 4,000 people applied when the UK challenge launched in 2010, and hopefully more will apply this year. Baroness Neville-Jones announced during the awards that the Government has already pledged £180,000 to part-fund the 2011 competition, due to open for registration on the 28th March. I’ll be applying, with the aim of being more than just a spectator next year.

In WarGames, WOPR concluded that “the only way to win is not to play”. News just in: it’s already playtime!

Security by Encryption

February 18, 2011 2 comments

In The Security Oxymoron, I wrote about the possibility of an individual introducing security measures that seem inheriently reasonably but, when analysed, offer no additional security and at times even an increase in an organisation’s vulnerability.

An example is often more useful than a mere concept. The overall story is fictional, but I promise that the individual parts have been observed over the course of many years. It starts with the Datafile, a file whose existence was essential to the smooth running of the company, and were it to end up in an outsider’s hands the result could be catastrophic.

To ensure that the Datafile was stored as securely as possible, the following security mechanism was put into place:

  1. The Datafile was stored in a folder on the local network, accessible to all individuals in the company.  No ACLs were placed on the file, as the security enhancements that followed were deemed to be sufficient.
  2. The data in the file was securely encrypted (AES) with a passphrase, using a third party tool freely available on the Internet. The only access to the data would then be through this tool.
  3. For security, the chosen passphrase was around 20 characters, consisting of numbers and mixed-case letters. The downside of this was that the passphrase was meaningless and thus unmemorable for any individual in the company.
  4. To work around this, the password had been printed out onto strips of paper (little larger than the passphrase itself, printed at 14pt), and distributed to people’s desks by hand.
  5. An office move meant that the majority of employees lost their strips of paper. Nobody noticed.
  6. Because of the security in place, it was decided that no monitoring was required to ensure that the file was not, for example, copied onto a USB stick and taken to off-site where the same third party tool could be download and the easily-lost passphrase used to decrypt it with.

The suggestion that all encryption be dropped as counter-productive, and the file kept as plaintext secured with ACLs, was deemed ‘too risky’.

Categories: Security Tags: , ,