EdgioのBeyond the Edgeの紹介ポッドキャストエピソード4: DevSecOps:製品ロードマップを右にシフトしないように左にシフトするEdgioのグローバルキャンペーンマネージャーであるLauren Bradleyがホストしています。
Lauren Bradley: こんにちは。Beyond the Edgeへようこそ。ここでは、現代のデジタルビジネスの内外を詳しく見ていきましょう。 このエピソードの副パイロットを務めているローレン・ブラッドリーです。本日は、左翼への移行というトピックを取り上げます。具体的には、ウェブアプリケーションとAPI保護がDevOpsライフサイクルのネイティブかつ固有の部分になるにつれて、文化とテクノロジーがどのように変化するかについて説明します。
まず、Ponemon Instituteの衝撃的な統計から始めましょう。 今日では、ほとんどの企業では、侵害を検出するまでに200日以上かかります。 侵害を十分に迅速に検出しなければ、大きなコストがかかります。 IBMは、テスト段階で発見された修正バグのコストが、設計段階で発見されたバグのコストよりも15倍高いことを発見しました。
つまり、簡単に言えば、問題を捕まえるのを待つ時間が長くなればなるほど、コストがかかります。 また、コスト、再作業、時間、エネルギーだけでなく、最終的に製品ロードマップを変更することもできます。 では、どうすれば効果的に左にシフトし、貴重なリソースを無駄にせず、進歩を遅らせることができますか?
本日は、EdgioのプラットフォームエンジニアリングディレクターであるMichael GrimshawとEdgio Security Platformの製品管理シニアディレクターであるRichard Yewが参加します。 ようこそマイケルとリチャード あなたを参加させるのは素晴らしいことです。
マイケル・グリムショー: ありがとうローレン ここにいてよかった ありがとうございました
Lauren Bradley: 皆さん自身と、このトピックについての最初の考えについて、少し教えていただけますか。 マイク、まずはあなたから始めましょう。
マイケル・グリムショー: もちろんです まず初めにお礼を申し上げたいと思いますローレンこのような関心を持ってくれたことに感謝します この非常に重要なトピックでは、掘り下げて拡大しています。この1年間を含め、これについて私たちが行ってきた会話は、業界で行っている仕事にとって非常に貴重で不可欠なものです。
Michael Grimshaw: この理解は広く共有される必要があります。 私はマイケル・グリムショー 私はEdgioでプラットフォームエンジニアリングのディレクターを務めています。 プラットフォームに精通していない、または業界用語で非常に精通していない人にとっては、アプリケーションとインフラストラクチャを一貫したユニットに統合するという点で本当に考えています。
そして、私はセキュリティのバックグラウンドが非常に高いプラットフォームを担当しています。この分野は、セキュリティ、収益性の面で、非常に大きな変化をもたらすものであるため、私が非常に情熱を注いでいる分野です。 私たちの業界にとって非常に重要な分野の多くがあります。
DevSecOpsについては引き続き説明しますが、Richardに紹介してもらいます。
(リチャード・ユー) ありがとうマイケル はいはい はいはい これは非常に重要なトピックです。 私は個人的にソフトウェア開発のライフサイクルプロセス全体を経験し、それらをビジネスに変換してきたので、私の心の中で非常に近く、大切です。
さて、私がすることについて言えば… ローレンが言ったように、私はEdgioでセキュリティ製品管理組織を運営しています。 私の日々の生活は、研究開発チーム、エンジニアリングチームと協力して、お客様に価値を提供していることを確認することです。 そして、開発プラクティス、セキュリティ、CI CDプラクティスの最適化など、明らかに含まれるすべてのものが含まれます。 安全な製品を実際に提供できるようにするため。
そうだな これにより、お客様に価値を提供し、時間通り、予算通りに提供し、お客様に優れたエクスペリエンスを提供できるようになります。 ここでの私のレンズは、DevSecOps全体を人の視点から見ていくことです。つまり、テクノロジーとは対照的なプロセスであり、業界向けのベストプラクティスを実際に実装する方法です。
DevSecOpsとは
マイケル・グリムショー: 言いたいことは、リチャード、よろしければボールを盗ませてください。
DevSecOpsの意味を標準化して左シフトしましょう。 ガートナー社がありました。このDevSecOpsで耳を傾けている一部の人々のためのポイントを次に示します。用語の左へのシフト、右へのシフトなどは比較的新しいように聞こえるかもしれません。 これは新しいものではありません、ご存知のように、1年前にヒットしたばかりの最新の最もホットなものではありません。
いいえ、これはかなり長い間業界で焼かれています。 実際、ガートナー社は2017年にDevSecOpsのライフサイクルに関するレポートを発表しました。 DevOps、つまり業界のDevOpsトレンドの延長にすぎず、フィードバックループやソフトウェア開発ライフサイクルにinfosecのセキュリティを含めるように拡張されています。
ガートナー社は2017年にこのことについて書いていましたすでに業界ではプロセスであり運動であったのです その前にかなりの間 ですから、これらはまったく新しい概念ではありません。 これは、私たちが長年取り組んできたものの延長にすぎません。 DevSecOpsとは、DevOpsと同様のモデルを採用し、開発側と運用側があります。
要点は、設計の開始から、左側の開発者が開発側になるまでのプロセス全体を構築することです。失礼します。 右シフトは、オペレーションの可観測性側にあります。 今日は左側のシフトに焦点を当てますが、基本的には、スキャンと検証をテストする際に、できるだけ早く左に焼き付けています。 また、SDLCの開発ライフサイクルのできるだけ早い段階で使用できます。 たとえば、この記事で取り上げていることの1つは、 これも７年前に遡りますがセキュリティを確保することですオープンソースのサードパーティのライブラリリポジトリコードベースをスキャンしスキャンしてスキャンしてコードを書いてデザインアーキテクチャ9ヤード全部を最初から焼いていくことです そして、私が提供してきた例の1つは、開発者が使用しているIDEの構築とセキュリティスキャンです。 これはほんの一例であり、たくさんあります。
コードを書いているときに、すぐにフィードバックを得ることができます。 ああ、私はちょうどドアを開いたままにしておいた、クレデンシャルスタッフィングまたは続編注入、彼らは構文エラーのようになります、彼らはセキュリティエラーを取得しますコードを書くことです。 そのため、すぐに修正できるので、顧客やエンドユーザーが質を取られていることについて顧客から苦情を言われることはありません。1か月後、いいえ、すぐに処理されます。
最も安く、最も速く、最も簡単に発症します。 リチャード何か言うつもりだった
コストに関して左シフトが重要なのはなぜですか？
(リチャード・ユー) ああそうだ うんうん 私がコストについて話すのは実際に非常に重要だと思うように、ご存知のように、誰もが運営コストの多くを知っています、あなたは知っています、どんな組織でも、それは開発のようなものですよね? 研究開発プロセス。
コストに関しては、左にシフトする方が重要な理由です。 私たちは多くの努力を払って、なぜ、後で「どのように」に入るのかについて話しているからです。しかし、データがあるので、これがなぜそれほど重要なのかを理解したいと思います。
うんうん 私たちの調査によると、コードやプロダクションのリリース後に見つかったセキュリティ脆弱性を修正する場合、脅威の実装を行っている設計段階で見つかったときに予想されているよりも15のコストが高いことがわかります。 明らかに、開発の初期段階がすべてのセキュリティ脆弱性を完全に捕捉できるとは言っていません。
これが、多層防御を実装する必要がある理由です。 しかし、8つのフェーズを見てみると、一般的には、債務サイクル、計画、コード、 構築、テスト、監視、操作などを行うことができます。 そうだな セキュリティの脆弱性を見つけると、コストが高くなります。
組織が実際に問題を解決できるようにするためです ここでは、すでにプロダクションにコードをリリースした後に発生するスキャンの脆弱性を見つけることと、 たとえば、ステージング環境で動的なアプリケーションセキュリティタスクを実行して、コードをプロダクションに出荷する前に実際に検出するようになります。
Richard Yew: これらの問題を修正するか、またはコードリダクションをリリースする前に何らかの仮想パッチを事前に実装して、それを軽減することができます。 しかし、繰り返しになりますが、セキュリティはプロセスの最初のステップからベイクインする必要があることを理解することが非常に重要です。コードを記述し始める前であっても、IDEに何かを書き込んで脅威モデリングを行うことを検討し始める前であってもです。 ねえ、設計のどの部分が潜在的に悪用されやすい可能性がありますか?
DevOpsおよびセキュリティチームの日常的な影響
Lauren Bradley: ええ、それは本当に良い点ですね。 つまり、ユーザーの立場から見て、コスト以外に、DevOpsやセキュリティチームが最初からこの権利を実装していない場合、それが日常的に経験することになるのはどういう意味でしょうか。
また、DevOpsライフサイクルに効果的に導入する方法についても説明します。
マイケル・グリムショー: いい質問ですね いい質問だ 最初の返答は率直に言っておきます。 業界のすべての人、すべてのCEO、CTO、CFO–すべての人、エンジニア、 ユーザー–私たち全員が望んでいるのは、私たちが日々行うことができる魔法の弾丸にすぎません。
それから魔法の防犯弾がありますスイッチを入れるだけですべての作業が突然安全になります それは誰もが望んでいることですが、それは現実ではありません。 つまり人々は私たちに尋ねます ファンタジーランドの天気はどうですか? いいと聞いています。 このタイプの年は、セキュリティに近づくと、情報セキュリティと開発だけでなく、これは単なるボルトオンであるため、開発にも近づくと、あなたの情報セキュリティ、そしてあなたの開発。 「すべての開発と構築と展開が完了したら、ツールをいくつか購入します。すべてを安全にします」と、正直なところ、非常に高価なペーパーウェイトを購入しています。
これが、人、プロセス、 工具。 だからこそ、このアプローチの一貫性のある全体性が非常に重要なのです。 それが可能であったとしても、私たちははるかに年、数十年です。 正直に言うと、何かを設計し、セキュリティツールを実装するだけで、あなたは大丈夫ですという考えから多くの教訓を学びました。
これは、コストから開発者の速度、顧客へのコストまで、すべてに影響を与えます。 そして、これの良い例は、私の疑いです。キャリアのある時点でこのポッドキャストを聴いているほとんどの人は、新しい機能や新しいサービス、あるいは単にパッチとアップデートが導入された状況にあります。 何もかも順調だ。 すべてが順調に進んでいます。 すると、突然、顧客の1人から電話がかかってきたり、インフォセクが顧客の1人から電話をかけてきたりします。 「私たちは質に入れられたばかりです」、または「セキュリティインシデントが発生したばかりです」などのようなものです。 その理由は、デプロイしたのに、スキャンの実行が完了していないか、スキャンを実行していないか、または適切に調整されていないか、大規模なセキュリティ脆弱性が導入されたからです。
あなたにも影響するかもしれませんが、もっと重要なのは、あなたの顧客にも影響するということです。 DevSecOpsは、これらすべてを一貫したプロセスでまとめ、それを回避することです。 それはコスト削減についてです。 もちろんです 利益率の向上ですか？ 大きな意味でね しかし、それはあなたの会社とあなたの顧客の責任を取り除くことについてもあります。
DevOpsにセキュリティを組み込む–ケーキを焼くようなものです!
リチャード・ユー: その通りです 焼くことについて話すとき、マイクが一貫した全体性という言葉を使ったように。 こんなの本当なんだ これは非常に強力です。これは非常に強力な単語であり、なぜそれを適切な場所に焼くことが重要であるかを示すために非常に強力な単語です。
私はたくさんの類推を投げかけるのが好きで、私は知っている、私はこの素晴らしい聞いた。 私たちが知っているように、セキュリティ担当者として、私たちの仕事の大部分は伝道です。 適切なテクノロジーを実装し、プロセスを作成するだけでなく、実際に多くの社内マーケティングを行うことも重要です。
ビジネスにとってセキュリティが重要だと人に伝えるためですよね? なぜなら、セキュリティのリーダーとして、ワークフローにプロセスのレイヤーを追加するなど、セキュリティについてよく考えているようなものではありません。しかし、これについての正しい考え方は、セキュリティがビジネスをどのように加速できるかということです。
セキュリティが実際に収益を増やすにはどうすればよいでしょうか。これは、組織のセキュリティを確保するために必要なセキュリティの追加実装の多くを正当化するための良い方法だからです。 私が聞いた素晴らしい例えの1つは、セキュリティはケーキのアイシングのように扱われるべきではないということです。ケーキを焼き、最後のステップとしてすべてのアイシングを置く方法です。 これは通常、セキュリティやICDワークフローがなく、ファイアウォールやAPI保護など、本番フェーズの最終フェーズで実装するだけの場合に実行されます。 それは何であるべきか、セキュリティ、それは小麦粉のようなものです。 最初から何かあったはずだ
セキュリティはケーキを焼くための小麦粉のようなものです。 そして、セキュリティが正しく行われると、それを見ることはできません。 そして、セキュリティの全体的なポイントは、それが正しく行われたとき、それは焼き込まれているはずであり、目に見えないことです。 挑戦を生むものであってはならない。 組織を遅らせるようなものであってはなりません。
これが重要な理由をビジネスに示すのに役立っていた例えのように、強力なセキュリティプロセス、セキュリティテクノロジー文化を持つことは、強力なブレーキを持つようなものです。 レーシングカーではどのスーパーカーにも大きなブレーキがついていますそれがコーナリングを速くするためです
それは彼らが強くブレーキをかけることを可能にします。 より速く、より強く曲がることができますよね? それは彼らがレースに勝つことを可能にします。 強力なブレーキを持つことは強力なエンジンを持つことと同じくらい重要です。 これが、哲学的な安全保障を考えるときの考え方です。 明らかに高レベルの話をしていますよね？ ですから、私たちは明らかに、もっと深く掘り下げたいと思っています。 要点はこうですこれらは全て問題ありませんがどのように実装するのでしょうか？
マイケル・グリムショー： そうです それはブレーキングというのが良い呼び声だと思います。 強力なブレーキでコントロール。 流れがあったり、先にある道路はカーブやヘアピンカーブでいっぱいになっています。もちろん、ブレーキに触れずに、すべてをナビゲートするために、ブレーキ、私が思うに、愛があると思います。 私はこれらの両方の類似性が大好きですリチャードブレーキの類似性は、制御を与え、縁石、課題、そして予期しないことに直面したときに、より細かく粒度を制御できるからです。
（リチャード・ユー） 素晴らしい発見でした ところで、私が明確にしたいと思いますが、私はそのアナロジーを思いついたのではありません。それはDr. Eric Kohという男からです。 彼は素晴らしいポッドキャストを運営しています 皆さんにご覧になることをお勧めします しかし、はい、ビジネスにコンセプトを説明するときは、特にこの種の概念に慣れていない人には、それが非常に適切だと思います。
問題が発生し、チームがサイロ化し、ロードマップがシフトしている
Lauren Bradley: リチャード、あなたが言ったことについて、もしそうなら、 DevSecOpsは完成していますよね？ あなたはそれを見ません。 明らかに目を引く可視性の1つはコストです サイロ化されたチームでもあります。 また、これらの問題が発生したときにチーム間に断絶があるようにも感じます。なぜ以前は捕捉されていなかったのでしょうか。
これらを迅速または効果的に解決するために、どのようなプロセス、どのようなコミュニケーションが行われていなかったのでしょうか。 では、皆さんに質問したいのは、皆さんの経験で、どのようなものがあるか、ということです。 おそらく、透明性が欠けているのです。 意思決定に時間がかかり、リソースを浪費する可能性があります。
チームがサイロ化している場合、チームがサイロ化しているときに最も問題になる傾向がある問題は何ですか？
Richard Yew: はい、これを使います。 私が個人的に過去の人生で経験したことの1つは 製品や計画のようなものについて話すときは、CTO組織のように研究開発部門に組み込まれていないセキュリティチームがいることが重要です。
多くの組織では、セキュリティチームとCTO組織の間でサイロ化していることがありますが、その後多くのプロセスが実行されていることがわかります。 例えば、セキュリティチームとエンジニアリングチームの間に強力なコミュニケーションコラボレーションがないため、多くの製品やコードをリリースする状況に遭遇します。
結果的には組織はコンプライアンスを遵守しなければならないということです 具体的な例として、年に1、2回のようにチームがスキャンを行うことがあります。 これらのスキャンの結果はどうなりますか? さて、私は言われます。「ねえリチャード、次の四半期には、100種類の大小のセキュリティバグが見つかったからです。たとえば、20種類くらいです。上位の20は重大度1と2以上ですが、残りはご存知のとおりです。 それは、あなたがそれらのものを修正することに集中することについてです。」
そして、組織内には修正すべきSLAがあります。これを行うことで、基本的にロードマップを取って、次の四半期に放置することになります。 つまり、左にシフトせず、このプロセスを適切に構築せず、右側だけで行うことで、基本的にロードマップを推進しています。つまり、収益を生み出す成果物であり、ビジネスの拡大に役立つ可能性があります。 私たちはそれを正しく動かす可能性があります。つまり、実際に、四半期を費やして、これらの問題を軽減しようとします。
だからこそ、組織にとっても企業にとっても、ロードマップの項目を四半期ごとに変える必要があることを想像するのは非常に高価なことだと私は言います。 ですから、新製品、機能のリリーススケジュールはすべて変更する必要があります。 あなたはあなたの練習に左にシフトしなかったからです。
また、これらの機能のいくつかは、特に組織内のアプリケーションセキュリティチームと開発チームの間のコラボレーションの改善によって改善された可能性があります。 これが、多くの組織がこの新しい概念を導入し始めている理由です。 HR BPについて聞いたことがありますね。HRビジネスパートナーは、さまざまなビジネスユニットに組み込まれています。
現在、アプリケーションセキュリティBPの概念があります。 だから、あなたはAPP SEC BPのようなこれらの用語を耳にし始めます。これは、人々が働いている練習になる可能性があります。 エンジニアリングチームの半組み込みマネージャーのように、ソフトウェア構成分析の実装、セキュアIDの実装、すべての白黒箱タスクの実装など、開発ワークフローの各ステップで適切なガイダンス、ツール、プロセスを提供します。 このプロセスでは、開発ライフサイクルの早い段階で、これらの問題の一部を事前に把握できるようにしています。
（マイケル・グリムショー） 私は全てが大好きです いい質問だローレン あなたの言ったこと全部大好きよリチャード それにはコストがかかるからです。 もし人々が、誰かが聞いて、待っている製品にいるなら、私が左にシフトしても、ロードマップを右にシフトする必要はありません。
それは彼らの耳に音楽です。 しかし、CFOやオペレーション、その他のビジネス分野にとっては、それがもたらす影響は何か、と考えるかもしれません。 その影響は大きい。 あなたは営業部をひざまずいたわね 特にセキュリティに関しては、多くの顧客がいるため、顧客に影響を与えています。 プラットフォームの面では、ベンダーと話すときにロードマップが何かを知りたいと思います。なぜなら、私は監査役に会い、ロードマップに何かがリリースされるまで、報酬を得る必要があるからです。 もしあなたがこう言ったとしたら――私が四半期中に届けられると期待していたのは――4分の3になるでしょう 他のベンダーを見ていきます。 なぜでしょうか？ 私は監査役に義務を負っているからです
私も大好きですリチャードあなたは監査役とコンプライアンスプロセスを育てましたね これは、サイロ化が物事を根本的に爆発させる可能性がある場合について、ここであなたのポイントにここで別の例です。
PCI、SOC、ISO、FedRAMPなど、さまざまなコンプライアンスフレームワークの中にいて、統合されていない、まだ亡命精神を運用している場合は、おそらくコンプライアンスまたは情報セキュリティの担当者が監査役に話をすることになるでしょう。 彼らはそれを1、2層のレイヤーを通してエンジニアリング側に翻訳しなければなりません。エンジニアリング側は、意図したすべてのものを実装することを期待しています。そして、それは単に実装するためです。 証拠やスキャンなど他の人に提供するのに必要なものはすべて、幸運を祈ります。
それが実際に翻訳される場合は、私たちは皆、 小学校時代の古い噂ゲームは似たような機能で、監査役と連携している統合チームがあり、すぐに特定のテクノロジーに変換する方法を知っていて、スキャンを実行してすぐにそれを元に戻して置くことができます。 ルールセットでスキャンして検証し、監査人との会議中にリアルタイムで実行することもできます。 あなたはすべてのあなたの証拠をここにまとめています。 これは根本的なゲームチェンジャーです。 これにより、リチャードが言ったように、今すぐロードマップを変更するのではなく、顧客に迅速に物事を届けることができます。
ローレン・ブラッドリー: ええ では、CISOやAppSecのリーダーは、コストの影響や一般的な成功を理解するために、どのように指標を定量化することができるのでしょうか。
Richard Yew: 面白いのは、なぜ、何を知っているのかについてたくさん話しているからですが、その方法についてさらに詳しく見ていきましょう。私はそれを知っているので、多くの聴衆がそれを求めていることを知っているからです。 私たちはあなたにふわふわした高レベルの声明を与えるためにここにいません。 私たちがここで提供したいのは、それを実装する方法に関して少しだけ価値があることを願っています。
DevSecOpsチャートを表示して、手順を最適化する方法を見ていくことができます。 いいだろう 従来のセキュリティテストは直線的に実行されるようなものです それは、あなたの計画のように滝について話しているとき、あなたは持っている、美しさ、テスト、 そうでしょう？
オペレータ監視フェーズでは、多くのセキュリティテストが実施されました。 だから、それは右側にあります。 さて、新しいコンセプトは、次の写真に移りましょう。 このチャートの100の様々な種類を見つけることができるということです。 例えば、Google DevSecOpsをグーグルで検索すると、マイクが先ほど言ったように、このコンセプトは7の何年も前から存在していますよね。 一部の組織ではそのサイクルと呼ばれていないかもしれません 組織によっては、単にAppSecと呼ばれていますよね。 そのため、特定の組織ではセキュリティパイプラインと呼ばれています。 これは、セキュリティパイプラインが何を表しているかを大まかに表したものです。 そうでしょう？ それで最初から計画段階でしょ?
脅威モデリングの脅威分析があります。 ソリューションを設計している間は、このモデリングのすべてをベイクしていることを確認してください。 コーディングするとき、第2フェーズに進むとき、コーディングフェーズです。 あなたはあなたがフックされていることを確認したいです。 開発者がコードを書いているときに実際にリアルタイムで問題の一部を実際にキャプチャしているので、安全なIDEを使用していることを確認したいと思います。 明らかに、それは銀の弾丸ではありませんよね? しかし、これは追加のレイヤーであり、多層防御サイクルにおける追加のレイヤーについて説明しています。 さて、このプロセスをさらに進めていくと、そうでしょう? 一度コードを決めたら? すべてのコードの静的スキャンを実行して、自動依存性、サプライチェーン、脆弱性などをチェックできるプロセスが必要です。 ソフトウェア補正分析と併せて、使用しているソフトウェアのバージョンを示す資料のソフトウェアビューを作成します。 何歳ですか？
なぜなら、私は1週間か2週間前に統計を読んだだけです。Apache log4jのダウンロードの25%は、まだ脆弱性が含まれている古いバージョンから外れています。 私たちがほぼ2年になる今、それはまだ統計であることに私を困惑させます。 12月上旬に最初のApache log4jのゼロデイ脆弱性が発表されたのは、2年か3年かな? 2021年か? したがって、これは本当に私たちがより良いことに焦点を当てる必要があるものであり、この種のソフトウェアの会話/分析を実施して、実行しているソフトウェアのバージョンを正確に把握することができます。
重要なことです。 ではテストに移りましょう 内部テストがあること、動的テストが実装されていることを確認する必要があります。 実行中のアプリケーションをテストして、悪用される可能性のある脆弱性がないかどうかを確認できます。
これは通常ファジングによって行われることを知っています。 では、従来のDevSecOpsサイクルでは何が示されていないのでしょうか。 これは業界の標準的な慣行に見えるからです 展開、監視、対応に至るまでの道のりを歩んでいます。 これまで、ウェブアプリケーションファイアウォール、ボットマネージャー、APIセキュリティ、ウェブアプリケーションAPI保護ソリューションのすべてを、レスポンスと監視のフェーズに置いていました。 これは、本番トラフィックを監視するときに、攻撃がないことを確認するときです。
しかし、考慮すべきことは、このウェブアプリケーションAPI保護の一部を実際に移動することです。 左にも移動します。 この場合、写真では、それは一歩前進です。 動的なアプリケーションセキュリティテストを行う際には、テストフェーズに移行してください。 本番環境のセキュリティメカニズムでテストしてみてはいかがでしょうか。 コード間にどれだけの脆弱性が存在するかどれだけの脆弱性を軽減できるかということが重要なのですなぜなら私たちは常に開発をより迅速に進めることで現在のアプリサイクルのライフサイクルを改善する方法を見つけようとしているからです そのテスト中にセキュリティの脆弱性が見つかった場合の一般的な方法は、基本的に列車を停止することです。 戻ってきたんでしょ? コードを修正して、再度リリースします。 8つのステップをもう一度実行します。 しかし、もし私があなたに「ねえ、電車を止めないでください」と言う方法があると言ったらどうでしょうか。
列車を続けましょう。 ステップ4の前にセキュリティソリューションを使用した追加テストのようなものをリリースしましょう。これにより、本番環境で仮想的にパッチを適用する方法を事前に把握できるため、列車を停止する必要がなくなります。 列車を走らせろ 速度を維持します。
脆弱性を軽減するために仮想パッチを適用したコードをリリースし、次のサイクルで修正します。 これは、既存のCCDセキュリティワークフローを改善するために、お客様を教育し、協力するための革新的な方法でもあります。
マイケル・グリムショー: 気に入ったよリチャード 引っ張るという事実を愛してる左のシフトに引っ張る 要するに、ゲームプランが「ああ、これを本番に投入してから、心配する」ということです。 問題が発生し、開発、導入、運用プロセスの両方を通じて、バックサイドをカバーできる緩和策が得られます。 君が呼んだものは好きだ 似たような例えはカオスモンキーのようなものです ここに問題があります。 カオスモンキーがプロダクションで働いていて、カオスモンキーを扱っている唯一の時間は、それがプロダクション中のときである場合、あなたは恐ろしい開発と運用の経験を持つでしょう。
生産に入る前に、そのための計画、設計、エンジニアリングを行う必要があります。 さもなければ、あなたは悲惨になるでしょう。
コストへの影響と成功を理解するための指標の定量化
Richard Yew: ええ、そしてLauren、以前の質問に答えるのが好きです。DevSecOpsのライフサイクル全体と最適化方法を見ているので、今すぐ成功を測定するにはどうすればよいですか。 ベストプラクティスは何ですか?
非常に早く 成功を追跡する必要がありました ですから成功を数値化する必要があります そうだな つまり、セキュリティリーダーで、アプリケーションセキュリティプログラムの成功を測定しようとしている場合に役立つ指標がいくつかあります。これは、確認できることの1つであり、アプリケーションのカバレッジの範囲がどの程度であるか、 そうでしょう？
たとえば、組織全体のアプリケーションまたはインターネットに接続するアプリケーションのうち、90/95%以上が同じプロセスでカバーされているとしますか。 同じ標準化されたプロセスをカバーしていますか？ そうだな ソフトウェアの構成、分析、SAS、テスト、 テスト、テスト、Webアプリケーション、API保護のようなものです。
カバレッジを追跡し続けるためにそれらのものを配置していますか? リリースする頻度とロールバックする頻度はどれくらいですか？ セキュリティの脆弱性が原因で検出されたフェーズと、本番フェーズでロールバックする頻度と、 静的解析を行うコードコミットフェーズ。明らかにプロダクションのロールバックが行われるためです。
少し静的コード分析を行った後でコードを修正するよりも、はるかに高価になります。 そうだな 他の2つの統計は、ローレンが以前に言及したように、間違いなくとして測定したいと思います。 MTTDと呼ばれるものを検出するための業界平均平均時間は、200日数です。 ですから、右シフト左のプロセスで右シフト左のプロセスを使用すると、検出するまでの時間を大幅に短縮して、はるかに短くすることができます。 そこで、指標をまとめて、脆弱性が公開されてから、組織内のそれらの建物を検出するまでにどれくらいの時間がかかるかを検出してみましょう。
「対応までの時間」を実装しますよね? MTTRは解決までの間に解決しますよね? 業界平均は70日数なので、脆弱性が発見されてから70日数ですよね。 この問題を解決するには、組織の平均的な70日数が必要です。 しかし、この開始追跡で、どのくらい早く解決できますか? ソフトウェア構成分析でコードを使用してJの脆弱なバージョンのログを見つけたら、ファイアウォールでそれらを仮想パッチするのはどれくらい早くできますか。それとも、ライブラリを更新して別のソフトウェアを使用するのはどれくらい早くできますか。 ですから、非常に成熟した組織では、log4jイベントの時間を解決するために4時間の平均時間について話していることを実際に知っている組織と話をしました。
それは非常に印象的です。 これは、DevSecOpsプロセスの成熟度を物語っています。 だから、私はあらゆる種類を見てきました。 また、log4jのような重大な問題を解決するまでに数週間から数か月かかるお客様の組織を見てきました。 したがって、プロセス全体を改善しようとするときは、これらの指標を念頭に置いておくことが非常に重要です。
Michael Grimshaw: ここでは、他にもいくつかのKPIを紹介したいと思いますが、プラットフォーム側の場合と同様に、インフラストラクチャや多くの場合、エンジニアリングを扱う場合、コストは常に重要な要素でした。 しかし、金利が上昇しているここ数年で、あなたが知っている、スパイゴットはVCのお金とそれの多くは本当に乾燥していますが、ゲームの名前と上昇金利環境は非常に有益なビートアップです。
そしてここにある側面があります。 私はこの技術が大好きです。 明らかにプラットフォーム・エンジニアリングのディレクターです 私は技術的な面が大好きですが、特にここ数年では、インフラストラクチャなどのプラットフォームで働いている場合、財務の面、CFOやCTOにフィードバックを提供することが不可欠になってきました。
KPIはコストに関連しており、収益はこれもまた、ここでも非常に重要な側面です。 ですから、いくつかのことを言っておきましょう。例えば、収益の面です。 赤い線のディスカッションで座っている場合、購入しようとしているが製品を購入しようとしている顧客がいる場合、セキュリティの赤い線を通過することになります。セキュリティは誰もが考えているものであり、顧客はそれらを確実に保護したいと考えるからです。
彼らはここで彼らのリスクを最小限に抑えたいと思うでしょう。 そして、あなたが古い学校の精神で彼に来るならば。 そう我々は開発して情報セキュリティがそれらをスキャンするようにします 私は多くのレッドラインの議論や契約の議論をしてきましたが、それは単にもう飛ぶことはありません。
顧客のリスク部門と法務部門からのアンケートとアンケートのレベルは、過去5年間で、10年はもちろんのこと、さらに詳細なレベルに達しています。 さらに、完全に統合されたシフトレフトソリューションを使用して、WebアプリケーションとAPI保護を実現できます。 他の人の弁護士と話しているとき、これは針を大きく動かします。 それはどういう意味ですか？ つまり、取引をより早く成立させることができます。 左シフトを練習していない場合や、アドオンとしてinfosecと考えている場合は、 このようなタイプの製品の問題は、コストセンターと見なされることが多いため、成約率とその原因を確認し、特にセキュリティレッドラインのディスカッションを確認することをお勧めします。 彼らはそうではありません、彼らは収益のブロックを解除することができ、彼らはあなたに莫大な金額を節約することができます。
ポッドキャストの前半では、内部コストに関するコスト削減の多くについて説明しましたが、ベータ版の収益はここで重要だと思います。なぜなら、この金利上昇の世界では、多くの注目が集まっているからです。
まとめ
Richard Yew: それは素晴らしいポイントですね。 SDLCの帽子をかぶったり、ビジネス用の帽子をかぶったりして、少しだけ帽子をかぶったりしてよかったです。 これは素晴らしいです。 私たちが共有したこれらすべてのものが、観客に少しでも価値を提供してくれることを願っています。
Lauren Bradley:ありがとうございました。 これは最後に素晴らしいメモだと思います。 ここまでは、左翼の重要性と、ウェブアプリケーションとAPI保護をDevOpsライフサイクルに効果的に組み込む方法について説明してきました。 そしてもちろん、成功を効果的に測定する方法。 誤検出は少ないか？ 平均時間分解能はどのくらいですか？ ソフトウェアを出荷するまでの時間はどれくらいですか？ 収益が増えていますか？
これらの指標はすべて、ビジネスの成功に不可欠です。 マイケルとリチャードの二人に感謝します この度は、Beyond the Edgeに参加していただいた皆様にも感謝しております。 次のエピソードでお会いしましょう。
