サイバーエージェント 最高水準のセキュリティへ
NIST CSF 2.0 ベースの独自基準を活用した『Security CREST』制度
Author : 田中 宏明
1. 本稿の目的
本稿は、情報セキュリティガバナンスの強化を検討している情報セキュリティ担当者を対象に、弊社 株式会社サイバーエージェントにおける NIST Cybersecurity Framework Version 2.0 (以下「NIST CSF 2.0」とします) を活用した『Security CREST』制度の取り組みを紹介するものです。
※ NIST CSF 2.0は、米国国立標準技術研究所(NIST:National Institute of Standards and Technology)が2024年2月26日に公開したセキュリティ対策を検討・推進するためのサイバーセキュリティのフレームワークです。
目次
2. 背景
サイバーエージェントでは、様々な規模や環境のプロダクトが多数稼働しており、AWS 環境を活用したプロダクトも多数存在します。そのため、各プロダクトのエンジニアは、各組織のセキュリティ部門やグループ全体を横断するシステムセキュリティ推進グループと連携してセキュリティ対策に取り組んできました。
そのようななか、世間的に話題となったランサムウェア被害の事件を受けて、当社でも更なるセキュリティガバナンスの強化に向けた取り組みが始まりました。それは、各プロダクトにおけるセキュリティ施策の促進と、リスクアセスメントによる継続的なリスクの可視化によって、情報セキュリティ対応の指針を整理するというプロジェクトです。
しかし、サイバーエージェントではプロダクトごとの裁量が大きく、ビジネスモデルや使用しているソリューション、組織体制も多様です。そこで、プロダクトごとの裁量を保ちつつ、セキュリティの実施状況を一元的に評価・可視化できる共通フレームワークを模索することとなりました。その結果、弊社ではサイバーセキュリティに特化しつつ、エンジニア目線で理解しやすい枠組みを提示している NIST CSF 2.0 が共通のフレームワークとして選定されました。
なお、 当社では、エンジニアが NIST CSF 2.0 のフレームワークを自分のプロダクトに当てはめて考えやすくなるように、解説文や参考例を多く盛り込む等、独自にカスタマイズした指針「NIST CSF 2.0 Custom」を策定しております。
3. 「NIST CSF 2.0」を選定した理由
世界的に認められるフレームワーク
NIST CSF は、2013 年に米国オバマ政権下で策定されたサイバーセキュリティフレームワークであり、日本でも経済産業省と IPA が発行した 「サイバーセキュリティ経営ガイドライン Ver.3.0」 において参照されています。
また、AWS をはじめ、多くの組織が NIST CSF をベースとしたベストプラクティスを公開しており、実績と信頼性のある指針です。
以下、当社が NIST CSF 2.0 を選定した理由をご案内します。
3つの選定理由
① 6 つの機能 (Govern, Identify, Protect, Detect, Respond, Recover) の視点
セキュリティの施策を考える際、課題になりがちなのが「今どこのフェーズについて論じているのか」関係者間で認識がズレがちなことです。例えば、インフラ環境の管理一つとっても、予防の話なのか、それとも、有害イベントの検知の話なのかなど、フェーズを整理しないと議論が迷走することになります。
この点、NIST CSF 2.0 であれば 6 機能の観点から、情報セキュリティ対応の一連の流れのうち「今どこのフェーズについて論じているのか」を整理しやすく、現場と認識を合わせやすいと考えました (NIST CSF 2.0 の解釈として 6 つの評価機能は必ずしもフェーズを指さないとも解釈できますが、当社ではエンジニアの共通理解として「今どの部分の話をしているのか」にフォーカスしたため、フェーズという表現をしております)

