Ivan Ristić

Stop complaining and solve a security problem instead

Figuring out how to fix security issues is one of my favourite topics. I was flattered to be invited to present this keynote talk at the DeepSec security conference in Vienna:

Stop complaining and solve a security problem instead!
We have failed. Decades of ignorance have brought us to this point, right now, where software is universally insecure. It's tempting to hope that someone else will make things better, but letting things slide is exactly what got us here. Pointing to problems is not enough, either. We must pick ourselves up, dust ourselves off, and start fixing things. We must each take a problem -- no matter how small -- and fix, or help fix, the root cause.

Here are the slides:

• Stop complaining and solve a security problem instead (PDF, 434 KB)

We're hiring: I have 3 open positions on my WAF team

In my job at Qualys, I am busy building the next-generation web application firewall. It's too early to talk about it right now, but we will start to reveal more information in the coming months. I can tell you that it is going to be very good, very exciting, and that a lot of it is going to be open source.

Brian Rectanus joined me in August, and I am expecting to sign the third team member in the next week or so. We have 3 additional positions open (clicking on the names will lead you to the Qualys careers web site):

• Senior Java Developer
• Senior System Test Engineer
• Application Security Research Engineer

All these positions are full time and based in Madison, Wisconsin, USA. Once we fill them, we will have a tight team of 6 whose focus will be the web application firewall itself (i.e., no user interfaces -- that aspect will be handled by a separate team). Naturally I am biased, but I cannot recommend these positions enough: they are a rare opportunity to work on something new, innovative, and fulfilling. We need people who are driven, committed to their work, and enjoy working in a team.

In addition, Qualys is a great place to work: there's no politics or middle management, just focus on getting things done, producing high quality work, and keeping our users happy.

If you're interested please apply through the web site, but please do also send me an email.

Security is difficult; open source security sometimes even more so

I have prepared a presentation on Open Source security for the Open Source Specialist Group of British Computer Society (BCS OSSG):

• A_Look_at_Open_Source_Security  (PDF)

