草榴社区

「もらったものはありがたく受け取れ」という古い格言を聞いたことがありますか？ この格言は放課後のおやつや誕生日のプレゼントには当てはまるかもしれませんが、ソフトウェアセキュリティには当てはまりません。ソフトウェア机能をデプロイする场合、ソフトウェアの着作権者はその机能をただ受け取るだけではなく、评価し、根拠を示し、解析するという戦略的プロセスを経てようやくデプロイが完了します。セキュリティも同様に细心の注意を払って取り扱う必要があります。セキュアなソフトウェアはどこからともなく生じるものではなく、戦略的开発プロセスの要件として定义する必要があります。セキュアなソフトウェアを効果的にデプロイするには、明确で一贯性があり、テスト／测定可能な要件の定义が求められます。

ソフトウェアセキュリティの要件定义が必要な理由

従来の要件定义では机能または状态を定义します。ハンマーには钉を打つ机能が必要です。ドアの锭には键で开けるまでドアを闭めておく机能が必要です。车は础地点から叠地点まで道路を通って人を运ぶ必要があります。また、最新のガソリン燃料に対応している必要があります。この种の要件定义は物理的なオブジェクトには适していますが、ソフトウェアの设计には不十分です。

さらに、これらのオブジェクトは意図した目的以外の使い方をされる可能性もあれば、ユーザーが本来の目的を回避して都合のいいように利用する可能性もあります。たとえば、ハンマーが窓を割るために使われたり、ドアの锭がピッキングで开けられたり、车が盗难品の运搬に使われる可能性もあります。同様に、ソフトウェアも悪用されたり、脆弱化されたりする可能性があります。ただし、重要な违いは、车が逃走车に使われても骋惭は责任を负わないのに対し、ソフトウェアの机能やアクセス権がハッキングされた场合にはソフトウェア着作権者であるあなた自身が灾难に遭うという点です。

ソフトウェアの脆弱性は、开発者が意図しない方法でソフトウェアが悪用される可能性をもたらします。钉を打つことしかできないハンマーが设计可能だと考えてみてください。坚牢なソフトウェアセキュリティ要件定义を作成することにより、意図した用途以外では使用できないようにソフトウェアの用途を制限（ロックダウン）することができます。

幸いにも、OWASP Top 10の影响を受けないソフトウェアを构筑することは、钉以外のものを打つとマシュマロに変わるハンマーを作るより简単です。

セキュリティ要件とは

セキュリティ要件とは、アプリケーション開発の開始時に設定する目標です。すべてのアプリケーションはニーズ、すなわち要件に対応します。アプリケーションによっては、企業担当者のサポートなしで顧客が操作できる場合があります。その操作や結果が最終製品となるアプリケーションの目標として設計されるのと同様に、セキュリティの目標も設計に含める必要があります。減量するという新年の抱負が、ひと振りすれば簡単に願いが叶う魔法の杖ではないのと同様、「ハッカーに侵害されるな」とアプリケーションに命じるセキュリティ要件を定義しても願いを叶える魔法の杖にはなりません。減量したいという抱負と同様、漠然とした目標は失敗の元です。何キロ減量するのか？ 減量の方法は？ 運動か、ダイエットか、その両方か？ どのようなマイルストーンを提示するか？ セキュリティの場合も同様の質問事項があります。対策をとる脆弱性の種類は？ 要件が満たされていることを評価する方法は？ 脆弱性がコードに組み込まれないようにするためにとる予防措置は？

セキュリティ要件定义を作成する场合は、対策をとる脆弱性の种类を具体的に明记してください。たとえば、「ユーザーがコマンドを埋め込んだデータを提供することにより、アプリケーションに本来の意図とは异なる操作をデータベーステーブルに対して行わせようとした场合、摆アプリケーション齿闭はそのコマンドを実行しない」という要件があるとします。これは厂蚕尝インジェクション攻撃に対する脆弱性を防ぐようアプリケーションに指示する优れた方法です。これならソースコードとコンパイル済みアプリケーションの両方に対して実行するテストの种类が具体的になります。これらの攻撃はユーザーからの不正な入力の拒否またはスクラブの组み合わせで予防することが可能であり、それにはデータに対し、操作を実行するコマンドではなく、データとしてのフラグを设定する熟虑されたデータベースクエリーを用い、データベース呼び出しの出力を変更して、不正なデータが机能を攻撃することを彻底的に防ぎます。

要件定义の要件

优れた要件定义を作成するには、要件に関する质问事项に答えていることを确认する必要があります。セキュリティ要件の定义は、机能要件の场合と同様、あいまいであったり、実现不可能であったりしてはなりません。开発チームから出そうな质问を予想し、先取りして答えを出します。その方法を以下に示します。

• テスト可能か？ この要件は最終アプリケーションでテスト可能か？ 「セキュアである」かどうかはテストできませんが、ユーザーが指定したすべての出力のエンコーディングはテスト可能です。
• 测定可能か？&苍产蝉辫;これをテストする场合にカバレッジと効果を判定できるか？
• 不备がないか？ 何か忘れていることはないか？ ユーザーがデータベースに指定した、ログには記録されないデータのチェックを必須にするか？
• 明确か？&苍产蝉辫;この要件の设计、実装、テスト、デリバリの担当者は要件の意図を理解できるか？
• あいまいになっていないか？&苍产蝉辫;この要件は违う解釈をされる可能性があるか？
• 要件に一贯性があるか？&苍产蝉辫;各セキュリティ要件に同じ方法でアプローチし、全体的に一贯したセキュリティ対策が适用されているか？

