説明/参照:
製品設計フェーズでは、セキュリティ仕様の組み込み、テスト計画とデータの調整、アクセス制御の決定、設計文書、暗号化オプションの評価、および検証を扱います。
この実装は、セキュリティ ソフトウェアのインストール、システムの実行、受け入れテスト、セキュリティ ソフトウェア テスト、および完全なドキュメントの認証と認定 (必要な場合) を扱うため、正しくありません。
詳細設計は、情報セキュリティ ポリシー、標準、法的問題、および概念の早期検証を扱うため、正しくありません。
ソフトウェアの計画と要件は、脅威、脆弱性、セキュリティ要件、合理的な注意、デューデリジェンス、法的責任、コスト/利益分析、必要な保護レベル、テスト計画への対処を扱うものであるため、不正確です。
出典:
KRUTZ、Ronald L. & VINES、Russel D.、『CISSP Prep Guide: Mastering the Ten Domains of Computer Security』、John Wiley & Sons、2001 年、第 7 章: アプリケーションとシステム開発 (252 ページ)。
KRUTZ、Ronald & VINES、Russel、『The CISSP Prep Guide: Gold Edition』、Wiley Publishing Inc.、2003 年、第 7 章: セキュリティ ライフ サイクル コンポーネント、図 7.5 (346 ページ)。
145
システム開発ライフサイクルのどの基本段階でセキュリティ要件が正式化されますか?
A. 廃棄
B. システム設計仕様
C. 開発と実装
D. 機能要件定義
答えD
機能要件の定義中に、プロジェクト管理チームとシステム開発チームは、現在および将来起こり得る機能要件の包括的な分析を実行して、新しいシステムがエンドユーザーのニーズを満たしていることを確認します。また、チームはプロジェクトの開始段階からドキュメントを確認し、必要に応じて修正や更新を行います。小規模なプロジェクトの場合、このフェーズはプロジェクトの開始フェーズに組み込まれることがよくあります。この時点で、セキュリティ要件を形式化する必要があります。
開発ライフ サイクルは、通常システム開発ライフ サイクル (SDLC) と呼ばれるソフトウェア開発プロジェクトの計画、実行、および制御に使用できるプロジェクト管理ツールです。
SDLC は、システム アナリスト、ソフトウェア エンジニア、プログラマー、エンド ユーザーがプロジェクトの設計と開発に参加するプロセスです。業界全体に適用される SDLC はないため、組織はいずれかの SDLC 方式を使用することも、複数の SDLC 方式を組み合わせて使用することもできます。
SDLC は、機能要件の定義から実装までのソフトウェア開発プロジェクトのフェーズのフレームワークを提供するだけです。使用する方法に関係なく、SDLC では重要なフェーズの概要が説明されており、これらのフェーズは一緒に表示することも、個別の要素として表示することもできます。選択するモデルはプロジェクトに基づいている必要があります。
たとえば、一部のモデルは長期にわたる複雑なプロジェクトに適していますが、他のモデルは短期プロジェクトに適しています。重要な要素は、正式化された SDLC が利用されていることです。
フェーズの数は、3 つの基本フェーズ (コンセプト、設計、実装) から最大の範囲になります。
SDLC の基本フェーズは次のとおりです。
プロジェクトの開始と計画
機能要件定義
システム設計仕様
開発と実装
ドキュメントと共通プログラム制御
試験および評価管理（認証および認定）
本番への移行（実装）
システム ライフ サイクル (SLC) は SDLC を超えて拡張され、次の 2 つの追加フェーズが含まれます。
運用保守サポート（導入後）
改定とシステムリプレース
システム設計仕様
このフェーズには、システムとソフトウェアの設計に関連するすべてのアクティビティが含まれます。この段階では、システム アーキテクチャ、システム出力、およびシステム インターフェイスが設計されます。データ入力、データ フロー、出力の要件が確立され、通常は企業の全体的なセキュリティ アーキテクチャに基づいてセキュリティ機能が設計されます。
開発と実装
このフェーズでは、ソース コードが生成され、テスト シナリオとテスト ケースが開発され、単体テストと統合テストが実施され、メンテナンスや受け入れテストと運用への移行のためにプログラムとシステムが文書化されます。ソフトウェアの品質、信頼性、動作の一貫性に対する一般的な注意と同様に、セキュリティの悪用やその他のリスクにつながる可能性のある一般的な脆弱性を排除するためにコードが分析されるように特別な注意を払う必要があります。
ドキュメントと共通プログラム制御
これらは、プログラム内のデータを編集するときに使用されるコントロール、プログラムが実行する必要があるログの種類、およびプログラムのバージョンを保存する方法を制御します。このようなコントロールが多数必要になる場合があります。コントロールの完全なリストについては、以下のリファレンスを参照してください。
承諾
受け入れ段階では、できれば独立したグループがテスト データを開発し、コードをテストして、コードが組織の環境内で機能すること、およびすべての機能要件とセキュリティ要件を満たしていることを確認します。職務の分離の問題を防ぐために、独立したグループが開発の該当するすべての段階でコードをテストすることが不可欠です。セキュリティ テストの目的は、アプリケーションがセキュリティ要件と仕様を満たしていることを確認することです。セキュリティ テストでは、ユーザーがソフトウェア セキュリティ ポリシーおよび要件に違反する可能性があるすべての設計および実装の欠陥を明らかにする必要があります。テストの有効性を確保するには、実稼働環境をシミュレートする環境でアプリケーションをテストする必要があります。これには、セキュリティ認定パッケージとユーザー ドキュメントが含まれている必要があります。
認証と認定（セキュリティ認可）
認証は、事前に設定された一連のセキュリティ標準またはポリシーに照らして、ソフトウェアまたはシステムのセキュリティ スタンスを評価するプロセスです。認定では、システムが意図した機能要件をどの程度適切に実行するかも検査されます。認証または評価文書には、技術的および非技術的なセキュリティ機能と対策の分析、およびソフトウェアまたはシステムがその使命と運用環境のセキュリティ要件をどの程度満たしているかを含める必要があります。
本番環境への移行（実装）
このフェーズでは、新しいシステムは受け入れフェーズから実際の運用環境に移行します。このフェーズの活動には、セキュリティ認定の取得が含まれます。実装およびトレーニングのスケジュールに従って新規ユーザーをトレーニングする。インストールとデータ変換を含むシステムの実装。必要に応じて、並行操作を実行します。
改定とシステムリプレース
システムは実稼働モードであるため、ハードウェアとソフトウェアのベースラインは定期的な評価と監査の対象となる必要があります。場合によっては、アプリケーションの問題は欠陥や欠陥ではなく、アプリケーションで現在開発されていない追加機能である可能性があります。アプリケーションに対する変更はすべて、同じ SDLC に従い、変更管理システムに記録される必要があります。改訂レビューには、将来の問題を回避するためのセキュリティ計画と手順を含める必要があります。アプリケーション監査を定期的に実施し、問題が発生した場合のセキュリティ インシデントの文書化を含める必要があります。システム障害の文書化は、将来のシステム拡張を正当化するための貴重なリソースです。
以下は、NIST が 800-63 リビジョン 2 文書で使用しているフェーズです。上で述べたように、フェーズは文書ごとに異なります。試験の目的には、上記の短い形式で示されている公式 ISC2 スタディ ブックに記載されているリストを使用してください。SDLC の各段階での活動の詳細については、本書を参照してください。
ただし、すべての参考文献では非常に類似した手順が使用されています。公式ブックで述べられているように、最も基本的なバージョン (コンセプト、設計、実装) では 3 つのフェーズと同じくらい単純ですが、SDLC のより詳細なバージョンではさらに多くのフェーズになる可能性があります。
重要なのは、SDLC を利用することです。
SDLCフェーズ
この質問に使用された参考文献:
NIST SP 800-64 リビジョン 2 (http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf)
そして
シュナイター、アンドリュー (2013-04-15)。CISSP CBK の公式 (ISC)2 ガイド、第 3 版: ソフトウェア開発セキュリティ ((ISC)2 Press) (Kindle の場所 134-157)。アウアーバッハ出版物。キンドル版。
