New research: Comparing how security experts and non-experts stay safe online

Google Online Security Blog: New research: Comparing how security experts and non-experts stay safe online

Today, you can find more online security tips in a few seconds than you could use in a lifetime. While this collection of best practices is rich, it’s not always useful; it can be difficult to know which ones to prioritize, and why.

Questions like ‘Why do people make some security choices (and not others)?’ and ‘How effectively does the security community communicate its best practices?’ are at the heart of a new paper called, “...no one can hack my mind”: Comparing Expert and Non-Expert Security Practices” that we’ll present this week at the Symposium on Usable Privacy and Security.

This paper outlines the results of two surveys—one with 231 security experts, and another with 294 web-users who aren’t security experts—in which we asked both groups what they do to stay safe online. We wanted to compare and contrast responses from the two groups, and better understand differences and why they may exist.

Experts’ and non-experts’ top 5 security practices

Here are experts’ and non-experts’ top security practices, according to our study. We asked each participant to list 3 practices:

Common ground: careful password management

Clearly, careful password management is a priority for both groups. But, they differ on their approaches.

Security experts rely heavily on password managers, services that store and protect all of a user’s passwords in one place. Experts reported using password managers, for at least some of their accounts, three-times more frequently than non-experts. As one expert said, “Password managers change the whole calculus because they make it possible to have both strong and unique passwords.”

On the other hand, only 24% of non-experts reported using password managers for at least some of their accounts, compared to 73% of experts. Our findings suggested this was due to lack of education about the benefits of password managers and/or a perceived lack of trust in these programs. “I try to remember my passwords because no one can hack my mind,” one non-expert told us.

Key differences: software updates and antivirus software

Despite some overlap, experts’ and non-experts’ top answers were remarkably different.

35% of experts and only 2% of non-experts said that installing software updates was one of their top security practices. Experts recognize the benefits of updates—“Patch, patch, patch,” said one expert—while non-experts not only aren’t clear on them, but are concerned about the potential risks of software updates. A non-expert told us: “I don’t know if updating software is always safe. What [if] you download malicious software?” and “Automatic software updates are not safe in my opinion, since it can be abused to update malicious content.”

Meanwhile, 42% of non-experts vs. only 7% of experts said that running antivirus software was one of the top three three things they do to stay safe online. Experts acknowledged the benefits of antivirus software, but expressed concern that it might give users a false sense of security since it’s not a bulletproof solution.

Next Steps

In the immediate term, we encourage everyone to read the full research paper, borrow experts’ top practices, and also check out our tips for keeping your information safe on Google.

More broadly, our findings highlight fundamental misunderstandings about basic online security practices. Software updates, for example, are the seatbelts of online security; they make you safer, period. And yet, many non-experts not only overlook these as a best practice, but also mistakenly worry that software updates are a security risk.

No practice on either list—expert or non-expert—makes users less secure. But, there is clearly room to improve how security best practices are prioritized and communicated to the vast majority of (non expert) users. We’re looking forward to tackling that challenge.

OpenSSL CVE-2015-1793 (cert. verification bug) – what you need to know

OpenSSL CVE-2015-1793 (cert. verification bug) – what you need to know | Naked Security

If you have anything to do with web security, like we do, you've probably been in "bated breath" mode this week.

That's because the OpenSSL team announced, on Monday 2015-07-06, that it had a "high severity" update coming out in three days' time, meaning today, Thursday 2015-07-09:"
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p.
These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity. This defect does not affect the 1.0.0 or 0.9.8 releases.
And that's all she wrote.

What is OpenSSL?

OpenSSL is a very widely used internet security toolkit that implements a cryptographic security protocol called TLS/SSL, and puts the "S" in HTTPS for a great many websites.
OpenSSL is also widely known because of the Heartbleed vulnerability, uncovered in 2014.
Heartbleed meant that almost anyone with an internet connection could suck secret data out of your servers at will, without actually needing to break in or even to do any sort of hacking.
To trigger the Heartbleed bug, you merely asked the server to send you a so-called keep-alive message.
A keep-alive system is an uncontroversial feature that many internet protocols support, because keeping an existing connection going is a lot less complicated than starting a new one.
Keep-alives are a bit like those short conversations about not very much that you have every now and then when you're travelling in a car at night, just to make sure the driver's still alert.
The Heartbleed problem was that you could ask the server to send you a keep-alive response that was much larger than the memory buffer it was using to process your keep-alive message, and it would happily oblige.
So, you'd receive a reply that included your message, followed by random extra stuff out of server memory that you weren't supposed to see.
Most of it would be harmless, but every now and then you might get hold of snippets of other people's traffic, passwords, encryption keys, and more.

