SEI CERTセキュアコーディングスタンダードは、特に組込みやセーフティクリティカルなアプリケーションでコードを保護するための優れた選択肢です。この記事では、静的解析を使用してCERT Cスタンダードを適用し、セキュリティ・バイ・デザインを実現する方法について説明します。
「ソフトウェアを保護するという考えは重要だが、当然ながら、欠陥のないものを保護するほうが、脆弱性だらけのものを保護するよりも簡単だ」
– Gary McGraw, Cigital
組込みソフトウェアとIoTデバイスの普及は、日々セキュリティ攻撃のリスクを増加させています。私のIoT hall-of-shame（「IoT不名誉の殿堂」）では、水処理施設から自動車、子供のおもちゃまで、あらゆるものに対する絶え間ない攻撃の例が見られます。Thing（モノ）により多くのコードが搭載され、インターネットに接続されることは、新しい機能と機能性を約束しますが、悪意のある行為者がシステムや私たちの日常生活にまで侵入する可能性も高まります。
IoTと組込みセキュリティの問題
研究によると、自動車にも1億行を超えるコードが搭載される場合があるといいます。数人の開発者が目視でコードをレビューできる時代は終わりました。そのような大規模で複雑なシステムでは、ソフトウェアセキュリティについて真剣に考え始めなければなりません。幸いにも（同じ戦略で問題に対処できるという意味で）、セキュアなソフトウェアに関するコーディングの問題は、多くの場合、安全で信頼性の高いソフトウェアに関する問題と同じです。
多くの安全規格（ISO 26262、DO-178B/C、FDAなど）は、コーディングスタンダードと静的コード解析を使用することにより、ソフトウェアの安全性と信頼性を大幅に強化できることを示しています。静的解析は、コードを一貫して強化し、「テストによるセキュリティ」から「セキュア・バイ・デザイン」という考え方に移行するための最良の方法です。つまり、サイバーセキュリティを別のチーム任せにすることはできません。計画とコーディングを開始すると同時にセキュリティに対処しなければなりません。コーディング標準は、「ビルド、侵入テスト、修正」というサイクルから、「設計、ビルド、デリバリー」という、高品質、安全、およびセキュリティを実現するためのサイクルに私たちを立ち返らせます。
では、どのコーディングスタンダードを使用するべきでしょうか？セキュリティだけを考慮したとしても、多くのスタンダードがあります。ごく一部を挙げただけでも、一般的なセキュアコーディングスタンダードとしてCWE、OWASP、およびCERTがあります。なんらかの要件によって、使用するべきスタンダードが指定されているかもしれません。その場合はそれに従うべきです。しかしそうではない場合は、私としては、特に組込みやセーフティクリティカルなアプリケーションでは、CERTがコードを保護するための優れた選択肢であると主張したいと思います。
CERTがコードをセキュアにするのに最適な理由
当然、「なぜCERTなのか」という疑問が湧くことでしょう。CWEのほうが一般的ではないか？OWASPはどうなのか？それについてはまず、OWASP（Open Web Application Security Project）またはOWASP Top 10は、最初の足がかりを意図したものであり、すべてを厳密にカバーするアプリケーションセキュリティプロセスではないということが言えます。また、名前が表しているように、主にWebアプリケーション用です。
CWE（Common Weakness Enumeration）には、問題の上位25リストがあります。これもスタート地点としては適切ですが、十分ではありません。また、CWEはある意味、症状に基づくスタンダードです。CVE（Common Vulnerability Enumeration）などの特定の脆弱性につながるコードを検出できるように設計されています。これも有用で重要な作業ですが、その性質上、後手に回った対応です。
私がSEI CERTセキュアコーディングスタンダードを推す理由はいくつかあります。まず、症状だけではなく、セキュアコーディングプラクティスに重点を置いているところです（たとえば、SQLインジェクションは症状で、常に入力を検証することはセキュアコーディングです）。CERTは、どのガイドラインが最も重大であるか、また 確実に検出できるかを分析し、従うべき「ルール」と、それほど重要ではない、および/または確実な検出が難しい「レコメンデーション」に分類しました。これにより、静的解析の結果を最も重要なものだけにすばやく絞り込むことができます。
さらに、CERTはガイドラインの本質的な重大性、悪用の難易度、違反修正のコストを考慮して、特定のガイドラインの静的解析結果にさらに優先順位を付けるためのリスク評価フレームワークを作成しました。これにより、非常に詳細な優先順位付けが可能になり、膨大な静的解析違反を処理するのではなく、最も重要な違反に集中するのに役立ちます。
CWEなどの他のスタンダードにもリスク評価フレームワークがありますが、静的解析に完全に取り込むのは非常に難しいため、これまで例がありませんでした。たとえば、今まではCWEの「技術的インパクト」スコアが参考にされており、これも役には立ちますが、CERTのスコアのほうがはるかに自動優先順位付けに向けて進化しています。
これらのリスク評価フレームワークに関して言えることは、これまでは学術的な試みであって、議論の題材としては興味深いが現場では使えない、あるいは完全に手動のプロセスであり主観を排除できなかったということです。そこで私たちはCERTシステムを採用し、静的解析レポートシステムに組み込みました。詳細はこの後説明します。
セキュアコーディングの推進に特定の静的解析ツールを選ぶべき理由
そいういうわけで私はParasoftのエバンジェリストです。しかし、なぜParasoft製品を使用するべきなのでしょう？静的解析ツールなど、どれも基本的に同じではないのでしょうか？もちろん答えはいいえ、同じではありません。CERT Cセキュアコーディングスタンダードについて言えば、 Parasoft C/C++testが最も完璧なソリューションであり、主に次の 3 つの点で進歩に役立ちます。
- CERT Cルールの組み込みサポート。ParasoftはすべてのCERT Cルールを実装し、また、大部分のレコメンデーションを追加済みです。残りのレコメンデーションもまもなく実装される予定です。簡単に言えば、私たちはCERT Cのルールを完全に網羅している唯一のベンダーであり、レコメンデーションもどのベンダーより多くカバーしています。したがって、CERTガイドラインに関心があるなら、客観的に見てParasoft C/C++testが最良の選択です。
- 現実的なリスクスコアの利用。 CERTリスク評価フレームワークの実装は、CERTスタンダード用のすべてのウィジェットおよびレポートに組み込まれている独自のものです。つまり、ルールかレコメンデーションを選択し、優先度スコア、レベル、カテゴリなどを選択すると、変化を即座に確認することができます。
- 監査およびコンプライアンスレポートを簡単に作成。Parasoftは、静的解析ツールで一般的に利用可能なすべての通知手段（ユーザーがカスタマイズ可能なダッシュボード、PDFレポート、ヒストグラムなど）に加えて、動的なリスクウィジェットを提供します。しかし、Parasoftだけの真価は、これをすべて標準のコンプライアンスフレームワークにまとめたことです。つまり、何を実行したか、いつ実行したか、どのようにParasoftとCERTをマップしたか、その他セキュリティ監査に必要なすべてを証明するレポートを簡単に生成できます。セキュリティ担当者も顧客にも、おおいに感謝されるでしょう。
このすべてが、開発者がまさに必要とする方法で機能します。ParasoftのソリューションはビルドシステムやCIシステムに完全に統合し、誰もが結果を参照できるようWeb UIを備えています。さらに重要なのは、ソリューションは開発者のIDE（EclipseやVisual Studioなど）に統合されるため、開発者は最速でコードにフィードバックできる場所で作業を続けられることです。
過去に静的解析セキュリティツールを試してみたところ、あまりにもノイズが多い、またはコードを改善する効果がないなどの理由で苦労された方も、今がParasoftを検討する良い機会です 。
翻訳担当注：日本でのリリース
本記事はC++test 10.4.0に関する内容です。日本では2019年1月を目標にさらに次のバージョン10.4.1をリリース予定です。日本語環境で安定動作するバージョンをご提供できるよう準備を進めておりますので、リリースまでもう少々お待ちください。
（この記事は、開発元Parasoft社 Blog 「Securing IoT and embedded software with static analysis and SEI CERT C secure coding standard」2018年9月27日の翻訳記事です。）