opexxx · January 27, 2022 09:16
diff --git a/Minimum Viable Secure Product b/Minimum Viable Secure Product
 1 Business controls

 Control

 Description

 1.1 Vulnerability reports

 Publish the point of contact for security reports on your website

 Respond to security reports within a reasonable time frame

 1.2 Customer testing

 On request, enable your customers or their delegates to test the security of your application

 Test on a non-production environment if it closely resembles the production environment in functionality

 Ensure non-production environments do not contain production data

 1.3 Self-assessment

 Perform annual (at a minimum) security self-assessments using this document

 1.4 External testing

 Contract a security vendor to perform annual, comprehensive penetration tests on your systems

 1.5 Training

 Implement role-specific security training for your personnel that is relevant to their business function

 1.6 Compliance

 Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18

 Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses

 1.7 Incident handling

 Notify your customers about a breach without undue delay, no later than 72 hours upon discovery

 Include the following information in the notification:

 Relevant point of contact

 Preliminary technical analysis of the breach

 Remediation plan with reasonable timelines

 1.8 Data sanitization

 Ensure media sanitization processes based on NIST SP 800-88 or equivalent are implemented

 2 Application design controls

 Control

 Description

 2.1 Single Sign-On

 Implement single sign-on using modern and industry standard protocols

 2.2 HTTPS-only

 Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443)

 This does not apply to secure protocols designed to run on top of unencrypted connections, such as OCSP
 Produce a clear scan using a widely adopted TLS scanning tool

 Include the Strict-Transport-Security header on all pages with the includeSubdomains directive

 2.3 Content Security Policy

 Set a minimally permissive Content Security Policy

 2.4 Password policy

 If password authentication is used in addition to single sign-on:

 Do not limit the permitted characters that can be used

 Do not limit the length of the password to anything below 64 characters

 Do not use secret questions as a sole password reset requirement

 Require email verification of a password change request

 Require the current password in addition to the new password during password change

 Verify newly created passwords against common passwords lists or leaked passwords databases

 Check existing user passwords for compromise regularly

 Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function

 Enforce appropriate account lockout and brute-force protection on account access

 2.5 Security libraries

 Use frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs.

 Example: ORM for database access, UI framework for rendering DOM
 2.6 Dependency Patching

 Apply security patches with a severity score of "medium" or higher, or ensure equivalent mitigations are available for all components of the application stack within one month of the patch release

 2.7 Logging

 Keep logs of:

 Users logging in and out

 Read, write, delete operations on application and system users and objects

 Security settings changes (including disabling logging)

 Application owner access to customer data (access transparency)

 Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action. Logs must be stored for at least 30 days, and should not contain sensitive data or payloads.

 2.8 Backup and Disaster recovery

 Securely back up all data to a different location than where the application is running

 Maintain and periodically test disaster recovery plans

 Periodically test backup restoration

 2.9 Encryption

 Use available means of encryption to protect sensitive data in transit between systems and at rest in online data storages and backups

 3 Application implementation controls

 Control

 Description

 3.1 List of data

 Maintain a list of sensitive data types that the application is expected to process

 3.2 Data flow diagram

 Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored

 3.3 Vulnerability prevention

 Train your developers and implement development guidelines to prevent at least the following vulnerabilities:

 Authorization bypass. Example: Accessing other customers' data or admin features from a regular account

 Insecure session ID. Examples: Guessable token; a token stored in an insecure location (e.g. cookie without secure and httpOnly flags set)

 Injections. Examples: SQL injection, NoSQL injection, XXE, OS command injection

 Cross-site scripting. Examples: Calling insecure JavaScript functions, performing insecure DOM manipulations, echoing back user input into HTML without escaping

 Cross-site request forgery. Example: Accepting requests with an Origin header from a different domain

 Use of vulnerable libraries. Example: Using server-side frameworks or JavaScript libraries with known vulnerabilities

 3.4 Time to fix vulnerabilities

 Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery.

 4 Operational controls

 Control

 Description

 4.1 Physical access

 Validate the physical security of relevant facilities by ensuring the following controls are in place:

 Layered perimeter controls and interior barriers

 Managed access to keys

 Entry and exit logs

 Appropriate response plan for intruder alerts

 4.2 Logical access

 Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access

 Deactivate redundant accounts and expired access grants in a timely manner

 Perform regular reviews of access to validate need to know

 4.3 Subprocessors

 Publish a list of third-party companies with access to customer data on your website

 Assess third-party companies annually against this baseline

 src: https://mvsp.dev/mvsp.en/index.html
	1 Business controls

	Control

	Description

	1.1 Vulnerability reports

	Publish the point of contact for security reports on your website

	Respond to security reports within a reasonable time frame

	1.2 Customer testing

	On request, enable your customers or their delegates to test the security of your application

	Test on a non-production environment if it closely resembles the production environment in functionality

	Ensure non-production environments do not contain production data

	1.3 Self-assessment

	Perform annual (at a minimum) security self-assessments using this document

	1.4 External testing

	Contract a security vendor to perform annual, comprehensive penetration tests on your systems

	1.5 Training

	Implement role-specific security training for your personnel that is relevant to their business function

	1.6 Compliance

	Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18

	Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding Corporate Rules, and Standard Contractual Clauses

	1.7 Incident handling

	Notify your customers about a breach without undue delay, no later than 72 hours upon discovery

	Include the following information in the notification:

	Relevant point of contact

	Preliminary technical analysis of the breach

	Remediation plan with reasonable timelines

	1.8 Data sanitization

	Ensure media sanitization processes based on NIST SP 800-88 or equivalent are implemented

	2 Application design controls

	Control

	Description

	2.1 Single Sign-On

	Implement single sign-on using modern and industry standard protocols

	2.2 HTTPS-only

	Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443)

	This does not apply to secure protocols designed to run on top of unencrypted connections, such as OCSP
	Produce a clear scan using a widely adopted TLS scanning tool

	Include the Strict-Transport-Security header on all pages with the includeSubdomains directive

	2.3 Content Security Policy

	Set a minimally permissive Content Security Policy

	2.4 Password policy

	If password authentication is used in addition to single sign-on:

	Do not limit the permitted characters that can be used

	Do not limit the length of the password to anything below 64 characters

	Do not use secret questions as a sole password reset requirement

	Require email verification of a password change request

	Require the current password in addition to the new password during password change

	Verify newly created passwords against common passwords lists or leaked passwords databases

	Check existing user passwords for compromise regularly

	Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function

	Enforce appropriate account lockout and brute-force protection on account access

	2.5 Security libraries

	Use frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs.

	Example: ORM for database access, UI framework for rendering DOM
	2.6 Dependency Patching

	Apply security patches with a severity score of "medium" or higher, or ensure equivalent mitigations are available for all components of the application stack within one month of the patch release

	2.7 Logging

	Keep logs of:

	Users logging in and out

	Read, write, delete operations on application and system users and objects

	Security settings changes (including disabling logging)

	Application owner access to customer data (access transparency)

	Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action. Logs must be stored for at least 30 days, and should not contain sensitive data or payloads.

	2.8 Backup and Disaster recovery

	Securely back up all data to a different location than where the application is running

	Maintain and periodically test disaster recovery plans

	Periodically test backup restoration

	2.9 Encryption

	Use available means of encryption to protect sensitive data in transit between systems and at rest in online data storages and backups

	3 Application implementation controls

	Control

	Description

	3.1 List of data

	Maintain a list of sensitive data types that the application is expected to process

	3.2 Data flow diagram

	Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored

	3.3 Vulnerability prevention

	Train your developers and implement development guidelines to prevent at least the following vulnerabilities:

	Authorization bypass. Example: Accessing other customers' data or admin features from a regular account

	Insecure session ID. Examples: Guessable token; a token stored in an insecure location (e.g. cookie without secure and httpOnly flags set)

	Injections. Examples: SQL injection, NoSQL injection, XXE, OS command injection

	Cross-site scripting. Examples: Calling insecure JavaScript functions, performing insecure DOM manipulations, echoing back user input into HTML without escaping

	Cross-site request forgery. Example: Accepting requests with an Origin header from a different domain

	Use of vulnerable libraries. Example: Using server-side frameworks or JavaScript libraries with known vulnerabilities

	3.4 Time to fix vulnerabilities

	Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery.

	4 Operational controls

	Control

	Description

	4.1 Physical access

	Validate the physical security of relevant facilities by ensuring the following controls are in place:

	Layered perimeter controls and interior barriers

	Managed access to keys

	Entry and exit logs

	Appropriate response plan for intruder alerts

	4.2 Logical access

	Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access

	Deactivate redundant accounts and expired access grants in a timely manner

	Perform regular reviews of access to validate need to know

	4.3 Subprocessors

	Publish a list of third-party companies with access to customer data on your website

	Assess third-party companies annually against this baseline

	src: https://mvsp.dev/mvsp.en/index.html