CISOは、開発者と早期から連携し、セキュリティを日々の業務に統合することで大きなメリットを得られる。
eamesBot – shutterstock.com
CISOの主な任務の一つは、「ノーと言う部署」であることをやめることだ。新たなリスクを生み出すことなく、企業にとっての製品やサービスの迅速な提供を可能にする方法を見つけなければならない。
これが、端的に言えばパラドックスである。プロダクトチームが常に新しいテクノロジーを試し、記録的なスピードでアップデートをリリースしなければならない環境では、開発サイクルの終盤に行う従来型の監査では追いつけない。セキュリティは前倒しにする必要がある。イノベーションを阻害するのではなく後押しする、プロアクティブで実行可能な対策として、日々のオペレーションに統合されなければならない。
そのためCISOは、最初からチームとより密接に連携し、明確で実務的なリスク許容度を定め、セキュリティを開発プロセスに組み込む必要がある。
早期にパートナーシップを結び、成果を形作る
CISOは、最後に登場しても影響力を高めることはできない。ゲートキーパー的な発想を捨て、初日から真のパートナーでなければならない。かつては、セキュリティ対策が終盤になって導入されていたため、意思決定者はプロジェクトの遅延を受け入れるか、軽減されていないリスクを容認するかという難しい選択を迫られていた。プロダクトサイクルが四半期単位で、スピードが競争力を左右する決定的要因ではなかった時代には、このアプローチにも合理性があった。しかし、AI駆動のプロダクト開発が進む現在、週次スプリント、継続的デリバリー、ベンダー依存が前提となる環境では、こうしたプロセスはもはや機能しない。
セキュリティ部門が売上目標、顧客への約束、規制リスクを理解していれば、ガイドラインは具体的で有用なものになる。そのため企業は、各プロダクトチームにセキュリティ担当者を一人ずつ配置すべきだ。そうすることで、アイデンティティ、データフロー、ログ取得、暗号化に関する判断が必要になったとき、常に信頼できる相談相手が存在することになる。開発者が簡単な質問をするだけで2週間待ちのチケットを切らなければならないような状況は望むべきではない。オープンな「オフィスアワー」やチャットチャンネル、短い電話ミーティングなどを用意し、API設計、暗号化要件、地域間のデータ移動といった意思決定について、即時のフィードバックが得られるようにすべきだ。
セキュリティの世界からは官僚主義を排除しなければならない。セキュリティマネージャーは、スプリント計画や初期のデザインレビューに参加し、認証フロー、最小権限アクセス、ログ取得のカバレッジ、あるいは本番環境での変更がどのようにSIEMやEDRで監視されるかといった重要な論点を明確にすべきだ。CISOがテーブルについていれば、問いは「これは実行できるか？」から「どうすれば安全に実行できるか？」へと変わり、初日からより良い結果が得られるようになる。
リスク許容度とガードレールを定義する
チームは、どう進めるべきか確信が持てないとスピードが落ちる。そのため、意思決定の一部を肩代わりし、認証・認可・監査の統合を開発プロセス側で担うべきだ。認証については、データベースにハードコードされた、簡単に侵害されうるアカウントを作るのではなく、企業のアイデンティティ管理ソリューションを構築・活用すべきである。
セキュリティ責任者はまた、ソリューション設計における明確な職務分掌を保証する、標準化されたロールベースのアクセス制御レベルを定義しなければならない。その際、監査は単なるログの集合ではなく、異常検知のために高カーディナリティのデータを収集すべきだ。その後、それらを脅威の検知と対応を行う中央のSOC（セキュリティオペレーションセンター）に統合する必要がある。プロダクト開発チームにセキュリティ業務を担わせるべきではなく、別のチームが本番環境のソリューションに対する脅威の可視性を継続的に監視すべきである。
CISOは、解釈の余地が生じないよう、ビジネスの言葉で企業のリスク許容度を定義しなければならない。どのようなサードパーティプロファイルが詳細な評価を要し、どのようなものが代替コントロールを伴う限定的なパイロットとして実施できるかを定めるべきだ。どの脆弱性がマージをブロックしなければならないのか、どの脆弱性であれば期限付きの修正計画とともに進めてよいのかを決める必要がある。どのデータ分類が地域をまたいで扱えるのか、またそのためにどのような保護策が必要なのかを明確にすべきだ。
そのうえで、これらの判断を自動化に落とし込む必要がある。CI/CDやInfrastructure as Codeに保護策を組み込み、ポリシーの適用を一貫性のある、可視化された形で行うのだ。すべてのコードコミットを脆弱性についてスキャンし、変更が重大なポリシーに違反している場合は、明確な理由と解決策を提示したうえでビルドを失敗させる。変更が許容範囲内であれば、手動介入なしに先へ進める。結果として得られるのは、開発チームの働き方に合わせた、予測可能で透明性が高く、スピードを高めるためのガバナンスである。
Security by Designを高速な開発サイクルに統合する
開発者が1日に何度もコードをデプロイするような環境では、リリース前に「最終セキュリティレビュー」を行うやり方は通用しない。この従来型の終盤ゲートキーピングモデルは、イノベーションを阻害するだけでなく、実際のリスクを見逃してしまう。効果的であるためには、セキュリティは開発の最中に組み込まれていなければならず、事後的にチェックされるだけでは不十分だ。
安全なやり方のほうが危険なやり方よりも難しければ、開発者は毎回、簡単なほうを選ぶ。CISOの役割は、50ページのPDFを配布することではなく、セキュリティを開発者の環境に直接統合し、認証と認可があらかじめ組み込まれた、ハードニング済みのテンプレートを提供することだ。デフォルトで安全なこれらのテンプレートは、事前に検証されており、安全なコンポーネントのほうが安全でない代替手段よりも使いやすくなっている必要がある。そうなっていれば、開発者はいつでも、何の苦労もなくそれを利用できる。
自動化は、この戦略を実行するためのレイヤーである。セキュリティツールをCI/CDパイプラインに直接統合すれば、ほぼリアルタイムでフィードバックが得られる。これにより、チームは重大なリスクに対して「早く失敗」しつつ、同時に実行可能な修正を行うことができる。
この規律は本番環境にまで徹底されなければならない。最高水準のDevSecOpsを実践していても、ゼロデイ攻撃や設定の逸脱は起こりうる。そのため、堅牢なWebアプリケーションファイアウォールとランタイム攻撃防御、自己防衛機能を統合した、Webアプリケーション保護の横断的なソリューションに依拠すべきである。これらのソリューションは、本番稼働中のアプリケーションにおいて、脆弱性やリスクをリアルタイムで軽減する。これにより、開発チームは、サービス停止やセキュリティ侵害を起こすことなく、根本原因を修正するために必要な決定的な時間を確保できる。また、他のすべてのコントロールが失敗した場合でも、なお介入できることを保証する。
ランタイムテレメトリとリスクベースのアラートは、このコンセプトにおける最後の防御層である。これにより、開発者が最初の1行のコードから本番環境まで、自らのアプリケーションに対して全面的な責任を負う文化的な変化が促進される。一方でセキュリティは、ボトルネックになることなく、広範かつ持続的なカバレッジを実現できる。（jm）
