ICSのサイバーセキュリティリスクをもたらソフトウェア・サプライチェーン問題
2021年末に発生したApache Log4jの脆弱性問題が対岸の火事だと思っているとしたら大変残念なことだと言わざるを得ない。そこで、本記事ではLog4jの脆弱性をおさらいするとともに、どのようにICSと関連しているのかについて述べた上で、現在米国を中心にソフトウェア・サプライチェーン・セキュリティの課題解決のためにどのような取り組みが始まっており、ICS分野にどのような影響が起こりうるのか考えてみたいと思う。
Apache Log4jとは？
Apache Log4jは「アパッチ ログフォージェイ」と読み、オープンソースのJava プログラム用のロギングユーティリティとして2001年1月8日にバージョン1.0がリリースされている。その元となるコードは1995年９月から1998年8月にかけてEUで実施された「SEMPER」プロジェクト[1]におけるEコマースの汎用アーキテクチャ開発の中でJavaベースのツールキットが開発される過程で誕生し、Apacheライセンスによって配布されるオープンソースプロジェクトとしてJavaアプリケーションの標準的なロギングユーティリティとして長く利用されている。システムの性能に影響が少なく、設定ファイルを構成することによってデバッグ情報、エラー情報などをJavaプログラム内からコンソール、ファイル、その他ログサーバ等に出力することができる。プログラムを書いたことがある方なら、こういった機能がどれだけ便利かよくお分かりと思うが、このユーティリティは痒いところに手が届く便利で使いやすいものであるが故に多くのシステムに利用されており、実はICSアプリケーションにも使用されている。
Log4jの脆弱性の概要とオープンソースソフトウェア
発見されたリモートコード実行の脆弱性はCVE-2021-44228[2]として採番され12月10日に公開されたが、対象のバージョンは2.0 beta9から2.15.0までで、これらのバージョンではJava Naming and Directory Interface (JNDI) という機能が、攻撃者の制御下にあるLDAPやJNDIのエンドポイントに対して保護されないため、JNDIのメッセージ置換の機能が有効な場合、攻撃者は制御下のLDAPサーバーからコードを送信することで任意のコードを遠隔実行できるというものである。この脆弱性を解消するためにバージョン2.16.0（Java 8環境向け）と2.12.2（Java 7環境向け）がそれぞれリリースされたが、対策が不完全だったため、新たにサービス拒否の脆弱性としてCVE-2021-45046[3]が採番された。
Log4jに限らず、オープンソースソフトウェアのコードを開発・保守しているのはインターネットを通して個々のプロジェクトに参加している開発者達で、個人的な興味や、仕事上の必要性に駆られて[4]参加し、コードを書き、修正し、今回のように脆弱性が発見されれば開発チームのメンバーはインターネット上のプロジェクトのホームページやリポジトリと呼ばれるソースコードや設計文書やメンバー間のチャットなどが紐づけられたサイト上で共同の開発作業を行なっている。
Apache Logging ServicesTM のホームページ
Log4jのソースコードや開発文書は、他の多くのオープンソースソフトウェア同様、GitHubに格納されている。
ここで重要なのは、Log4jはオープンソースソフトウェアであり、これらの脆弱性の修正は開発プロジェクトに任意で参加している開発者達が行っているということ、またコードの更新頻度が高いことである。そして、Log4jのように広く利用されて活発な開発が継続しているソフトウェアでは、Contributor（コントリビューター）[5]によって短期間で脆弱性を修正した新しいバージョンが提供される。
Log4jで発見された脆弱性はリスクの高いものではあったものの、開発チームのメンバーが問題を分析し、課題ごとに対処していった様子をJIRAと呼ばれるバグ追跡ツールを通して誰もが確認することができ（図5）、GitHub上では、誰もが更新頻度や関わっている開発者の人数などを確認することができる。[6]このように、オープンソースソフトウェアの良いところは、必要なソフトウェアを必要とする人たちが共同で開発保守し、課題を可視化するための仕組みがあるところだが、一方で、更新頻度が低いソフトウェアは脆弱性が発見されても修正されるまで時間がかかるか、修正されないことが起こりうる。これは商用ソフトウェアを利用しているときと状況は大きく変わらない。仮に商用ソフトウェアを利用して自社の製品やアプリケーションを開発していたとしても、利用者が増えずに市場から消えていったソフトウェアは沢山あったわけで、入手できなくなれば他の商用ソフトウェアに置き換えるか、自ら必要なソフトウェアを開発するか、あるいは当該ソフトウェアが実現していた機能を破棄するかの選択に迫られることになる。また、脆弱性が発見された場合は開発ベンダーが脆弱性対策を施したパッチやアップデートを待つことになる。これはオープンソースソフトウェアの利用に際しても同じリスクが存在しているのである。
Log4j の2022年2月から3月の1ヶ月間に関与した開発者数と更新内容
お使いのICSアプリケーションとLog4jの脆弱性の影響詳細は各メーカーのホームページにて確認いただけると思うが公開していない場合もあるので個別にお問い合わせいただく必要があるだろう。影響が広範に認められたケースもあるので、運用中の設備で利用している製品については調査されるよう強くお勧めしたい。
Log4jの脆弱性が発見されたおかげで、これらの製品がJavaを用いて開発されオープンソースソフトウェアを組み込んでいることが明らかになったわけだが、ユーザーにとっての利点があったとすれば「Javaや関連するオープンソースの脆弱性情報の感度を上げておく」ことが必要だと認識する機会になったことだろう。感度を上げておくことで、悪意ある第三者が新たに発見された脆弱性を悪用して問題を引き起こす可能性をメーカーと同じタイミングで察知することができ、対処するための準備を開始できるからである。
実は、今回のLog4jのようなオープンソースの脆弱性によって発生する問題を社会全体で可視化して対処するための仕組みがすでにあり、Software Bill of Materials（SBOM）あるいはソフトウェア部品表と呼ばれている。
SBOM（ソフトウェア部品表）とはどのようなものか
製造業で部品表といえば、設計部品表や製造部品表のように、製品の設計開発段階から部品の調達から製造工程までで共有される「製品を構成する多種多様な部品の台帳」のことだが、いままでソフトウェアの世界ではこのような「部品表」というものは利用されてきていなかった。ソフトウェアは人が書いているわけだが、オープンソースが登場してからも現在に至るまでソフトウェアの部品を管理するという考え方はあったものの、それはそれぞれの開発組織の中で独自に行われていたもので、サプライチェーンの上流と下流とで共有されることを想定していなかった。
自動車、家電製品、パソコン、スマートフォンや家具など、工業製品は（恐らく）殆どが製品を構成する「部品」を管理するために「部品表」があり、製造や保守のために納入業者に発注し、倉庫の在庫の数を確認し、工場のラインに投入される際に参照されている。しかし、ソフトウェアは必要な時にインストールするなどして利用できるようにしてあればよかった。しかし、サイバー犯罪やサイバーインシデントと呼ばれるソフトウェアの脆弱性や弱点を悪用した事件や犯罪の影響が拡大したことで、この「脆弱性」や「弱点」などのソフトウェア固有の問題を根本的に解決するために登場したのがSBOMなのである。
電子化された工業製品の多くはソフトウェアがなければ動作しないが、そのソフトウェアはオープンソースや商用ソフトウェアなど非常に多くの「部品」を用いて組み立てられており、それらすべてを特定して部品表を生成することにより、脆弱性が発見された時点でどの製品向けのソフトウェアに影響があるかがたちまち判ることになる。いままでは部品表が無いためLog4jに脆弱性が見つかってもどのソフトウェアがLog4jを使っているかは開発者やごく一部の人しか知ることが無かったが、SBOMによってサプライチェーン全体で流通するソフトウェアに含まれる「部品」の一覧が共有されることになるため、問題の発見と対処に費やす時間を大幅に削減することができるということになる。このソフトウェア部品表を開発推進してきた米国のNTIAという組織では、ITやソフトウェア開発に詳しく無い議員や経営者などに説明するため、SBOMとはお菓子のパッケージに印刷されている食品添加物の一覧と同じ意味を持つのだと説明している。たとえば、蕎麦アレルギーを持っている人はパッケージの食品添加物一覧に蕎麦があるかどうかを確認すれば良いということだ。同様に使用するソフトウェアに含まれる「部品」を知ることができ、Log4jが含まれていることがわかれば、パッチを当てる、あるいはソフトウェアの提供元に対して対策を求めるなどの対処が速やかに行えるようになるのである。
もちろんパッチが当てられない場合があることは承知しているので、「対処」にはパッチを当てずに他の対策を行うことも含まれるのは言うまでもない。
なお、SBOMを流通させるための国際規格はLinux Foundationの推進するSPDX（ISO/IEC 5962:2021）と米国NISTのSWID（ISO/IEC 19770-2:2015）が成立しており、OWASPが推進するCycloneDxは急速に支持者を増やしており台風の眼となりつつある。本記事ではこれらSBOMの規格の詳細を述べないが、最後に少しだけ米国などで高まっているソフトウェアのサプライチェーンセキュリティ問題とSBOMの導入の動向について述べることとする。
米国大統領令とソフトウェアサプライチェーンのセキュリティ問題
2021年5月12日、バイデン大統領によりEO 14028, Improving the Nation’s Cybersecurity.（大統領令 14028、国家のサイバーセキュリティの向上）が発令さ[7]れた。米国は大規模なサイバー攻撃やサイバー犯罪に苦しめられてきたが、具体的な対策についての指示を2022年5月11日までのロードマップと緻密かつ大胆な指示が行われている。特にソフトウェアを含む製品やサービスの調達に関してSBOMの提出が求められることとなり、米国政府の調達品目にかかわらず、今後急速に米国内ではSBOMの提出が一般化するのでは無いかとも言われている。先に述べたように、ソフトウェアは非常に便利だがサイバー攻撃などでは脆弱性を悪用されることになるが、そもそも脆弱性のあるソフトウェアがどこで使われているか分からないまま対策していたことが問題だとようやく気がついたのである。そして、米国政府の調達品、それがソフトウェアであれ、ソフトウェアをインストールした機器であれ、どのようなソフトウェアを組み合わせて構築してあるのか素性を明らかにすることが求められるということになる。詳細な条件は今後明らかになると思われるが、設備系での調達も対象となるだろう。
同様にソフトウェアを可視化することで課題を明らかにする動きは、消費者向けのネットワーク機器、医療機器、自動車などさまざまな分野で議論が進んでおり、国際医療機器規制当局フォーラム（IMDRF）はすでにサイバーセキュリティに関するガイドラインを更新しており、厚生労働省も令和2年5月13日にIMDRFのガイダンスの周知を行なっている。経済産業省はタスクフォースを構成し、現在SBOMの実証プロジェクトなどを進めており、今後さまざまな産業分野でソフトウェアを安全に利用するための取り組みが行われてくるものと思われる。
まとめ
Log4jというオープンソースソフトウェアの重大な脆弱性は、ソフトウェアを利用することのリスクを明らかにしたが、それは産業分野を選ぶものではなく、オープンソースソフトウェアによって多様な製品が支えられていることを理解するきっかけとなった。またこの機会にソフトウェアサプライチェーンやソフトウェア部品表（SBOM）という考え方や取り組みを理解することで、差し迫っているあたらしいリスク管理の世界的な取り組みについて適切な対応が可能になるのでは無いかと思う。
[1] SEMPER(Secure Electronic Marketplace for Europe) project https://cordis.europa.eu/project/id/AC026
[2] リモートコード実行の脆弱性（Remote code execution）とは、ネットワーク越しに対象のアプリケーションを悪用し、任意のプログラムコードを実行することができる欠陥
[3] サービス拒否（DoS/Denial of Services）とは、正常な処理ができなくなるよう大量の要求やデータで通信やアプリケーションを溢れさせることで発生する障害で、このような障害を発生させる攻撃をDoS攻撃と呼ぶ
[5] Contributorとは、プロジェクトに参加し、コードを書き、修正や改善、保守を行う任意の開発者のこと。
[6] 原稿執筆時（2022年3月15日）のContributorの数は99名のようである。
[7] https://www.synopsys.com/blogs/software-security/ja-jp/biden-cybersecurity-executive-order/
※この元記事は月刊計装2022年5月号に寄稿したものです。