Waiting for the fix

These historical facts – the prevalence of OpenSSL and bad memories of Heartbleed – meant that OpenSSL's terse email notification on Monday wasn't very comforting.
Why an update just for a single security hole? How "high" was the high severity?
Was this going to be a denial-of-service bug? Or would it be a data leakage hole, like Heartbleed?
Or a full-on remote code execution flaw that would allow outsiders to run commands on your server as if they were actually logged in to your network?
More specifically, would all sub-versions of OpenSSL in the 1.0.1 and 1.0.2 series be at risk, or would some releases turn out to be OK?
How to prepare for what was coming on Thursday?

The flaw

The update is out, and our verdict is that the bug isn't as bad or as widespread as we feared at first.
Nevertheless, if you're vulnerable, you need to act.
Simply explained, CVE-2015-1793 is a certificate verification flaw.
This means that crooks who can lure or misdirect you to a bogus website (or email server, or indeed any internet service using TLS/SSL for its security) may be able trick you into thinking that you are somewhere legitimate and secure.
As you probably know, TLS/SSL relies on a "chain of trust" formed by cryptographic certificates.
This chain of certificates reassures you that the secure website you are visiting really does belong to the organisation you expect.
Here's an example we've used before, based on Naked Security itself:

Naked Security's certificate is owned by Sophos; Sophos's right to represent itself as Naked Security is vouched for by GlobalSign; and GlobalSign's right to vouch for Sophos is vouched for by Firefox.
If crooks created their own certificate claiming to be Sophos, and used it to vouch for a fake version of Naked Security, they'd almost certainly come unstuck.
Your browser would complain: the certificate presented by the crooks wouldn't be vouched for by any trusted certificate authority (CA).
You'd see a warning like this:

→ Wrongly-signed certificates do turn up from time to time, and can cause serious security problems. Bad certificates are often down to an insecure, venal orincompetent CA. CAs who don't take security seriously are usually thrown out by the major browser makers, thus effectively cancelling all certificates they've signed. The errant CA will be expected to show strong reasons before it will be trusted again.

Effects of the bug

This latest bug in OpenSSL means that a crook may be able to create a certificate in someone else's name, and then to sneak it past OpenSSL's certificate verifcation process without without triggering a warning, even though the certificate isn't signed by a trusted CA.
That makes a man-in-the-middle (MiTM) attack feasible, where a crook intercepts your traffic, say to a social networking site; feeds you a fake login page with a fake HTTPS certificate; and convinces you to give away your password because the warnings that ought to prevent the phishing deception never show up.

How big is the risk?

Fortunately, the scope of this bug is narrower than we feared after reading Monday's OpenSSL advisory.
First, this bug doesn't give cybercrooks the ability to steal data or break into your servers directly, because:
Crooks can't bleed confidential data from your server at will, as with Heartbleed.
Crooks can't sniff (record) arbitrary network traffic and crack the TLS encryption later.
Crooks can't send malformed data packets and break into your web, email, or other OpenSSL-protected servers.
Second, only four of the many officially-supported OpenSSL versions are affected:
Versions 1.0.2b and 1.0.2c need updating to 1.0.2d. (The -a and -b sub-versions are immune.)
Versions 1.0.1n and 1.0.1o need updating to 1.0.1p. (Sub-versions up to and including -n are immune.)
All 0.9.8 versions are immune.
All 1..0 versions are immune.
Third, most servers (unless they connect to other servers, or do reverse certificate verification of clients, which is rare) are not affected, because this certificate trickery affects the client that is connecting, not the server it is connecting to.
Fourth, all the Big Four web browsers – Internet Explorer, Firefox, Safari and Chrome – do not use OpenSSL and are therefore immune.

What to do?

Many products other than web browsers, including software updaters, RSS feed readers, scripting tools and email clients, not only use TLS/SSL but may include code from OpenSSL.
These may need updating.
If you aren't sure, ask the maintainers (for open source products) or your vendor (for commercial software) to tell you whether they use OpenSSL, and whether the products needs updating.

