ソフトウェアサプライチェーンセキュリティ技術交流会（OSCS）は、2023年7月18日夕方19時30分より、ソフトウェアサプライチェーンに関わる様々な企業から71名が参加し、第1回オンライン非公開セミナーを開催しました。セキュリティ技術専門家の登録については、セミナー参加規定の要件に従って申請者を審査し、最終的にインターネット、金融、通信事業者、ソフトウェアメーカー、国有企業から35名以上のセキュリティ専門家がセミナーに参加しました。その夜。
「ソフトウェアサプライチェーンセキュリティ構築の価値」テーマ共有
セミナーの最初の部分は、Murphy Security & OSCS の創設者 Zhang Huapeng 氏によるテーマ共有で、Zhang Huapeng 氏は 3 つの公式を使用して、ソフトウェア サプライ チェーン セキュリティの構築価値についての考え方を共有しました。
次に、計算式の各要素を 1 つずつ分解して分析します。まず、ソフトウェア サプライ チェーンのセキュリティのリスクを管理する必要があります。ソフトウェア サプライ チェーンのセキュリティ資産が最も重要なリンクであることは明らかです。資産台帳は、管理・コントロールすべきリスクの対象であり、その総量は将来のその建設の価値を測る重要な分母でもあります。
ソフトウェア サプライ チェーンの資産台帳のコレクションは、オフィス ソフトウェア、自社開発ソフトウェア、および外部委託生産ソフトウェアの 3 つの側面から収集およびカウントできます。
ソフトウェア サプライ チェーンへの攻撃によって引き起こされる可能性のあるデータ侵害は、依然として企業にとって最も懸念されるリスク ポイントです。
2 つ目は、ソフトウェアの知的財産コンプライアンスの満足度であり、ソフトウェアのユーザーとソフトウェアの作成者の両方が、コードの知的財産コンプライアンス管理に関する非常に重要な問題を抱えています。
さらに、誰もが hvv 期間中に侵害されないことを最も懸念しており、結局のところ、攻撃訓練や防御訓練で最も一般的に使用される攻撃方法は、ソフトウェア サプライ チェーンの脆弱性を悪用することです。
毎年の大規模な攻防訓練に加えて、誰もが最も懸念しているリスクは、実際には、ソフトウェア サプライ チェーンの一般的な脆弱性によって脅迫されるリスクです。
企業の中級および上級管理者にとって、ソフトウェア サプライ チェーンのセキュリティは新しい技術的方向性です。新しい技術的方向性では、いくつかの最先端の技術的探求と実践があり、業界への成果は、企業における影響力を高めることになるでしょう。業界を強制する非常に良い方法です。
構築の利点についての説明は終わりましたので、構築コストについて話しましょう。ほとんどの場合、このコストは主に運用コストです。実際、運用コストは、成熟したソフトウェア サプライ チェーンのセキュリティ機能と統合すると、非常に制御可能です。 。
1 つ目は、ソフトウェア サプライ チェーンのセキュリティ機能の導入と使用にかかるコストです。成熟した商用製品を使用する場合、コストは非常に制御可能です。自社開発の場合、エンジニアリングの観点から非常に高くなります。および脆弱性ナレッジベースの運用です。
さらに、ソフトウェアのサプライチェーンにおけるセキュリティ問題に対処するコスト、脆弱性を迅速に修復してソフトウェアのアップグレードによって引き起こされる互換性の問題を回避する方法、および実際には引き起こされない脆弱性を除外する方法が主要な課題となります。
日々のセキュリティ技術の運用は、継続的な運用の効果を確保するための非常に重要な手段であるため、開発者のセキュリティ意識を継続的に向上させ、企業ソフトウェアサプライチェーンのセキュリティガバナンス要件を明確にする必要があります。
ソフトウェア サプライ チェーンのセキュリティ ガバナンスに関する企業の事例をいくつか共有する
費用対効果の高いガバナンス ソリューション
体系化されたケーススタディ
会議前に質問を集めたワークショップからの抜粋
Q1: 脆弱性データの正確性を確認する方法
多くの CVE 脆弱性には多くのデータ フィールドが欠落しており、さまざまなパブリック チャネルから収集された一部の脆弱性の一部のデータ情報は正確ではない可能性があります。この質問の核心は、サプライ チェーン ツールのセキュリティ テストを行うときに、脆弱性データベース全体のデータが正確であることをどのように確認するかということです。一部のフィールド、修正、影響範囲などを含みます。
| インターネット企業の上司：過去には、大量の脆弱性情報が受信され、収集後、一部の学生がデータを調整して処理するように特別に手配されました。
| ソフトウェアメーカーのお偉いさん：この分野に関しては実はあまり蓄積がなく、主にグループの能力を活用しています。たとえば、SCA が特定された後、脆弱性ライブラリと衝突した後に脆弱性を修復するなど、脆弱性にある程度の沈着が見られます。私たちのチームは、脆弱性を悪用するための条件の抽出を行い、それらをできるだけ多くデポジットします。バグをより良く修正するためにいくつかの開発言語に変換すると、実際に作業負荷が軽減されます。
| ソフトウェアメーカーのお偉いさん: 外部脆弱性ライブラリには、CVE 脆弱性などのいくつかの落とし穴があることがわかります。少し前に、金融会社のセキュリティ チームと連絡を取りました。コンポーネントの影響範囲によって特定された CVE 脆弱性の多くは、非常に不正確です。実際にさまざまなモジュールに影響を与える log4j の脆弱性も含まれます。例えば、log4j-core、log4j-apiなどがあります。モジュールは多数あり、脆弱性の影響を受けるモジュールも異なりますが、CVE内の識別情報にはlog4jが1つだけ書かれています。脆弱性の照合を行うと、log4j 関連のすべての脆弱性が照合される可能性があります。しかし、実際には、異なる脆弱性によって影響を受けるモジュールは実際には異なります。これは典型的なピットです。前述したように、このピットでは各脆弱性の実際の影響を手動で分析する必要がある場合があります。この分析により、その後のマッチング結果の精度をある程度保証できることがポイントの一つです。
もう 1 つの例は修復計画ですが、実際には多くのデータが入手できず、脆弱性ごとの修復計画の精度はさまざまなデータ ソースから収集したデータで調整する必要があるとも言われています。
10 年以上前、アリのうぬぼれで放蕩息子は Java の脆弱性研究に焦点を当てていました。彼は Java のゼロデイ脆弱性を掘り出す方法について言及しました。Java の一部のゼロデイ脆弱性は、特定の構成が必要な場合にのみこのゼロデイ脆弱性を引き起こします。コミュニティでその間違った設定を行うように他の人に教える人もいます。外部で収集されたデータや与えられた修復ソリューションの多くは、実際には間違っています。実際のところ、特別なスキルはないと思いますが、各脆弱性の実際の影響を整理する必要がある場合があり、脆弱性の修復計画を検証する必要がある場合もあります。このようにして修理のための研究開発に進められる場合、安全性を確保するという専門性と権限が疑われることはありません。
Q2: ソフトウェアサプライチェーン攻撃の脅威と予防策、サプライチェーンの透明性とトレーサビリティ、サプライチェーンのセキュリティとコンプライアンス。
| ソフトウェアメーカーのお偉いさん: 最初の質問は実際にはサプライ チェーンの能力構築に関するもので、2 番目の部分は実際にはソフトウェア サプライ チェーンの資産台帳の構築に関するものです。3 番目の部分はコンプライアンスに関するもので、1 つは海に行くということはライセンスのコンプライアンスが重要になる可能性があるということです。さらに、一部の国内の自主管理可能な新荘コンプライアンス。次回はこの問題に関するセミナーを開催できればと思います。
Q3: サプライチェーンの脆弱性による誤検知を減らす方法
| ソフトウェアメーカーのお偉いさん: 誤検知を減らすには、2 つのことを行う必要があると理解しています。
最初に行うことは、サプライ チェーン コンポーネントの精度を特定することです。この部分での過去の実践のいくつかは、主に特定することです。たとえば、Java のような多くのプロジェクトは、 pom.xml で構成するときにスコープをテストとしてマークしており、一部はランタイムですなど、さまざまなタグが付いています。異なるタグは、異なるコンパイル環境で使用されるコンポーネントに対応します。この点は注意が必要で、例えばテスト環境で使用するコンポーネントはオンライン上では影響を受けない可能性があるため、脆弱性を公開する際にはこの部分を除外する必要があります。
2つ目は、サプライチェーンの成分分析を行う際に、成分分析の精度を考慮することです。たとえば、パッケージ管理ツールとしての Python は、パッケージ管理の依存関係を実行するときに、正確な特定のバージョンを識別できない可能性があります。一般的な一致を行うと、誤検知が発生する可能性があります。これは最も基本的な誤検知です。もちろん、他にも多くの状況があります。
2 番目の主な状況は、脆弱性へのアクセス可能性の検証です。これは海外では多く行われていますが、中国ではほとんど行われていません。私たちの統計によると、脆弱性の 95% 以上は誤検知です。たとえば、fastjson はこのバージョンにのみ一致し、脆弱ですが、実際には、fastjson の欠陥関数メソッドがコード内でトリガーされるのでしょうか? それによってトリガーされる関数クラスのメソッドがコード内で呼び出されることを含みますが、そのテイントが制御可能なパラメーターや抜け穴を渡すことができるかどうかは、JDK バージョンなどの依存環境に依存してトリガーされます。これらは、誤検知結果を減らす際に考慮する必要がある点です。海外では脆弱性アクセシビリティ分析という比較的成熟した基盤があり、現在は機能ベースの手法を進めており、このようなコードレベルでの識別や、最近では環境識別によるマッチングなども行っています。脆弱性の到達不可能性。
上記の回答にも記載されています: デモンストレーションの脆弱性の開発は本当に影響を受けますか? 研究開発部は、コードの脆弱性によってこの関数クラス メソッドがトリガーされることをセキュリティよりもよく理解している場合がありますが、呼び出されないため、研究開発部がセキュリティに疑問を抱くという不正確な結果につながります。
| ソフトウェアメーカーのお偉いさん：先ほどの2つの意見には賛成です、実は脆弱性データベースを連携させる方法は他にもありますが、弊社製品を使用する必要があるため、ツールの修正についてはあまり経験がありません。私たちが維持しているのは、実際には脆弱性の悪用条件です。もう 1 つは、誤検知脆弱性データベースを維持し、誤検知脆弱性に対して脆弱性データベースを逆最適化することです。
| インターネット企業の上司：少し混乱していますが、なぜ全員が誤検知をするのでしょうか？影響範囲が比較的大きい fastjson と log4j を除いて、その他の高リスクの脆弱性はせいぜい数十、数百の資産に影響を与えるものであり、修復コストはそれほど高くありません。
| ソフトウェア メーカーの偉い人: 実際、複雑な依存関係を持ついくつかのコンポーネントをアップグレードする必要がある企業がいくつかありますが、そのシステムはもう保守されていません。新人が古いシステムの保守とアップグレードを引き継いだだけです。互換性の問題なので、修正するつもりはありません。
また、研究開発が比較的好調でプロジェクトの進捗が比較的タイトな企業もありますが、多くの場合、研究開発の心理として「抜け穴は直したくない」「修正したくない」という心理が働きます。セキュリティが毎日抜け穴を修正するように要求することに同意できません。質問: この脆弱性は本当に影響しますか? 研究開発者がたまたまセキュリティに精通していて、コードロジックがこの脆弱性によって引き起こされることはないと判断した場合、そのような疑いが生じた場合、セキュリティ担当者はその脆弱性を修正するよう求めてきますが、その協力は決して高くありません。バージョンの一致だけが行われるため、実際には潜在的な隠れた危険にすぎません。この脆弱性が確実に引き起こされるということや、オンライン コードに影響を与えるということを意味するものではありません。多くの企業の研究開発部門は、この件について多くの疑問を抱くでしょう。
しかし、国有企業や○○クラウドのような企業は、特に国家インフラなどの管理・統制に対する要求が高く、システムを持っている場合は変更する必要があり、研究開発の協力度も非常に高い。しかし、汎インターネット顧客のほとんどは、実際にはこの問題を解決するのが非常に困難です。
Q4: 効果的に構築およびプロモーションするにはどうすればよいですか? 構築後、どのようにして完全に機能することができるでしょうか?
| ソフトウェアメーカーのお偉いさん: 今日は詳しく説明するのではなく、最初に主な一般的な方法について説明します。○○クラウドの体験など、最初の運用やプロモーションでは基本的に制度や規範、要件が出てきます。XXクラウドは脆弱性の解消を要求しており、顧客に納入するすべての基本コンテナの脆弱性を解消することが求められている。システムを推進、導入するためのシステム、評価、賞罰を開発し、研究開発のためのサポートツールを提供します。評価を行うには、XX クラウドの宣伝が比較的強力です。質問の中に、開発が承認しない場合は停止されると記載されています。個人的には、会社の管理要件はそれほど厳しくないと感じています。
Q5: 主な矛盾と利点をどのように定義するか
| ソフトウェアメーカーのお偉いさん：昔はイベントドリブンでしたが、今は毎日そんなにイベントが多くないかもしれないので、これをやると本来の原動力が失われることに等しいので、これを日常的にやると長期的なメリットをどう評価するか。
Keike にいた頃と Baidu にいた頃では、私のセキュリティに対する考え方や概念が大きく変わりましたが、Keike の上司が CCB 出身だったことも影響しているのかもしれません。インターネット企業の典型的な考え方は、大きなイベントが起こったら、その機会を利用して能力を構築するというものです。ただし、銀行や多くの主要産業では、その構築は、オフィス ネットワーク、生産環境、アウトソーシング システムを含むすべてのシステムなどの資産全体を識別するなど、会社全体の全体的なリスクを軽減する傾向が強くなります。資産は整理されており、整理後に分析されます。特に CTO や CEO レベルでの懸念は、ソフトウェア サプライ チェーンのセキュリティに向けた会社全体の全体的な状況を明確に説明できるかどうかです。たとえば、資産はいくつあり、これらの資産にはどれだけの隠れた危険があるのでしょうか? 私たちが歴史的に問題を発見することで、隠れた危険を解決できるでしょうか? たとえば、美団のすべての SRC によって同様の脆弱性が何件発見されたか、攻撃インシデントが何件発生したか、ネットワーク保護期間中に発生した攻撃インシデントが何件あったか、あらゆる側面からグローバル資産に関連するリスクが何件あったかなどです。分析結果からどの主要資産を予測するとも言われており、主要事業に対応する抜け穴が企業の最大の潜在リスクとなる。来年は、上記の結果に基づいて、潜在的な隠れた危険が最も大きいいくつかのシステムが今年のガバナンスの対象となります。来年、この要件はさらに高くなる可能性があります。より多くのリソースがあれば、ガバナンスの第 2 段階に移行できます。終わり。これは、企業の主要な矛盾を独自の観点から分析することです。
もう一つの次元は水平比較であり、水平比較の論理は、同じ業界であれば、自分の会社のセキュリティ構築が優れていれば、自分を攻撃せずに他の友人を攻撃する可能性がある、というものです。例えば、同じ業界の皆さんはどうされていますか？アリの例を挙げると、アリ自身が金融属性とインターネット属性を持っているため、リーダーシップとセキュリティ能力の深さを継続的に確保する強力な能力を持っています。
もう一つの側面は、全体的なリスクを明確にすることです。それを明確にすることを前提として、リーダーはこれらの重要なリスクを管理しなければならないことを認識・判断し、リソースを投入することになります。リーダーがリスク管理の必要性を認識していないのであれば、少なくとも責任の所在を明確にすることは、安全保障にとって非常に重要な論理だと思います。会社が現在どれだけの潜在的なリスクを抱えているか、どれだけのリソースを投資する必要があるか、そしてそれをどの程度まで管理できるかをリーダーに説明する必要があります。ガバナンスがどの程度必要かについては、企業の判断に委ねられています。しかし、それが明確でない場合、従業員としての責任は比較的大きいです。
| インターネット企業の上司：前提として、まず資産のビジョンを構築することが必要です。資産は構築する必要がありますが、その後の脆弱性管理や制御は必ずしもリスクとは考えられず、事例の観点から見ると、実際に log4j を使用して攻撃を生成するなど、実際に脆弱性を悪用する事例は比較的少ないです。現時点では、脆弱性スキャンの依頼が時々ありますが、公平に見て、リスクはそれほど高くありません。
| ソフトウェアメーカーのお偉いさん：各企業の状況にもよりますが、美団は実際にこの分野に多額の投資を行っており、基本的なセキュリティは比較的良好です。したがって、この場所は在庫の世界的なリスクがあるかどうかを評価する必要があると思います。そうでない場合、重要なのは、新しいゼロデイまたは新しい脆弱性が発見されたときに、適切なガバナンスを確保するだけで十分であるということかもしれません。
| インターネット企業の上司: ビジョンを共有するために、内部に抜け穴が見つからなかった後、実際にはアップグレードが必要な自分で開発したコンポーネントが多数あることに気付きました。
| ソフトウェアメーカーのお偉いさん：インターネット会社が現在これを行っていることを知りました。彼らの場合は、ソース セキュリティ ゲートウェイになります。プライベート ソース カードのすべての内部セカンド パーティ コンポーネント、および社内で開発された共通コンポーネントはプライベート ソースのウェアハウスにアップロードする必要があり、すべてのセカンド パーティ コンポーネントをアップロードするときにセキュリティ上の問題がないことを確認する必要があります。
| インターネット企業の上司: 私のビジョンはセキュリティの観点からのものではありません。私が発見した問題点は、バージョンが低いため、サードパーティ コンポーネントの研究開発に問題が発生することです。低いバージョンは不安定で、一部の機能に互換性がないため、アップグレードする必要がありますが、それが非常に困難です。自分で押してください。実際、私たちは会社のコンポーネントが統合バージョン管理を実行できるように支援することができ、これはセキュリティ以外の利点となる可能性があります。
Q6: AI は、企業がそのサプライ チェーンにおけるセキュリティ脅威を予測し、防止するのにどのように役立ちますか?
| ソフトウェアメーカーのお偉いさん: AI と組み合わせた最近の探査のいくつかを共有させてください。私たちの考えを小規模に共有してください。AI と組み合わせることで、私たちは予測を行うのではなく、主にソフトウェア サプライ チェーンのセキュリティの問題を解決します。
1 つ目は、オープンソース コンポーネントの選択に関する作業です。ソフトウェア サプライ チェーンのセキュリティは、単純にセキュリティ問題として理解できないことがわかりました。たとえば、特定のコンポーネントを選択したり、特定のコンポーネントをアップグレードしたりする場合、セキュリティ問題の解決を考慮するだけでなく、このコンポーネントのスケーラビリティ、コミュニティ維持の健全性と成熟度、シナリオの適応（財務など）も考慮する必要があります。業界のシナリオは適応できるか? 取引支払いのシナリオは適応できるか?)。したがって、コンポーネントの選択に関しては、AI を使用してオープンソース コンポーネントの選択をインテリジェントに分析します。コンテンツを抽出して要約し、シナリオ（どのようなシナリオでの使用にどのようなオープンソース コンポーネントが適しているか）を分析します。
もう 1 つのポイントは、修復コードを生成するか、ソフトウェア アップグレードの互換性評価を行うことです。ソフトウェアをアップグレードするときは、アップグレード後に互換性の問題が発生するかどうかを誰もが考慮することがわかりました。このコンポーネントのさまざまなバージョン間の多数の相違点と、そのコンポーネントの問題およびリリース ノートの一部を分析する必要があります。この点で、私たちは AI の大規模モデルを要約および調整する機能を使用して、いくつかの探索を行います。
Q7: 依存関係の状況と脅威レベルを分析する
| ソフトウェアメーカーのお偉いさん: 前の ppt で述べたように、すべてのコード ウェアハウス内のすべてのソフトウェアのすべての依存関係を分析し、脆弱性の重大度を相関させ、脆弱性の影響分析とデータ統計を行うことができます。この点に関して私たちは 1 つのことを行いました。それは、CVE 脅威を改造し、脅威を 3 つのカテゴリ (強く推奨される修正、推奨される修正、およびオプションの修正) に分類することでした。POC、EXP があり、リスクレベルが高く深刻な脆弱性を分類し、それらを真に影響力のあるものとみなすことを強くお勧めします。脅威レベルの分析では、階層的な処理を実行してレポートを生成するために、単一の脆弱性によって影響を受ける資産の数やビジネスの重要性を関連付けることもできます。これは価値分析において非常に重要なポイントだと思います。
Q8: ソフトウェアサプライチェーンのセキュリティ構築の価値に対する開発者の認識を強化するにはどうすればよいですか
| ソフトウェアメーカーのお偉いさん: 企業がソフトウェアサプライチェーンのセキュリティ構築を行う場合、セキュリティの脆弱性を修正する開発者など、この作業への参加を開発者に大きく依存することが非常に重要であるため、開発者がセキュリティ構築の価値を認識する必要があると思います。このプロセスにおいて、私は 2 つの点が非常に重要であると考えています。
1つ目のポイントは、企業内の一部のイベントや事例を通じてでも、実際の事例を企業内で共有することで、より効果的な方法となります。例えば、log4j や fastjson の抜け穴が社内のセキュリティインシデントを引き起こしたり、Blue Army が攻防訓練を実施する際に攻撃と防御のシミュレーションを行った結果、コードが攻撃される可能性があることが判明し、企業のデータ漏洩が発生したりするなど、またはサービス侵入のリスク。
2つ目は、セキュリティリスクを管理した後は、セキュリティ上司に報告するだけでなく、社内に積極的に広報する必要があるということです。肯定的な宣伝により、開発者はセキュリティの本当の影響とリスクを理解できるようになります。たとえば、社内のケース共有は定期的に行われます。どの開発者とどの部門が開発プロセスに参加しているか、オープンソース コンポーネントの選択とアクセスを行う際、プロジェクトのセキュリティはすでに非常によく改善されています。どの事業部門が毎週および毎月、どのセキュリティ問題を解決したか、解決策の適時性、および解決策の効果がどれほどであるかまで。もう 1 つのアプローチは、リスク データや社内インタビューのベンチマーク ケースの公開など、構築の結果をこの作業に関与するすべての開発者に毎週または毎月共有し、トレーニングすることです。これにより、ソフトウェア サプライ チェーン全体のセキュリティ構築の価値に対する開発者の認識をより確立することもできます。
Q9: サプライチェーンのセキュリティガバナンスの効果を定量化して反映するにはどうすればよいですか?
| ソフトウェアメーカーのお偉いさん： 脆弱性処理の適時性、各脆弱性の平均修復回数、資産台帳に関連するリスク削減の数、突然のゼロデイ脆弱性またはサプライ チェーンの脆弱性の適時性など、いくつかの重要な指標があります。単一イベントの適時性、処理効率の向上など
部分的な主要産業の場合、プロセスシステムの完全性、業界のベストプラクティス、論文特許の優れたテーマの選択などはすべて、直接的および間接的に価値を説明できます。
ブレーンストーミング
| 物流会社の警備責任者: 私は古い伝統的な会社からインターネットベースの会社に転職しました。現在の主な問題は、SCA プロセスが確立された後、上司の中心的な考えがコストを削減して効率を向上させ、リソースを節約するために社内で実行しようとすることです。 。SCA を実行する場合、当社の研究開発チームは脆弱性の修復により協力的になりますが、より正確な修復方法が必要です。たとえば、高リスクの脆弱性や fastjson タイプの契約は修復する必要があります。弊社でも多くの製品を研究してきましたが、Murphysec製品は実際にコードを呼び出す機能を備えており、正確な修理の条件としても利用できます。
2 番目の問題は、リソースが少ない場合にどのように投資するかです。現在、プロセスが稼働しており、高リスクおよび中リスクの脆弱性は基本的に解決でき、研究開発とセキュリティの間に比較的良好な相互作用と規範が形成されています。しかし、上司がリソースを投資することに消極的である場合、セキュリティとしてどのように測定し、対応すべきでしょうか。たとえば、ビジネスがどのくらいの規模に成長したか、サプライチェーンのセキュリティをどのレベルで達成する必要があるか、より良い結果を達成するにはどのレベルの人員を投資する必要があるかなどです。業界では測定比率や基準がないようです。それで、どうやってそれを行うのか一緒に話し合いましょう？
| ソフトウェアメーカーのお偉いさん：この問題は美団の問題と少し似ている気がしますが、ある程度のガバナンスができてしまうと、その原動力がなくなってしまう可能性があるので、もっと投資したほうがいいのでしょうか？
まずレンガを投げておきますが、私は以前より効果的な方法をいくつか試したことがありますが、
最初のポイントは、同じ業界、同じ規模の企業を比較することです。たとえば、美団と百度、テンセントを比較して、同じ業界の何人の人がこの方向に投資し、どの程度まで投資しているか。例: アリの多くのバグは自動的に修復できますが、アリはすべての修復を必要とします。
2点目は、企業内部の現実のリスクの視点に立ち返り、攻撃と防御の観点からリスクを顕在化させることです。脆弱性を検出した後、実際に侵入する脆弱性をいくつか見つけたり、内部攻撃と防御のために重要な業務システムの重要な脆弱性を赤青対決と同様の方法で見つけて、どの程度のデータ漏洩が発生するかを実際にデモンストレーションして確認します。脆弱性が原因となります。
2008 年頃、Baidu はセキュリティにあまり注意を払っておらず、リソースもあまりありませんでした。当時、Jianxin が Baidu で最初にしたことは、中核となる内部システムを攻撃し、リスク状況を上司に報告することでした。これは、Baidu にとって非常に直感的です。リスクを見る重要な方法。
| 物流会社の警備責任者：確かにそのほうが合理的ですし、攻撃と防御の観点からも適用していますが、サプライチェーンのセキュリティには基本的に抜け穴はありません。同業界と比較すると、当社の投資は決して十分ではありません。
| オペレーターのセキュリティ上司: 付け加えておきますが、ソフトウェア サプライ チェーンの初期段階で、ソフトウェア サプライ チェーンのセキュリティに最も多くの投資をするようになった理由は、その段階全体に関係しています。まず、従来のアプローチは、保護とテストを継続することです。たとえば、Meituan の偉い人が提案した log4j など、企業内に標準外のアプリケーションが存在することは避けられず、私はこの側面の識別に投資してきましたが、100% 実現することはできません。次に、攻撃をシミュレートし、不足している部分を補うためにこの領域の検出を行うなどして、最終的に基準に達する必要があります。
この分野への投資は非常に高額であることがわかりました。log4j などの脆弱性が発生した場合、その原因を分析して攻撃者の観点からチェーンを悪用する場合、特にその時点で log4j の影響を受ける資産が 2,500 以上ある場合には、影響範囲を迅速に確認する方法がありません。 . ビジネスをすぐに修正して優先順位を付ける方法はありません。
そこで私たちが当時行ったのは、DNS と実行された特定のコードを含む攻撃チェーンとエクスプロイト チェーンを解体することであり、これには約 6 つのステップが必要でした。つまり、これら 6 つのステップで段階的に解体することになります。ネットワーク層では、コードの実行中に、他のリンクに層ごとに制限とカードを設定し、イントラネットにいくつかの機能を投資し、これらの逆転を防ぎます。外出先からの接続など。これらの操作を待ちます。インシデント対応の観点から見ると、この問題への投資コストは非常に高く、ビジネスへの影響は比較的大きくなります。当時は原爆レベルの脆弱性が多発し、企業自体がこのような拷問に耐えられず、事前に何か良い解決方法はないかと率先して相談してくれました。適切にビジネスに問題を解決してください。
このプロセス中に、調達からの非標準アプリケーションの制御や新製品発売のテストを含む 3 つの同期を含め、安全性を左にシフトすることにある程度のエネルギーを投資していることがわかりました。この一連のロジックに、サプライ チェーン セキュリティの検出機能と手段、または知識ベースの予備が追加されると、インシデント対応のコストは実際に大幅に削減され、効率が大幅に向上します。この観点から見ると、ROI 投資収益率は間違いなくプラスです。
| 銀行のセキュリティ責任者：サプライチェーンの構築が黒、白、グレー、SCAを含む一定の段階に達したら、次の構築の方向性は何ですか？皆さんにお聞きしたいのですが。さらに、構築ツールの脆弱性発見機能、脆弱性修復機能、脆弱性精度を継続的に最適化します。他の建設方向は何ですか?
いくつかアイデアがあるので、実現可能性を見てください。一方ではAIですが、AIは将来のセキュリティの価値を反映できると思います。2 番目の側面はアプリケーション セキュリティ データの監査で、今年はアプリケーション データ セキュリティ監査に関する構築をいくつか行いました。多くのトップ メーカーを調査した結果、誰もがトラフィック レイヤー製品に基づいており、トラフィックをミラーリングし、トラフィック内で API に関する機密データの送信がないかどうかをチェックしているという問題がありました。ただし、弊社側のデータ暗号化は比較的厳重であり、復号化する方法がなければ、この種の機器は無効となります。実際には、IAST は復号化されたトラフィックを非常に適切にサポートしていることがわかっていますが、これら 2 つの側面を組み合わせられるかどうかはわかりません。
3 番目の側面は、到達不可能な脆弱性の検証です。バグを修正していたとき、シーンは基本的に頭を叩きつけるようなものでした。一方では、業界のどの抜け穴が修復されたかによって決まりますが、他方では、その抜け穴が悪用できるかどうか、またその抜け穴が脅威であるかどうかによって決まります。そのため、到達不能な脆弱性の解析も今後の検討の方向性となりますので、他に良いアイデアがあれば参考にしていただければと思います。
| 海外進出企業のセキュリティ担当者：プロセスは確立しており、最近では下半期の目標を設定したところです。当社のビジネス シナリオはより複雑で、IoT、クラウド、APP、組み込みなど、さまざまな方向に構築できるさまざまなスマート ホーム ハードウェアなど、多くのものが含まれています。私たちの次の方向性は、過去に十分な対応ができなかったいくつかの企業を見つけ出し、脅威モデリングに焦点を当てることです。例えば、外部事業の中にはSDKなどを含むプラットフォームに開発者がアクセスする必要があるものもありますが、開発者の観点からSDKに問題がないかを確認します。クラウド プラットフォームと APP 組み込みハードウェア開発をドッキングするプロセスでは、いくつかの IDE プラグインを提供しますが、これらについてはこれまで十分に深く取り上げられていなかった可能性があるため、これについては後ほど取り上げます。
| インターネット企業のセキュリティ責任者：最近はAIを活用した構築もやっているんですが、例えばSDLをやっているとプロセスの推進やツールのQAの問題も出てきます。一般的な QA の質問、またはセキュリティ SDK などの修正案。カスタマーサービスに類する業務の一部をAIGCに移管いたします。