ファーウェイのセキュリティUKの問題は安全なコーディングの必要性を示している
最初に公開されました 情報化時代。これは、Wind River Systemsのリアルタイムオペレーティングシステム製品であるVxWorksの継続的なセキュリティサポートに関する位置付けを修正した更新版です。
英国のファーウェイサイバーセキュリティ評価センターからの最近の報告では、ファーウェイのソフトウェアエンジニアリングプロセスにおける主要なセキュリティ問題が特定されました。この重要なレポートに関するニュースの多くは、前年の未解決の問題に焦点を当てていますが、より危険で見過ごされがちな問題は、ファーウェイが採用しているセキュアコーディングのガイドラインと慣行が明らかに欠如していることです。しかし、これは解決できる問題です。
中国の通信大手Huaweiにとってのニュースは悪化の一途をたどっています。米国はファーウェイの今後の政府業務を全面的に禁止しているが、英国はファーウェイのデバイスとコードの根本的な欠陥の多くは修正可能であるという事実をより受け入れている。英国は、ファーウェイ製品のセキュリティ問題を評価して対処し、製造するために、2010年にファーウェイサイバーセキュリティ評価センター（HCSEC）を設立しました。 年次報告書 彼らについて。しかし、今年の報告は特に酷かった。
ニュースで取り上げられた 2019 HCSEC レポートの焦点の多くは、前年のセキュリティ上の欠陥がほとんど解決されていないという事実に関係しています。これには、Wind Riverの古いバージョンのVxWorksリアルタイムオペレーティングシステムの使用も含まれていますが、間もなくサポートが終了します。ファーウェイはこの問題を解決することを約束していますが (Wind River Systemsからの継続的なサポートも受けられます)、英国の通信インフラの多くで中核となるコンポーネントであることに変わりはありません。
主流の報道機関のほとんどが見落としていると思われる重要な要素は、会社の新しいソフトウェアとハードウェアの開発と展開において存在する、根本的に壊れたプロセスである可能性があるということです。このレポートでは、ファーウェイが社内のエンジニアリング手法を処理する方法に関する「重大な技術的問題」が指摘されています。
レポートで概説されている技術的な問題の例をいくつか見てみましょう。ファーウェイが行った最も良いことの1つは、エンジニアやプログラマーが新しいコードを導入するのに役立つ安全なコーディングガイドラインを作成したことだと言わざるを得ません。これらのガイドラインは、信頼できるライブラリから提供される既知の安全なバージョンのシステム機能やプロセスの使用など、幅広いベストプラクティスを網羅していますが、既知の脆弱性を持つバリアントは対象外です。これは理論的には素晴らしいことですが、英国のファーウェイの生産システムを実際に評価したところ、これらのガイドラインはプログラマーに伝えられなかったか、無視されたか、あるいは単に実施されなかったかのどちらかであることがわかりました。
このレポートでは、一般向けアプリケーション内の特定のメモリ処理機能（この場合は、プログラムの機能としてユーザーが入力を追加するように促すメッセージボードのセット）を調べました。ユーザー入力エリアは決して「信頼できる」ものとして扱われるべきではないことを考えると、ファーウェイの内部ガイドラインによると、これらのエリアには安全なコードのみが含まれることが予想されていました。具体的には、テスターは、これらのプロダクションシステム内でメモリ処理関数 memcpy ()、strcpy ()、sprintf () を直接呼び出す方法を調べました。これらの関数は、それ以降、バッファオーバーフローなどの深刻なセキュリティ問題を引き起こす可能性があることが知られています。 1988 。
驚いたことに、17 個の既知の安全な memcpy () 関数が 5,000 回直接呼び出されただけでなく、12 個の安全でないバリアントが 600 回も使用されていました。他の関数とほぼ同じ比率でした。安全な strcpy () 呼び出しは 1,400 回ありましたが、既知の脆弱性を持つ不正な呼び出しも 400 回ありました。また、sprintf () の安全な使用法が 200 回見つかったのに対し、安全でない使用法は 200 回見つかりました。これらの関数のほとんどの使用が安全だったのは良いことですが、それでもコード全体の約 20% が既知の攻撃に対して脆弱なままになっています。これは脅威サーフェスの攻撃対象領域としては非常に大きく、3 つのメモリ処理関数の直接呼び出しのみが考慮され、関数ポインタによる間接的な使用は考慮されません。監査担当者が調べたのはこれらの特定の機能のみでしたが、問題があるのは選ばれた 3 つのメモリ処理関数だけであるとは考えにくいです。
ファーウェイがプログラマー向けのベストプラクティスガイドを作成したことは良いことですが、まだやるべきことが残っていることは明らかです。これはセキュリティへの期待を概説するための1つのステップですが、そのガイドラインが積極的に守られ、開発コホートに親しまれている場合にのみ効果があります。ファーウェイは、ファーウェイの社内ガイドラインに従う方法の基本をざっと見ておくだけでなく、プログラマーを効果的にトレーニングすることを約束することで、セキュリティの向上において大きな進歩を遂げることができるでしょう。彼らはさらに一歩踏み込んで、より安全にコーディングする方法全般を実証しなければなりません。コーダーは、良い (安全な) コーディングパターンと悪い (安全でない) コーディングパターンについて十分なトレーニングを受け、会社が説いていることを毎回実践する責任を与えられる必要があります。
HCSECレポートで概説されている特定のコーディング問題の多くは、その一環として対処され、実施されています。 セキュア・コード・ウォリアー プラットフォーム。プログラマーとサイバーセキュリティチームが常に安全なコードをデプロイして維持できるようにトレーニングします。ユーザーの入力を決して信用しない、常に確立されたライブラリから関数を引き出す、すべての入力をサーバーに渡す前にサニタイズする、その他多くの安全なコーディング手法がプラットフォーム内で常に実証されています。また、非常に具体的な脆弱性にも注目し、それらを回避および軽減する方法を段階的に示します。
熟練したトレーニングに加えて、ファーウェイのような企業はDevSecOpsソリューションを利用することができます。企業のセキュリティガイドラインに合わせてカスタマイズされた安全なコーディングレシピを活用したリアルタイムのコーチングをIDEに直接追加し、開発者がコードを書くときにコーディングの「キッチン」で開発者のスーシェフとしての役割を果たします。このようなアプローチは、あらゆるスキルレベルのファーウェイのプログラマーがより優れたコードを書き、潜在的な脆弱性を認識するのに役立つと同時に、ファーウェイのセキュリティ専門家がポリシーに従い、コマンドの実行に役立つレシピの「クックブック」を作成できるようにもなります。
ファーウェイの問題から得られる主な教訓は、プログラマーが安全なコーディングガイドラインについて知らなければ、あるいは単に優れたコーディング慣行に従う方法を知らなければ、意味がないということです。今回のケースでは、社内のベスト・プラクティス・ガイドラインがファーウェイ独自のzhilaohu（西側では「ジラオウ」と呼ばれる）であることが判明しました。ペーパータイガー'。スタイルはたっぷりあるが、内容は全くない文書だった。本物らしさを生かすには、適切な実践的なツールと、実践的なアプローチをとり、継続的な知識とスキルを身につける実際のトレーニングプログラムが必要でした。
英国のファーウェイサイバーセキュリティ評価センターからの最近の報告では、ファーウェイのソフトウェアエンジニアリングプロセスにおける主要なセキュリティ問題が特定されました。しかし、これは解決できる問題です。
最高経営責任者（CEO）、会長、および共同設立者
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
最高経営責任者（CEO）、会長、および共同設立者
Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ（Business Insider）、Cyber Security Professional of the Yearを受賞（AISA - Australian Information Security Association）、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。
最初に公開されました 情報化時代。これは、Wind River Systemsのリアルタイムオペレーティングシステム製品であるVxWorksの継続的なセキュリティサポートに関する位置付けを修正した更新版です。
英国のファーウェイサイバーセキュリティ評価センターからの最近の報告では、ファーウェイのソフトウェアエンジニアリングプロセスにおける主要なセキュリティ問題が特定されました。この重要なレポートに関するニュースの多くは、前年の未解決の問題に焦点を当てていますが、より危険で見過ごされがちな問題は、ファーウェイが採用しているセキュアコーディングのガイドラインと慣行が明らかに欠如していることです。しかし、これは解決できる問題です。
中国の通信大手Huaweiにとってのニュースは悪化の一途をたどっています。米国はファーウェイの今後の政府業務を全面的に禁止しているが、英国はファーウェイのデバイスとコードの根本的な欠陥の多くは修正可能であるという事実をより受け入れている。英国は、ファーウェイ製品のセキュリティ問題を評価して対処し、製造するために、2010年にファーウェイサイバーセキュリティ評価センター（HCSEC）を設立しました。 年次報告書 彼らについて。しかし、今年の報告は特に酷かった。
ニュースで取り上げられた 2019 HCSEC レポートの焦点の多くは、前年のセキュリティ上の欠陥がほとんど解決されていないという事実に関係しています。これには、Wind Riverの古いバージョンのVxWorksリアルタイムオペレーティングシステムの使用も含まれていますが、間もなくサポートが終了します。ファーウェイはこの問題を解決することを約束していますが (Wind River Systemsからの継続的なサポートも受けられます)、英国の通信インフラの多くで中核となるコンポーネントであることに変わりはありません。
主流の報道機関のほとんどが見落としていると思われる重要な要素は、会社の新しいソフトウェアとハードウェアの開発と展開において存在する、根本的に壊れたプロセスである可能性があるということです。このレポートでは、ファーウェイが社内のエンジニアリング手法を処理する方法に関する「重大な技術的問題」が指摘されています。
レポートで概説されている技術的な問題の例をいくつか見てみましょう。ファーウェイが行った最も良いことの1つは、エンジニアやプログラマーが新しいコードを導入するのに役立つ安全なコーディングガイドラインを作成したことだと言わざるを得ません。これらのガイドラインは、信頼できるライブラリから提供される既知の安全なバージョンのシステム機能やプロセスの使用など、幅広いベストプラクティスを網羅していますが、既知の脆弱性を持つバリアントは対象外です。これは理論的には素晴らしいことですが、英国のファーウェイの生産システムを実際に評価したところ、これらのガイドラインはプログラマーに伝えられなかったか、無視されたか、あるいは単に実施されなかったかのどちらかであることがわかりました。
このレポートでは、一般向けアプリケーション内の特定のメモリ処理機能（この場合は、プログラムの機能としてユーザーが入力を追加するように促すメッセージボードのセット）を調べました。ユーザー入力エリアは決して「信頼できる」ものとして扱われるべきではないことを考えると、ファーウェイの内部ガイドラインによると、これらのエリアには安全なコードのみが含まれることが予想されていました。具体的には、テスターは、これらのプロダクションシステム内でメモリ処理関数 memcpy ()、strcpy ()、sprintf () を直接呼び出す方法を調べました。これらの関数は、それ以降、バッファオーバーフローなどの深刻なセキュリティ問題を引き起こす可能性があることが知られています。 1988 。
驚いたことに、17 個の既知の安全な memcpy () 関数が 5,000 回直接呼び出されただけでなく、12 個の安全でないバリアントが 600 回も使用されていました。他の関数とほぼ同じ比率でした。安全な strcpy () 呼び出しは 1,400 回ありましたが、既知の脆弱性を持つ不正な呼び出しも 400 回ありました。また、sprintf () の安全な使用法が 200 回見つかったのに対し、安全でない使用法は 200 回見つかりました。これらの関数のほとんどの使用が安全だったのは良いことですが、それでもコード全体の約 20% が既知の攻撃に対して脆弱なままになっています。これは脅威サーフェスの攻撃対象領域としては非常に大きく、3 つのメモリ処理関数の直接呼び出しのみが考慮され、関数ポインタによる間接的な使用は考慮されません。監査担当者が調べたのはこれらの特定の機能のみでしたが、問題があるのは選ばれた 3 つのメモリ処理関数だけであるとは考えにくいです。
ファーウェイがプログラマー向けのベストプラクティスガイドを作成したことは良いことですが、まだやるべきことが残っていることは明らかです。これはセキュリティへの期待を概説するための1つのステップですが、そのガイドラインが積極的に守られ、開発コホートに親しまれている場合にのみ効果があります。ファーウェイは、ファーウェイの社内ガイドラインに従う方法の基本をざっと見ておくだけでなく、プログラマーを効果的にトレーニングすることを約束することで、セキュリティの向上において大きな進歩を遂げることができるでしょう。彼らはさらに一歩踏み込んで、より安全にコーディングする方法全般を実証しなければなりません。コーダーは、良い (安全な) コーディングパターンと悪い (安全でない) コーディングパターンについて十分なトレーニングを受け、会社が説いていることを毎回実践する責任を与えられる必要があります。
HCSECレポートで概説されている特定のコーディング問題の多くは、その一環として対処され、実施されています。 セキュア・コード・ウォリアー プラットフォーム。プログラマーとサイバーセキュリティチームが常に安全なコードをデプロイして維持できるようにトレーニングします。ユーザーの入力を決して信用しない、常に確立されたライブラリから関数を引き出す、すべての入力をサーバーに渡す前にサニタイズする、その他多くの安全なコーディング手法がプラットフォーム内で常に実証されています。また、非常に具体的な脆弱性にも注目し、それらを回避および軽減する方法を段階的に示します。
熟練したトレーニングに加えて、ファーウェイのような企業はDevSecOpsソリューションを利用することができます。企業のセキュリティガイドラインに合わせてカスタマイズされた安全なコーディングレシピを活用したリアルタイムのコーチングをIDEに直接追加し、開発者がコードを書くときにコーディングの「キッチン」で開発者のスーシェフとしての役割を果たします。このようなアプローチは、あらゆるスキルレベルのファーウェイのプログラマーがより優れたコードを書き、潜在的な脆弱性を認識するのに役立つと同時に、ファーウェイのセキュリティ専門家がポリシーに従い、コマンドの実行に役立つレシピの「クックブック」を作成できるようにもなります。
ファーウェイの問題から得られる主な教訓は、プログラマーが安全なコーディングガイドラインについて知らなければ、あるいは単に優れたコーディング慣行に従う方法を知らなければ、意味がないということです。今回のケースでは、社内のベスト・プラクティス・ガイドラインがファーウェイ独自のzhilaohu（西側では「ジラオウ」と呼ばれる）であることが判明しました。ペーパータイガー'。スタイルはたっぷりあるが、内容は全くない文書だった。本物らしさを生かすには、適切な実践的なツールと、実践的なアプローチをとり、継続的な知識とスキルを身につける実際のトレーニングプログラムが必要でした。
最初に公開されました 情報化時代。これは、Wind River Systemsのリアルタイムオペレーティングシステム製品であるVxWorksの継続的なセキュリティサポートに関する位置付けを修正した更新版です。
英国のファーウェイサイバーセキュリティ評価センターからの最近の報告では、ファーウェイのソフトウェアエンジニアリングプロセスにおける主要なセキュリティ問題が特定されました。この重要なレポートに関するニュースの多くは、前年の未解決の問題に焦点を当てていますが、より危険で見過ごされがちな問題は、ファーウェイが採用しているセキュアコーディングのガイドラインと慣行が明らかに欠如していることです。しかし、これは解決できる問題です。
中国の通信大手Huaweiにとってのニュースは悪化の一途をたどっています。米国はファーウェイの今後の政府業務を全面的に禁止しているが、英国はファーウェイのデバイスとコードの根本的な欠陥の多くは修正可能であるという事実をより受け入れている。英国は、ファーウェイ製品のセキュリティ問題を評価して対処し、製造するために、2010年にファーウェイサイバーセキュリティ評価センター（HCSEC）を設立しました。 年次報告書 彼らについて。しかし、今年の報告は特に酷かった。
ニュースで取り上げられた 2019 HCSEC レポートの焦点の多くは、前年のセキュリティ上の欠陥がほとんど解決されていないという事実に関係しています。これには、Wind Riverの古いバージョンのVxWorksリアルタイムオペレーティングシステムの使用も含まれていますが、間もなくサポートが終了します。ファーウェイはこの問題を解決することを約束していますが (Wind River Systemsからの継続的なサポートも受けられます)、英国の通信インフラの多くで中核となるコンポーネントであることに変わりはありません。
主流の報道機関のほとんどが見落としていると思われる重要な要素は、会社の新しいソフトウェアとハードウェアの開発と展開において存在する、根本的に壊れたプロセスである可能性があるということです。このレポートでは、ファーウェイが社内のエンジニアリング手法を処理する方法に関する「重大な技術的問題」が指摘されています。
レポートで概説されている技術的な問題の例をいくつか見てみましょう。ファーウェイが行った最も良いことの1つは、エンジニアやプログラマーが新しいコードを導入するのに役立つ安全なコーディングガイドラインを作成したことだと言わざるを得ません。これらのガイドラインは、信頼できるライブラリから提供される既知の安全なバージョンのシステム機能やプロセスの使用など、幅広いベストプラクティスを網羅していますが、既知の脆弱性を持つバリアントは対象外です。これは理論的には素晴らしいことですが、英国のファーウェイの生産システムを実際に評価したところ、これらのガイドラインはプログラマーに伝えられなかったか、無視されたか、あるいは単に実施されなかったかのどちらかであることがわかりました。
このレポートでは、一般向けアプリケーション内の特定のメモリ処理機能（この場合は、プログラムの機能としてユーザーが入力を追加するように促すメッセージボードのセット）を調べました。ユーザー入力エリアは決して「信頼できる」ものとして扱われるべきではないことを考えると、ファーウェイの内部ガイドラインによると、これらのエリアには安全なコードのみが含まれることが予想されていました。具体的には、テスターは、これらのプロダクションシステム内でメモリ処理関数 memcpy ()、strcpy ()、sprintf () を直接呼び出す方法を調べました。これらの関数は、それ以降、バッファオーバーフローなどの深刻なセキュリティ問題を引き起こす可能性があることが知られています。 1988 。
驚いたことに、17 個の既知の安全な memcpy () 関数が 5,000 回直接呼び出されただけでなく、12 個の安全でないバリアントが 600 回も使用されていました。他の関数とほぼ同じ比率でした。安全な strcpy () 呼び出しは 1,400 回ありましたが、既知の脆弱性を持つ不正な呼び出しも 400 回ありました。また、sprintf () の安全な使用法が 200 回見つかったのに対し、安全でない使用法は 200 回見つかりました。これらの関数のほとんどの使用が安全だったのは良いことですが、それでもコード全体の約 20% が既知の攻撃に対して脆弱なままになっています。これは脅威サーフェスの攻撃対象領域としては非常に大きく、3 つのメモリ処理関数の直接呼び出しのみが考慮され、関数ポインタによる間接的な使用は考慮されません。監査担当者が調べたのはこれらの特定の機能のみでしたが、問題があるのは選ばれた 3 つのメモリ処理関数だけであるとは考えにくいです。
ファーウェイがプログラマー向けのベストプラクティスガイドを作成したことは良いことですが、まだやるべきことが残っていることは明らかです。これはセキュリティへの期待を概説するための1つのステップですが、そのガイドラインが積極的に守られ、開発コホートに親しまれている場合にのみ効果があります。ファーウェイは、ファーウェイの社内ガイドラインに従う方法の基本をざっと見ておくだけでなく、プログラマーを効果的にトレーニングすることを約束することで、セキュリティの向上において大きな進歩を遂げることができるでしょう。彼らはさらに一歩踏み込んで、より安全にコーディングする方法全般を実証しなければなりません。コーダーは、良い (安全な) コーディングパターンと悪い (安全でない) コーディングパターンについて十分なトレーニングを受け、会社が説いていることを毎回実践する責任を与えられる必要があります。
HCSECレポートで概説されている特定のコーディング問題の多くは、その一環として対処され、実施されています。 セキュア・コード・ウォリアー プラットフォーム。プログラマーとサイバーセキュリティチームが常に安全なコードをデプロイして維持できるようにトレーニングします。ユーザーの入力を決して信用しない、常に確立されたライブラリから関数を引き出す、すべての入力をサーバーに渡す前にサニタイズする、その他多くの安全なコーディング手法がプラットフォーム内で常に実証されています。また、非常に具体的な脆弱性にも注目し、それらを回避および軽減する方法を段階的に示します。
熟練したトレーニングに加えて、ファーウェイのような企業はDevSecOpsソリューションを利用することができます。企業のセキュリティガイドラインに合わせてカスタマイズされた安全なコーディングレシピを活用したリアルタイムのコーチングをIDEに直接追加し、開発者がコードを書くときにコーディングの「キッチン」で開発者のスーシェフとしての役割を果たします。このようなアプローチは、あらゆるスキルレベルのファーウェイのプログラマーがより優れたコードを書き、潜在的な脆弱性を認識するのに役立つと同時に、ファーウェイのセキュリティ専門家がポリシーに従い、コマンドの実行に役立つレシピの「クックブック」を作成できるようにもなります。
ファーウェイの問題から得られる主な教訓は、プログラマーが安全なコーディングガイドラインについて知らなければ、あるいは単に優れたコーディング慣行に従う方法を知らなければ、意味がないということです。今回のケースでは、社内のベスト・プラクティス・ガイドラインがファーウェイ独自のzhilaohu（西側では「ジラオウ」と呼ばれる）であることが判明しました。ペーパータイガー'。スタイルはたっぷりあるが、内容は全くない文書だった。本物らしさを生かすには、適切な実践的なツールと、実践的なアプローチをとり、継続的な知識とスキルを身につける実際のトレーニングプログラムが必要でした。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
最高経営責任者（CEO）、会長、および共同設立者
Pieter Danhieuxは、セキュリティコンサルタントとして12年以上の経験を持ち、SANSの主席講師として8年間、組織、システム、個人をターゲットにしてセキュリティの弱点を評価する方法に関する攻撃的なテクニックを教えている、世界的に有名なセキュリティエキスパートです。2016年には、オーストラリアで最もクールな技術者の一人として認められ（Business Insider）、Cyber Security Professional of the Yearを受賞（AISA - Australian Information Security Association）、GSE、CISSP、GCIH、GCFA、GSEC、GPEN、GWAPT、GCIA認定を保有している。
最初に公開されました 情報化時代。これは、Wind River Systemsのリアルタイムオペレーティングシステム製品であるVxWorksの継続的なセキュリティサポートに関する位置付けを修正した更新版です。
英国のファーウェイサイバーセキュリティ評価センターからの最近の報告では、ファーウェイのソフトウェアエンジニアリングプロセスにおける主要なセキュリティ問題が特定されました。この重要なレポートに関するニュースの多くは、前年の未解決の問題に焦点を当てていますが、より危険で見過ごされがちな問題は、ファーウェイが採用しているセキュアコーディングのガイドラインと慣行が明らかに欠如していることです。しかし、これは解決できる問題です。
中国の通信大手Huaweiにとってのニュースは悪化の一途をたどっています。米国はファーウェイの今後の政府業務を全面的に禁止しているが、英国はファーウェイのデバイスとコードの根本的な欠陥の多くは修正可能であるという事実をより受け入れている。英国は、ファーウェイ製品のセキュリティ問題を評価して対処し、製造するために、2010年にファーウェイサイバーセキュリティ評価センター（HCSEC）を設立しました。 年次報告書 彼らについて。しかし、今年の報告は特に酷かった。
ニュースで取り上げられた 2019 HCSEC レポートの焦点の多くは、前年のセキュリティ上の欠陥がほとんど解決されていないという事実に関係しています。これには、Wind Riverの古いバージョンのVxWorksリアルタイムオペレーティングシステムの使用も含まれていますが、間もなくサポートが終了します。ファーウェイはこの問題を解決することを約束していますが (Wind River Systemsからの継続的なサポートも受けられます)、英国の通信インフラの多くで中核となるコンポーネントであることに変わりはありません。
主流の報道機関のほとんどが見落としていると思われる重要な要素は、会社の新しいソフトウェアとハードウェアの開発と展開において存在する、根本的に壊れたプロセスである可能性があるということです。このレポートでは、ファーウェイが社内のエンジニアリング手法を処理する方法に関する「重大な技術的問題」が指摘されています。
レポートで概説されている技術的な問題の例をいくつか見てみましょう。ファーウェイが行った最も良いことの1つは、エンジニアやプログラマーが新しいコードを導入するのに役立つ安全なコーディングガイドラインを作成したことだと言わざるを得ません。これらのガイドラインは、信頼できるライブラリから提供される既知の安全なバージョンのシステム機能やプロセスの使用など、幅広いベストプラクティスを網羅していますが、既知の脆弱性を持つバリアントは対象外です。これは理論的には素晴らしいことですが、英国のファーウェイの生産システムを実際に評価したところ、これらのガイドラインはプログラマーに伝えられなかったか、無視されたか、あるいは単に実施されなかったかのどちらかであることがわかりました。
このレポートでは、一般向けアプリケーション内の特定のメモリ処理機能（この場合は、プログラムの機能としてユーザーが入力を追加するように促すメッセージボードのセット）を調べました。ユーザー入力エリアは決して「信頼できる」ものとして扱われるべきではないことを考えると、ファーウェイの内部ガイドラインによると、これらのエリアには安全なコードのみが含まれることが予想されていました。具体的には、テスターは、これらのプロダクションシステム内でメモリ処理関数 memcpy ()、strcpy ()、sprintf () を直接呼び出す方法を調べました。これらの関数は、それ以降、バッファオーバーフローなどの深刻なセキュリティ問題を引き起こす可能性があることが知られています。 1988 。
驚いたことに、17 個の既知の安全な memcpy () 関数が 5,000 回直接呼び出されただけでなく、12 個の安全でないバリアントが 600 回も使用されていました。他の関数とほぼ同じ比率でした。安全な strcpy () 呼び出しは 1,400 回ありましたが、既知の脆弱性を持つ不正な呼び出しも 400 回ありました。また、sprintf () の安全な使用法が 200 回見つかったのに対し、安全でない使用法は 200 回見つかりました。これらの関数のほとんどの使用が安全だったのは良いことですが、それでもコード全体の約 20% が既知の攻撃に対して脆弱なままになっています。これは脅威サーフェスの攻撃対象領域としては非常に大きく、3 つのメモリ処理関数の直接呼び出しのみが考慮され、関数ポインタによる間接的な使用は考慮されません。監査担当者が調べたのはこれらの特定の機能のみでしたが、問題があるのは選ばれた 3 つのメモリ処理関数だけであるとは考えにくいです。
ファーウェイがプログラマー向けのベストプラクティスガイドを作成したことは良いことですが、まだやるべきことが残っていることは明らかです。これはセキュリティへの期待を概説するための1つのステップですが、そのガイドラインが積極的に守られ、開発コホートに親しまれている場合にのみ効果があります。ファーウェイは、ファーウェイの社内ガイドラインに従う方法の基本をざっと見ておくだけでなく、プログラマーを効果的にトレーニングすることを約束することで、セキュリティの向上において大きな進歩を遂げることができるでしょう。彼らはさらに一歩踏み込んで、より安全にコーディングする方法全般を実証しなければなりません。コーダーは、良い (安全な) コーディングパターンと悪い (安全でない) コーディングパターンについて十分なトレーニングを受け、会社が説いていることを毎回実践する責任を与えられる必要があります。
HCSECレポートで概説されている特定のコーディング問題の多くは、その一環として対処され、実施されています。 セキュア・コード・ウォリアー プラットフォーム。プログラマーとサイバーセキュリティチームが常に安全なコードをデプロイして維持できるようにトレーニングします。ユーザーの入力を決して信用しない、常に確立されたライブラリから関数を引き出す、すべての入力をサーバーに渡す前にサニタイズする、その他多くの安全なコーディング手法がプラットフォーム内で常に実証されています。また、非常に具体的な脆弱性にも注目し、それらを回避および軽減する方法を段階的に示します。
熟練したトレーニングに加えて、ファーウェイのような企業はDevSecOpsソリューションを利用することができます。企業のセキュリティガイドラインに合わせてカスタマイズされた安全なコーディングレシピを活用したリアルタイムのコーチングをIDEに直接追加し、開発者がコードを書くときにコーディングの「キッチン」で開発者のスーシェフとしての役割を果たします。このようなアプローチは、あらゆるスキルレベルのファーウェイのプログラマーがより優れたコードを書き、潜在的な脆弱性を認識するのに役立つと同時に、ファーウェイのセキュリティ専門家がポリシーに従い、コマンドの実行に役立つレシピの「クックブック」を作成できるようにもなります。
ファーウェイの問題から得られる主な教訓は、プログラマーが安全なコーディングガイドラインについて知らなければ、あるいは単に優れたコーディング慣行に従う方法を知らなければ、意味がないということです。今回のケースでは、社内のベスト・プラクティス・ガイドラインがファーウェイ独自のzhilaohu（西側では「ジラオウ」と呼ばれる）であることが判明しました。ペーパータイガー'。スタイルはたっぷりあるが、内容は全くない文書だった。本物らしさを生かすには、適切な実践的なツールと、実践的なアプローチをとり、継続的な知識とスキルを身につける実際のトレーニングプログラムが必要でした。
%20(1).avif)
.avif)