What about Sophos products?

The good news is that Sophos products are not at risk from this bug.
Only the current pre-release version of Sophos Management Communication System (MCS 3.0.0 Beta) includes an affected version of OpenSSL.
However, MCS does not use the buggy part of the OpenSSL code, so cannot fall foul of the bug. (Nevertheless, we expect to update MCS 3 Beta with the latest OpenSSL version by mid-August 2015.)
All other Sophos product families either don't use OpenSSL at all, or use one of the unaffected versions.
This list includes: Sophos UTM, Sophos Secure Web Gateway, Sophos Secure Email Gateway, PureMessage for Unix/Linux, Sophos Antivirus/Sophos Endpoint Protection, Sophos for vShield, Sophos Cloudand Sophos Mobile Control (server and mobile apps).

True story : réparer un auto-DDOS

True story : réparer un auto-DDOS| CommitStrip

Alerte rouge : une autre vulnérabilité critique dans OpenSSL

Alerte rouge : une autre vulnérabilité critique dans OpenSSL

Le projet OpenSSL demande de se préparer à la proche venue d'un patch pour combler une vulnérabilité de sécurité à l'importance jugée élevée.
Mystère et boule de gomme mais le projet OpenSSL tient en alerte les administrateurs système et développeurs. Le 9 juillet, il y aura la publication d'un patch afin de corriger une vulnérabilité de sécurité dont l'indice de gravité est au plus haut.

OpenSSL est la fameuse bibliothèque open source de chiffrement qui est largement utilisée pour les communications Internet avec les protocoles SSL / TLS. Le Web garde encore en mémoire l'affaire de la faille dite Heartbleed divulguée l'année dernière.

Puis il y a eu POODLE quelques mois plus tard et ce avant FREAK. Pas encore de petit nom anxiogène pour la prochaine grosse faille dans OpenSSL… et c'est peut-être un bon signe.

Le projet OpenSSL indique que des mises à jour pour les versions 1.0.1 et 1.0.2 d'OpenSSL seront publiées jeudi prochain afin de combler la mystérieuse vulnérabilité. Respectivement, elles prennent actuellement en charge TLS v1.1 et TLS v1.2. Il faudra alors compter sur une bonne réactivité des administrateurs système et développeurs.

À ce stade, le seul véritable indice est qu'une vulnérabilité de sécurité à l'importance élevée peut couvrir des problèmes comme un déni de service pour un serveur, une fuite de mémoire significative et une exécution de code à distance. Suspense…

Les heures propices pour bosser en open space

Les heures propices pour bosser en open space | CommitStrip

The top three banking malware families

The top three banking malware families

The primary motivator behind banking malware attacks is to capture credentials, financial data, and personal information from employees, and partner company employees, across industries. Then apply this stolen information in fraudulent wire transfers or fake automated clearing house (ACH) transactions to steal funds.

SecurityScorecard sinkholes found 11,952 infections affecting 4,702 organizations and identified the top banking malware families to be Dridex, Bebloh and TinyBanker:

These malware families are simple in functionality which is proving to be more profitable than more complex techniques and methods, such as taking antiquated, bloated code bases from third party malware coders.

Dridex is the most prolific Trojan being circulated within the corporate sector.

The use of banking malware is not limited to large financial institutions, though they remain the primary targets.

Dridex spreading campaigns appear to be orchestrated by more advanced actors with an interest in targeted attacks.

The healthcare industry experienced lowest rate of Bebloh infections, but did not experience the same rate of infection as other industries.

"Security awareness and education is never enough. The evolving tools, techniques, and procedures that are continuously honed by malicious actors make it nearly impossible for every individual in an enterprise to be aware of the latest attack method," said Alex Heid, Chief Research Officer of SecurityScorecard. "To prevent financial losses from an attack, businesses need a closed loop of communication between partners, suppliers, and all third parties that are impacted by banking malware. It is critical that companies think about their collective information security ecosystem when gauging their own security risk."

The top three banking malware families being captured are all direct variants of Zeus, or mimic Zeus-like functionalities. These malware attacks are the preferred method of obtaining stolen credentials, especially when traditional attacks on web applications or network-based attacks are being monitored by internal security teams.

Mieux veut guérir que prévenir

Mieux veut guérir que prévenir | CommitStrip