※ 上記の定義は NIST CSF 2.0 の理解を前提に、NIST CSF 2.0 Custom 用に定義を再設定しております
② Tier (成熟度モデル) による段階的なセキュリティ目標の視点
セキュリティの施策を考える際に、もう一つ課題になりがちなのは「何をどの程度まで行うべきなのか」を判断し難い事です。この点、NIST CSF 2.0 では、Tier (成熟度モデル) により段階的なセキュリティ目標を設定できるので、当社のようにプロダクトごとに基準とするセキュリティレベルが異なる場合であっても、セキュリティ改善目標を Tier の概念を応用することで柔軟に設計できると考えました。
③ 網羅性とボリュームのバランス
セキュリティガバナンスの組み立てにおいては、様々なセキュリティガイドラインや規格、基準を参考にしますが、その中でも NIST CSF 2.0 は網羅性とボリュームのバランスに優れていると感じました。
例えば、政府情報システムのためのセキュリティ評価制度「Information system Security Management and Assessment Program」通称 ISMAP は、1,000 を超える要件を有することから非常に高い網羅性を誇ります。しかし、あまりにもボリュームが大きいことから、様々なプロダクトを擁する当社に適用しようとすると、対応しきれないプロダクトが発生することが懸念されました。
この点、NIST CSF 2.0 は 6 つの機能という大枠を保ちつつ、その中で 22 個のカテゴリ、106 個のサブカテゴリの形で体系的にサイバーセキュリティ活動の成果を定義しています。そのため、どのようなプロダクトであっても、サイバーセキュリティの取り組みに現実的に対応できるボリュームであると判断しました。
4. NIST CSF 2.0 Custom の特徴
先述のとおり、サイバーエージェントでは、NIST CSF 2.0 ベースにした独自指針「NIST CSF 2.0 Custom」を策定しております。
NIST CSF 2.0 のカスタマイズに際しては、エンジニアがいかに具体的にアクションをイメージできるかを強く意識しました。最終的にセキュリティの取り組みを実施するのはエンジニアであるため、抽象論に終始してしまうと具体的なアクションを惹起できないことが懸念されたためです。そこで、カスタマイズに際しては以下の点を重視しました。
①「なぜ」に答える
まず、エンジニアにとって納得感があるように、各サブカテゴリごとに、その遵守目的を明記しました。これは、NIST CSF 2. 0で定義された言葉の要約では無く、当社内のリスクに則り「何のために遵守する必要があるのか」を独自解釈して言語化する取り組みです。
例えば、ID.AM-02:「組織が管理するソフトウェア、サービス、およびシステムのインベントリが維持される」であれば、「インベントリの管理により、用途不明や管理者不明の資産を排除することで、セキュリティリスクを低減する」と目的を明記しています。
➁「スコープ」を明確にする
各サブカテゴリの対象範囲を具体的に記載し、議論の混乱や認識のずれを防ぐようにしました。ここも、NIST CSF 2.0 で定義されたものではなく、当社プロダクトの各環境を念頭に置いて、「どこを確認すればよいのか」を具体的にイメージできるよう、独自解釈して言語化を行いました。
例えば、ID.AM-02で は以下を対象と定義しています。
ⅰ:クラウドリソース
ⅱ:サービス上にインストールされたソフトウェア
ⅲ:コンテナ
ⅳ:ソースコード
もう一例挙げると、PR.PS-06 :「安全なソフトウェア開発の実践が統合され、そのパフォーマンスがソフトウェア開発ライフサイクル全体で監視される」について、ソフトウェア開発ライフサイクル (SDLC) のプロセスを整理すると下記のようになります。
ⅰ:計画
ⅱ:設計
ⅲ:実装
ⅳ:テスト
ⅴ:デプロイ
ⅵ:メンテナンス
このとき、もし PR.PS-06 を何の注釈も無しに提示してしまうと、ⅰ~ⅵ のどのプロセスを論じているのか議論が錯綜する恐れがあります (そもそも、SDLC のプロセスが全員同じ認識とも限らない)。
そこで、当社の場合は、PR.PS-06 は「実装」「テスト」フェーズにスコープを限定し、他のプロセスは他のサブカテゴリに譲るなどスコープの整理を行いました。
③ 参考となる実装例を提示する
各サブカテゴリ各 Tier に対して、参考例として、具体的なソリューションを挙げ、技術者が取り組みのイメージを掴みやすくしています。その際、組織の体制や予算の差異に配慮し、特定のソリューションの採用を必須条件としない柔軟な例示を目指しました。
サイバーエージェントでは、AWS 環境を利用しているプロダクトも多いことから、必要に応じて AWS ソリューションも具体的に提示しています。この点、AWS 様からも具体的なソリューションについてコメントを頂きながら参考例をブラッシュアップしました。
5. NIST CSF 2.0 Custom 作成の流れ
NIST CSF 2.0 Custom の作成は、実際に現場エンジニアとセキュリティコンサルタントが連携しながら、次の流れで進めました。
① 実装対象サブカテゴリの選定
NIST CSF 2.0 のサブカテゴリ全てを実装するのではなく、初期の試行として一部を抜粋しました。狙いとしては、まずは 106 のサブカテゴリのうち、当社のリスクを踏まえて特に重要と判断したサブカテゴリを選定することで、各プロダクトの取り組みを早期に可視化できると判断したためです。また、現場側も論点を絞り込むことで、スムーズに状況のキャッチアップが出来ると判断しました。
② Tier(成熟度)の定義
- Tier 4 : 部分的である
ルールや基準が存在せず場当たり的な状態
※ NIST CSF 2.0 だと「組織のサイバーセキュリティリスク戦略の適用が一時的な形で管理されている」 - Tier 3 : リスク情報を活用している
リスクに基づきプロダクト内でルールや基準が整備/運用されている
※ NIST CSF 2.0 だと「リスクマネジメントプラクティスは経営陣から承認されるが、組織全体のポリシーとして確立されない場合がある」 - Tier 2 : 繰り返し適用可能である
プロダクト内で定期的な実施確認ができている
プロダクト内で運用の抜け漏れ防止施策ができている
※ NIST CSF 2.0 だと「組織のリスクマネジメントプラクティスは正式に承認され、ポリシーとして述べられている」 - Tier 1 : 適応している
プロダクト内でセキュリティ施策が高度に自動化されている
プロダクト内でエンジニアの職務領域を超えて、組織全体で横断的にセキュリティ施策を実施できている
※ NIST CSF 2.0 だと「発生する可能性のあるサイバーセキュリティイベントに対処するためのリスク情報を活用した、ポリシー、プロセス、手順を用いた、組織全体のサイバーセキュリティリスクマネジメントのアプローチが確立されている」

