Tag: security

大勢がレビューしていても信用しないという仮説

大勢がレビューしているから、バグがないという考え方。これは神話です。

この記事は　https://aliceevebob.com/2017/04/04/disbelieving-the-many-eyes-hypothesis/　を翻訳したものです。
コードを書くことは大変な作業です。
ソースコードを書くのは、もっと大変です。もっと、もっと大変なのです。

セキュリティの機能を実装するコードを書いているとわかりますが、このようなコードは詳細まで精査されたアーキテクチャとデザインに基づいています。

さらに世界中でレビューされるというプロセスを経た、パーフェクトで破られることがないスタンダードが反映されているかもしれません。
（「パーフェクトで破られることがない」まあ、本当かどうかは置いておいて、そう仮定しましょう）

が、このようにデザインとアーキテクチャが素晴らしくても、実際のソフトウェアに組み込むのはとても特殊なことです。

数学的にソフトウェアが正しいと証明されても、実現しようとしている機能が正しく実装できるソフトウェアを書くということは、科学と芸術の間にあるようなものです。（デザインとアーキテクチャに寄るとは言っても結局自分が何をしたいかに寄るのですが。）

ソフトウェアをデバッグしたり、ソフトウェアに踏み入ることでその正確さを推測しようとする人にとっては、当然のことです。ただ、このブログ記事のポイントではありません。

誰も（コードを5行以上書いたことがある人、Perlでだったら6行）実際にソフトウェアがこのプロセスでパーフェクトになるとは思わないでしょう。
しかしソフトウェアは出来るだけパーフェクトでバグがないよう作るべきだ、というのはわかってもらえると思います。
だからこそ、コードレビューはソフトウェア開発の中心なのです。

ラッキーなことに（少なくとも私的には）、私たちが日々使うコードのほとんどはオープンソースです。これは誰もがコード見ることができ、何千もの人にレビューしてもらうことができる、ということです。

ここで問題が生じます。
オープンソースがたくさんの人にレビューされるということは、全てのバグが解決されるという考え方があります。

これは神話です。とても危険な都市伝説です。

先ほどの考えには二面性があります。
一つ目は、「ビルドすれば、出来上がる」という間違った考え方です。
世界中に全てのウェブサイトがリストされていた昔、そこにあなたのウェブサイトを登録すれば皆さんに見てもらえると思った時代があったでしょう。
（私も登録しました。見てもらえました。これは奇跡です）

同じように、オープンソースプロジェクトは（おそらく）少なかったので、たくさんの人がコードレビューしてくれました。
このような時代は終わりました。ずっと昔に。

二つ目に、セキュリティの機能を、良い例として暗号化の基礎などですが、正しくレビューできる人はすごく少ないのです。

ベンダー特有のコードに問題が少ないという訳ではありません。むしろ、正反対です。
ベンダー特有のコードのデザインやアーキテクチャがレビューに対してオープンになっていない、ということではなく、コードを見てくれる人が少なくてヒエラルキーなプレッシャーと組織的な考え方に寄る危険性がとても大きいということなのです。

「ベンダーのコードは安全だ」というのは神話というより、フェイクニュースでしょうね。
多くの企業がセキュリティソフトを隠したい理由がよくわかります。
「知的財産の保護」と彼らがよく言うのは、実際リリースするのに安全ではないからなのではないか、と心配してしまいます。
私にとってセキュリティソフトとは、一貫して「オープンなソース」なのです。

では、何ができるでしょう。
セキュリティを気にする企業や組織はリソースを割いて機能を実装したりコードのチェックやレビューができるはずです。そして、そうする責任があると私は考えます。
その部分に私の勤めるRed Hatがコミットしているのです。

同時にオープンソースコミュニティはクリティカルなプロジェクトをサポートし、コードに含まれるレビューの数を増やそうとする方法を探しているのです。（例えば Linux Foundationの Core Infrastructure Initiativeです）

さらに学術組織に、オープンソースソフトの大切さをハイライトすることはもちろん、セキュリティソフトの書き方とレビューという暗黒アートを
生徒に訓練させるよう推奨する必要があります。

改善できることはあるでしょう。事実、改善もしています。
「多くのレビュー（略）神話」はコードを改善できないという訳ではなく、むしろできるということを認識しなければいけません。ただ、もっとエキスパートのレビューが必要だということです。
元の記事：
https://aliceevebob.com/2017/04/04/disbelieving-the-many-eyes-hypothesis/
2017年4月4日　Mike Bursell

