Dept of Know Live! : Ellen Körbes 氏が語る「セキュリティチームは開発エクスペリエンスにどうアプローチすべきか」
セキュリティチームと開発チームの間にしばしば摩擦が生じることは周知の事実です。迅速にコードをデプロイするプレッシャーに直面している開発者は、セキュリティ要件を理由にプロジェクトの進行にストップがかかると、苛立たしく感じることもあるでしょう。第三回目の「Dept of Know Live!」で Omar 氏が述べたように、セキュリティチームは開発プロセスへの影響を考えずに新しいプログラムを導入することがよくあります。
先週、私はこのトークシリーズに参加し、セキュリティチームと開発チームの関係の内実について探りました。具体的には Kelly Shortridge 氏と Bea Hughes 氏と共に、セキュリティチームが開発者の期待に応えられていない理由と、開発者を考慮してセキュリティを実現するとはどういうことかについて話し合いました。
セッションはこちらからご視聴できます。それでは、主なポイントについて見てみましょう。
1. 開発者の優先事項に興味を持つ
セキュリティチームは、十分な好奇心を持って開発チームとの関係に臨む必要があります。開発者が特定のポリシーに違反していることが分かった場合、そのような状況が発生している「原因」を検討することが重要です。undefined違反が繰り返し見られる場合は、ワークフローに何らかの問題がある可能性があります。セキュリティチームは、自分たちが影響を与えようとしている開発チームのことを考え、彼らの優先事項について理解しようと努力する必要があります。セキュリティ要件を満たすために、開発者がワークフローや優先事項を変えることを期待するのではなく、開発者の優先事項と一致するものをセキュリティチームは開発者に提供すべきです。
2. あらゆるコンテキストスイッチを追加コストと考える
新しいセキュリティ要件を導入する際にセキュリティチームが慎重に検討すべき指標のひとつに、開発者が対応しなければならないコンテキストスイッチの量があります。今日の開発者は大量のコードを管理しており、その量は増え続ける一方です。そのため、作業を妨げるものを排除することが非常に重要です。コンテキストスイッチは常にコストの加算を伴い、コンテキストスイッチが無い状況が理想であることをセキュリティ担当者は心に留めておくべきです。セキュリティ要件に対応するために開発者がコードから注意をそらす必要がある状況や、開発環境を離れてセキュリティツールを使用しなければならない回数を減らす必要があります。どうしても必要である場合を除いて、開発者にコンテキストスイッチを強要しないようにし、すべてのコンテキストスイッチを慎重に扱うようにしましょう。
3. 「見えない」セキュリティの在り方を受け入れる
開発者が対応しなければならないコンテキストスイッチの量を減らすということは、インフラをバックグラウンドにフェードアウトさせるアイディアを受け入れるということを意味します。開発環境はライブ環境の一種であるため、記述されるコードや変化する開発環境をモニタリングできるセキュリティツールを何らかの形で統合する必要があります。その際、できる限り自動化することが重要です。極端に言えば、開発者はセキュリティが「目の前から消える」ことを望んでいます。もちろんこれは、セキュリティ担当者にとって聞くに堪えがたいことだと思います。「私の仕事は重要ではないということか？」と考えてしまうのが普通でしょう。しかし「ほとんど見えなくなる」には、別の立場にある相手が達成しようとしているゴールに対する深い共感と理解が実際に求められます。これは、体が元気なときは健康に気を遣わず、何事もなく生活を続けるのと似ています。
結論
セキュリティチームと開発チームの優先事項が対立することもありますが、どちらも「組織の成功」という共通目標の達成を目指すチームメイトであることを認識するのが、チーム間の摩擦をなくすための第一歩です。セキュリティチームは、開発チームに対して好奇心と共感を抱き、開発エクスペリエンスを優先させながら共通の目標を達成することではじめて、「ダメ出し専門チーム」という不名誉なレッテルから解放されるのです。
「Dept of Know Live!」はオンデマンドでご視聴いただけます。また、Unsupervised Learning の設立者で、大手ファイナンスサービス企業で Head of Vulnerability Management and AppSec を務める Daniel Miessler 氏は、3月31日に開催されたセッションで、セキュリティにおいてアセット管理の果たす役割が重要となる理由について語りました。
