Hey board directors, help your companies fight cybercrime - and yes, it matters

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Boardrooms need to "wake up" to the danger of cybercrime, according to a recent report.

The UK's ICSA, commissioned by the government's Department for Business, Innovation and Skills (BIS), issued the guidance document on how boards can better understand and cope with the threats posed to businesses by malware, hacking, cyber espionage and other digital dangers.

Now, in security circles, "ICSA" generally refers to a leading security testing and certification body, formerly known as NCSA. Or, in some specialist cases, the International Chinese Statistical Association (for some reason, founded in San Francisco and registered as a non-profit in Delaware).

But no, the ICSA we're talking about here is the Institute of Chartered Secretaries and Administrators.

Their report didn't get much attention when it first appeared a few weeks ago. In fact, I didn't spot it until the press release was picked up by, of all places, an Isle of Man-based news site.

So, I hear you ask, what's the rumpus? A bunch of people moan about their bosses' ignorance, and no-one really listens. Big deal.

Two things though. First, these are not the people who do the typing and answer the phones. Important and delightful as those secretaries are, these are corporate secretaries, a whole different thing.

Corporate secretary is a high-power position, basically sitting between the board of directors and the company at large, ensuring the board gets the information it needs from the company, and the company acts on the board's decisions.

The ICSA is the body representing the most experienced and highly-qualified corporate secretaries in the UK, and rightly refers to itself as "a recognised authority on corporate governance and compliance". So, if they say boards are paying too little attention to cyber issues, you can be pretty sure they're right.

Second, their report (PDF) provides some pretty good advice. It gives a clear, simple breakdown of the dangers businesses might face, stressing the need to weigh up the risks specific to a given organisation and the importance of focusing on resilience in the face of attack:

The cyber threats facing businesses and their supply chains cannot be prevented through investment in technology alone. It requires comprehensive risk assessment processes to identify and prioritise the protection of critical information assets.

It puts particular emphasis on the problem extending to all parts of a company:

Internal functions such as HR, finance, legal and marketing may not appreciate the extent to which critical information is at risk, nor realise the potential impact of a cyber attack on their organisation. ...Day-to-day control of cyber risks should not be left to the IT department.

Few companies can survive these days without some sort of internet presence, and even the smallest are likely to be making ever more use of information technology.

For most, all this is still a relatively new side of doing business, and it changes and evolves at a bewildering pace. This exposes firms to a whole new world of risk, which many staff - especially in senior roles - have minimal understanding of.

Board positions tend to be very senior roles indeed, so members might not be in touch with the fast-moving world of cyber security.

They also tend to be filled from a limited set of backgrounds, mainly financial, sales, marketing and legal areas with limited uptake of people from more technical departments. But their input and backing is vital to ensure cyber security is given the proper emphasis at every level.

It seems that board members need all the help and advice they can get when it comes to shoring up their firms against digital dangers.

So, if you're a board member, read the guidance, and act on it. If you're working for a board which isn't helping with your cyber security needs, try subtly pointing them towards this kind of advice - it just might sink in.

Follow @VirusBTN
Follow @NakedSecurity

Images of hand shadow, boardroom and blindfolded man on computer courtesy of Shutterstock.

View the original article here

Apple finally adopts HTTPS for the App Store - here's why it matters

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Last year, a Googler named Dr. Elie Bursztein noticed that Apple's App Store protocols weren't very secure.

Much of the interaction your iDevice had with the App Store was conducted via plain old HTTP.

Apple should really have been using HTTPS, or secure HTTP.

HTTPS, as you probably know, is HTTP traffic carried inside a Secure Sockets Layer (SSL) or Transaction Layer Security (TLS) wrapper.

? SSL/TLS uses public-key cryptography to create a secure data channel, even between users or websites that have never corresponded before. Conventional encryption, like a doorlock, relies on a single key that can lock or unlock. How to share that one-size-fits-all key before you start using it is a security problem all of its own. Public key cryptography relies on an algorithm that uses two keys. One is kept private, and the other made public. What the public key locks, only the private key can unlock.

The problem with HTTP is that if you're on someone else's network, whether it's wired or wireless, they can probably listen into all your web traffic.

Likewise, if someone else is on your network, they can do the same thing, eavesdropping undetectably.