Disbelieving the many eyes hypothesis

There is a view that because Open Source Software is subject to review by many eyes, all the bugs will be ironed out of it. This is a myth.

大勢がレビューしていても信用しないという仮説

Writing code is hard.  Writing secure code is harder: much harder.  And before you get there, you need to think about design and architecture.  When you’re writing code to implement security functionality, it’s often based on architectures and designs which have been pored over and examined in detail.  They may even reflect standards which have gone through worldwide review processes and are generally considered perfect and unbreakable*.

However good those designs and architectures are, though, there’s something about putting things into actual software that’s, well, special.  With the exception of software proven to be mathematically correct**, being able to write software which accurately implements the functionality you’re trying to realise is somewhere between a science and an art.  This is no surprise to anyone who’s actually written any software, tried to debug software or divine software’s correctness by stepping through it.  It’s not the key point of this post either, however.

Nobody*** actually believes that the software that comes out of this process is going to be perfect, but everybody agrees that software should be made as close to perfect and bug-free as possible.  It is for this reason that code review is a core principle of software development.  And luckily – in my view, at least – much of the code that we use these days in our day-to-day lives is Open Source, which means that anybody can look at it, and it’s available for tens or hundreds of thousands of eyes to review.

And herein lies the problem.  There is a view that because Open Source Software is subject to review by many eyes, all the bugs will be ironed out of it.  This is a myth.  A dangerous myth.  The problems with this view are at least twofold.  The first is the “if you build it, they will come” fallacy.  I remember when there was a list of all the websites in the world, and if you added your website to that list, people would visit it****.  In the same way, the number of Open Source projects was (maybe) once so small that there was a good chance that people might look at and review your code.  Those days are past – long past.  Second, for many areas of security functionality – crypto primitives implementation is a good example – the number of suitably qualified eyes is low.

Don’t think that I am in any way suggesting that the problem is any lesser in proprietary code: quite the opposite.  Not only are the designs and architectures in proprietary software often hidden from review, but you have fewer eyes available to look at the code, and the dangers of hierarchical pressure and groupthink are dramatically increased.  “Proprietary code is more secure” is less myth, more fake news.  I completely understand why companies like to keep their security software secret – and I’m afraid that the “it’s to protect our intellectual property” line is too often a platitude they tell themselves, when really, it’s just unsafe to release it.  So for me, it’s Open Source all the way when we’re looking at security software.

So, what can we do?  Well, companies and other organisations that care about security functionality can – and have, I believe a responsibility to – expend resources on checking and reviewing the code that implements that functionality.  That is part of what Red Hat, the organisation for whom I work, is committed to doing.  Alongside that, we, the Open Source community, can – and are – finding ways to support critical projects and improve the amount of review that goes into that code*****.  And we should encourage academic organisations to train students in the black art of security software writing and review, not to mention highlighting the importance of Open Source Software.

We can do better – and we are doing better.  Because what we need to realise is that the reason the “many eyes hypothesis” is a myth is not that many eyes won’t improve code – they will – but that we don’t have enough expert eyes looking.  Yet.

* Yeah, really: “perfect and unbreakable”.  Let’s just pretend that’s true for the purposes of this discussion.

** …and which still relies on the design and architecture actually to do what you want – or think you want – of course, so good luck.

*** nobody who’s actually written more than about 5 lines of code (or more than 6 characters of Perl)

**** I added one.  They came.  It was like some sort of magic.

***** see, for instance, the Linux Foundation‘s Core Infrastructure Initiative

Ignorance as a virtue: being proud to say “I don’t know”

“I am the wisest man alive, for I know one thing, and that is that I know nothing.” Socrates

In order to be considered an expert in any field, you have to spend a lot of time learning things.  In fact, I’d argue that one of the distinguishing traits of someone who is – or could become – an expert is their willingness and enthusiasm to learn, and keep learning.  The ability to communicate that knowledge is another of those traits: you can’t really be an expert if you have no way to communicate that knowledge.  Though that doesn’t mean that you need to be a great speaker, or even a great writer: by “communicate” I’m thinking of something much broader.  In the field of security and IT, that communication may be by architecture diagram, by code writing, by firewall rule instantiation, or by GUI, database or kernel module design, to name just a few examples.  These are all ways by which expertise can be communicated, instantiated or realised: the key is that the knowledge that has been gained is not contained, but can be externalised.

