MVSPチェックリスト(日本語訳)

概要

GoogleとSalesforceが公開したMVSPチェックリストをDeepL翻訳しました。

MVSP（Minimum Viable Secure Product）

Minimum Viable Secure Productは、B2Bソフトウェアおよびビジネスプロセスアウトソーシングのサプライヤ向けの最小限のセキュリティチェックリストです。

このチェックリストは、シンプルであることを念頭に設計されており、製品のセキュリティ態勢を最低限確保するために実装しなければならない管理項目のみが記載されています。

私たちは、B2Bソフトウェアを開発している企業、または広義の機密情報を取り扱っている企業に対し、少なくとも以下の対策を実施することを推奨します。また、セキュリティプログラムにおいては、これらの対策以上の対策を実施することを強く推奨します。

１ ビジネス・コントロール

1 Business controls

control	description
1.2 脆弱性の報告	・セキュリティレポートの連絡先をウェブサイトに掲載する ・妥当な期間内にセキュリティレポートに対応する
1.2 顧客テスト	・ご要望に応じて、お客様の顧客またはその代理人が、お客様のアプリケーションのセキュリティをテストできるようにします。 ・本番環境と機能的によく似ている場合は、非本番環境でテストを行う ・非本番環境に本番データが含まれていないことを確認する
1.3 自己評価	・本文書を使用して、年1回（最低）のセキュリティ自己評価を実施する。
1.4 外部テスト	セキュリティベンダーと契約し、自社システムの包括的なペネトレーションテストを毎年実施する
1.5 トレーニング	従業員に対して、業務内容に応じた役割別のセキュリティトレーニングを実施する
1.6 コンプライアンス	・PCI DSS、HITRUST、ISO27001、SSAE18など、お客様のビジネスに関連するすべての業界セキュリティ基準に準拠する。 ・GDPR、Binding Corporate Rules、Standard Contractual Clausesなど、貴社および貴社の顧客に適用される管轄区域の法律および規制に準拠する。
1.7 インシデント処理	・侵害を発見してから72時間以内に、不当な遅延なく顧客に通知する 通知には、以下の情報を含めること 　- 関連する連絡先 　- 侵害の予備的な技術分析 　- 合理的な期限を定めた修復計画

２ アプリケーションの設計管理

2 Application design controls

control	description
2.1 シングルサインオン(SSO)	最新かつ業界標準のプロトコルを使用したシングルサインオンの導入
2.2 HTTPSオンリー	・HTTP プロトコル（ポート 80）のトラフィックを HTTPS（ポート 443）にリダイレクトする これは、OCSP など、暗号化されていない接続の上で動作するように設計された安全なプロトコルには適用されません。 ・広く採用されている TLS スキャンツールを使用してクリアスキャンを行う。 ・includeSubdomains ディレクティブを使用して、すべてのページに Strict-Transport-Security ヘッダを含める。
2.3 コンテンツ・セキュリティ・ポリシー	最小限の寛容なコンテンツ・セキュリティ・ポリシーを設定する
2.4 パスワードポリシー	シングルサインオンに加えてパスワード認証を使用する場合。 　・パスワードの長さを 64 文字以下に制限しない。 　・秘密の質問を唯一のパスワードリセット要件として使用しない。 　・パスワード変更要求の際に電子メールによる確認を要求する 　・パスワード変更時に、新しいパスワードに加えて現在のパスワードも要求する。 　・新しく作成したパスワードを、一般的なパスワードリストや流出したパスワードのデータベースと照合する。 　・既存のユーザーのパスワードが漏洩していないか定期的に確認する 　・メモリに負荷のかかる一方向性ハッシュ関数、またはCPUに負荷のかかる一方向性ハッシュ関数を使用して、ハッシュ化され、かつ塩付けされた形式でパスワードを保存する 　・アカウントへのアクセスに対して、適切なアカウントロックアウトとブルートフォースによる保護を実施する
2.5 セキュリティライブラリ	出力をエスケープし、入力をサニタイズすることで、実装上の弱点に体系的に対処するフレームワーク、テンプレート言語、またはライブラリを使用する。 　例） データベースアクセスのためのORM、DOMレンダリングのためのUIフレームワーク
2.6 パッチの適用	深刻度スコアが「中」以上のセキュリティパッチを適用するか、またはパッチリリースから1カ月以内にアプリケーションスタックのすべてのコンポーネントに対して同等の緩和策が利用できるようにする
2.7 ロギング	以下のようなログを記録する 　・ユーザーのログインとログアウト 　・アプリケーションやシステムのユーザやオブジェクトに対する読み取り、書き込み、削除の操作 　・セキュリティ設定の変更（ロギングの無効化を含む 　・アプリケーションの所有者による顧客データへのアクセス（アクセスの透明性 ログには、ユーザーID、IPアドレス、有効なタイムスタンプ、実行されたアクションの種類、このアクションの対象が含まれていなければなりません。ログは少なくとも 30 日間保存しなければならず、機密データやペイロードを含んではならない。
2.8 バックアップおよびディザスタリカバリ	・すべてのデータを、アプリケーションが稼働している場所とは別の場所に安全にバックアップする。 ・災害復旧計画を維持し、定期的にテストすること ・バックアップの復元を定期的にテストする
2.9 暗号化	利用可能な暗号化手段を使用して、システム間の移動中およびオンラインデータストレージやバックアップでの保存中の機密データを保護すること

３ アプリケーションの実装管理

3 Application implementation controls

control	description
3.1 データのリスト	アプリケーションが処理することが期待されるセンシティブなデータタイプのリストを維持する。
3.2 データフロー図	センシティブデータがどのようにシステムに到達し、最終的にどこに保存されるかを示す最新の図を維持すること
3.3 脆弱性の防止	少なくとも次のような脆弱性を防ぐために、開発者を教育し、開発ガイドラインを実施すること。 　・認証のバイパス。例。通常のアカウントから他のお客様のデータや管理者機能にアクセスすること 　・安全でないセッションID。例 推測可能なトークン、安全でない場所に保存されたトークン（例：secureおよびhttpOnlyフラグが設定されていないcookie）。 　・インジェクション。例 SQL インジェクション、NoSQL インジェクション、XXE、OS コマンドインジェクション 　・クロスサイトスクリプティング。例 安全でないJavaScript関数の呼び出し、安全でないDOM操作の実行、ユーザーの入力をエスケープせずにHTMLにエコーバックする行為 　・クロスサイト・リクエスト・フォージェリ 例 異なるドメインからのOriginヘッダーを持つリクエストを受け入れること 　・脆弱なライブラリの使用。例 脆弱性が知られているサーバーサイドフレームワークやJavaScriptライブラリの使用
3.4 脆弱性の修正時期	セキュリティに重大な影響を与えるアプリケーションの脆弱性に対して、発見から90日以内にパッチを作成して配布すること。

４ 運用管理

4 Operational controls

control	description
4.1 物理的アクセス	以下の管理が行われていることを確認することにより、関連施設の物理的セキュリティを検証する。 　・層状の境界線管理および内部バリア 　・鍵へのアクセス管理 　・入退室記録 　・侵入者の警告に対する適切な対応計画
4.2 論理的アクセス	・機密データへのアクセスは、正当な必要性のあるユーザーのみに限定する。データ所有者はそのようなアクセスを承認しなければならない ・冗長なアカウントや期限切れのアクセス権を適時に無効化する ・知る必要性を検証するためにアクセスを定期的にレビューする
4.3 サブプロセッサー	・顧客データへのアクセス権を持つ第三者企業のリストを Web サイトで公開する ・このベースラインに照らして第三者企業を毎年評価する