ソフト開発監査チェックリスト（１１）セキュリティ要件管理技術
要件管理チェックリストの４つ目はセキュリティです
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では②要件管理の中の構成管理の個々の項目について紹介します。（チェックリストそのものは ソフト監査実務・チェックリストその８：開発技術・要件管理（管理全般）の記事に載っていますので、そちらをご覧下さい）
ソフト監査で見るのは製品に搭載されるソフトのセキュリティで主に脆弱性の確認です
サーバー戦争に関するニュースが一般のテレビや新聞にも登場するようになってきて、日本でも最近はセキュリティに関する関心が高まってきました。良い傾向なのですが、残念ながら世界から10年以上は遅れているのが現状です。とはいえ、あらゆる物がインターネットに繋がっていく今の世の中では、組み込みソフトもセキュリティ対策をしっかりとしておく必要があります。
ところがセキュリティは、本来の装置や機器の機能や性能に直接かかわる物ではないので、どのレベルまでのセキュリティ対策を採用すれば良いのかをしっかりと決めておかないと開発する段階で困った事になります。ですので、要求仕様書にもできるだけ具体的にセキュリティについての要件が掛かれている事が大切です。 まだまだ件数は少ないですが、このセキュリティについてのチェック項目は、今後もっと増やしていく必要があると思っています。
なお、ソフト開発監査で使用するこのチェックリストに書いてある項目は、製品に搭載されるソフトのセキュリティに関する内容です。出荷した機器や装置が乗っ取られたり他者を攻撃する時の踏み台にされたりするような脆弱性が無いかどうかについての確認です。
セキュリティと言うと世間一般では、このような製品のセキュリティではなく、仕事の仕方についてのセキュリティが良く話題になります。例えば社内にある顧客や社員の個人情報が漏れたり盗まれたりしないか、という話題ですね。このようなセキュリティは、仕事の進め方やルールについてのセキュリティです。
こちらのセキュリティも勿論大切なのですが、ソフトウ開発監査で注目しているのは、あくまでも製品に搭載されるソフトですので、チェックリストの項目も製品に搭載されるソフトのセキュリティについてです。 事の仕方についてのセキュリティは、また別のセキュリティに関する監査のような物が必要なのですが、ソフト開発監査としては対象外としています。 チェックリストでは項目番号が SE- で始まる3件ですので、順にみていきましょう。
【項目番号：SE-01】
製品に搭載されるソフトウエアのセキュリティ対策とは、要するにソフトウエアの脆弱性をどうやって減らすのかに尽きます。 脆弱性が残っていると、そこを攻撃されてシステムを乗っ取られたり重要な情報を盗まれたり機能を止められたりと、いろいろと都合の悪い状態を許してしまうリスクがあります。 脆弱性を減らすには大きく分けて２つの方法があります。一つ目は既知の脆弱性を調べあげてその脆弱性が潜んでいない事を確認する方法です。そしてもう一つが未知の脆弱性が潜んでいないかを確認する方法です。 ２つとも脆弱性を見つけるための方法なのですがアプローチの仕方が違います。ですので、要求仕様書にセキュリティの要件が書いてあるのならば、既知の脆弱性の対策と未知の脆弱性の対策のどちらか一方のみで対策をするのか、両方を合わせて対策するのか、セキュリティ対策についての基本的な方針が決められている事が大切です。 そのようなセキュリティ対策についての方針が掛かれているかどうか、に注意して確認します。
【項目番号：SE-02】
既知の脆弱性につての対策を行うには、既知の脆弱性をさらに２つに分類して対策の進め方が変わってきます。一つ目が既に公開されている既知の脆弱性で、もう一つが未だ公開されていない既知の脆弱性です。
なぜ公開と非公開の情報があるのでしょうか、実は脆弱性とは裏を返せば攻撃に適したセキュリティの穴なのです。脆弱性の存在が判れば、攻撃する側つまりはシステムを乗っ取ったり情報を盗んだししようと考えていいる攻撃者は、その脆弱性を突いて攻撃を仕掛けてきます。ですので、基本的に脆弱性というのはもし見つけたとしたら、攻撃者に知られる前にその脆弱性を修正してしまう必要があります。そのために、発見された脆弱性は、多くのメーカがその対策を取るまでは非公開として、その脆弱性を抱えているメーカにのみ情報として通知されます。
殆どのメーカの製品で脆弱性の対策が済んでから、その脆弱性は公開され、今後の製品で同じ脆弱性が作りこまれないように、予防処置がとられます。このような既知の脆弱性の情報については、情報の公開/非公開について制御されているので、どちらの脆弱性情報を使うのかによって対応作業の仕方が変わってきます。
ですので、要求仕様書にはどちらの脆弱性を使うのか、どうやって脆弱性情報を入手するのか、などの具体的な要件が書いてある必要があります。そのような点に注意して、チェックリストによる確認を行います。そして、既知の脆弱性の情報を使う場合には、その情報を何処から入手するのかなどの具体的な情報の入手経路と、その情報を製品の開発にどう使うかのかという情報の使い方が決まっている必要があります。そのような点が要求仕様書に書かれているかという視点で確認をします。
【項目番号：SE-03】
脆弱性のもう一つは未知の脆弱性です。まだ見つかって居ない脆弱性がソフトのソースコードの何処かに潜んでいる可能性はゼロにはできません。各国の各種のサイバー攻撃部隊は、様々なソフトに潜んでいる、まだ見つかっていない脆弱性を日夜探し続けています。そして、もし新しい脆弱性を発見したらその脆弱性を突く攻撃手段を考えて準備をした上で、その攻撃手段を将来使う時のためにそっと隠します。なぜなら、一度攻撃手段として使ってしまえばその脆弱性が在る事が知られてしまい、脆弱性の対策がされてしまうからです。
脆弱性の発見とその対策はイタチゴッコが続いているので、ソフトを開発した時には、そこに未知の脆弱性が潜んでいないかを調べる事も必要です。ツールを使ったり専門家に攻撃をしてもらったりと、色々な方法があるのですがどの方法も結構な費用が掛かります。ですので、どのようなレベルまで未知の脆弱性についての調査を行うのか、要求仕様書に明確に書いていないと、実際の作業が難しくなります。 そのような点に注意して、確認をしていきます。
保守性の次はセキュリティです
保守性の確認の次はセキュリティについての確認項目について、次の記事で紹介します。