アクセリアは、インターネットやサイバーセキュリティを専門とするスペシャリストが身近におりますので、知見にたけた専門家協力の元、お客様のご要望に沿ったソリューションのご提案も得意としております。また、弊社Webサイトでは、「サイバーレジリエンス」と題し専門家によるコラムも連載しております。
ECのミカタでも、コラムをご紹介させていただくことになりました。皆さまの効果的な対策につなげるためのヒントになれば幸いです。

●前回のコラム
　サイバーセキュリティに求められる バランス感覚
　https://ecnomikata.com/company_blog/15023/

アクセリア株式会社
https://www.accelia.net/

サイバーセキュリティが損なわれる原因とは

前回のコラム（https://ecnomikata.com/company_blog/15023/）ではサイバーセキュリティが世界共通の課題であり、皆さんの会社のオンラインでの商売の安心、安全にかかわる大事なキーワードだということをご紹介しました。安心、安全を具体的に考えるうえで、それが損なわれる原因を具体的に考えていくことはとても大切です。

安心、安全が損なわれる、つまりサイバーセキュリティが損なわれる原因とはどういったものでしょうか。今回から数回程度の連載として、サイバーセキュリティが損なわれる原因について、あらためて解説してみたいと思います。

サイバーセキュリティを損なわないために

サイバーセキュリティの安全性について考えるうえでは、まずサイバーセキュリティを分解して考える必要があります。サイバーセキュリティとは前回のコラムで触れたようにサイバースペースの安心、安全のことであり、サイバースペースはそれを構成するコンピュータ、ネットワーク、そしてそれを利用する人間がつながって、相互に情報をやりとりすることで出来ています。つまりサイバーセキュリティを損なわないためには、コンピュータ、ネットワーク、そしてそれを利用する利用者それぞれの安心、安全について、またそれらの相互作用における安心、安全について考える必要があります。

コンピュータやネットワークの安全性について考えるとき、脆弱性、つまりソフトウェアなりハードウェアの脆さ、について考えることが一般的です。ソフトウェアについては、理想的には、脆弱性が全くない状態、つまり、どんなでたらめな入力を与えてもソフトウェアが正しく機能する状態、が望ましいのですが、いろいろな理由からソフトウェアの脆弱性は増え続けています。なおソフトウェア脆弱性に加えて、「設定の脆弱性」「プロトコル脆弱性」「ハードウェア脆弱性」そして「人間の脆弱性」があることを前回のコラムでも触れましたが、これらについてはcrash.academyのオンライン学習コンテンツ（https://crash.academy/lecturer/kadobayashi/）で解説しています。このコラムでも、機会をみて解説することにしましょう。

やっかいなソフトウェア脆弱性

ソフトウェア脆弱性は、とても厄介です。まず間違いを認めて、ミスがおきた箇所を修正して、テストもやり直して、納品した顧客にお詫びして、アップデートするタイミングについて協議して、等々、頭の痛い問題が山積です。そのため、ソフトウェア開発の現場での甘い誘惑は「なかったことにする」です。「誰も気づきやしないよ」「２０万行もあるソースコードの１行だけでしょ」「外部から指摘されたら、そのとき考える」「インターネットにつながったシステムでは使わない前提だから大丈夫」「そんな不正な入力はめったに起きない」「そんな悪意のある入力をする奴が悪い」。。甘い誘惑を正当化する理由は、プライドの高い、頭のいいプログラマならいくらでも思いつきます。

では、ソフトウェアを使う立場である残り大半の人たちは、どうすればいいでしょうか。ソフトウェア脆弱性の有無を検査することはもちろん必要です。これについては巷に情報が溢れているのでここでは詳しく触れません。いちばん厄介なのは、セキュリティ専門家が「これはソフトウェア脆弱性だ」と言っているのに、製造元が「いえ、これは仕様です」と言い張る場合でしょう。ソフトウェアの製造元としては「仕様です」と言わないと製品そのものの作り直しになって、膨大なコストがかかってしまう。セキュリティ専門家はコストなどおかまいなしに、現実に問題が起きているのだから「脆弱性だ」と指摘している。この場合、ソフトウェアやクラウドサービスなどを活用する立場としてはどう考えればいいでしょうか。

