【GitGuardianブログ】国家のサイバーセキュリティ向上に関する大統領令（ＥＯ）ー「クリティカルソフトウェア」とは、またそのセキュリティ対策とは？ー

本記事は、GitGuardian社のホームページで公開されたブログ記事を日本語に翻訳したものです。GitGuardian社はGitHubから流出した機密情報をリアルタイム検知するサービスを提供しています。
（原題）Improving the Nation’s Cybersecurity — What is ‘Critical Software’ and how should it be secured?
https://blog.gitguardian.com/improving-the-nations-cybersecurity-what-is-critical-software-and-how-should-it-be-secured-part-1/

米国国立標準技術研究所（National Institute of Standards and Technology、以後NIST：）は2021年5月12日、米国大統領令（EO）14028号の発令を受け、米国のサイバーセキュリティ向上のための施策を開始しました。本施策の一環として、NISTは「Critical Software（クリティカルソフトウェア）」、すなわち組織のサービスや事業を運営する上で必要不可欠なソフトウェアについて、定義・公開しています。本情報には、こうしたクリティカルソフトウェアに対するセキュリティ対策のためのガイドラインが示されており、米国連邦政府機関に向けた、組織内に導入されている対象のソフトウェア、すなわちEO-クリティカルソフトウェアを特定し、安全に使用するための指針ともなっています。

本来この情報は連邦政府機関向けに公開されたものですが、当社ではこうした基準をソフトウェア産業全体で共有し、結果として強化されたセキュリティをそれぞれの事業に活かすことを期待します。本記事では、NISTにより公開された情報を、わかりやすくまた、実際の業務にも応用できるような形で紹介していこうと思います。

本情報がビジネスにとって重要な理由

ソフトウェアは現代のビジネスにとって欠かせない存在です。ウェブサイト、ウェブアプリケーション、モバイルアプリを運用する企業の場合、これらはすべて攻撃の侵入ポイントとなり得ます。アプリケーションの75％以上に少なくとも1つのセキュリティ上の欠陥があり、そのうちの24%が重大な欠陥だと言われています。こうしたアプリケーションの多くがインターネットに接続されているため、インターネット接続があれば誰でもアクセスできてしまいます。つまり、攻撃に対して非常に脆弱な状態にあると言えます。

攻撃者はこれまでにも、ウェブサイトやウェブアプリケーションを能動的にスキャンし、脆弱性を特定するコンピューターボットを開発しています。ある調査によると、Github上で意図的にリークされた、漏えいリスクのあるAWSの認証情報の場合、わずか1分で特定・悪用できてしまうことが分かっています。このことは、未確認・未公開の脆弱性に対し、攻撃者がどれほど短時間で行動を起こすのかを示した一例すぎず、我々はデジタル資産をどう保護していけばよいか、その方法を心得ておく必要があります。

今回の大統領令14028号は、サイバー脅威から身を守る企業の取り組みの支援を目的として発令されました。

「EO-クリティカルなソフトウェア」とは

NISTは、大統領命令で規定するクリティカルなソフトウェア、すなわち「EO-クリティカルなソフトウェア」について、以下の属性を少なくとも1つ持つ、単独または複数のコンポーネント（ソフトウェアの構成部品）に対し直接的なソフトウェア依存関係を持つソフトウェアと定義しています：

• 権限昇格または管理権限で動作するように設計されている
• ネットワーキングやコンピューティングのリソースに直接または特権的にアクセスできる
• データまたは運用技術へのアクセスを制御するよう設計されている
• 信頼に不可欠な機能を果たしている
• 通常の保護の境界外で、特権的なアクセスで動作する

* NISTはソフトウェア的依存関係について、単体のソフトウェアに直接組み込まれているまたはその動作に必須のコンポーネントと定義している。よくある例として、ライブラリ、パッケージ、モジュール等がある。
* 信頼に不可欠な機能には、ネットワーク管理、エンドポイントセキュリティ、ネットワーク監視、ネットワーク保護といったセキュリティ機能に使用されるソフトウェアのカテゴリも含まれる。

上記の属性が重要である理由

権限昇格
ユーザーあるいはソフトウェアがもたらすことのできる被害の大きさは、その権限レベルに制限されます。例えば管理レベル権限で動作するプログラムの場合、実行環境であるシステムおよびネットワーク上ではほぼすべての操作が可能です。これとは対照的に、ゲストアカウントの場合、もたらされる被害はほぼ皆無です。結果、権限昇格で動作するソフトウェアプログラムの場合、アカウントの不正アクセス＝重大な被害となるため、リスクが高くなります。このような理由から、権限昇格で動作するソフトウェアプログラムはクリティカルソフトウェアであるとみなします。

ネットワークリソースに対する直接または特権的にアクセスできる
ネットワークリソースにアクセス可能なソフトウェアは、ネットワークのほかの部分に不正アクセスするための侵入ポイントとして利用されることがあります。こうしたアクセスは基本的に玄関口の役割を果たし、ソフトウェアが不正にアクセスされた場合、企業ネットワークへの侵入が可能になります。このようなアクセスが権限昇格で行われた場合（特権アクセス）、想定される被害の大きさはさらに拡大します。

データまたは運用技術へのアクセス管理
データまたは運用技術へのアクセスを管理するソフトウェアには主に2つの懸念があります。一つは、攻撃者により企業データへのアクセス手段として利用され、データを窃取、暗号化（ランサムウェア）されるあるいは社内ネットワークのほかのテクノロジーにアクセスされる可能性。もう一つは、リソースを使用できない状態にすることでビジネスが機能不全になる可能性です。後者の例として最も大きなものは、ランサムウェアとDDoS攻撃です。いずれのケースも、被害に遭った場合、何週間あるいは何か月もの間、事業中断を余儀なくされてしまいます。