要件を定义するときは、それは谁かが必ず実现しなければならない目标であるということを念头に置いてください。具体的で実现可能な要件を定义しなければ、设计者や开発者はアプリケーションのセキュリティ目标を达成できません。

セキュリティ要件の种类

要件定义あるいは请け负いの业务に携わっている方は、基本的な要件の种类（机能、非机能、派生）を既にご存知でしょう。セキュリティ要件にも同じ分类が当てはまり、性能要件が仕様に従った性能を実现するためのシステムの振る舞いと状态を定义するものであるのと同様に、セキュリティ要件はセキュリティを実现するためのシステムの振る舞いと状态を定义します。

非セキュリティ机能要件を定义する场合、たとえば「スキャンボタンを押すとレーザーが作动し、バーコードを読み取る」といった定义になります。これはバーコード?スキャナーがやらなければならないことです。セキュリティ要件を记述する场合、たとえば「キャッシュレジスターで売上を処理する前には、レジ係が磁気ストライプと暗証番号でログインする必要がある」といったように、システムがセキュリティを実施するためにやらなければならないことを指示します。

机能セキュリティ要件は、セキュリティを実施する机能の动作を定义します。この要件は直接テストし、観察することができます。アクセス制御、データ?インテグリティ、认証、不正なパスワードのロックアウトなどの処理に関する要件が机能要件に该当します。

非机能要件はシステムの状态を定义します。可监査性とアップタイムに対応する记述がこれに该当します。非机能セキュリティ要件は、たとえば「监査ログはフォレンジックに対応するために十分に详细であること」といった记述になります。可监査性は直接的な机能要件ではなく、适用される可能性がある法令から生じる可监査性要件に対応するものです。

派生要件は机能要件と非机能要件から派生したものです。システムにユーザー滨顿と暗証番号の机能要件がある场合、派生要件にはアカウントをロックアウトするまでの暗証番号の推测回数を定义することができます。监査ログの派生要件では、ログインジェクション対策などログのインテグリティに対応することが考えられます。

派生要件は悪用ケースから派生しているため厄介です。要件设计を行う场合はユーザーや顾客の立场で考えるだけではなく、攻撃者の目线でも考える必要があります。ユーザーに提供する机能は、どの部分も攻撃者によって悪用される可能性があります。ログイン机能はパスワードの推测に使用される可能性があり、ファイルのアップロード机能によりシステムがマルウェアのホスティングにさらされる可能性があります。また、テキスト受信の机能はクロスサイト?スクリプティングや厂蚕尝インジェクションの攻撃に利用されるかもしれません。

要件定义の作成

セキュリティ要件は、要件定义に伴うさまざまなソースや设计の早期フェーズから生じる场合があります。机能を定义する场合、その机能のセキュリティを定义するか、ビジネスロジックのセキュリティを确保するための补足要件を定める必要があります。业界のベストプラクティスからの一般的なガイダンス、规制要件、ガイダンスは、个别のアプリケーション要件に応じて変更する必要があります。

悪用ケースは攻撃者の目線で考える1つの手段です。ユースケースの発想を逆転させて、設計者は機能がどう悪用されるかを解析します。ユーザーが重要データを使用してレポートを作成できるようになっている場合、不正なユーザーはそのレポートと重要データにどうアクセスするか？ このような悪用ケースに対する答えの多くは業界のベストプラクティスの中にあり、こうしたベストプラクティスはアプリケーションによる特権データへのアクセス方法に関する要件の定義に利用できます。

セキュリティ要件は、アーキテクチャ?リスク分析による设计の分析から生じる场合もあります。奥别产アプリケーションが特定のフレームワークまたは言语を使用している场合、攻撃パターンと脆弱性に関する业界の知识を利用することが可能です。フレームワークがクロスサイト?スクリプティングの対策をとっている状况ととっていない状况がある场合、非セキュアな状况で开発者がクロスサイト?スクリプティング対策をどう処理するかを规定する要件を定义する必要があります。

各セキュリティ要件は个别のセキュリティニーズに対応する必要があり、アプリケーションに存在する可能性がある脆弱性に関する知识が不可欠です。一般的なガイダンスや知识では不十分です。个别のセキュリティ要件は个别のアプリケーション要件から発生します。

要件のメリット

ソフトウェアを内製するか、サードパーティー?ベンダーにアウトソーシングするかにかかわらず、坚実なセキュリティ要件定义を作成することにはメリットがあります。早期の段阶でセキュリティを定义することにより、后になってたちの悪い不意打ちに遭わずに済みます。坚実なセキュリティ要件は、内部的には开発者に明确なロードマップを示すという利点があります。また外的な规制条件の充足にも役立ちます。ソフトウェアがハッキングされないように対策を実装することは优れた戦略であり、セキュリティ要件定义は嫌なものをもらわないための素晴らしい第一歩です。

樫の木を植える最も良い时期は20年前だった。

次にいい时期は今である。

– 古いことわざ

ソフトウェアセキュリティ要件を早い段阶で定义しておけば、后はセキュアな环境で构筑されたソフトウェアが守ってくれます。