③ 参考例の提示
AWS のサービスや企業内ツールを利用しながら、現場が導入の過程でイメージしやすい具体的な参考例(ソリューションや方法論の例)を提示しました。
参考例の提示に当たっては、下記の AWS リソース (※) を参照し、具体的な方法論を提示するようにしました。また、ソリューションについては実際に AWS からもコメントを頂きました
- NIST の「CSF」に関する運用上のベストプラクティス
- AWS クラウドにおける NIST CSF への準拠
- AWS_Services_and_Customer_Responsibility_Matrix_for_Alignment_to_the_CSF
なお、AWS リソースの NIST CSFは2.0 ではないものの、NIST からは、NIST CSF 2.0 との Mapping 表なども発行されているため、これらを活用しながら参考例をキャッチアップしてきました。
6. 優れたセキュリティレベルを有するプロダクトを賞賛する「Security CREST」
サイバーエージェントでは、NIST CSF 2.0 Custom の策定と同時に、各プロダクトにおける情報セキュリティの高度な取り組みを奨励し、チームのモチベーションを高めるために、社内表彰も行う制度として 「Security CREST」 を立ち上げました。
もともと、当社では各プロダクトのエンジニアが各々セキュリティの取り組みに真摯に向かい合っていたのですが、その活動に光を当てたいという思いから本制度を発足させ、評価軸として NIST CSF 2.0 Custom を策定した流れになります。
なお、「Security CREST」の名称は、優れたセキュリティレベルを有するプロダクトを賞賛することで、サイバーエージェント全体のセキュリティレベルを押し上げ、最高水準 (CREST) を目指すことに由来します。