There’s another trait that, for me, betrays a true expert, and that’s the ability to say “I don’t know”.  And it’s difficult.  We enjoy and cultivate our expert status and other’s recognition of it: it’s part of our career progression, and it hits the “esteem” block in Maslow’s Hierarchy of Needs[1].  We like people asking our opinion, and we like being able to enlighten them: we take pride in our expertise, and why wouldn’t we?  We’ve earned it, after all, with all that hard graft and studying.  What’s more, we’ve all seen what happens when people get asked a question to which they don’t know the answer to something – they can become flustered, embarrassed, and they can be labelled stupid.*  Why would we want that for ourselves?

The problem, and very particularly in the security field, is that you’ll always get found out if you fake it.  In my experience, you’ll go into a customer meeting, for instance, and there’s either the sandal-wearing grey-beard, the recently-graduated genius or just the subject matter expert who’s been there for fifteen years and knows this specific topic better than … well, possibly anybody else on the planet, but certainly better than you.  They may not be there in the first meeting, but you can bet your bottom dollar*** that they’ll be in the second meeting, or the third – and you’ll get busted.  And when that happens, everything else you’ve said is called into question.  That may not seem fair, but that’s the way it goes.  Your credibility is dented, possibly irreparably.

The alternative to faking it is to accept that awkward question and simply to say, “I don’t know”.  You may want to give the question a moment’s thought – there have been times when I’ve plunged into an response and then stopped myself to admit that I just can’t give a full or knowledgeable answer, and when I could have saved myself bother by just pausing and considering it for a few seconds.  And you may want to follow up that initial acknowledgement of ignorance by saying that you know somebody else who does (if that happens to be true), or “I can find out” (if you think you can) or even “do you have any experts who might be able to help with that?”

This may not impress people who think you should know, but they’re generally either asking because they don’t (in which case they need a real answer) or because they’re trying to trip you up (in which case you don’t want to oblige them).  But it will impress those who are experts, because they know that nobody knows everything, and it’s much better to have that level of self-awareness than to dig yourself an enormous hole from which it’s difficult to recover.  But they’ll also understand, from your follow-up, that you want to find out: you want to learn.  And that is how one expert recognises another.

* it’s always annoyed me when people mock Donald Rumsfeld for pointing out that there are “unknown unknowns”: it’s probably one of the wisest soundbites in recent history**, for my money.

** and for an equivalently wise soundbite in ancient history, how about “I am the wisest man alive, for I know one thing, and that is that I know nothing”, by Socrates
*** other currencies and systems of exchange are available

Systems security – why it matters

… to understand how things will work together, you have to consider them as a system…

“A system is a set of interacting or interdependent component parts forming a complex or intricate whole.  Every system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning.” (Wikipedia: system)

I’ve been involved with various types of security over the years, from features within products to storage, network and other communications security, and including stand-alone application security, cryptographic protocol design and other weird and wonderful issues like why you shouldn’t lose too much weight on holiday.*  That’s a subject for another post.  But what I keep coming back to is systems security.

And that’s because you can design all the security into a particular component that you like, you take as much care in coding it as you like, you can ensure that you compile is safely, you can test it to within an inch of its life, and ensure that it is deployed where and how you like – but if it’s part of a system, and that system has other holes, than you might as well not bother.  We** often talk about “the weakest link in the chain” as a way of pointing out that if you have a single problem in a set of components, that’s what will break.  That’s too simplistic an analogy***, though, as different components interact in different ways with each other, dependent on a variety of factors.

In order to understand how things will work together, you have to consider them as a system, to define what their behaviour as a system will be, and to architect the system with an understanding of the risks, threats and likely attackers that it will have to deal with in its lifetime.

Much of the content this blog may discuss components, but I hope that I’ll manage to explain their place in systems, and how they work together.  Join me: it should be fun****.

*that’s a subject for another post – it’ll be fun

**by which I mean the nebulous “security community”

***don’t start me on analogies

****another disclaimer – I think that security is fun.  Not everybody agrees.  I’m presuming that the fact that you’ve made it this far means that you are at least open to the suggestion.