英国におけるHuaweiのセキュリティ問題は、セキュアコーディングの必要性を浮き彫りにしている。

初出：Information Age。本稿は、Wind River SystemsによるリアルタイムOS製品「VxWorks」の継続的なセキュリティサポートに関する記述を修正した更新版です。

英国のHuaweiサイバーセキュリティ評価センターによる最近の報告書で、Huaweiのソフトウェアエンジニアリングプロセスにおける重大なセキュリティ上の問題が指摘されました。この重要な報告書に関するニュースの多くは、前年から未解決のままの問題に焦点を当てていますが、より危険で見過ごされている問題は、Huaweiが採用しているセキュアコーディングのガイドラインや実践が明らかに欠如しているという点です。しかし、これは解決可能な問題です。

中国の通信大手Huaweiにとって、状況は悪化の一途をたどっています。米国が同社の将来的な政府関連業務への参画を全面的に禁止した一方で、英国はHuaweiのデバイスやコードに内在する欠陥の多くは修正可能であるという事実をより受け入れています。英国は2010年にHuaweiサイバーセキュリティ評価センター（HCSEC）を設立し、Huawei製品のセキュリティ問題を評価・対処し、年次報告書を作成してきました。しかし、今年の報告書は特に厳しい内容となっています。

ニュースで報じられた2019年のHCSEC報告書の焦点の多くは、前年からのセキュリティ欠陥がほとんど修正されていないという事実に関連しています。これには、まもなくサポート終了となるWind River社のリアルタイムOS「VxWorks」の旧バージョンを使用していることも含まれます。Huaweiはこの問題の修正を約束しており（Wind River Systemsから継続的なサポートを受ける予定です）、しかし、これは依然として英国の通信インフラの多くにおける中核コンポーネントとなっています。

主流メディアのほとんどが見過ごしていると思われる重要な要因は、同社の新しいソフトウェアやハードウェアの開発・展開プロセスに根本的な欠陥がある可能性が高いという点です。報告書は、Huaweiの社内エンジニアリング手法の扱いに「重大な技術的問題」があると指摘しています。

報告書で概説されている技術的問題の例をいくつか見てみましょう。Huaweiが行った最善の取り組みの一つは、エンジニアやプログラマーが新しいコードを実装する際に役立つセキュアコーディングガイドラインを作成したことです。これらのガイドラインは、信頼できるライブラリから安全であることがわかっているシステム関数やプロセスを使用し、既知の脆弱性を持つバリエーションは決して使用しないといった、幅広いベストプラクティスを網羅しています。理論上は素晴らしいことですが、英国のHuawei本番システムを実際に評価したところ、これらのガイドラインはプログラマーに伝達されていないか、無視されているか、あるいは単に強制されていないことが判明しました。

報告書は、公開されているアプリケーション内の特定のメモリ処理関数を調査しました。今回は、プログラムの機能としてユーザーが入力を行うメッセージボード群が対象です。ユーザー入力領域は決して「信頼できる」ものとして扱われるべきではないため、Huaweiの社内ガイドラインに従い、これらの領域にはセキュアなコードのみが含まれていることが期待されていました。具体的には、テスターは本番システム内でのmemcpy()、strcpy()、sprintf()といったメモリ処理関数の直接呼び出しを調査しました。これらは1988年以来、バッファオーバーフローのような深刻なセキュリティ問題を引き起こす可能性があることが知られています。

驚くべきことに、安全であることが知られているmemcpy()関数の直接呼び出しが5,000件あった一方で、安全ではないバリエーションの使用も600件ありました。他の関数についても同様の比率でした。strcpy()の安全な呼び出しは1,400件ありましたが、既知の脆弱性を持つ不適切な呼び出しも400件ありました。また、sprintf()の安全な使用は2,000件見つかりましたが、安全でない使用も200件ありました。これらの関数の使用のほとんどが安全であることは良いことですが、それでもコード全体の約20%が既知の攻撃に対して脆弱なままです。これは非常に大きな攻撃対象領域であり、しかもこれは3つのメモリ処理関数の直接呼び出しのみを考慮したもので、関数ポインタを介した間接的な使用例は含まれていません。監査人はこれらの特定の関数のみを調査しましたが、選択された3つのメモリ処理関数だけが問題を抱えているとは考えにくいでしょう。

Huaweiがプログラマー向けのベストプラクティスガイドを作成したことは評価できますが、さらなる対策が必要なのは明らかです。セキュリティへの期待を概説することは第一歩に過ぎず、ガイドラインが積極的に遵守され、開発チームに周知されて初めて効果を発揮します。Huaweiは、社内ガイドラインに従うための基本をなぞるだけでなく、プログラマーを効果的にトレーニングすることにコミットすることで、セキュリティを大幅に向上させることができます。彼らは、より安全にコーディングする方法を具体的に示すという一歩先へ進まなければなりません。コーダーは、優れた（安全な）コーディングパターンと悪い（安全でない）コーディングパターンについて十分なトレーニングを受け、会社が掲げる方針を毎回実践する責任を負う必要があります。

HCSEC報告書で概説されている具体的なコーディング問題の多くは、Secure Code Warriorプラットフォームの一部として対処・強制されています。このプラットフォームは、プログラマーやサイバーセキュリティチームが常にセキュアなコードを実装・維持できるようにトレーニングを行います。ユーザー入力を決して信頼しない、確立されたライブラリから常に機能を呼び出す、サーバーに渡す前にすべての入力をサニタイズする、といった多くの安全なコーディング手法がプラットフォーム内で常に実演されています。また、非常に具体的な脆弱性についても調査し、それらを回避・軽減する方法をステップバイステップで示しています。

熟練したトレーニングに加え、Huaweiのような企業はDevSecOpsソリューションを活用できます。これは、IDE内で直接リアルタイムのコーチングを追加するもので、企業のセキュリティガイドラインに合わせてカスタマイズされたセキュアコーディングレシピを利用し、開発者がコードを書く際に「キッチン」の副料理人のような役割を果たします。このようなアプローチは、Huaweiのあらゆるスキルレベルのプログラマーがより良いコードを書き、潜在的な脆弱性を認識するのに役立つと同時に、Huaweiのセキュリティ専門家がポリシーを遵守し、コマンドの実行を支援する「レシピ本」を作成することを可能にします。

A core lesson from Huawei's troubles should be that creating secure coding guidelines is meaningless if programmers don't know about them, or simply don't know how to follow good coding practices. In this case, the internal best practices guidelines turned out to be Huawei's own zhilaohu; what the West would call "a paper tiger'. It was a document with a lot of style, but no substance. To give it real teeth would require the right practical tools and an actual training program, one that takes a hands-on approach and builds continuous knowledge and skill.