海の向こうの“セキュリティ”

米CISAが新たな「CPGs(セキュリティパフォーマンス目標)」発表、18項目からなるIT分野版の固有目標とは

 米サイバーセキュリティ・インフラセキュリティ庁(Cybersecurity & Infrastructure Security Agency、以降CISA)は、情報技術(IT)および製品設計分野向けに自主的なサイバーセキュリティパフォーマンス目標(Cybersecurity Performance Goals:CPGs)を新たに発表しました。

 この「IT分野固有目標(IT Sector Specific Goals:IT SSGs)」についてCISAは、セキュア・バイ・デザインの原則に沿っており、インシデントから当該分野を保護し、製品のリリース前に脆弱性を特定して対処し、インシデント対応を改善し、ソフトウェアセキュリティを大幅に改善するのに役立つものであるとしています。また、IT分野に特化していますが、全ての重要インフラ分野のソフトウェアおよび製品の開発者に、取り組みの焦点となる最低限の基礎的な実践内容(practice)を提供するものであるとも説明しています。

 なお、CISAはすでに「分野横断サイバーセキュリティパフォーマンス目標(Cross-Sector Cybersecurity Performance Goals:Cross-Sector CPGs)」を提供しており、それに基づいた化学分野、エネルギー分野、ヘルスケア分野向けの「分野固有目標(Sector Specific Goal:SSG)」がそれぞれCISAまたはそれ以外の組織から提供されています。今回はその「IT分野版」であり、金融サービス分野向けのSSGの提供も予定されています。

 ここで注意しなければならないのは、今回公開された「IT SSGs」が、分野横断CPGを超える、セキュリティ対策に効果の高い自主的実践内容の「追加項目」であるという点です。つまり、「IT SSGs」だけでなく、分野横断CPGも当然ながら必要となります。

 「IT SSGs」は、11項目からなる「ソフトウェア開発プロセスの目標」と、7項目からなる「製品設計の目標」の計18項目からなり、各項目に対して以下の内容が記載されています。

  • Outcome(結果)
  • TTP or Risk Addressed(TTPまたは対処されるリスク)
  • Scope(範囲)
  • Recommended Action(推奨されるアクション)
  • Measurement(測定)
    主にYes/Noで回答する質問事項
  • NIST SSDF Reference(NIST SSDF参照項目)
  • NIST CSF 2.0 Reference(NIST CSF 2.0参照項目)
  • CISA Secure Software Development Attestation(CISAセキュアソフトウェア開発認証)
  • Cost(費用)
    High/Medium/Lowで記載
  • Impact(インパクト)
    High/Medium/Lowで記載
  • Complexity(複雑性)
    High/Medium/Lowで記載

 ここからは「IT SSGs」の全18項目を紹介します。また、一部の項目では「推奨されるアクション」も紹介します。

ソフトウェア開発(Software Development:SD)プロセスの目標

IT/SD SSG #1

ソフトウェア開発で使用される全ての環境を分離する

IT/SD SSG #2

ソフトウェア開発環境全体に渡って権限付与とアクセスに使用される信頼関係を定期的に記録・監視・レビューする

IT/SD SSG #3

ソフトウェア開発環境全体に渡って多要素認証(MFA)を必須とする

IT/SD SSG #4

ソフトウェア開発環境全体に渡って使用されるソフトウェア製品のセキュリティ要件を確立して必須とする

推奨されるアクション:
- ソフトウェア開発環境全体に渡って使用されるソフトウェア製品のリスクを管理するためのプロセス、ポリシー、手順を文書化する。
- ポリシー、プロセス、手順に従ってソフトウェアを保守、交換、削除する。
- 環境で使用する前にソフトウェアの信頼性と完全性を評価する。

IT/SD SSG #5

ソフトウェア開発環境で使用される認証情報をセキュアに保存および送信する

推奨されるアクション:
- 機密データまたは認証情報をソースコードに保存しない。代わりに、シークレットマネージャを使用するなど、暗号化された方法で機密データや認証情報を保存する。
- SSHキーをセキュアに保存してローテートする。

IT/SD SSG #6

最新式のリアルタイムアラートを備えた効果的な境界および内部ネットワーク監視ソリューションを実装し、疑わしいサイバーインシデントや確認されたサイバーインシデントへの対応を支援する

推奨されるアクション:
- インシデントを宣言するための基準と、役割と責任を明確に定義し、通知を必要とする関係者を特定するプロトコルを含むインシデント対応プレイブックを作成する。
- 企業のインシデント対応チームを任命し、頻繁に机上演習を実施する。

IT/SD SSG #7

ソフトウェアサプライチェーンリスク管理プログラムを確立する

推奨されるアクション:
- コードテストを実施し、ソフトウェアサプライチェーンの実践を監査し、実行したアクティビティを文書化する。

IT/SD SSG #8

ソフトウェア部品表(SBOM)を顧客に提供する

IT/SD SSG #9

自動化ツールまたは同等のプロセスを通じてソースコードの脆弱性を検査し、製品、バージョン、またはアップデートのリリース前に既知の脆弱性を軽減する

