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