The main aim of the presentation is to give an overview of the current state of security in open source projects. I discuss why security is difficult (hint: it's because few people care), and why security in open source is sometimes even more difficult. At the end, I give a simple 3-point strategy for quick evaluation of the security posture of open source projects.

D.J. Bernstein, I salute you!

I have long held a view that we get the software we deserve. The lack of quality, which manifests itself through defects, crashes, security and usability problems, is just a result of our buying decisions. By accepting to use crappy software we encourage software publishers to continue to give us more crap.

So it is a breath of fresh air to see D.J. Bernstein respond to a security report for djbdns:

Even though this bug affects very few users, it is a violation of the expected security policy in a reasonable situation, so it is a security hole in djbdns. Third-party DNS service is discouraged in the djbdns documentation but is nevertheless supported. Dempsky is hereby awarded $1000.

Not only that, but he apologises:

In the meantime, if any users are in the situation described above,
those users are advised to apply Dempsky's patch and requested to accept
my apologies. The patch is also recommended for other users; it corrects
the bug without any side effects.

D.J. Bernstein, I salute you!

Is that open source project secure (enough)?

Type the words "open source security" into a search engine and you will get dozens of links to articles, blog posts, emails, forum messages, and research papers. You can try to read them all, but I don't think you should bother. The opinions mostly fall under one of the following categories:

1. Having access to source code is better than not having access to source code.
2. Community-produced software is better than vendor-produced software.
3. The freedom to modify source code is a fundamental right of every software user.
4. Open source developers are careless, disorganised and fickle.
5. Commercial vendors only care about money.
6. Who are you going to blame when an open source product fails?
7. Open source is dangerous, but you can pay us to help you deal with it.

Most of these claims have a grain of truth in them, but they almost always miss the point in trying to distil complex realities into simple convenient truths. That just doesn't work. The simple truth is that every single project is unique, and must be observed on its own merits. But therein lies the difficulty: how do you determine if a given software product is secure?

I know the proper answer: design an assessment methodology (or use one that already exists—the Software Assurance Maturity Model is nearing completion; Building Security In Maturity Model is expected in a week or so), then use it to make informed decisions. While this approach is suitable for academia, it is too inefficient in real life, where you need to make your decisions quickly and effectively. So what do you do?

Did I mention that I spent almost 6 years of my life working on a fairly popular open source project? In that time I struggled to use my limited resources to do what's best for the project, security being only one of my concerns. I did reasonably well, but made many mistakes along the way. That experience (along with a similar experience in developing closed-source software) has given me an insight into what makes software developers tick and, especially, what makes open source software tick.

So I came up with an idea to avoid measuring the quality of code itself (because that's too difficult and time consuming), instead focusing on the external manifestations of good and bad practices. I call it a Project Security Posture Review. A review might focuses on the following aspects:

1. Does the organisation follow good software development practices?
2. How are security issues handled?
3. Are there any public-facing services available (e.g. source code repository, issue tracking, wiki, etc.)?
4. Is the source code tidy?
5. Is the project mature and popular?
6. Does the project have a reputation for quality?

The idea is that you can answer most of the questions by simply looking at the project's web site, browsing through its code and documentation, and looking at the experiences of other people with it. The obvious advantage of this approach is that it is quick, even though it may be somewhat inaccurate.

If you think the above list is, well, vague—you are absolutely right. I am currently working on a comprehensive list, which I will present during the Open Source Security talk for the Open Source Specialist Group (OSSG) on March 30th.

Update (March 5th): BSSIM is available at http://bsi-mm.com.

The world is full of penetration testers

Mark Curphey has a nice little rant over at his blog: Are You a Builder or a Breaker.

[...] I personally find it is disappointing that after a decade of it being considered a discipline in it’s own right, it is still predominantly made up of breakers and not builders. It’s still predominantly made up of an army of skilled hackers focused on better ways to break systems apart and find new ways to exploit vulnerabilities than “security architects” who are designing secure components, protocols and ultimately secure systems.

I feel the same way. The world is full of penetration testers, who are paid to break things. While I don't have anything against that—they are doing the people they work for a valuable service—it is a shame that we don't have more people who are willing to work to increase security. It is very indicative that only very few people work on the defence side because they passionately believe in making things better. Sometimes it feels the only people on this side (my side) are those are paid for it. (Truth be told, I am paid for my work these days, but it wasn't always like that.) It's really sad, but at most conferences you will find that the most popular talks are those who will mock the current state of security on the Web.

We should pay more attention (and help!) to the efforts that are designed to improve security, for example the Intrinsic Security Working Group at OWASP.

Stop picking on Google Chrome

Chrome, the new browser from Google, apparently has some security issues. So what. Chrome is a brand new application, exposed to the public for the first time, and marked as beta. It's expected to have security issues. The whole point of having a public beta release is expose a product to a wide audience and deal with the discovered problems prior to a stable release. The existence of security issues in Chrome is in line with our current inability to develop software free from security issues. Thus, people should not be distracted by the small problems that are now discovered. We should be  looking at the big picture instead. Chrome is a browser that's been designed from the ground up with security in mind. That's bound to have a positive impact. We'll know more about the impact once the details of its architecture surface.

On the other hand, we should put pressure on Google to stop it from abusing the beta moniker like they did with GMail. Bluring the line between beta and stable is simply not acceptable. How else are users going to be able to judge what is acceptable for production use and what isn't?

Defect-free code is vulnerability-free code

I've come to realise that our efforts to improve the state of security through focus on the software development life cycle (SDLC) are flawed. Although we may see some improvement in the short term (a span of a few years), such an effort is a waste of time as it cannot solve the problem. If you think it can then you are looking at the wrong problem. (Borrowing Mark Curphey's favourite line.) Underneath all our security issues lies our inability to write defect-free code. Solve that and we've solved the security issues. Focus on the security alone and we won't solve anything.

Changes to Computer Misuse Act will turn security professionals into criminals

ComputerWeekly has just published my opinion on the forthcoming changes to the Computer Misuse Act (CMA). From the article:

The most recent changes to the Computer Misuse Act will give power to prosecute those who help or enable others to commit computer crime. While I am very supportive of this addition, I am also in great fear of this change and its consequences - the amendments are so vaguely worded that they will instantly turn security researchers into criminals once they come into force later this year.

If you are new to the story you'll find more facts in my previous post: Changes to British law target criminals, but affect the entire security industry.

The CMA seems to be intentionally written to be ambiguous in order to cover all sorts of activities, including the legitimate ones, leaving it to prosecutors to decide what is crime and what isn't. Frankly, I think that is ludicrous.

No one disputes that we need to be able to prosecute all criminal activities, but we shouldn't be destroying the innocent people's lifes in the process. Good intentions only count before laws are passed. Afterwards, laws just have lives of their own.

Verizon's Data Breach Investigations Report is a pot of gold

Verizon's 2008 Data Breach Investigations Report is worth its weight in gold, even when you print it on the thickest paper available.

Data breaches. You’ve gleaned all you can from the headlines; now you have access to information directly from the investigator’s casebook. The 2008 Data Breach Investigations Report draws from over 500 forensic engagements handled by the Verizon Business Investigative Response team over a four-year period. Tens of thousands of data points weave together the stories and statistics from compromise victims around the world.

This sort of detailed information has so far only been available to a selected few, while the rest of us have had to speculate. That is now over, and anyone can make decisions based on facts now.

I know different people are going to focus on different aspects but, for me, these stand out:

1. In 62% of the cases errors contribute significantly to data breaches. This means that even if you erradicate insecurity in your applications the breaches are still going to continue.
2. In 53% of the cases the attackers took days, weeks and months to compromise a system after making a successful entry.
3. In 55% of the cases no skills or low skills were used to carry out the attacks.
4. In 85% of the cases the attacks were entirely opportunistic.

I urge you to read the report in full, and a few times over.