記事の序文
ソフトウェア製品の開発後は、需要者の実際のニーズを満たしているかどうかを判断するためにビジネス機能の機能テストを実施するだけでなく、製品全体のセキュリティを検出するために製品のセキュリティテストも実施する必要があります。 SDL プロセスでは、製品が開発を達成するためには、バージョン標準が製品マネージャやプロジェクト マネージャによって確立された期待される機能的なビジネス目標を満たしているだけでなく、安全性と品質の標準も満たしている必要があります。
測定対象
ソフトウェア製品は、次のカテゴリに大別できます。
社内システム：社内通信ソフトウェアや社内データベースシステムなど、企業が社内で使用するために開発したシステム。
外部システム: 企業の外部公式 Web サイトや企業のエクストラネット オフィス システムなど、企業が外部公開するために開発したシステム。
製品の調達: 企業は業界製品を評価し、セキュリティ製品、コラボレーション オフィス製品、およびサードパーティが開発したその他のソフトウェア システムを購入することを選択します。
メトリクス
また、さまざまな種類のソフトウェア製品に対して、さまざまなソフトウェア セキュリティ品質測定基準が存在します。
内部システム: 企業が内部使用のために開発したシステムは、ホストに中リスクの脆弱性がないこと、および Web に中リスクの脆弱性がないという要件を満たす必要があるだけです。
外部システム: 企業によって開発され、外部にリリースされるシステムは、Web 漏洩スキャン、手動侵入、およびコード セキュリティ監査の要件を満たしている必要があり、中リスクの脆弱性がなく、セキュリティ設計チェックリストが基準を満たしている必要があります。
製品の購入: 第三者は製品の安全性認証資料を提供する必要があり、契約を締結する際には安全責任協定および緊急ストップロスのアフターサービスを含める必要があります。ここでの安全認証資料とは通常、第三者のセキュリティ会社が発行するレポートを指します。 、コード監査レポート、メインストリーム スキャナの見逃しスキャン、ペネトレーション テスト レポート、オープン ソース コンポーネント リスト (依存するオープン ソース コンポーネントのタイプとバージョン情報) を含む
脆弱性評価
企業は、自社のビジネスの重要性だけでなく、業界標準や法律や規制に基づいて脆弱性をセキュリティ グレード付けできます。以下に簡単な例を示します。
学年 |
評価基準の説明（以下のいずれかの条件を満たしているもの） |
||||||||||
低い |
1) 明らかなセキュリティ上の問題は見つかりませんでした |
||||||||||
2) 関連する国内業界標準および仕様から逸脱していないこと |
|||||||||||
3) セキュリティ脆弱性の悪用は、システムに明らかなセキュリティ リスクを引き起こしません (たとえば、セキュリティ脆弱性の悪用は、システム コンポーネントに関する特定の情報のみを取得します)。 |
|||||||||||
4) 上記と同様に有害なその他のセキュリティ脆弱性 |
|||||||||||
真ん中 |
1) 関連する国家業界標準および仕様からの逸脱、およびその逸脱により、部分的な情報漏洩などの問題が発生しますが、重大な問題 (バックエンド データベースの読み取りなど) を直接引き起こすことはありません。 |
||||||||||
2) セキュリティの脆弱性が悪用されると、システムに一定の影響が及ぶ可能性があります (通信プロセスで非機密情報が取得されるなど)。 |
|||||||||||
3) セキュリティの脆弱性が悪用されるとシステムに重大な影響を及ぼしますが、悪用するのは簡単ではありません。 |
|||||||||||
4) 上記と同様に有害なその他のセキュリティ脆弱性 |
|||||||||||
高い |
1) 関連する国家業界標準および仕様からの逸脱、およびその逸脱が重大な問題を直接引き起こすこと (例: プログラムのソース コードの取得、システム ファイルのリモートでの読み書きやバックグラウンド データの操作、コマンドを通常どおりリモートで実行できること)ユーザーまたはサービス拒否攻撃の実行など）、管理ユーザーとしてコマンドをリモートで実行できるなど） |
||||||||||
2) セキュリティ脆弱性の悪用は、システムに深刻な影響を及ぼし、悪用が容易です (例: プログラムのソース コードの取得、システム ファイルのリモートでの読み書きやバックグラウンド データの操作、一般ユーザーとしてのコマンドのリモート実行、または拒否の実行) -of-service 攻撃、管理ユーザーとしてリモートでコマンドを実行するなど) |
|||||||||||
3) 上記と同様に有害なその他のセキュリティ脆弱性 |
|||||||||||
記事の最後にまとめ
製品の安全性と品質は、製品が発売要件を満たせるかどうか、また製品が予定通りに発売できるかどうかを決定するため、製品の安全性と品質の測定基準と SDL 製品発売規制の導入と公表は早ければ早いほど良いのです。プロダクト マネージャー、プロジェクト マネージャー、研究開発担当者は、後の段階でセキュリティの問題によってオンラインに接続できなくなったり、製品の機能が再構築されたりすることを避けるために、ソフトウェア開発サイクル中にセキュリティの問題にもっと注意を払う必要があります。