仕様そのものが脆弱

意外に多く、そして意外なほど議論されないのが仕様そのものが脆弱であるケースです。ソフトウェア脆弱性がない状態、つまり「どんなでたらめな入力を与えてもソフトウェアが正しく機能する状態」を仕様として想定していなければ、頭のいいプログラマでも「そんな悪意のある入力をする奴が悪い」と開き直ってしまうでしょう。

例えば皆さんの個人情報を預かるデータベースのほとんどは、仕様そのものが脆弱です。データベースというのは、そもそも1970年代に考えられた技術で、データベース専門のオペレータがデータベース専用言語で入力して操作するように作られているわけです。重要なデータを預かるわけですから、データベースは入室制限された区画に鎮座しており、限られた人間だけがアクセスするのが普通でした。これをウェブの登場にともない、インターネットに繋いで商売ができるようにしてしまったのだから大変です。結果として数多くの情報漏洩事件につながり、現在もなくなる気配はありません。
データベース専用言語というのは、本来「そんな悪意のある入力をする奴が悪い」と開き直って作られています。言語を設計するときに、データベース専門のオペレータが十分な知識をもとに操作することを前提としているからです。

つまり、仕様そのものが脆弱です。

しかし、今更そんなことを蒸し返して指摘する人はほとんどいません。仕方がないので、データベースとインターネットの境界で何重にもチェックをして、情報漏洩が起きないようにするわけですが、これとて万全ではありません。

もうひとつ例を挙げるとすればプログラミング言語の脆弱性でしょう。プログラミング言語といえば JavaScript, PHP, C++ など色々ありますが、チェックが厳しいものと、チェックが甘いものがあります（厳密には、専門用語では、静的型検査や動的型検査など、色々な概念があります）。チェックが甘いプログラミング言語は、プログラムを書く時に「面倒なおまじない」が少ないのでプログラムが書きやすく、このため若い人たちが好んで使う傾向にあります。当然チェックが甘いわけですから、ソフトウェア脆弱性が発生するケースも飛躍的に多くなります[1]。
しかし、ウェブでシステムを作っているときに、このあたりを蒸し返して指摘する人はほとんどいません。JavaScript を筆頭にチェックの甘いプログラミング言語が主流になっており、みな感覚が麻痺しているのだと思います。みんなで渡れば怖くない、本当でしょうか。「水飲み場攻撃」(Drive-by download attack) という種類のサイバー攻撃がありますが、本質的にはこのあたりの麻痺した感覚につけ込まれているのだということを理解すべきです。

今回はこれくらいにしておきましょう。次回のコラムでも、セキュリティ専門家でなくても知っておきたいソフトウェア脆弱性の性質について紹介したいと思います。

参考文献
[1] P. Vixie, “Go Static or Go Home”, ACM Queue 13(2), http://doi.acm.org/10.1145/2716276.2721993

コラムは以上となります。

ITエンジニア向け動画配信サービスcrash.academy

本文にも登場しましたが、アクセリアが運営するITエンジニア向け動画配信サービスcrash.academyでは、著者の門林 雄基が講師をつとめる「標準サイバーセキュリティ」シリーズで、サイバーセキュリティの基礎概念を学ぶことができます。
現在、crash.academyでは、オリジナル（有料）講座1本プレゼントのキャンペーンを行っております。
この機会に是非講座を受講いただき、更なるレベルアップを実現していただければと存じます。
キャンペーンページ：https://crash.academy/news/68/

著者

門林 雄基

アクセリア株式会社 主幹研究員
奈良先端科学技術大学院大学 情報科学研究科 教授
Adjunct Professor, Unitec Institute of Technology, New Zealand
日欧国際共同研究「EUNITYプロジェクト」日本側研究代表
WIDEプロジェクトボードメンバー