Worse still, it's very likely that they'll be able not only to watch what you're doing, but also to modify the traffic you send and receive.

So, in an ideal world, there would be HTTPS only, since the encryption layer inhibits both eavesdropping and unauthorised modification. Nobody would use HTTP for anything.

And why not? SSL/TLS encryption can be made largely transparent both to the programmer and the user, so the difference in online experience between encrypted and unencrypted web sessions is pretty modest.

In practice, however, HTTPS isn't quite as convenient for your IT department as HTTP.

You need to get certificates signed, your private keys stored securely, and more.

That means an operational change, which means paperwork, implementation time and (you can guess what comes next) money.

Also, because every HTTPS download is encrypted uniquely for each user each time they fetch it, it's much harder to cache HTTPS traffic.

If 2000 users from the USA pull down the same image file from your database in New Zealand, you can't rely on a web cache on the USA side to serve up an identical copy of the file to 1999 of them, because each download is individually negotiated and encrypted.

That means an operational change, which means paperwork, implementation time and (you can guess what comes next) money.

As a result, a sort-of HTTP/HTTPS hybrid evolved.

You use HTTPS for the parts of the transaction that really have to be secret, such as sending passwords, credit card numbers and other Personally Identifiable Information (PII).

For everything else, you use HTTP.

That was the model used by many online services, including webmail providers and social networks, until fairly recently.

Things started to change after the release of Firesheep, security researcher Eric Butler's mildly controversial effort to push the envelope of web encryption.

Implemented as a Firefox plugin, Firesheep listened on the network until the HTTPS-protected part of your social networking session was complete.

Then it sniffed out your session cookie, the magic token embedded in your post-authentication HTTP requests that tells Facebook, Twitter and others that you're an authorised user.

Firesheep could then pretend to be you, posting status updates, links, tweets and more from your accounts as if you had done it yourself.

Of course, even without actively hijacking your social networking accounts, an eavesdropper can learn an awful lot about you from your HTTP traffic.

After all, not everything you upload to Facebook or Twitter is inevitably intended for public consumption, so it oughtn't really to be uploaded without being wrapped in an SSL/TLS session.

Facebook, Twitter and others, bless them all, eventually bit the bullet and simply switched to HTTPS for everything. (At least, they did for web-based clients. Special-purpose mobile apps were, and some still are, a different story, but we shall ignore that issue here.)

But Apple, it seems, didn't bother with HTTPS everywhere, even for its own App Store, until 2013.

Since there's no other place to shop when you're buying or selling iDevice software, and since Apple likes it that way, you might think that Cupertino would have set the bar a bit higher.

You might also have expected Apple to react a bit more quickly after Dr. Bursztein's fairly detailed explanations of why the bar really needed to be higher.

In July 2012, he explained several problems, which he's now made public, including active attacks (that's where you change HTTP content en route between server and client) by which a malcontent could steal your password, trick you into buying the wrong App, deliver you a bogus update, or quietly prevent you from applying a needed update.

Burzstein also showed that the App Store routinely uploaded an unencrypted list of already-installed Apps from your device.

That doesn't sound like much, but it is.

Firstly, some of those Apps will identify aspects of your life that would be handy for a social engineer to know: the bank you use, the newspapers you like, the games you play, the share-trading services you invest with, and more.

Secondly, the complete selection of Apps on your device may very well be unique to you, thus making it a handy form of digital fingerprint for an attacker.

Earlier this year, Apple finally made a start towards the change that many of its web traffic competitors like Google, Facebook and Twitter made some time ago, and bumped all the App Store's active content to HTTPS:

Good. (Better yet would have been to serve everything using HTTPS, but let's be thankful for what we've got.)

If you're a web developer and your web services rely on users sending you traffic that contains anything at all that oughtn't to be public, you should be doing the same.

Even data that isn't legally considered PII can be pure gold to cybercrooks, and so leaking it could be putting your customers at risk.

And you wouldn't want that, would you?

Would you like to know more about SSL/TLS?

Here's a quarter-hour Sophos Techknow podcast, featuring Paul Ducklin and Chester Wisniewski as they explain the S in HTTPS:

Listen now:

(03 August 2012, duration 16'10", size 11MBytes)

Listen later:

Follow @duckblog

View the original article here