以前 について詳しく説明しました。この記事では、この変革に関連するトレンドの 1 つ、つまりセキュリティ エンジニアリングの台頭について詳しく説明します。 、サイバーセキュリティの成熟と、約束ベースのセキュリティから証拠ベースのセキュリティへの移行 約束ベースから証拠ベースのセキュリティへの移行と IT の進化 の成熟について話すとき、私は主に、私たちがそれを行う方法を変えることを意味します.ごく最近まで、私たちはそれを機能と考え、セキュリティはツールの問題であると考えていました。トップ ベンダーから「適切な」「次世代」セキュリティ製品を購入すれば、「安全」になります。 サイバーセキュリティ このアプローチが期待を裏切らないことを何年にもわたって見てきた今、私たちはセキュリティが機能ではなくプロセスであることを理解し始めています。セキュリティ データを 1 か所に収集し、環境で何が起こっているかを理解し、組織内の通常のビジネス プラクティスを構成するものと侵害の兆候となる可能性があるものを学び、その方法を特定するという、基本に立ち返る必要があるという体系的な信念を構築しています。悪意のある動作を検出し、適切に対応します。有効にすると侵入できない保護シールドをアクティブにするウィジェットを取得する代わりに、成熟したセキュリティ チームは、レイヤーと実行するジョブのレンズを通してセキュリティを見ています。 「セキュリティ体制を構築する最善の方法は、監視、テスト、強化できるコントロールとインフラストラクチャの上に構築することです。これは、額面通りに受け取る必要のあるベンダーからの約束に基づいて構築されたものではありません。これは、保護されている悪意のあるアクティビティと動作の正確なセットを把握し、これをテストして証明できる必要があることを意味します。また、検出して防止したいことを記述できれば、ベンダーの介入なしに一方的に適用できるはずです。たとえば、セキュリティ エンジニアが WannaCry について読んだことがあれば、ベンダーが新しいリリースを行うまで 1 日か 2 日待つことなく、独自の検出ロジックを作成できるはずです。」 セキュリティの実施方法を変えているもう 1 つの要因は、過去 10 年間に目撃されてきた IT の進化です。インフラストラクチャのさまざまな要素がどのように機能し、相互にやり取りし、それらを保護するために何が必要かについての基本的な理解を提供するため、セキュリティの専門家として始めるには IT のバックグラウンドがあれば十分だった時代がありました。 IT の自動化とクラウドの台頭により、バックグラウンドで行われている多くのことが抽象化されているため、IT インフラストラクチャに関するメンタル モデルを開発し、それを保護する方法を理解することが難しくなっています。今日のセキュリティで成功するには、オンプレミス インフラストラクチャ、クラウド インフラストラクチャのさまざまなコンポーネント、コードとしてのインフラストラクチャ、DevOps パイプラインなどを理解する必要があります。 IT がますます複雑になるにつれて、この複雑さを維持、管理、および理解する担当者に対する要件が増えています。 セキュリティの方法の変化を加速するその他の要因には、次のようなものがあります。 - 結果とセキュリティ支出の間の弱い相関関係、 - 測定可能な結果を要求するビジネス、 - セキュリティと顧客環境の複雑化、 - セキュリティ ツールの急増、 - セキュリティ専門家の成熟度の高まり、 - 保険料の上昇、 - 新世代のサービスプロバイダーの出現、 - サポートするベンダー エコシステムの出現、 - セキュリティフレームワークの確立、および - 証拠に基づいたセキュリティに対する投資家のサポート。 未来のサイバーセキュリティは、ソフトウェア エンジニアリングによく似たものになるでしょう ソフトウェア エンジニアリングをサイバーセキュリティのモデルと見なす サイバーセキュリティは、ハッキング サークルで生まれました。製品やツールのリバース エンジニアリング、いじくり回し、破ることができないと見なされていたものへの侵入に興味を持っている技術志向の人々の間でした。その後、いくつかのセキュリティベンダーが安全を約束するためにやって来て、「何か悪いことが起こったときに警告します。警告を確認する人がいるだけです」と述べました.このようなシンプルさの可能性に驚いた私たちは、 アナリストを雇ってアラートを監視し始めました。それから 10 年ほど経った今日、私たちは基本に立ち返らなければならないことを目の当たりにしています。この見方は明らかに単純化しすぎていますが、真実は、ハッカーを業界に戻す必要があるということです。真実は、未来のサイバーセキュリティはソフトウェア エンジニアリングに非常によく似たものになるということです。 セキュリティ ソフトウェア開発は私たちに優れたモデルを提供します。ビジネス アナリストとプロダクト マネージャーは、ビジネスとテクノロジーの間で活動します。彼らは顧客と話し、ビジネス要件を理解して評価し、それらを技術要件に変換し、開発のためにこれらの要件に優先順位を付けます。セキュリティ チームが、顧客と話をしておらず、ビジネスを十分に理解していないと非難されていることをよく耳にします。感情は公平ですが、これらの発言をしている人々は要点がずれていると思います。技術的なセキュリティの専門家がビジネスを理解していないことを批判することは、バックエンド エンジニアがユーザー インタビューを行うのが得意ではないことを批判することに似ています。真実は単純です。バックエンド エンジニアがユーザー インタビューを行いたい場合、バックエンドを選択せず、代わりに UX デザイナーになったはずです。 ビジネスをよりよく理解するには、セキュリティ チームが必要です。それについては疑いの余地がありません。しかし、IT 部門とセキュリティ部門のすべての人に会社全体の従業員へのインタビューを開始しても問題を解決することはできません (ただし、関係の構築を奨励する必要があります)。代わりに、 に相当する人材が必要です。 ギャップを埋めるためにセキュリティのビジネス アナリストやプロダクト マネージャー サイバーセキュリティのためのソフトウェア工学の原則 ソフトウェア エンジニアリングは、明日のサイバーセキュリティを共有する優れたツール、概念、原則、およびメンタル モデルのセットを提供します。 まず第一に、明日のセキュリティはコードとしてのセキュリティです。 コードとしてのポリシー、コードとしてのインフラストラクチャ、コードとしてのプライバシー、コードとしての検出など、すべてをコードとして取得したので、変更を展開、追跡、およびテストすることができます組織のセキュリティ体制を見直し、必要に応じて元に戻します。つまり、これは、テストと検証が可能なアプローチを意味し、証拠に基づくセキュリティに関する要点をさらに強固なものにします。ソフトウェア エンジニアリングでの仕組みと同様に、自動化されたセキュリティ テストを実行してシステムがどのように動作するかを確認し、品質保証担当者 (ペネトレーション テスターと考えてください) を雇って自動化を超えて、自動化ではカバーされないエッジ ケースを探すことができるようになりました。 . 第二に、未来のサイバーセキュリティは、継続的な監視、継続的な展開、および頻繁な反復に基づいています。組織のセキュリティ体制は静的ではなく、刻一刻と変化しており、その変化のスピードはクラウドの台頭により加速しています。新しい検出と対応のカバレッジが展開されてから数秒で、組織の環境は変化し、数例を挙げると、数百の仮想マシンがクラウドで起動され、数十の新しい SaaS アプリケーションがエンドポイント全体にインストールされます。セキュリティの評価と適用範囲は、静的なままではいけません。組織自体の進化に合わせて進化する必要があります。したがって、セキュリティは機能ではなくプロセスであり、組織のセキュリティ体制の継続的な評価と継続的な改善に基づくプロセスです。 第三に、明日の業界は、API ファーストの方法で大規模に物事を行う必要があります。セキュリティ チームが数十のツールにログインして構成を手動で微調整し、セキュリティ ソリューションを手動で展開する必要があった時代は終わりました。 API を使用して、すべてをマシン スケールで実行する必要があります。 第 4 に、サイバーセキュリティでは、商用ツールの世界が共存し、オープン ソースの世界と緊密に統合されます。オープンソースのライブラリとコンポーネントを利用するすべての商用ソフトウェア エンジニアリング ツールを使用するソフトウェア エンジニアリングでは、しばらくの間、これが当てはまりましたが、サイバーセキュリティでは、オープン ソースはベンダー市場とは別に見られることがよくあります。私は以前、サイバーセキュリティにおけるオープンソースの役割を詳しく調べてきました。この役割は、業界が成熟するにつれて大きくなっていると思います。サイバーセキュリティ ベンダーは、オープン ソース ツールの商用バージョンを作成するだけでは逃れられません。彼らは、「私たちはオープンソースではありません」という声明を出したり、SOC 2 準拠証明書を示したりするだけでなく、その上に構築し、真の価値を付加する必要があります。 セキュリティにエンジニアリング アプローチを採用するということは、コンプライアンス ボックスをチェックするのではなく、防御を継続的に提供するためのプロセスの改善に重点を置くことを意味します。セキュリティ チームは、より多くの人員を採用することを推奨する前に、技術的なソリューションを提供し、スケーラブルなツールを構築できるようになります。これらすべての要因が組み合わさることで、私が詳細に説明したセキュリティへのエビデンスに基づいたアプローチは避けられないものになります。それはもはや問題ではなく、いつなのかの問題です (答え: すでに起こっています)。 製品ライフサイクルにおけるセキュリティの位置 セキュリティについて考えるとき、最初に頭に浮かぶ質問の 1 つは、「セキュリティはソフトウェア開発ライフ サイクルのどこに属するのか?」です。これはもっともな質問ですが、ソフトウェア開発のライフ サイクルだけに注目すると、実際のソフトウェアで何が起こっているかについて、目を見張るようなスポットが作成されます。サイバーセキュリティに対するエンジニアリング アプローチの役割を適切に議論するためには、ソフトウェアがどのように構築されているか、および本番環境で使用され始めた後に何が起こるかを含め、製品ライフサイクル全体を検討することが不可欠です。 歴史的に、セキュリティは製品を構築する開発チームから分離されていたため、リリース前に「コンプライアンス」を確保するための最後のステップと見なされていました。確かに、サイロとして存在していたソフトウェア開発ライフサイクル (SDLC) の部分はセキュリティだけではありませんでした。製品管理 (PM)、設計、エンジニアリング (フロントエンドとバックエンドに分割されることが多い)、品質保証 (QA) なども同様です。 クロスファンクショナル チームのアイデアを取り入れたアジャイルが採用される前は、ソフトウェア開発は大まかに次のように見えました。 プロダクト マネージャーは要件を作成し、デザイナーに送信します。 デザイナーはモックアップを作成し、開発チームに送ります。 バックエンド エンジニアは作業の一部を完了し、残りの部分をフロントエンド チームに送信します。 完成品はレビューのためにQAに送られました 適切な人が適切な段階で関与していなかったため、この従来のいわゆるウォーターフォール アプローチは、多くの無駄、非効率性、やり直し、不適切な意思決定をもたらしました。スクラムと のフレームワークによるアジャイルは、短いイテレーションとコードの頻繁なリリースにつながり、最も重要なことは、PM、デザイナー、ソフトウェア エンジニア、および QA が連携する機能横断的な製品チームを作成したことです。実際には、ソフトウェア エンジニアと QA は、要件と設計が開発の準備ができていると見なされる前にフィードバックを提供し、PM/QA は製品の構築中に入力を提供することで、後でコードを破棄する必要性を減らしました。そして、すでに「行われた」ことをやり直します。 かんばん アジャイルがすべての問題を解決したわけではありません。特に、DevOps が登場したとき、DevOps エンジニアは、製品チームが何をしているかについてのコンテキストがまったくないことに気づき、彼らの仕事は反応的でやりにくくなりました。最終的に、組織設計のベスト プラクティスが追いつき、最近では 2019 年に、Manuel Pais と Matthew Skelton が、テクノロジ チームの設計に関する私の意見では最も影響力のあるガイドである 公開しました。マヌエルとマシューは著書の中で、組織設計の一般的な課題をレビューし、成功するチーム パターンと相互作用に関するベスト プラクティスを共有し、テクノロジー企業のバリュー ストリームを最適化する方法を推奨しています。 Team Topologies: Organizing Business and Technology Teams for Fast Flow を 最近まで、セキュリティは開発組織の一部になることに遅れをとっていました。サイロ化されたチェックポストとして存在し、最良のシナリオでは、リリースを承認し、新しいチケットを開発チームに割り当て、一般的に「最優先」とマークされていました」。これは依然として多くの組織で見られるパターンですが、セキュリティへのアプローチは近年変化し始めています。 DevOps に対するセキュリティの対応として DevSecOps の成長が見られます。セキュリティが CI/CD パイプラインに組み込まれるにつれて、セキュリティの役割はコンプライアンスから防御の提供へと変化しています。新製品の開発に関連して、セキュリティは確かにソフトウェア エンジニアリングのように見え始めています。 将来的には、セキュリティ チームが組織内の独立したユニットとして機能し続ける可能性があります。ただし、アプリケーション固有の脆弱性は、製品を構築し、コードに関するコンテキストを最も多く持つソフトウェア エンジニアによって処理されることがますます多くなります。セキュリティ チームは、プラットフォームおよびサイトの信頼性エンジニアが現在果たしている役割と同様に、製品開発チームのコンサルタントとして行動します。 セキュリティ インフラストラクチャと運用に関するエンジニアリングの考え方 ソフトウェア開発について話すとき、セキュリティに対するエンジニアリングの考え方がどのように見えるかを想像するのは一般的に簡単ですが、セキュリティ インフラストラクチャと運用 - 日々発生するもの、その後、そしてソフトウェア開発の外。これは主に、アプリケーション セキュリティがソフトウェア開発ライフサイクルの一部であり、ベンチャー資金によるクラウド ネイティブの新興企業がコードを保護し、それを拡張可能な方法で行う方法を積極的に探しているためです。 比較的、エンジニアリングの考え方、アプローチ、およびフレームワークをセキュリティ運用、検出と対応、インシデント処理、デジタル フォレンジック、およびその他のセキュリティ分野に導入することについての議論はほとんど見られませんでした。企業のサイバーセキュリティ プロセスのこれらの重要なコンポーネントは、ネットワーク上に展開された「適切な製品」と、これらの製品を監視する少数の人々がいる限り、適切に機能する内部部品と見なされてきました。最も重要なことは、セキュリティ チームは一貫してリソースが不足しており、最新の攻撃を仕掛けることで消費されており、積極的に防御を構築することに集中できていないことです。 言うまでもなく、このアプローチは制限的であり、組織のセキュリティ スタンスにしばしば有害であることが証明されています。この声明を裏付ける証拠はありませんが、過去数年間に侵害を受けたとニュースで取り上げられているほとんどの (すべてではないにしても) 企業は、最新かつ最高のツールを社内に展開していたと推測します。環境。これらのツールがビジネスをセキュリティ インシデントから保護できなかったという事実は、決して悪いことをしているということではありません (まったく逆です)。代わりに、これらのイベントは、ベンダーのマーケティングが何を示唆していても、防弾の製品はなく、ビジネスと従業員を守るために、セキュリティへの取り組み方を変える必要があることを浮き彫りにしていると思います. エンジニアリングの考え方をセキュリティに取り入れることは、次のようないくつかのことを意味します。 ツールは単なるツールであることを受け入れ、実践領域としてのサイバーセキュリティの基礎をベンダーの選択だけでなく検討します。これは、次のような質問をすることを意味します。私が直面しているリスクは何ですか？私の環境ではどのような悪意のある動作が発生する可能性がありますか?それらをどのように検出していますか？検出された場合、どのように対応すればよいですか?」ではなく、「組織を保護するためにどのツールを購入すればよいですか?」 この認識を武器に、企業はこのアプローチを実践し、環境 (「単一画面」) を完全に可視化し、何を検出し、どのようにそれを行っているか (環境でどのような検出が機能するかを知る) を確保する必要があります。 、正確に何を検出し、どのように検出するか)、再現可能な方法で防御をテストする機能を備えています。 セキュリティ運用の多くのコンポーネントを自動化でき、自動化する必要があることを認識し、組織に防御を提供するためのスケーラブルな方法を構築する方法を探しています。実際には、これは、コードとしての検出、コードとしてのインフラストラクチャ、および他の技術分野で機能し拡張することが証明されているその他のアプローチを採用することを意味します。チームが新しい脆弱性や悪意のある動作を検出した場合、明日同じ脆弱性に対して同じ対応を手動で適用する必要がないように、それらに対応するためのツールが必要です。 歴史的に、セキュリティに関する知識のほとんどは、「そこにいて、それを行った」経験豊富な実践者の頭の中にありました。業界が成熟するにつれ、この知識を体系化し、世界中の組織が使用および改善できるように、共有、テスト、およびアクセスできるようにする方法を探す必要があります。サイバーセキュリティは、創造的で知的な敵に対処するため、常に芸術です。ただし、知識ベースを拡大し続け、現場で「最高の中の最高」を雇う余裕のない組織がサイバー防御にアクセスできるようにするためには、科学にもなる必要があります。科学に基づくエンジニアリング アプローチをセキュリティに適用することで、セキュリティ チームはシステムとプロセスを構築し、一貫して作業を行うことができます。 セキュリティ エンジニアリングの台頭と、それが未来のサイバーセキュリティをどのように変えているか 検出工学の進化とサービスとしての検出工学の出現 ここ数年、脅威の検出における透明性が非常に重視されてきました。この問題は、セキュリティ担当者、スタートアップの創業者、業界アナリストなどの注目を集めています。 2022 年、Gartner の元アナリストである Anton Chuvakin と Oliver Rochford の 2 人は、「検出における信頼と透明性について」というタイトルのミニペーパーを書きました。痛いほど明白に聞こえますよね？しかし、セキュリティ業界の全歴史を通して、これが常にそうであったとは限らないことは明らかです。私たちの中 顧客が検知の仕組みを確認することができなかったことを覚えている人もいます。市場は語りましたが、これらのベンダーはすべて、 とその子孫によって死んで葬られました。ブログの投稿は、このトピックに興味のある人にとっては素晴らしい読み物です。 には、ネットワーク IDS 侵入検知システムが導入された初期の頃、 Snort すべての組織の環境は唯一無二であり、その独自性は、SaaS の成長と、ほぼすべてに特化したツールの出現によって増加する一方です。組織内のすべての部門には、作業を管理するために使用するツールが数十個あります (マーケティング、人事、財務、製品、および運用チームだけで、スプレッドシートの使用を置き換えるように設計されたアプリケーションの数だけを想像してみてください)。それに加えて、一定レベルの成長を達成しているほぼすべての企業は、独自の内部アプリケーションを開発して、その業務、ビジネス モデル、または市場開拓戦略に固有のユース ケースに備えています。 すべての組織の環境の独自性は、攻撃者がすべての組織に侵入する方法と、防御者がその環境で悪意のある動作を検出できる方法の両方が異なることを意味します。実際には、セキュリティ チームが組織の環境に固有のものを検出するという問題を解決するには、その特定の環境用の検出ロジックを作成する必要があります。 あらゆる人を包括的にカバーすることを約束するセキュリティ ベンダーは (ウイルス対策と同様に) 優れた基本層ですが、失うものが多い企業にとっては十分ではありません。 検出工学は過去 年間で大きく進化しました。上記の記事で、Datadog のセキュリティ リサーチ ディレクターである Zack Allen は、検出コンテンツを作成するための「多ければ多いほど良い」アプローチが、単に「より多くの検出を行う」だけでなく、高品質で包括的な検出コンテンツが必要であるという成熟した認識へと進化したことを説明しています。 ". 以前は「魔法使い」と見なされていた検出エンジニアは、「尖塔から降りて、Blackhat と DEFCON で発表された最新の調査結果を世界に説教する」ようになりました。 10 検出工学について話すと、Zack は次のように結論付けています。 「ネットワーク セキュリティの専門家がいなければ、ネットワーク セキュリティ製品の検出を作成することはできません。これは、エンドポイント、クラウド、アプリケーション、およびホスト ベースの検出でも同じです。これは、患者の喘息を検出するための機械学習モデルを多数のデータ サイエンティストに構築させるようなものです。しかし、彼らは、肺炎患者がどのようにモデルに偽陽性を与えるかを説明するために医師を連れてくるのを忘れていました.対象分野の専門家が必要です。これは業界で変わっていませんし、変えるべきでもありません。何が変わったかというと、これらの専門家はソフトウェア エンジニアリングの原則の確固たる基礎を必要としているということです。これらすべての検出をスケーリングして最新の環境にデプロイしたり、スプリントを管理したり (そう、これはソフトウェア エンジニアリングです :))、多くの本体や多くの自動化なしでは、単体テスト、統合テスト、回帰テストを作成することはできません。上司は、人を雇うよりもソフトウェアを使って問題を解決できると聞いたほうがましだと断言できます。」 検出エンジニアリングが専用の明確な専門職に進化したことを示す 2 つの兆候 見られます。また、それを実装する際に組織が通過する成熟度の段階を定義することの始まりです。 による 組織全体の機能の能力と成熟度を測定するための最良の試みです。 が Kyle Bailey 検出エンジニアリング成熟度マトリックスは、 検出ロジックが万能ではなく、セキュリティ ベンダーが「すべての人を安全に保つ」という約束を果たせそうにないことを認識している組織が増えているため、建物の検出を専門とするサイバーセキュリティの新興企業を目にするようになりました。コンテンツ。これらの企業は、単純にアラートをトリガーするのではなく、ルール自体の内容を表示および編集可能にすることで、セキュリティ チームが環境内で正確に何が検出されているか、どのように検出されているか、どのプレイブックまたはアラートがトリガーされるかを理解できるようにします。が検出されます。この分野のスタートアップの 2 つの注目すべき例は、SOC Prime と SnapAttack であり、どちらも検出コンテンツを記述するための事実上の標準言語である Sigma をサポートしています。これらのベンダーは、完全なカバレッジを約束する代わりに、企業が完全に透明性のある従量制の方法でセキュリティ カバレッジにアクセスできるようにします。 組織は、検出エンジニアリングを専門とするベンダーから一般的な検出カバレッジを購入できるだけでなく、セキュリティ サービス プロバイダーに環境に合わせてカスタマイズされたアラート ロジックを構築させることができます。これは今日、すべてのプロバイダーが提供するものではありませんが、セキュリティ コンサルタント会社や管理された検出および対応企業が、ベンダーの選択やアラートの監視を超えた付加価値を求めているため、業界はこの方向に向かっていると思います。間もなく、サービスとしての検出エンジニアリングがセキュリティ サービス プロバイダーの標準となるでしょう。 特に、顧客の期待の変化は、エンドポイントの検出と応答 (EDR) や拡張された検出と応答 (XDR) などのセキュリティ ベンダーの運用方法も変化させています。多くの場合、すべての顧客に対して社内で構築された汎用検出ロジックを実行する「ブラック ボックス」として開始されましたが、現在では、顧客が独自の検出を上に書き込む機能も提供しています。私が製品を率いる LimaCharlie、Panther、およびいわゆる Open XDR のまったく新しいカテゴリなどの新しいベンダーも、組織のセキュリティ カバレッジ (カスタム ルールだけでなく、組織内で実行されるすべての検出) を完全に可視化しています。 セキュリティ エンジニアリングの重要性の高まり 例として検出工学を使用します。セキュリティのすべての分野で、エンジニアリングへの大きな推進力が見られます。コードとしてのインフラストラクチャにより、インフラストラクチャの管理は IT 部門ではなくエンジニアリング部門が担当するようになりました。したがって、ソフトウェア エンジニアリング スキルはセキュリティの前提条件になりつつあります。 クラウドの台頭に伴い、ソフトウェア エンジニアリングの原則と実践が、インフラストラクチャのプロビジョニング方法、セキュリティ ポリシーと構成の適用方法、企業のセキュリティ体制のテストと調査方法、セキュリティ構成の変更の実装と追跡方法などを支えています。 . DevOps エンジニアはインフラストラクチャのプロビジョニングと管理を担当しますが、エンジニアリングに関する深い知識とセキュリティに関する深い理解を兼ね備えたセキュリティ エンジニアは、インフラストラクチャのセキュリティを確保するのに理想的です。 今日、ほとんどのサイバーセキュリティの専門家は、ネットワーク アーキテクチャの設計、ファイアウォールのプロビジョニングとファイアウォール ポリシーの管理、および企業内の IT を維持するために重要なその他のタスクなど、IT のスキルを身につけています。残念ながら、セキュリティ担当者の多くは、ソフトウェア エンジニアリングの最も基本的な知識しか持っていないため、インフラストラクチャ、ポリシー、検出など、すべてがコードとして存在する世界で必要なスキルを開発できていません。基盤となるインフラストラクチャがコード化されている場合、セキュリティ プロフェッショナルがコード化を学ぶ必要があるのは当然のことです。同じことが自動化と API の使用にも当てはまります。技術的なタスクの大部分は API を介して大規模に達成されるようになったため (以前はセキュリティ チーム内で手動で行われていた作業を含む)、設計方法を理解している人が必要です。安全な方法で API を使用および廃止します。 セキュリティ エンジニアリング チームは、セキュリティの問題に対するエンジニアリング ソリューションを構築する運用管理を超えて取り組むことが期待されています。既製のセキュリティ ツールではニーズや環境の独自性に対応できないことに多くの組織が気付くにつれて、適切なレベルのリソースとサポートを持ち、セキュリティ体制の強化を真剣に考えている組織は、商用の構成を超え始めています。製品。一部のユース ケースでは、セキュリティ ベンダーから購入したツールをそのまま実装するのに適していますが、多くの場合、組織固有のニーズに対応するために微調整が必要です。しかし、特に大量のデータを扱う大企業やクラウド ネイティブ企業の間では、商用ツールでは多数のセキュリティ ニーズや要件に対応できないという理解がますます高まっています。これらの企業は、セキュリティ スタックの一部の要素を社内で構築し始めており、これらのソリューションの設計と開発を社内のセキュリティ アーキテクトとセキュリティ エンジニアに委任しています。 Appdome の Tom Tovar は、彼の で、セキュリティ組織を 3 つのカテゴリに分類できると提案しました。 最近のポッドキャスト 従来のセキュリティ チームは、セキュリティとコンプライアンスに関する深い知識と、両方のベスト プラクティスを備えた、技術的に優れたセキュリティ プロフェッショナルで構成されています。 多くの場合、システムの設計、製品評価、侵入テストなどを担当するセキュリティ研究者やセキュリティ アーキテクトを擁する高度なセキュリティ チーム。 現代の組織向けのセキュリティ ソリューションを構築および提供できる「ハードコア」なエンジニアリングの才能を持つサイバーセキュリティおよびエンジニアリング組織 私は、これらのカテゴリを成熟度の異なる段階としてではなく、組織のニーズに関する進化として見ています。クラウド ネイティブ企業は、DevOps、ソフトウェア エンジニアリング、および製品開発と密接に連携するように設計されたセキュリティ エンジニアリング チームの構築を開始しています。これにより、従来は IT チームとセキュリティ チームが所有していた要素の多くが、DevOps チームとセキュリティ エンジニアリング チームが所有するようになりました。ビルダー (セキュリティ ソリューションを作成できるエンジニアリングの才能) に依存するこのモデルは、すべての組織に必要なわけではありません。しかし、ますます多くの企業が初日からクラウド ファーストを開始し、SaaS ツールの急増により環境がよりユニークになり、より多くのセキュリティ チームがニーズに合わせて調整されたセキュリティの価値を認識するにつれて、大規模なセキュリティエンジニアリングへのシフト。 この記事を書いている時点では、組織設計のベスト プラクティスがセキュリティ エンジニアリングの台頭に追いついていないことがわかります。実際には、セキュリティ エンジニアリング チームは管理を担当する独自のツールを持っていますが、セキュリティ エンジニアとソフトウェア/DevOps エンジニア、および運用セキュリティ チームの間で、所有権をめぐって多くの対立があるようです。今日の時点で、セキュリティ エンジニアリング チームを持つ幸運なすべての組織で、そのチームの形はわずかに異なるように見えると言っても過言ではありません。組織の対立と所有権の不明確な領域は、新しい分野の形成における自然なステップであるため、私たちが見ているものは有機的で期待されています. セキュリティ アナリストの役割の性質の変化 サイバーセキュリティがアズコードになるにつれて、コーディングしない人にとってはますます難しくなります。私が話しているのは、セキュリティ アナリストの役割の変化についてです。 セキュリティ アナリストは、従来、Tier 1 (トリアージ スペシャリスト)、Tier 2 (インシデント レスポンダー)、Tier 3 (エキスパート アナリスト) に分類され、セキュリティ オペレーション センター (SOC) チームで重要な役割を果たしています。最近の自動化の進歩により、この役割の形が変わり始めています。 まず第一に、セキュリティ チームが効率と生産性を向上させる方法を模索しているため、以前は手動だった SOC のプロセスと手順がますます自動化されています。第 2 に、人工知能 (AI) の台頭により、セキュリティ チームが経験している最大の問題点の 1 つである、何千ものアラートを手動でトリアージする必要がなくなります。今日の時点では、AI はセキュリティの自動化という約束をまだ果たせていませんが、最終的には実現するでしょう。おそらく私たちが想像しているよりも早く、敵対者が独自のモデルと防御を訓練する AI の戦いを見ることになるでしょう。未来像はさておき、SOC アナリストはセキュリティの変化する形に適応する必要があります。 上記の 2 つの要因により、SOC アナリスト (特に、従来「Tier 1」と呼ばれていたアナリスト) は、新しいスキルの習得を開始する必要があります。最も差し迫った技術的スキルはコーディングであり、アナリストは、2022 年に で示されているように、それを理解しています。 Tines によって委託された SOC アナリストの声の調査 業界には、アナリストの将来は暗いと示唆する人騒ぎが十分にあるが、私は別の見方をしている.役割がなくなるわけではありませんが、その形や範囲は変化していきます。これまでアナリストとは、主に特定のセキュリティ製品の使い方を知ることでした。現在、セキュリティはツールの問題ではなく、アプローチの問題として見られ始めています。さらに、セキュリティ ツールはコモディティ化および標準化されているため、すべてが互いに同様に機能します。アナリストが 1 つの EDR を使用した場合、別の EDR を習得するのに多くの時間を必要としない可能性があります。アナリストが過去に使用した正確な製品は、セキュリティの基礎を理解することほど重要ではなくなります。業界が成熟するにつれて関連性を維持しようとするアナリストは、より技術的になる必要があります。誰もがエンジニアになるわけではありませんが、攻撃者がどのように世界を見て、どのように攻撃が行われるかを理解することがますます重要になります。 セキュリティのアナリストの未来は、ソフトウェア開発の QA (品質保証) プロフェッショナルの未来と似ていると思います。 QA ジョブの大部分はもはや手作業ではなく、自動化ツール、言語、およびフレームワークを使用する必要があります。 Amazon や他の多くの企業が現在「テスト中のエンジニア」と呼んでいるのは、製品の機能と API のテストに重点を置いたソフトウェア エンジニアです。手動の QA はまだ存在しますが、手に入れるのは難しく、その役割は信じられないほど競争が激しく、資格のある労働者の供給が需要を大幅に上回っているため、彼らの報酬は最も低く抑えられています。 Amazon の Mechanical Turk はゲームを劇的に変え、QA のコストをさらに削減します。品質保証は死んだわけではありませんが、大きく変化しました (特に、高度な AI と ML を使用しても変化しませんでした)。 未来のセキュリティ スタック セキュリティ チームがより技術的になるにつれて、どのベンダーも「安全性」と「セキュリティ」を機能として約束できないことに気づき始めます。従来、市販のセキュリティ ツールのほとんどは、セキュリティ チームから基本的なレイヤーを抽象化し、何が起こったかを要約したアラートとレポートの形式で概要を提供していました。セキュリティ インフラストラクチャの基盤層とイベント レベルのデータを可視化する必要がある組織は、オープン ソース ツールを使用するか、ツールをゼロから構築する必要がありました。 DevSecOps アプローチではセキュリティの基盤レイヤーを可視化する必要があるため、いわゆるサイバーセキュリティ マーケット マップを見ると、将来のセキュリティ スタックは現在のものとは大きく異なるものになるでしょう。まず第一に、実践者がシステムを調査し、環境を完全に可視化し、ニーズに合わせたセキュリティ カバレッジを構築するために使用できる中立的なソリューションがますます増えるでしょう。これらのツールは透過的に機能し、その作業は簡単にテストおよび検証できます。重要なことは、組織のセキュリティ ユース ケースに対処するために連携できる、商用ソリューションとオープン ソース ソリューションの融合が見られることです。セキュリティの中心には、プロセスとセキュリティの専門家がいます。ツールは単なる「製品」であるため、ツールではありません。それらがどのように使用され、何のために使用されるかが重要です。 過去数年間で、盲目的にベンダーを信頼するという考えを拒否するセキュリティ リーダーが増えているのを目にするようになりました。 SOC Prime、Panther、Prelude、そして Interpres などがあります。 最近では 以下の画像は、セキュリティに対してエビデンスに基づいたエンジニアリング アプローチを採用している今日の企業とオープン ソース ツールのリストです。網羅的なものではなく (上記の基準を満たす優れたツールは他にもたくさんあります)、従来の「マーケット マップ」ではありません。 才能のギャップを埋める 優秀な人材を採用するには、ビジネスの仕組みを変える必要があります 悪意のある攻撃者からビジネスを守るセキュリティ チームは、ストレスを受け、人手不足で、過小評価され、過小に支払われています。現実には、ハッキング グループは、どの企業よりも技術的な人材を引き付けるのに優れています。彼らは非課税で、どの企業よりもはるかに多く支払っています。素晴らしいワークライフ バランス、ハッキングのスリル、達成感を提供します。それらのほとんどは 100% 匿名です。価値のない認定資格を蓄積し、数年ごとに数百ドルを支払ってそれらを「最新の」状態に維持する必要はありません。また、採用担当者、人事、基本的なコンプライアンス トレーニング、職場の政治、法務、コンプライアンス、給与、要求の厳しい上司に対処する必要もありません。あげくの果てに。これが私が攻撃者のために働いていることを宣伝しているように聞こえる場合、それは私の意図ではまったくありません。実際のところ、これは経験豊富なセキュリティ プロフェッショナルにとって目新しいことではありません。私は単に、優秀な人材を雇うためには、ビジネスを改善する必要があることを示しているにすぎません。 この投稿は、最高のセキュリティ プロフェッショナルの多くが、大企業で働く官僚主義に対処する意欲を感じていないという事実と相まって、現在の雇用市場の暗い状況を描いています。 迅速で簡単な解決策のリストを私が持っていると提案するのは非倫理的で真実ではないため、業界として一緒にそれらを見つけなければなりません.初心者レベルの仕事の「5 年以上の経験」の要件を削除することから始めて、先入観を取り除き、採用プロセスを改善しながら、それを積み上げていくことができます。 ソフトウェアエンジニアにセキュリティを任せる セキュリティのすべてが as-code になりつつあるため、サイバーセキュリティの人材にとってめったに議論されないパイプラインの 1 つは、ソフトウェア エンジニアリングである可能性があります。技術的なセキュリティの専門家であるソフトウェア エンジニアリングよりも、エンジニアにセキュリティを教える方が簡単であると主張する人もいます。私はこの声明の正確性について判断を下すのに適切な人物ではありませんが、その道が現実であることを知るために、十分な数のソフトウェア エンジニアがセキュリティ専門家になるのを見てきました。 課題は、サイバーセキュリティがソフトウェア エンジニアリングの卒業生にとって実行可能なキャリア パスであることを知らせること、適切なトレーニングを提供すること (コンピューター サイエンス プログラムに深いレベルのサイバーセキュリティ コースを追加すること)、および彼らが自分の道を見つけるための有意義なキャリア パスを設計することにあります。サイバーセキュリティ。これは、新卒者が指揮できる多くの初級レベルのサイバーセキュリティの仕事に対する報酬の問題を提起します.セキュリティで提供されるものよりも20〜40％高いソフトウェアで最初の仕事に就くことができれば（面接を受けることさえできれば）. )、ソフトウェア エンジニアにセキュリティを任せるという考え全体が崩壊します。 新世代のセキュリティ エンジニアの教育 サイバーセキュリティにおける人材不足については多くのことが語られており、この問題を解決することを約束する新規参入者の海に気付くのは簡単です. 6 週間のサイバーセキュリティ ブートキャンプからオンライン コース、新しい大学の学位取得まで、誰もが「セキュリティの未来を教育する」というパイの一部を求めています。私たちが必要としているのは、より多くの高校生と大人がセキュリティに興奮してキャリアを変え、これらのプログラムに登録する準備ができていることだけだと考えたくなります.3〜5年後、私たちはすべて準備が整っています. 大多数の教育プログラムを見ると、カリキュラムでエンジニアリングの要素が省略されていることがわかります。データの編集に十分な時間を費やしていないため、このトピックに関する私の観察はかなり逸話的ですが、ここに私が見ているものがあります: ほとんどのブートキャンプは非常に短期間でレベルが高いため、卒業生に業界に関する深い知識を提供できるとは信じられません。私は、ブートキャンプを経験した多くの優れたセキュリティ プロフェッショナルに会いました。しかし、彼らはブートキャンプに参加したからではなく、彼らが彼らの外で何をしたかによって偉大になりました.これらの短い没入型コースに価値がないとは言いません。私が言おうとしている点を説明するために、フロントエンド開発を教える 4 ～ 8 週間のブートキャンプが非常に多く、バックエンド開発を教える 4 ～ 8 週間のトレーニングが少ない理由を考えてみてください。その答えは単純です。バックエンド開発は、セキュリティと同様に、技術的な理論と概念を深く理解し、これらの概念を処理し、多くの場合視覚的なフィードバックなしでコードに実装する能力を必要とするからです。簡単なウェブサイトの作成方法を人々に教えるのにかかる時間と同じ時間で、それを教えることはできないと私は記録に残します. 多くの大学のプログラムは、特に修士レベルでは、実践的なスキルの開発よりもポリシーの作成に重点を置いています。より深く実践的なものでさえ、大学教育全体としては、古すぎる、理論的すぎる、浅すぎる傾向があります。セキュリティは日々進化しており、新しいエクスプロイト、新しい脆弱性、新しい攻撃ベクトル、新しいテクノロジーがすべて毎日作成されています。大学のプログラムは、長い承認、厳格な学術レビュー、および評価を経なければならないため、プログラムが承認されるまでに、6 か月以上前のニュースについて語られます。業界の最新情報を把握し、生徒に役立つ実用的で最新のスキルを教えるために懸命に取り組んでいる優れた教師やインストラクターが何人かいます。私たちは皆、彼らの仕事に深く感謝すべきですが、これらの人々は教育システム自体に沿って働いているのではなく、学生と社会のために良いことをするためにその限界を回避していると言う価値があります. サイバーセキュリティ認定は、市場が必要とするスキルや経験を反映していません。私は、人々がそれらに費やす労力を減らすつもりはありません。代わりに私が言いたいのは、ごくわずかな例外を除いて、これらの認定資格は理論的な概念を提供し、実際にそれを行う実際のスキルを提供することなく、セキュリティをどのように行うべきかを人々に知っているように感じさせるということです.攻撃者はコードに深く入り込み、制御を回避し、脆弱性を悪用し、データを盗み出す方法を探していますが、私たちは、人々にポリシーの書き方を教え、クラウド セキュリティに関する多肢選択式試験に合格することで攻撃を阻止できると真剣に考えているようです。 .人生で一度も手術をしたことがない「心臓の証明書」を持つ心臓外科医によって手術を受けることを想像してみてください（私はできません）。 これらすべては、今日の最高のセキュリティ プロフェッショナルは大学出身ではなく、将来のように見えるものからも生まれないということを言います。セキュリティ エンジニアリングの最先端の専門家になる人々は、侵入テスト、軍事、NSA、および強力な攻撃要素を持つその他の政府機関での実践的な仕事から生まれます。彼らは、セキュリティを真剣に扱うクラウドネイティブ企業の成熟したセキュリティ チームから来ています。彼らはコンピューターの前で、CTF (capture the flag) 大会や、Open SOC、Black Hat、DefCon などのイベントで独学しています。 セキュリティの未来を形作り、人材のギャップを埋めるために、十分な意欲のある個人が、人々、企業、および国を保護するために必要なスキルを独学する方法を見つけることを期待することはできません.希望は戦略ではなく、6 週間のブートキャンプでもありません。技術的なサイバーセキュリティのギャップを埋めるためのシステムと機関を構築する必要があります。セキュリティは難しいです。セキュリティを教えることも難しいですが、実行する必要があります。コンプライアンスとポリシーの作成は重要ですが、それだけではネットワークを攻撃者から守ることはできません。 ソフトウェア エンジニアをサイバーセキュリティに参入させる方法を見つける必要がある一方で、エンジニアリング スキルを習得するための専門性の高いセキュリティ専門家も必要です。すべてのインシデント対応、デジタル フォレンジック、およびエンドポイント セキュリティ担当者がエンジニアになるわけではありませんが、ソフトウェア開発の基礎を理解し、Python などの言語に堪能になることは、ほとんどの人にとって有益です。セキュリティ運用に工学的アプローチを採用することで、インシデント対応の手動部分を自動化し、組織の境界を保護するスケーラブルな方法を継続的に構築しながら、積極的な防御の構築により多くの時間を費やすことができます。そのためには、ソフトウェア エンジニアリングやコンピュータ サイエンスの学位でセキュリティの基礎を教えるべきであるのと同じように、サイバーセキュリティ教育にソフトウェア エンジニアリングのコースを含める必要があります。 最後に 確かに、すべてのセキュリティ問題を解決する特効薬はありません。また、セキュリティ エンジニアを増やしても解決しません。ただし、セキュリティにエンジニアリング アプローチを採用することで、ソフトウェア製品に最初からセキュリティを組み込み、業界の成熟を加速させ、セキュリティ オペレーションの将来性を保証することができます。 人材不足は間違いなく障害になるだろう。しかし、必要なリソースがないからといって、困難な問題に対する実行可能な解決策を却下することはできませんし、すべきではありません。また、雇用慣行を変更し、将来のセキュリティ リーダーを特定する基準を再評価する必要があることも明らかです。最適化するものを取得します。攻撃者は毎日、数え切れないほどの時間を新しいテクノロジーの学習、私たちが構築したソフトウェアのリバース エンジニアリング、コードの脆弱性の探索に費やしています。セキュリティの求人情報を見ると、多肢選択式テストに合格し、コードがどのように機能し、それを防御するかを理解するために必要なスキルとは非常に異なるスキルである認定を取得することで、攻撃者を阻止したいと考えていると簡単に結論付けることができます。 サイバーセキュリティに対する工学的アプローチは避けられないと確信しています。すでにその成長の兆しが見え始めており、ここからさらに加速するでしょう。問題は、その開発のためのインフラストラクチャをどれだけ迅速に構築できるかということです。歴史が私たちに何かを教えてくれているとすれば、それは全体として、サイバーセキュリティの実践の状態が、DefCon や Black Hat などで行われた最新かつ最高の講演から何年も遅れているということです。業界を変える出来事が次にどのようなものになるかを見極める必要があります。 この記事のリード画像は、プロンプト「cybersecurity」を介して HackerNoon の によって生成されました。 AI Image Generator
