web-dev-qa-db-ja.com

テスト段階でセキュリティ指標はどのように検証されますか?

アプリケーションのアーキテクチャを分析して作成する必要があります。私が見つけた要件を分析している間、私のシステムのユーザーの個人識別情報(PII)の機密性は非常に機密性の高い品質要件であり、NFR( 非機能要件 )セクションに移動する必要があります。 NFRは、すべての応答が、検証フェーズでテスターに​​よって使用される測定可能な方程式を持つ必要があることを要求します。

私はこの分野の新人であり、データセキュリティ関連の対策とその許容限度を準備するためのハードルに直面しています。以下のようにNFRテーブルを作成しましたが、検証フェーズではテスターがこの要件を検証するのが難しいため、適切な方法ではない可能性があります。

それで問題は、テスターに​​よるそのようなソフトウェア検証フェーズのために、アーキテクトがデータの機密性とセキュリティ属性の測定値と許容限度を通常どのように設定するのかということです。

3

既に推測したように、「攻撃成功率<= 0.001%」のような指標は、受け入れテキストのテスト指標として特に有用ではありません。

このページ をご覧ください。それは言う:

非機能要件

安全保障

プロバイダーシステムは、不正、偶発的、または意図しない使用に抵抗し、正当なユーザーにのみアクセスを提供するものとします(SHALL)。技術的な詳細については セキュリティガイダンスページ を参照してください。

もちろん、これはテスト可能な要件ではありません。それは願いです。ただし、そこにリンクされているセキュリティガイダンスページにアクセスすると、(特に)次のことがわかります。

安全な接続ネゴシエーション

プロバイダーシステム:

  • Spine Secure Proxy(SSP)からの接続のみを受け入れる必要があります

  • クライアント証明書を使用して要求に応答する前に、SSPを認証する必要があります。

  • 承認されたサポート対象の暗号の使用のみを許可する必要があります

  • 安全でないプロトコルで提示された暗号化された接続とドロップ接続試行のみを受け入れる必要があります

  • 一致するエンドポイントURLのSsp-Toヘッダーで指定されている、割り当てられたアドレススペース識別子(ASID)の要求のみを受け入れる必要があります(SHALL)

  • Ssp-InteractionID値が要求されているエンドポイントと一致していることを確認する必要があります(SHALL)

  • すべてのSSPヘッダーの存在を確認する必要があります。

  • 承認ベアラートークンが存在し、正しく形成されていることを確認する必要があります

  • JSON Web Token(JWT)のrequested_scopeクレームの許容値を調べることにより、APIエンドポイントへのアクセスを承認できます。

  • 不適切なリスクを防ぐために、トランスポート層セキュリティ(TLS)通信のエンドポイントのセキュリティをリスク管理します(たとえば、GETパラメータの監査ログから保護されていない監査ログへの監査ログ)。

ああ、今、私たちはどこかに着いています。ほとんどの場合、これらはテスト可能な要件です。それらは特定でテスト可能であるだけでなく、セキュリティ戦略の詳細な概要も提供します。

3
Robert Harvey

NFRは、すべての応答が、検証フェーズでテスターに​​よって使用される測定可能な方程式を持つ必要があることを要求します。

これがおそらくあなたの問題の根本的な原因だと思います。一部の問題は非常に困難であり、簡単なメトリックに簡単に減らすことはできません。

ビジネスがユーザーのPIIの保護に真剣に取り組んでいる場合、最善の方法は、ほとんどの場合、専門の侵入テストサービスによってテストされ、メトリックを「些細な脅威レベルを超えるすべてのセキュリティの脆弱性が解決されたこと」に設定することです。 」.

2
Philip Kendall