サイバーセキュリティエンジニアとしてのキャリアの中で、マシュー・ローゼンクイスト氏は数々の挫折を経験しました。 自社の主力製品に脆弱性があることをチームが指摘したところ、そのチームを解雇してしまったCEOがいました。 セキュリティの経験がなく、しかもそれを身につけようとも思わなかったソフトウェアエンジニアたちがいました。
「彼ら自身は、自分たちが優秀なプログラマーだと考えており、それだけで十分だったのです」とローゼンクイスト氏は述べています。 「彼らは『それは私の問題ではありません』と言いました。 「私はただ、動作するようにコードを書くだけで、あとはセキュリティ担当者の問題です。」
その敵対的な態度は理解できます。 ソフトウェア開発者は、反復的な設計、迅速なリリース、そして「最小限の機能を備えた製品（MVP）」という世界の中で活動しています。 時間の都合やコードそのものに重点を置くため、セキュリティを含め、それ以外の事柄についてはあまり気にしていません。 彼らは、それをスケジュールの足かせ、あるいは製品そのものへの負担だと捉えることがよくあります。
[プラットフォームエンジニアリングとDevOpsの違い、セキュリティの責任の所在が不明確になる点、そしてAIツールが導入された際に何が変化するのかについてご覧ください]
「開発者やエンジニアの方にとって、これはまさに『自分の子供』のような存在です」と、サイバーセキュリティ戦略家であり取締役顧問の Rosenquist氏（）は語ります。同氏はインテルで 23 年間勤務し、現在はソフトウェア暗号化企業Eclipz.ioのCISOを務めています。 「締め切りがありますね。 あなたが、期限内にコードを正常に動作させられるかどうかが評価の対象となります。 さらに、御社の製品について詳しくないサイバーセキュリティ担当者が加わるとなると、話は別です。 「私にX、Y、Zをやってほしいのですか？」 「それじゃ、予定が狂ってしまいますね。」 この摩擦は次第に蓄積していきます。 「それより悪いのは、セキュリティ対策をまったく講じないことだけです。」
亀裂を修復する
ローゼンクイスト氏が述べているような摩擦は、決して新しいものではありません。 これは、企業内で長年にわたり存在していたDevOpsチームとセキュリティチーム間の溝に端を発し、世界的な健康危機に伴う課題によってさらに悪化しました。 ノートパソコン、デスクトップPC、タブレットなど、数千万台に及ぶエンドポイントを通じて、数百万人のリモートワーカーが機密データシステムにアクセスしていることから、脆弱性やセキュリティ侵害が急増しています。 According to a survey that Tanium released in 2020, North American businesses lose $700 billion a year as a result of IT downtime. チーム間の亀裂は、事態を悪化させています。
しかし、彼らは協力し合わなければなりません。 例えば、「DevSecOps」と呼ばれる新たな取り組みは、セキュリティチームのメンバーやプロセスをソフトウェア開発ライフサイクルに統合し、脆弱性を早期に発見することで、対立する部門間の架け橋を築くことを目指しています。 とはいえ、根深い文化的な問題や、 に示されているようなセキュリティ分野における世界的な人材不足、 に示されているような組織体制の問題が、依然としてチーム間の調和を妨げているのです。 ITのリーダーたちがこうした課題を克服する方法を模索する中で、経営陣レベルでのより明確な賛同の獲得や、協力的な風土の醸成など、いくつかのベストプラクティスが浮上してきました。 まずは、以下の手順に従って始めてみてください：
トップが方向性を示す
2001年にマイクロソフトを襲った2つの深刻なワーム被害を受けて、ビル・ゲイツ氏は翌年、全社員宛てに のメモ（ ）を送り、セキュリティが同社の全製品のコーディングに不可欠な要素となることを発表しました。「機能の追加とセキュリティ問題の解決のどちらを選ぶかという局面に直面したとき」とゲイツ氏は記しています。「私たちはセキュリティを選ぶ必要があります。」 … 現在、当社の開発者全員に対し、最新のセキュアコーディング手法に関する研修を実施しております。... 「当社のソフトウェアは、お客様がそのことを一切心配する必要がないほど、根本的に安全でなければなりません。」
その結果、同社は画期的であり、後に多く模倣されることとなった「セキュリティ開発ライフサイクル」を確立しました。これは、製品の開発および成熟の過程において、セキュリティを組み込んでいく一連の実践手法です。 それ以来、テクノロジー業界全体の企業が、これらのセキュリティ対策を取り入れ、それぞれの状況に合わせて適応させてきました。
[関連記事：セキュリティチームとIT運用チーム間の関係悪化が、企業をリスクにさらしている]
教訓：製品開発ライフサイクルにセキュリティ対策の工程を追加すると、スケジュールに少なからず影響が出る可能性があります。 そして、上層部がこれを優先事項としていないのであれば、組織の下位層にその重要性を納得させるのは、はるかに困難になるでしょう。 「トップから、企業の目標に沿ったビジネスへの理解を深めなければなりません」とローゼンクイスト氏は述べています。
「トップから、企業の目標に沿ったビジネスへの理解を深める必要があります」Eclipz.io Inc.のCISO、マシュー・ローゼンクイスト氏
デビッド・ハーン氏（ ）は、これを実際に目の当たりにしました。 シリコンバレー銀行やメディア大手ハースト、インテュイットなどでサイバーセキュリティ業務に携わってきたCISOとして、彼は、サイバーセキュリティが意思決定の場に参画すべきであるという点で合意し、最終的には連携して機能しなければならないさまざまなスキルセットの重要性を各チームのメンバーに伝えることで、ITリーダーたちとの連携を成功させてきました。 「後から参加して、悪役を演じるなんてことはできませんよ」と彼は言います。
説明責任の所在の変化
この隔たりを埋める一つの方法は、セキュリティを開発プロセスにより密接に組み込むことです。 EYの調査によると、現在、企業の3分の2近くが、ITプロジェクトの初期段階においてセキュリティチームを関与させていないとのことです。
専門家によると、そのギャップを埋めるための方法の一つとして、「シフト・レフト」というソフトウェアテスト手法の採用が挙げられます。これは、開発サイクルのかなり早い段階でテストを優先し、事後的に付け足すのではなく、開発の初期段階からテストを取り入れるというものです。 また、セキュリティチームと開発者間の連携を、必須とは言い切れないまでも、より一層促進するものです。
そうした取り組みは、従来の縦割り構造を打破するのに役立ちます。 「新しいチームを作り上げることが目的です」とハーン氏は述べています。 「誰もが開発、セキュリティ、運用に関するスキルを身につけるべきですが、ある分野の経験が他の人よりも豊富な人もいるでしょう。」
彼らをそのレベルに引き上げる方法の一つは、研修を行うことです。 ハーン氏は、ソフトウェア開発者にセキュリティスキルを身につけさせることは「成長の機会」だと述べています。 同様に、多くのセキュリティアナリストにとっても、基本的なプログラミングを学ぶことは有益でしょう。 「GoやPythonといったプログラミング言語から始めて、手続き型プログラミングやソフトウェア開発の複雑な仕組みを理解することができます」と、英国を拠点とするソフトウェア開発会社Sonatypeのセキュリティ研究者兼エンジニアであるAx Sharma氏は述べています。 「これにより、セキュリティ部門がチームの成果物作成に参画できることに対する懐疑的な見方が和らぐでしょう。」
DevSecOps：セキュリティと開発に対する新たな考え方を模索する
今後数年の間に、セキュリティチームとソフトウェア開発チームが新たな「クンバヤ」のような一体感を見出せるようになるのであれば、その一因は、両チームが、ソフトウェア開発者とIT運用チームの間という、もう一つの長年の企業内対立を解消する上で大成功を収めてきた働き方を採用したことにあります。 ここ10年ほどの間、開発者はIT運用部門とこれまで以上に緊密に連携し、両部門の機能を統合することで、かつてないほど迅速かつ効率的に新しいソフトウェアをリリースできるようになりました。
これは「DevOps」と呼ばれる手法であり、GitLabによると、現在、企業組織の約 62% が何らかの形で実践しているとのことです。 DevSecOpsは、この考え方を基盤としており、セキュリティテストを開発の「後」ではなく、開発の「過程」に取り入れています。
DevSecOpsは、単にセキュリティチームをプロセスの早い段階から関与させるだけでなく、組織全体としてリスク許容度を検討することを可能にします。 サイバーセキュリティ担当者が開発の足を引っ張るのではないかと懸念するソフトウェアエンジニアに対し、ハーン氏は、全員の認識を一致させ、開発を円滑に進める方法があると述べています。それは、脆弱性を早期に発見できなかった場合に何が起こるかを、彼らに明確に説明することです。 「脅威モデルを導入しましょう」と彼は言います。 「それを図に描き始めると、具体的なものになってくるのです。」 「『デビッドの意見はあまり良くなかった、私はそれが気に入らない』といった個人的な意見ではなく、技術的な議論となるのです。」
脅威モデルは、双方にとって妥協点を見出す手段となります。 例えば、ソフトウェアエンジニアは、独自の記録を網羅した完全なデータベースを含む、新製品のMVPやベータ版を作成することに熱心です。 セキュリティ部門は、脆弱性に関する徹底的なテストが完了するまでは、そのデータベースを製品に一切近づけたくないと考えています。 脅威モデルは、未完成の製品において機密データを公開することに内在するリスクを指摘する可能性があります。
そして、セキュリティチームが声を上げる番となります。 「彼らは、『そのリスクを冒す必要はありません』と言うべきです。 「ダミーデータを入れることもできます」とハーン氏は述べています。 EYの報告書も同様に、セキュリティチームはこうしたリスクについて、より効果的に情報を伝達できるはずだと指摘しています。
双方の連携を図るにあたり、シャルマ氏は、セキュリティプロセスの現状や全製品の脅威レベルの見直しなど、小規模な取り組みから始めることを提案しています。 そうすることで、脆弱性がどこで生じるのかについて理解が深まります。 その後、両チームは、 のセキュリティ自動化ツール（）やマルウェア検出ソフトウェアなどを活用して、残存する脆弱性を洗い出すことができます。 「取り組みの最初の1ヶ月は、チームがその効果を確認し、協力し合い、無駄を排除するための改善を繰り返せるよう、観察段階と捉えてください」とシャルマ氏は述べています。
事態が思わぬ方向に進んでしまったとき
うまくいくこともあります。 また、そうでない場合もあります。 ハーン氏によると、双方が協力できない場合、その原因として2つが挙げられます。1つは、プロジェクトのスケジュールやプロセスを狂わせてしまう「スコープクリープ」、もう1つは「エゴ」です。 「つまり、合意した原則を守らない人たちのことですね」と彼は言います。
その段階では、たとえリリース日が遅れることになっても、開発を一時中断すべき時です。 ハーン氏は、プロジェクトの進行を2ヶ月遅らせるようなセキュリティ上の脆弱性を発見する方が、一般公開後に起こりうる大惨事に直面するよりはましだと述べています。
「常に何らかのコストはつきものです」と、Eclipz.ioのCISOであるローゼンクイスト氏は述べています。 「しかし、損失を軽減したり、規制を確実に遵守したりしているわけですね。」 また、セキュリティ部門とIT部門を統合することは、従業員にとって良いことだけにとどまらない、と彼は付け加えています。 「それは競争上の優位性となり得ます。」
