こんにちは、エウレカの原田です。
セキュリティを測定可能にする技術 でも触れられている通り、今年のエウレカのセキュリティチームは様々な取り組みを進めてきました。この記事ではその中でもいわゆる DevSecOps の取り組みについて、深ぼって紹介したいと思います。
背景
エウレカでは、各チームのエンジニア主導でのセキュリティ改善の取り組みが盛んに行われていたり ( 例: PairsにおけるEKSセキュリティの取り組み ) 、アプリケーションやインフラの開発におけるセキュリティを担保するツール群もいくつか導入されており、今年はこれらの運用をさらに成熟させていく、というタイミングでした。この状況で、セキュリティチームとして担うべき役割はいくつかありました。
セキュリティチームとして担保したいこと
各チーム主導の取り組みは、各技術分野を深く掘り下げたり、それぞれの主担当分野をスコープとするもの、単発のプロジェクト、が多くなる傾向があります。対してセキュリティチームとしては、よりベーシックな脆弱性管理、パッチマネジメントといった取り組みについて、組織全体の状況の可視化や、その継続性を確実に担保していく必要があると考えています。また、細かな部分では各種セキュリティツールが開発のスピードを損なわないようなチューニングであったり、日々の運用やプロセス設計におけるアドバイザーとなる必要もあります。こういった取り組みを整理するために、以下の概念やフレームワークを参考にしました。
DevSecOps
全体像の整理のため、このようなエウレカのSDLC (システム開発ライフサイクル) の中で必要十分なセキュリティを確保していく取り組み全体を指して、よく耳にする DevSecOps というワードを使うことにしました。
DevSecOpsの構成要素として、プロセスやコミュニケーションといったソフト面、ツールやプラクティスといったハード面に大別できると考えており、それぞれの取り組みの事例調査と整理を行いました。特にツール群に関しては既に導入済みであったことから、今年の大きな注力ポイントはプロセスやコミュニケーション、具体的な対応のプラクティスに関してでした。(このため、あえて本記事では具体的なツール名に関しては言及しておりません)
CIS Controls
また、セキュリティを測定可能にする技術 でも触れられている通り、エウレカではセキュリティ対策の成熟度評価に CIS Controls v8 を活用しており、セキュリティ施策を進める上では、都度こちらを参照 & マッピングするようにしています。DevSecOpsの取り組みに関しても、関連する以下の Controls & Safeguards をベースに具体化、整理を行いました。
- CIS Controls 07 — Continuous Vulnerability Management
- CIS Controls 16 — Applications Software Security
最終的に整理した内容は具体的すぎるため省略しますが、DevSecOpsの事例と、CIS ControlsのSafeguardsを組み合わせて多面的に考えることで、参考にすべきトレンドと逃すべきでない要点をバランス良く組み合わせた整理ができたと思います。
これをもとにして、以下のような取り組みを進めました。
⓪ 前準備
開発者へのヒアリング
まずは既に導入済みのツール群について、開発上のペインとなってしまっている部分がないか開発者にヒアリングを行い、いくつかの問題を解消していきました。後述する各種の取り組みを立ち上げていく前に、既存の摩擦を解消したかったからです。
特に印象的だったポイントを一つ紹介すると、開発者が一般的に意識するCIのバツと、セキュリティ系のCIのバツのニュアンスの違いは大きなストレスになるということです。
前者はテストコードやリンターのような絶対的な信頼を置くべきものが多く、また開発者にとって多くの場合コントローラブルな領域です。しかし、後者は必ずしもすべてを直すことが正解ではなく、大量のFalse PositiveやSeverityの判断が求められ、内容も判断しづらいことがあります。
これらが同じPull RequestのCI欄に並んでいると、初めてみる人は「どうするのが正解かわからん」となり、慣れると「いつも落ちてるし、無視してマージしてしまおう」になってしまいます。そのため、確実に対応してほしいものだけを通知するようにSeverityのフィルターや検出ルールの調整を行ったり、運用にのせ直すまで一時的にPRのCIから外したものもありました。
① 全社の脆弱性情報の見える化
ツールのカバー範囲整理とカバレッジ向上
各ツールのカバーできている範囲を整理しました。整理の軸はいくつかあり、サポートされる言語の範囲、どのレイヤーの何をチェックするツールなのか、それぞれのツールにおける対象とすべきアセットの登録率などです。
そこから、組織全体の状況を可視化するため、既存のツールで適用範囲を広げていきました。また、リポジトリが作成されたら自動的にスキャン対象になるであったり、Terraformでのリソース作成に伴ってツール側に自動で登録される、などの継続的にカバレッジが担保され続ける設定をなるべく入れるようにしました。
ここで新規追加となるスキャン対象に関しては、前述のような感度調整を行ったり、PRでは発火させないといった方針をとり、なるべく影響を与えずにまずは情報だけを収集できるようにしました。
脆弱性対応ポリシーと現状の共有
CVSS値や各ツールによって付与されるSeverityごとに期待される脆弱性対応速度に関するポリシーを作成し、エンジニア組織の定例MTGで共有をしました。このポリシーは現時点で厳密に運用されるものというよりは、各チームごとの対応サイクルを成熟させて到達したい目標 (SLO) 的な運用を意識するものです。
あわせて、各ツールから収集した情報をまとめて一覧化できるようにし、その大まかな解釈 (どこが強み、どこが伸びしろ) を共有しました。
対応の温度感やフォーカスポイントを擦り合わせることがセキュリティは特に難しいと感じており、このような可視化と対話のベースラインの構築は重要だと思っています。
② 継続して脆弱性を減らしていく
全体の可視化からよりブレイクダウンして、いくつかのチームでは、各チームの開発サイクルにうまく馴染む方法でセキュリティ対応のサイクルを回せるようにしたり、定期的にリスクに関する会話ができる体制をつくることを目指したセキュリティ運用改善の取り組みを開始しました。
より深ぼった現状の共有とディスカッション
セキュリティ目線での課題を、先の全体向けの共有よりもすこし具体性を上げ、各チームの管理下の情報資産にフォーカスして共有します。実装レベルでこういうことが起き得る、という話だったり、具体的にどうやったらもっと改善できそうか、運用状況はどうか、といったディスカッションもここで行いました。
パッチ対応等のフロー相談
対応フローを決めるにあたって、日々の細々としたパッチやアップデートのような対応は、セキュリティ対応のためだけのプロセスにせず、パッケージや言語バージョンの最新化といった開発者にもメリットがあることと合わせて行われるとよい、ということが発見でした。 ( というより、各チームで主要なリポジトリでそういった取り組みが既にあり、会話する前から対応サイクルが回っていることも多かったです。)
誰が運用しているのか曖昧なシステムなども中にはあるので、そういったものはオーナーシップを明示的に決めに行き、各チームの上記のような取り組みに含めてもらうような動きが必要になります。
トリアージのペアワーク
各チームから代表者を1人アサインしてもらい、セキュリティチームとペアワークのような形で脆弱性のリストの確認とトリアージを行いました。単に既存の脆弱性に対応する、という意味合い以上に、false positive, won’t fix 等の判断基準、各言語でのあるあるパターン、実はもう使ってないコンポーネント、manifestの管理方法、アップデートの実際の重さなどなど、MTGするだけではなかなか分からない細かいけど大事な情報を双方でシェアできるのが良かったです。
定期MTG
ちょうど年内はこのペアプロの取り組みが落ち着いたところでした。来年からは各チームとの定期的なMTGをセットし、今回対応したような取り組みの継続に加え、より大きめ & 長期的な課題に関して話せる場とする予定です。パッチ対応フローの話と同じく、こういった話に関しても、技術的な挑戦や、開発生産性の向上などに繋がる一石N鳥のタスクに昇華して発展解消できるのが理想なので、そういった会話をできるとよいなと思っています。
Slack Channel
セキュリティ関連の話題を集約する、#sec-{team-name} のSlackチャンネルをチーム毎に作成し、継続的に発生するセキュリティに関する会話のコンテキストを追いやすくしています。各チームのセキュリティにおける大きなテーマや、あるあるパターンなどが明らかにできるメリットがあるし、何よりすぐできるので、これもおすすめの取り組みです。
③ セキュリティチームのダブルチェック体制
こういった取り組みの洗練度を徐々に上げていき、基本的にはセキュリティチームが介入せずにうまく対応が回るような状態を目指しています。 ( SRE界隈でよくみる 民主化 / 権限移譲 みたいな話と似てきそうかなと思っています。)
…が、実際にはまだまだ取り組みを開始していないチームや分野もあること、だからといって脆弱性を見逃すわけにはいかないので、新規に発生した脆弱性や、全社で見た総量に関して、セキュリティチームが随時確認できるような監視体制を持っています。
既に立ち上げた対応プロセスがうまく回っていなさそうな場合も、ここで検知し、前述の定期MTGでフィードバックしたり、個別に対応の依頼をする、といった動きをすることで、深刻な対応漏れを防いでいます。
会社全体での取り組みのカバレッジや成熟度が上がってくると、この場でキャッチする必要のあるものが徐々に減っていくだろう、という一種の成熟度バロメータとしても使えるのではないかと思っています。
まとめ
まだまだ荒削りではありますが、今年はDevSecOpsの取り組みとして、社内のセキュリティ状況の可視化を進めたり、いくつかのチームと協力し、セキュリティ改善の継続的な取り組みを開始することができました。来年はこの取組をより洗練させていきたいと考えています。
明日の Eureka Advent Calendar 2022 は、@__yucatty さんの 「Google Cloudサービス アカウントをセキュアに管理するためのtips」です。お楽しみに！
