We have regular ConfCalls with our security support to exchange trends and issues we see. During the last one we had an interesting discussion I would like to share with you: We seem to get a hell lot of calls mainly from the consumer segment with Virus/Trojan/Spyware infections. The way they get the malware is a pretty well known one: You go to a web page which is telling you that your PC is infected by malware and that you have to install the "protection software" immediately – which then installs the malware. That's the reason why we call this software "Scareware". There are two things which frighten me:

One is that it shows how easy social engineering works (once again).

But the second one is much more frightening: The malware installed is by far not sophisticated. It is usually pretty old and well known. Therefore every AV scanner would detect it easily and prevent it from being installed. This tells us that there is still a high percentage of people not running AV software on their PC… Since years we are telling our customers you have to do at least three things to run your system: Use a firewall, keep your software updated, run an Anti-Malware software and keep it updated. Similar things are true for ISPs. Why do people still not do it? Is it the money?

Roger

At Blackhat we announced an important change to our Security Bulletins becoming effective during the October release.

One of the requests we often heard talking to our customers is, that they would like to get better information on how hard it is to exploit a vulnerability. We will introduce an Exploitability Index by October. Basically we will give you three values on each vulnerability addressed:

• Consistent Exploit Code Likely. This means analysis has shown that exploit code could be created in such a way that an attacker could consistently exploit that vulnerability. This would make the vulnerability an attractive target for attackers; therefore, it is more likely that exploit code would be created. As such, customers who have reviewed the security bulletin and have determined its applicability within their environment might treat a vulnerability with this value as a higher priority.
• Inconsistent Exploit Code Likely. This means analysis has shown that exploit code could be created, but an attacker would likely experience inconsistent results, even when targeting the affected product. While an attacker may be able to increase the consistency of results by having better understanding and control of the target environment, the unreliable nature of this attack makes it a less attractive target for attackers. As such, customers who have reviewed the security bulletin and determined its applicability within their environment might treat a vulnerability with this value as an important update; however, if prioritizing against other highly exploitable vulnerabilities, they could choose to rank this lower in their deployment priority.
• Functioning Exploit Code Unlikely. This means analysis has shown that exploit code which functions successfully is unlikely to be released. While an attacker could create exploit code that could trigger the vulnerability and cause abnormal behavior, it is unlikely that an attacker would be able to create an exploit that could successfully exercise the full impact of the vulnerability. Therefore, once customers have reviewed the security bulletin to determine its applicability within their environment, they might prioritize this update below other vulnerabilities within a release.

I hope that this makes live for you easier when assessing our updates.

If you would like to get more information, read the fact sheet.

As always, your feedback is very welcome

Roger

As you know, I am Swiss. Switzerland is known as being one of the most direct democracies in the world. It is not uncommon for us having (or being allowed) to vote every other month as there are a lot of ways to influence what our politicians and/or our government does. This makes the system often pretty slow but I really, really like it.

When I was working for PricewaterhouseCoopers years ago (I think it is around 10 year ago now), the discussions around e-Voting started to come up. People loved it – and I hated it. Let me tell you why: We have (here in Switzerland) several options to vote: We can go to the local community early during the week before a voting and hand our votes in. We can send it via Post (which I use most often) or hand the vote in on the voting weekend. There is a lot of effort then going on to count the votes and we usually have the results ready on the voting weekend around 5pm or 6pm. So, the system works well but there is significant manual work involved, I know. The key thing here is that this process is in the heart of our democracy. If this process is broken (or just not THAT trusted anymore) this would be a significant problem for our country.

Now there were a lot of politicians would loved to talk about e-Voting (without really knowing the consequences in my opinion) as it gave them the touch of being modern, technology aware etc. and there were trials in different states here in Switzerland which were pretty successful.

Why am I still against it? Well, I am convinced that these systems can be built in a more secure way than the old process. Manually counting votes is flawed, we know that. But guess what: We learned to live with that since a long time and trust this system. Do we trust a computer counting the votes? I do not think so. Do we trust a computer not losing votes if we have to do a re-counting (which happens from time to time here of the result is close) – hmm, I guess not.

And looking at recent articles, I think we are right: Diebold comes clean, admits that its e-voting machines are faulty, Mom, Can My Voting Machine Spend the Night? (people taking voting machines home), Why Election Technology is Hard (Bruce Schneier)

So, it is by far not a technology problem but a trust problem. And guess what: I am a geek and I love technology – I will still use paper to vote!

Roger

If you ever heard me keynote an event you know that one of the key messages I have is, that partnerships are necessary in order to be able to protect against today's threats.

At Black Hat USA we just announced a new program called Microsoft Active Protections Program. The program is designed to give security vendors advance notification of our security bulletin release. This will help our partners to be able to protect our joint customers against the vulnerabilities we are fixing. The reason why we decided to launch this program is that exploits are developed much faster than they were in the past and security vendors have to act very fast – so let's give them some additional time and try to get ahead of the curve.

The key question will definitely be, who is eligible to join this program. The fact sheet gives you the answer:

• Members must offer commercial protection features to Microsoft customers against network- or host-based attacks.
• Members must provide protection features to a large number of customers.
• Members may not sell attack-oriented tools.
• Protection features provided by members must detect, deter or defer attacks.

Roger

I just read an interesting post by Michael Howard (Security is bigger than finding and fixing bugs). He refers to a statement Google seem to have made on its development practices (Google shares its security secrets):

In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers.

This reminds me of the days back at University: I learned a hell lot about Software Engineering, Data Modeling and stuff like that. Well, I learned about programming as well (up until I was able to look at Niklaus Wirth's Modula-2 compiler – but this is a different story). And then I started my first job in the industry – and all of a sudden I had to learn that there nobody actually cared about a design. Just write the code! Nobody "had time to do a design on paper, this is just a waste of time". Did it work? Not really.

Now, we are coming to security and what do we do: Look at the code. Look for security vulnerabilities in the code. What about the design? What about the threat models? This drives me nuts: Why are we not ready to learn from…

1. … the past
2. … the learning others went through?

I know that our Security Development Lifecycle is pretty successful which can be shown by a lot of different metrics – Michael gives a few in his blog. Additionally, we are working with SafeCode to share the experience and learn from others. Why do other companies not join in?

Roger