すべてのソフトウェアの欠陥が同等というわけではありません。
それは言うまでもなく明らかです。何百万行ものソフトウェアコードが、プレッシャーの下で作業している何千人もの人間によって記述されているということを前提とすると、ソフトウェアコードには重大なものもそうでないものも含めてさまざまな種類の誤りがいくつもあるのは当然のことです。
この誤りには、機能、コンパイル、ランタイム、構文、および論理面でのエラーから、コマンドの欠落、通信の問題まで多岐にわたります。この誤りがアプリの誤作動やクラッシュにつながったり、攻撃に対する脆弱性をもたらしたりする可能性があります。
しかし、ここでは単に個々の欠陥の違いについて検討するのではありません。アプリの設計、またはソフトウェアで作成したその他の製品の設計で生じるまったく異なるクラスの欠陥もあるのです。このような欠陥は、自動化されたツールで検出され、数回のキーを叩くだけで修正できるようなコード行での単純な誤りではなく、機能構造における誤りです。
Black Duckでは、コーディングでの誤りを「バグ」と呼び、設計上の誤りを「欠陥」と呼んでいます。これらは標準的な業界用語ではありませんが効果的です。バグと欠陥は異なるリスクをもたらすため、設計上の欠陥は見逃されがちである一方で、バグには多くの注目が集まるためです。
欠陥とバグの比較例
この違いを物理的に表すのは、ワシントン州のピュージェット湾をまたぐ悪評で有名になったです。この橋は1940年に開通しましたが、同年の11月7日、時速40マイル（64キロ）の風で崩壊しました。エンジニアの話では、穏やかな風が「自励的で際限のない空力弾性フラッタ（風によっていつまでも橋が振動し続けること）」を生成したとのことです。
この崩壊は最悪の設計上の欠陥が原因で起きました。この橋の建設が仕様に正確に従って行われたとしても（実際にそうであったのでしょう）、設計に欠陥があったために崩壊する運命にありました。
Synopsysの主任科学者であるSammy Miguesは「コンクリートの一部を流し込み忘れたり、ボルトを1本忘れたりした場合はバグに相当する」と言います。「問題は、橋が必要な設計パラメータに合わせて建設されなかったことだ」と。
ソフトウェアの教訓：ネットワーク、システム、およびアプリケーションのセキュリティを確保するには、セキュリティの欠陥とバグの両方に対処することが非常に重要です。
『BSIMM（Building Security In Maturity Model）for the past decade』の共著者であるMiguesは「プログラムのソフトウェアのすべてがアプリケーションであるわけではない。そのため、アプリケーションのコードばかりを心配している場合は、おそらくソフトウェアの多くに注意を払っていないことになる。それは問題だ」と述べています。
実際、おおよその推定では、ソフトウェアセキュリティの欠陥の半数が設計上の欠陥です。ハッカーが望むようにその欠陥を無視すると、攻撃しやすいアタックサーフェスになります。
欠陥の修正がバグの修正よりも難しい理由
では、セキュリティの欠陥に向けられる注意がはるかに少ないのはなぜでしょうか。おそらく、欠陥の検出と修正を行うのがより難しく、時間と費用がかかるからでしょう。
コードに何千ものバグが含まれていても、自動化ツール（静的、動的、インタラクティブな解析、およびソフトウェア・コンポジション解析（SCA）によって、開発者は、作業中でもリアルタイムでバグを検出して修正することができます。
これは、バグの修正は比較的すばやく、簡単に、あまり費用をかけずに行うことができることを意味します。「エラーの発生時にそれを見逃して、アプリケーションがクラッシュした場合、コードの行を変更すれば、正しく機能する」とMiguesは言います。
それとは対照的に、欠陥は配列リファレンスにおける「1つ違い」のエラーや、間違ったシステム呼び出しよりもはるかにわかりにくい場合がほとんどです。
Miguesによると、「設計は2つのものの間のプロトコルであり、ファイルの構築方法、またはログの手法である可能性があります。」
「『このアプリケーションまたはこのマイクロサービスが任意のソースから任意の速度で任意数の要求を受け入れることが許可され、速度チェッカーもID管理やアクセス制御、アクセス管理もない』としたら、それは設計上の欠陥であり、単にコード行に誤りがあるのではない」のです。
あいにく、設計上の欠陥の検出はバグの検出よりも労力がかかり、かなりの専門知識を要します。組織が依然として十分にそれを行っていないのは、そのためです。
脅威モデリングによるセキュリティ上の欠陥の検出
Miguesによると、組織は設計の見直しにおいて段階的な進歩を遂げましたが、それは脅威モデリング（TM）という最も基本的なバージョンのみについて言えることです。アーキテクチャ・リスク分析（ARA）と呼ばれる「より深く掘り下げた」バージョンでは、そうは言えません。
Miguesによると、1～10段階評価では、TMは1～3の範囲、TMとARAの組み合わせは4～6、集約型ARAは7～10の範囲です。
さらに、「TMを開始した組織が多数あります。TMは『自分たちの知識に基づくと、この設計には何か問題があるか？』ということを意味します。それは概して、設計を破棄するものではありません。脅威モデラーのエクスペリエンスを利用して、何か欠落していないか、問題が起こるようなことが行われていないかなどを確認するのです」と続けています。
これには何らかの価値はあります。しかし、Miguesが言うように、脅威モデリングでは、小さな石や中サイズの石で窓を壊すことはできないと判断したが、大きな石なら壊すことができるかどうかを確認しないようなものです。
アーキテクチャ・リスク分析によるセキュリティの欠陥の検出
アーキテクチャ・リスク分析では、大きな石について知ることができますが、あまり行われていません。
基本的な脅威モデリングの域を超えて、「4～6の範囲になっても、費やす労力は次第に減少する。8以上となると、それは植込み型医療機器や自動運転車の構築などの特殊な作業向けである」とMiguesは言っています。
それは、深いレベルのセキュリティの欠陥を発見するには、深く掘り下げた設計の見直しが必要になるためです。Miguesによると、「植込み型医療機器またはTeslaに対するARAには2～9か月かかります」。
「ARAは、人の力に頼るプロセスです。CI/CDまたはDevOpsの黄色いれんがの道（幸福の道）をどれだけ進んでも、TMとARAには向きません。一部のデータを収集することや、プロセスのごく一部を自動化するために役立つことなどはありますが、スキルのある人材がいなければTMもできず、ARAは言うまでもありません。これは大手SME向けです。」
もちろん、それにはさらに多くの時間と費用がかかります。つまり、Miguesが言っているように、設計の見直しは依然として困難なのです。「機能速度」のプレッシャーを考えると、これは、設計上の欠陥の検出について言えば、「おそらく脅威モデリングの段階で足止めされている状態で、これを自動化に転換するテクノロジーがないため、この問題は以前も、今も存在している」ことを意味します。
しかし、それはお手上げだと諦めて、ソフトウェアセキュリティの脆弱性の半分を無視するという意味ではありません。個人、チーム、組織に役立つ手段があります。
個人
「OWASP Top 10リスト」など、使用しているプラットフォームのセキュリティの戒律から開始するとよいでしょう。これらは、HTTPS Cookie、入力のサニタイズ、脆弱なACLなど、開発者がセキュリティ確保を主導できる分野です。
さらに、IEEE Center for Secure Designによって発行された「Avoiding the Top 10 Software Security Design Flaws（回避すべきソフトウェア・セキュリティ設計の欠陥トップ10）」というホワイトペーパーがあります。その指示に従うと、設計に「セキュリティを組み込む」ことで、検出しなければならないセキュリティの欠陥はほとんどなくなります。その方法を以下にご紹介します。
- 信頼は勝ち取るものまたは与えるものであり、当然のものと見なすことはできません。
- 改ざん防止かつバイパス不可能な認証システムを使用してください。
- 承認は認証後に行います。
- データと制御命令を厳密に分離し、信頼されていないソースから受信した制御命令は処理しないでください。
- すべてのデータが明示的に検証されることを保証するアプローチを定義します。
- 暗号は正しく使用します。
- 機密データとその処理方法を特定します。
- 常にユーザーを考慮します。
- 外部コンポーネントを統合するとアタックサーフェスがどのように変わるかを理解します。
- オブジェクトおよびアクターへの今後の変更の考慮は、柔軟に行います。
チームと組織
Miguesはチームについて次のように語っています。チームは「大きな変更に取り組む際、それぞれの体験を持ち寄って、脅威モデリングを行うことができます。新しいAPIの追加や、モノリシックアプリケーションのマイクロサービスへの分割など、特にアタックサーフェスを変更する際にそれが言えます」。
最後に、組織は、「基本」アプリケーションのストックを構築し、それに対して集中的なARAを行い、他のアプリケーションの構築のフレームワークとして使用することを開発者に要求することで、独自の努力を進めることができます。
「そうすることで、すべてJavaで構築されている100個のアプリケーションの脅威モデリングやARAを行わずに済みます」とMiguesは語っています。「同じフレームワーク、同じセキュリティ・バイ・デザインのライブラリ、同じ出力プロトコル、同じ入力検証を使用します。基礎アプリケーションにはレイヤ1～5が含まれているので、開発者が処理する必要があるのはレイヤ6と7だけです。」
「これが負荷を削減するための1つの方法です。」
Continue Reading
AI を活用したPolaris Assistでアプリケーションコードの修正を高速化
May 08, 2024 / 1 min read