推奨されるアクション:
- 必要に応じて、静的アプリケーションセキュリティテスト(Static Application Security Testing:SAST)、動的アプリケーションセキュリティテスト(Dynamic Application Security Testing:DAST)、およびソフトウェア構成分析(Software Composition Analysis:SCA)を実行する。

IT/SD SSG #10

製品リリース前に特定された脆弱性に対処する

推奨されるアクション:
- 製品リリース前にセキュリティ脆弱性が特定された場合に取るアクションを管理するプロセスまたはポリシーを開発、維持、実行する。

IT/SD SSG #11

脆弱性開示ポリシーを公開する

推奨されるアクション:
- 脆弱性開示ポリシー(vulnerability disclosure policy:VDP)を公開して、製造元が提供する製品について一般の人がテストすることを許可し、誠意を持ってVDPに従う努力をしている人に対して法的措置を推奨または追求しないことを約束し、脆弱性を報告するための明確なチャネルを提供し、調整された脆弱性開示のベストプラクティスと国際標準に沿って脆弱性を公開できるようにする。
- 公開されたソフトウェア脆弱性にタイムリーに対処する。

製品設計(Product Design:PD)の目標

IT/PD SSG #1

多要素認証(MFA)の使用を増やす

推奨されるアクション:
- ユーザーと管理者に対してデフォルトでMFA(理想的にはフィッシング耐性のあるMFA)を有効にするように実装するなどして、MFAの使用を増やす。
- 製品に「シートベルトチャイム」を実装して、ユーザーにMFAを有効にするよう促す。これには、ユーザーまたは管理者にMFAが有効になっていないことを通知したり、管理者がフィッシング耐性のあるMFAを有効にするよう提案したりするバナーや隙間広告が含まれることがある。
- 製品のベースラインバージョンで標準ベースのシングルサインオン(SSO)をサポートし、顧客がMFAをサポートする独自のIDプロバイダーの使用を設定できるようにする。

IT/PD SSG #2

デフォルトパスワードの削減

推奨されるアクション:
組織のソフトウェア製品からデフォルトパスワードを削除する。代わりに、次のような別のアプローチを採用する。
- 製品に対して、インスタンス固有のランダムな初期パスワードを提供する。
- 製品をインストールするユーザーに、インストールプロセスの開始時に強力なパスワードの作成を要求する。
- セットアッププロセスが完了すると自動的に無効になり、セキュアなパスワード(またはフィッシング耐性のあるMFAなどのよりセキュアな認証方法)の設定を必要とする、時間制限のあるセットアップパスワードを提供する。
- 初期セットアップとインスタンス固有の認証情報の指定には物理的なアクセスを必須とする。
- 既存の機器配備をデフォルトパスワードからよりセキュアな認証メカニズムに移行するキャンペーンを実施したり、更新を提供したりする。

IT/PD SSG #3

脆弱性クラス全体の削減

推奨されるアクション:
次のようなアプローチで脆弱性クラス全体を削減するよう取り組む。
- パラメータ化されたクエリを実装してSQLインジェクションの脆弱性を削減する。
- メモリ安全性の脆弱性を削減するために、メモリセーフ言語の使用に移行する。
- Webテンプレートフレームワークを使用してクロスサイトスクリプティング(XSS)脆弱性を削減する。

IT/PD SSG #4

顧客にセキュリティパッチをタイムリーに提供する

IT/PD SSG #5

製品のサポート終了が近付き、セキュリティパッチが提供されなくなることを顧客に確実に理解させる

IT/PD SSG #6

組織の製品全ての共通脆弱性識別子CVE(Common Vulnerabilities and Exposures)レコードに共通脆弱性タイプ一覧CWE(Common Weakness Enumeration)フィールドと共通プラットフォーム一覧CPE(Common Platform Enumeration)フィールドを含める

推奨されるアクション:
- 組織の製品の全てのCVEレコードに正確なCWEおよびCPEフィールドを含める。さらに、少なくとも、顧客によるパッチ適用のアクションを必要とする、またはアクティブな悪用の証拠がある全ての致命的または影響度の高い脆弱性(内部で発見されたか、第三者によって発見されたかに関係なく)についてCVEをタイムリーに発行する。

IT/PD SSG #7

組織の製品に影響を及ぼすサイバーセキュリティ侵入の証拠を顧客が収集する能力を高める

推奨されるアクション:
- 可能な限り、全ての製品にログ記録機能があるかどうかを確認する。


 まだ作成して間もなく、推敲が足りなかったのか、書きぶりがそろっていなかったり、表現にぎこちなさもあったりしますが、非常にシンプルかつコンパクトにまとまっており、チェックリストとして使いやすい形になっています。うまく活用してください。

山賀 正人

CSIRT研究家、フリーライター、翻訳家、コンサルタント。最近は主に組織内CSIRTの構築・運用に関する調査研究や文書の執筆、講演などを行なっている。JPCERT/CC専門委員。日本シーサート協議会専門委員。