「リスクアセスメントによる継続的なリスクの可視化」という文脈ですと、どうしてもセキュリティ監査のように一方的な評価点検の雰囲気が出てしまいがちになります。
この点、今回の SecurityCREST は、NIST CSF 2.0 Custom に照らして、キチンと出来ている部分にスポットを当てることをコンセプトにしているので、むしろ、現場側がセキュリティの取り組みとしてPRしたい部分があれば積極的にキャッチアップできるような位置付けとしました。
7. 本取り組みの結果
NIST CSF 2.0 Custom の作成と並行して上述の「Security CREST」制度を発表したところ、社内から自ずと「自分のプロダクトを評価したい」と応募がありました。これは、セキュリティ要件をトップダウンで押し付けるのではなく、エンジニア目線のセキュリティの枠組みを提示したことで、現場の裁量を保ち、現場にとって受け入れやすい形にできたためだと考えています。また、NIST CSF 2.0 Custom の作り込みの過程においても、NIST CSF により論点が整理されていたため、論点がブレることなく議論を重ねることができました。
そして現在、NIST CSF 2.0 Custom に照らした評価が始まっています。これにより、プロダクト側での数あるセキュリティ施策のうち何が出来ていて何が出来ていないのかといった、プロダクトごとのセキュリティ対策状況が一元的に可視化され始めています。
さらに、調査を進める中で、プロダクトの拡張性の観点で気づきが得られたという声もプロダクトチームから挙がっています。具体的には、「ID.AM-02 : 組織が管理するソフトウェア、サービス、およびシステムのインベントリが維持される」という項目において、現場レベルでは利用ソフトウェアやサービスを把握しているものの、それがインベントリとして管理されることで、今後プロダクトの規模が拡大した場合に現状をより把握できるようになると気づけたという声がありました。
これから調査が進むことで、各プロダクトの取り組みが可視化され、それぞれのプロダクトにおいて、セキュリティの指針策定に繋がる気づきを得られていくのではないかと考えております。
なお、一点、NIST CSF 2.0 をカスタマイズする際の注意点としては、柔軟性が高いがゆえに、各サブカテゴリにおいて予め目的とスコープを定義しなければならない点です。ここを怠ると、他のサブカテゴリとの重複が発生するなど整合性にネガティブな影響を与える恐れがあると感じました。この点、サイバーエージェントでは「エンジニア目線」の軸が最初から想定されていたため、目的とスコープを最初から定義できていたことが良かった点です。
8. 今後の展望
① NIST CSF 2.0 Custom による仕組みと可視化
NIST CSF 2.0 Custom を通じて、各プロダクトの情報セキュリティの可視化を実現し、自組織の「現在地点」と「目指すレベル」の間で合意を得ることを目指します。これにより、現場エンジニアの目線で、次に目指すべき方向性を提示できると考えています。
➁ 優れた取り組みの共有
本取り組みを通じて、特に優れた情報セキュリティの実装例を可視化し、それを社内全体に共有します。具体的なソリューションやポリシーの参考例とすることで、他のプロダクトも自然にガバナンスレベルを向上させるドライブが生まれると考えています。
③ NIST CSF 2.0 サブカテゴリの拡張
NIST CSF 2.0 のサブカテゴリを更に拡張し、さらに多様なリスクの可視化を図ります。
④ セキュリティソリューションとのマッピング強化
AWS や自社サービスをはじめ、様々なセキュリティソリューションとのマッピングを更に強化することで、従業員が現場の状況に合った最適な解決方法を選択しやすくしようと考えています。自社ならではの導入例を他プロダクトにも共有し、サイバーエージェント全体のセキュリティレベル向上を図ります。
筆者プロフィール

田中 宏明 (たなか ひろあき)
株式会社サイバーエージェント
システムセキュリティ推進グループ セキュリティガバナンス推進チーム リーダー
ISMS や PCI DSS 等の準拠支援コンサルタントを経て、2023 年 8 月から株式会社サイバーエージェントに入社しました
現在は、セキュリティコンサルタントとして、サイバーエージェントグループ全社のセキュリティガバナンス強化に向けた施策推進に取り組んでいます
AWS を無料でお試しいただけます