信頼に不可欠な機能
このテーマは、社内においてセキュリティ機能を担うソフトウェアすべてが対象です。攻撃者がこのタイプのソフトウェアを不正に制御あるいはアクセスできてしまった場合、企業は攻撃に対して無防備な状態となり、企業ネットワークへの侵入ならびに長期的な潜伏の足掛かりとして死角を作られるといったことが懸念されます。

通常の保護の境界外で、特権的なアクセスで動作する
企業における通常の保護制限の管理下にないソフトウェアで、中でも権限昇格で動作するソフトウェアは、通常のアプリケーションに比べて危険度が増大します。つまり、こうしたアプリケーションはほかのソフトウェアに課される通常のチェックおよび調整の対象から外れることを意味し、その結果、セキュリティインシデントを回避する目的で監視ならびに使用の制限が必要になります。

「EOクリティカルなソフトウェア」に対するセキュリティ施策（SM）

SM-1：「EOクリティカルソフトウェア」および「EOクリティカルソフトウェアプラットフォーム」を不正アクセス・不正使用から保護する。

• 「EOクリティカルソフトウェア」の全ユーザーおよび管理者に対し多要素認証を実施する。
• 「EOクリティカルソフトウェアまたはソフトウェアプラットフォーム」へのアクセスを試行するサービスごとに一意に識別・認証を行う。
• ネットワークベースの管理では特権アクセス管理方針に従う。例えば、管理用プラットフォームのセキュリティレベルの向上（脆弱性の軽減等）、管理セッションすべてをログに記録する、管理者ごとに一意のIDを求めるといった方法があります。
• ネットワークセグメンテーション、アイソレーション（分離）、ソフトウェア定義の境界、プロキシ等で「EOクリティカルソフトウェア」を境界防御する。

SM-2：「EOクリティカルソフトウェア」および「EOクリティカルソフトウェアプラットフォーム」で使用されるデータの機密性、整合性、可用性を確保する。

• 「EOクリティカルソフトウェア」のデータに対しインベントリを作成し、保守する。
• データおよびリソースに対するアクセス管理を細かく設定し、「最小限の原則」（PoLP）を実践する。
• 「EOクリティカルソフトウェア」で使用されている機密データを暗号化することで、保存データを保護する。
• 機密の通信を相互認証・暗号化することで通信のデータを保護する。
• データのバックアップ、バックアップの復元の練習、万一の緊急事態に備えたデータの復旧体制を整える。

SM-3：「EOクリティカルソフトウェアプラットフォーム」およびこれらプラットフォームに導入されているソフトウェアを特定・管理し、「EOクリティカルソフトウェア」の悪用を防ぐ。

• 「EOクリティカルソフトウェア」が動作するすべてのプラットフォームを対象にソフトウェアインベントリを作成し、管理する。
• パッチ管理プラクティスを活用して、「EOクリティカルソフトウェアプラットフォーム」およびそれらプラットフォームに導入されているすべてのソフトを管理する。
• 構成管理を活用して、すべての社内端末でセキュリティ設定が適切に行われるようにする。

SM-4：「EOクリティカルソフトウェア」および「EOクリティカルソフトウェアプラットフォーム」が関与する脅威およびインシデントに速やかに検出、対応、復旧する。

• ログの採取を設定し、「EOクリティカルソフトウェア」関連のセキュリティイベントの必要情報を記録する。
• 「EOクリティカルソフトウェア」のセキュリティ状況を継続的に監視する。
• エンドポイントセキュリティ保護を導入する。
• ネットワークセキュリティ保護を導入する。
• セキュリティオペレーションスタッフおよびインシデント対応チーム全員に対し、それぞれの役割と責任に応じたトレーニングを実施する。

SM-5：「EOクリティカルソフトウェア」および「EOクリティカルソフトウェアプラットフォーム」のセキュリティにつながる人間の行動について理解を深め、パフォーマンスを強化する。

• 「EOクリティカルソフトウェア」のユーザー全員に対し、それぞれの役割と責任に応じたトレーニングを実施する。
• 「EOクリティカルソフトウェア」および「EOクリティカルソフトウェアプラットフォーム」の管理者全員に対し、それぞれの役割と責任に応じたトレーニングを実施する。
• セキュリティに対する認識を高める活動を頻繁に実施する。

事業全体のインターネットおよびソフトウェアの使用状況のボリュームを考えると、ソフトウェアベースの脆弱性は今後も高い確率で攻撃者にとっての有力な侵入経路になっていくものと考えられます。企業にとっては、自社の最重要のデジタル資産を見極め、そうした資産、特にインターネットに接続するソフトウェアアプリケーションの保護策を講じる方法を心得ておくことが重要です。NISTにより定義された上記の枠組みは、事業活動における効果的なサイバーセキュリティプログラムを構築する指針となります。米国大統領令（EO）14028号は、事業活動のセキュリティ実現のための複数レイヤーで構成されており、「EOクリティカルソフトウェア」は今回の施策のほんの一部分にすぎません。

本シリーズの次の記事では、ベンダーがソフトウェアソースコードを検証する際の最低基準を提案するNISTのガイドラインを取り上げようと思います。この最低基準は、ソフトウェアを販売する企業の方はもちろん、次の購入を計画しているユーザーの方にも、ぜひ知っておいていただきたい内容です。
※GitGuardian社のブログにアップされましたら、テリロジーワークスのサイトでもご紹介いたします。