様々な業界でデジタルを活用したスピーディーな事業創出が主要テーマとなっており、それに適合させた人材・組織の変革が経営課題となっています。しかし、全社的なセキュリティのあり方はそこに十分最適化されているでしょうか。硬直的なセキュリティポリシーが隠れた阻害要因になっていないでしょうか。そこには、デジタルを活用する事業部門主導で積極的に脆弱性等のリスクを特定しつつも、ムダな対応を極力生まない"リーン"な未来志向のセキュリティ文化づくりがカギになります。
これを志向した場合に多くの組織で直面することになる現実とのギャップ、それを乗り越えるためのマクニカなりのアイデアについて、テクノロジーと組織の両面から実例も踏まえて共有します。
テクノロジーで高速化する事業開発スピードとセキュリティ対応の"ムダ"
事業開発の普遍的な手法であるリーンスタートアップは、アイデアをできるだけ早く形にして、顧客にMVP（Minimum Viable Product）として提供します。その結果を計測してデータを学習し、新しいアイデアを反映してブラッシュアップしていきます。事業開発では、このサイクルを早く回すことで、新規事業につきまとう不確実性を埋めていくことが重要になります。
テクノロジーの進化によって、このサイクルをより高速化させることが容易になりました。例えば、PaaSを利用すれば、ユーザーはインフラをほとんど気にすることなく、アプリケーションに集中してサービスを開発できようになります。また、自然言語からAIがコードを自動生成するGitHub Copilotのようなテクノロジーにより、将来は超高速開発が当たり前になるかもしれません。
そうした時代のセキュリティはどうなっているのでしょうか。先に挙げたGitHub Copilotで生成されるコードには、まだセキュリティの不備が混在しており、GitHubはコードの不備を自動的に検出するCodeQLの併用を推奨しています。つまり将来は、AIによってコードが自動生成され、同時にセキュリティリスクを自動的に検知して修正方法が提示されるようになることも予想されます。
一方で、現実に立ち戻ると、開発においては、膨大なセキュリティガイドラインに準拠し、承認を得なければなりません。脆弱性検査で数百～数千もの脆弱性が検出されたり、危険度が「高」に分類される脆弱性が多数見つかったりすれば、脆弱性ごとに対処方針を決め、セキュリティ部門にレポートする必要があります。リリースの直前に問題が指摘されれば、開発チーム側に大きな手戻りが発生してしまいます。このように、テクノロジーとは別の課題は多くの企業が共通して持っているものでしょう。リーンで効率的なセキュリティを阻害する"ムダ"が数多く存在しているのではないでしょうか。
クラウドやAIなど事業開発においてアイデアを形にするテクノロジーの進化が、今後も事業開発のスピードを指数関数的に高めていく中で、レガシーなセキュリティ体制を維持したままでは事業開発のボトルネックになり、事業開発のサイクルがうまく回らなくなることが危惧されます。
テクノロジーと組織文化から探る"ムダ"の発生要因
こうしたセキュリティ対応での"ムダ"は、なぜ発生するのでしょうか。企業の組織構成で見た場合、従来のセキュリティチームは組織全体で捉えた「コーポレートセキュリティ」の観点から、統合的なガバナンスの確保や画一的なリスクマネジメントに取り組んできました。
一方で、新規事業の開発チームは、さまざまな不確実性の中で顧客や市場を獲得し、競合に打ち勝たなければならず、スピードや変化が非常に重要な要素となります。特にデジタルを活用した新しいサービスでは、セキュリティリスクが重要事項になります。昨今では、リリース直後のサービスがセキュリティ事故よって終了を余儀なくされる出来事が発生しており、開発チームはセキュリティリスクに向き合うことが必須となっています。
開発とセキュリティの間にこのようなズレが生じるのは、「ビジネスとセキュリティの関係性」「セキュリティリスクに対する正しい認識」「組織構造と責任モデル」に起因すると考えられます。実際にお客さまの現場では次のようなシーンを目にします。
「ビジネスとセキュリティの関係性」でA社のケースは、セキュリティ検査で発見された脆弱性の優先度が「中」以上の場合に必ず対処することにしており、対処をしない場合には、セキュリティチームを含めた会議で理由を説明し、必ず統括部長の承認を得るプロセスとしていました。
また、Z社のケースでは、開発に利用する全てのオープンソースを所定のExcelファイルに記録することとしており、ガイドラインに準拠しないオープンソースは利用しないルールとしていました。こうしたことを徹底すれば、開発チームには膨大な確認作業が発生します。このようなケースでは、セキュリティチームが開発チームを統制、コントロールするという発想にあり、開発チームに過剰な負担が発生している現状があります。
「セキュリティリスクに対する正しい認識」におけるS社のケースは、CVSSのスコアが「9.8」であり「Critical」に分類される脆弱性を必ず修正べきと判断していました。ある時、システム全体で50件もの「Critical」に分類された脆弱性が見つかり、1週間でこれらの精査と対処方針の説明資料を作ることになりました。逆のケースもあります。B社では、CVSSのスコアが「6.5」かつ「Middle」に分類される脆弱性について、リスクレベルが低いとの判断から、対応を見合わせていました。
S社やB社のケースは、一見すると適切な対応に見えますが、CVSSのような公的なスコアをそのまま適用してしまうことで、過大にリスクを見積もるまたはリスクを見逃すといった問題が生じている場合があります。ここでは正確なリスクを判断するための知識や手段を持ち合わせていることが重要となります。
「組織構造と責任モデル」におけるA社のケースでは、開発チームの役割が事業開発への貢献であり、セキュリティについてはセキュリティチームの責任範囲であり、開発チームはセキュリティ部門の責任やルールに関与できず、レポートラインも異なっていました。反対にH社のケースでは、セキュリティチームが開発チームに関与できない環境でした。権限がなく、また、開発効率が低下した際の責任を追及される懸念があったからです。
現在は、開発段階からセキュリティを組み込み、安全を確保していくDevSecOps関連のツールが普及していますが、仮に良いツールでも、組織構造や責任のあり方が変わらないのでは、効率性が大きく変わることはありません。ほとんどの企業では、開発の責任は開発チーム側に、セキュリティの責任はセキュリティチーム側にある形で運営されているでしょう。開発プロセスにおいて組織が分かれている状況は分断をもたらし、先述したように、リリース直前に実施したセキュリティ監査で問題が見つかった場合に、開発側にプロセスが引き戻される状況に陥ります。
開発が主導する"リーン"なセキュリティの実現
そもそも、セキュリティに"ムダ"がない状態（＝リーン）とは、どういうことでしょうか。簡単に言えば、リーンなセキュリティとは、ビジネスリスクとセキュリティ対応の負担のバランスが取れている状態です。例えば、ビジネスリスクが小さいにもかかわらずセキュリティ対策が過大なら、バランスが釣り合わずにムダが発生しているというわけです。
そこで、開発チームとセキュリティチームが別々に運営されセキュリティを実装している現状から、開発チームの中で開発とセキュリティの責任を果たしセキュリティのリーダーシップを発揮できる人材（セキュリティチャンピオン）をアサインする形が望ましいと言えます。
世界においても事業開発の中にセキュリティをボトルネックとすることなく取り込むことが課題になっています。セキュリティチャンピオンの概念は、現在世界標準となり数多くのガイドラインやドキュメントが整備され、そのプログラムの実践が推奨される状況です。
アプリケーションの静的解析サービスを手掛けるVeracodeによると、セキュリティチャンピオンとは、「セキュリティに関心がある開発者」と定義されます。「セキュリティに関心がある」という部分が重要で、決してセキュリティの専門家である必要はありません。開発の中で潜在的な問題に関心を持ち、問題を解決していく、あるいは、CISOなどに指導を求めることができる人材となります。
セキュリティチャンピオンについて、全社的なプログラムを導入するメルカリが取り組みを公開（https://mercan.mercari.com/articles/19140）しています。ここでは、セキュリティの知見やスキルセットを獲得するためコンテンツや教育機会が用意され、開発チームでセキュリティチャンピオンに相当する人材がこれらを利用し、最終的にセキュリティを自己解決でき、開発の中で迅速にビジネスリスクに応じた判断ができることを目指しています。
また、あるオンラインサービス企業では、開発チームの中に少なくとも1人はセキュリティに関心のある人材がおり、自ら調査してセキュリティリスクを判断しています。Slackにセキュリティチームと開発チームの中心メンバーが参加するチャンネルを作り、さまざまな情報を共有しています。実質的なセキュリティチャンピオンが橋渡し役を担っているのです。
2社の事例は、IT企業だからできるという面もありますが、巨大な組織でDevSecOpsを実践しているのが米国国防総省（DoD）です。DoDが公開しているリファレンスデザインには、組織のシニアリーダー層が理念に賛同し、開発や運用、セキュリティを一体で推進する組織文化に変革すること、責任の共有と全ての利害関係者から賛同を得ていくこと、スモールスタートで取り組みながら徐々に変革していくといったことが示されています。
セキュリティチャンピオンプログラムの展開では、まず開発チームの中でセキュリティを主導すると決意し、シニアレベルと合意することが重要です。そして、人材をアサインし、セキュリティチームと連携し、セキュリティチャンピオンが学ぶべきテーマを決めます。テーマは、難し過ぎず現場で活用できる内容が肝心です。開発チームで実践し検証しながら成果を取り入れるサイクルを回していきます。
セキュリティチャンピオンが最初に学ぶテーマとしてマクニカがお勧めするのは、オープンソースの脆弱性管理です。オープンソースの脆弱性は、サイバー攻撃に悪用される点でもリスクレベルが高いですし、脆弱性管理の仕組みや指標も体系化されているので、セキュリティチャンピオンが比較的取り組みやすいでしょう。
学ぶべき内容の例として、脆弱性は全て危険で必ず対処すべきという観念がありますが、実際には攻撃で悪用されるものが全体の5％程度であり、その5％の中でリスクレベルに応じた対応をしていくことになります。CVSSスコアも同様で、評価値が「7.0」以上の脆弱性は特に危険で率先して対処すべきと思いがちですが、CVSSの評価値は脆弱性の深刻度であって、セキュリティリスクではないことが明示されています。こうしたことを正しく認識することで、脆弱性管理の見方が変わります。
欧米では、リスクベースで脆弱性を管理する考え方が広がりつつあります。ここでは、侵害を受けたサーバーが個人情報を扱うか否かといった「資産の性質」と、攻撃の発生可能性や実際の状況といった「脆弱性の性質」の2つをかけ合わせて対応を判断していくことになります。
まとめ
セキュリティチームが開発チームのセキュリティチャンピオンをサポートし、開発チーム内のセキュリティチャンピオンは率先して脆弱性やリスクへの対応を判断できることが必要です。マクニカでも取り組んでいますが、今後、テクノロジーによって自動的に対応の優先順位付けやリスク分析ができる仕組みが実現されれば、そのアウトプットの知見を持ったセキュリティチャンピオンがスピーディーに正しく対処するための判断を行っていくことになります。このようなコンセプトが実装されることにより、組織とテクノロジ―の両面から、事業開発のスピードを損なうことのない非常にリーンなセキュリティが実現されるでしょう。マクニカは、この姿を実現するお手伝いをしていきます。
