Minimum Viable Secure Product Checklist

Minimum Viable Secure Product is a minimalistic security checklist for B2B software and business process outsourcing suppliers.

Designed with simplicity in mind, the checklist contains only those controls that must be implemented to ensure minimally viable security posture of a product.

We recommend that all companies building B2B software or otherwise handling sensitive information under its broadest definition implement at least the following controls, and are strongly encouraged to go well beyond them in their security programs.

1 Business controls
ControlDescription
1.1 Vulnerability reportsPublish the point of contact for security reports on your websiteRespond to security reports within a reasonable time frame
1.2 Customer testingOn request, enable your customers or their delegates to test the security of your applicationTest on a non-production environment if it closely resembles the production environment in functionalityEnsure non-production environments do not contain production data
1.3 Self-assessmentPerform annual (at a minimum) security self-assessments using this document
1.4 External testingContract a security vendor to perform annual, comprehensive penetration tests on your systems
1.5 TrainingImplement role-specific security training for your personnel that is relevant to their business function
1.6 ComplianceComply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18Comply 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 handlingNotify your customers about a breach without undue delay, no later than 72 hours upon discoveryInclude the following information in the notification:Relevant point of contactPreliminary technical analysis of the breachRemediation plan with reasonable timelines
1.8 Data sanitizationEnsure media sanitization processes based on NIST SP 800-88 or equivalent are implemented
2 Application design controls
ControlDescription
2.1 Single Sign-OnImplement single sign-on using modern and industry standard protocols
2.2 HTTPS-onlyRedirect 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 OCSPProduce a clear scan using a widely adopted TLS scanning toolInclude the Strict-Transport-Security header on all pages with the includeSubdomains directive
2.3 Content Security PolicySet a minimally permissive Content Security Policy
2.4 Password policyIf password authentication is used in addition to single sign-on:Do not limit the permitted characters that can be usedDo not limit the length of the password to anything below 64 charactersDo not use secret questions as a sole password reset requirementRequire email verification of a password change requestRequire the current password in addition to the new password during password changeVerify newly created passwords against common passwords lists or leaked passwords databasesCheck existing user passwords for compromise regularlyStore passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash functionEnforce appropriate account lockout and brute-force protection on account access
2.5 Security librariesUse 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 PatchingApply 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 LoggingKeep logs of:Users logging in and outRead, write, delete operations on application and system users and objectsSecurity 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 recoverySecurely back up all data to a different location than where the application is runningMaintain and periodically test disaster recovery plansPeriodically test backup restoration
2.9 EncryptionUse 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
ControlDescription
3.1 List of dataMaintain a list of sensitive data types that the application is expected to process
3.2 Data flow diagramMaintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored
3.3 Vulnerability preventionTrain 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 accountInsecure 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 injectionCross-site scripting. Examples: Calling insecure JavaScript functions, performing insecure DOM manipulations, echoing back user input into HTML without escapingCross-site request forgery. Example: Accepting requests with an Origin header from a different domainUse of vulnerable libraries. Example: Using server-side frameworks or JavaScript libraries with known vulnerabilities
3.4 Time to fix vulnerabilitiesProduce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery.
4 Operational controls
ControlDescription
4.1 Physical accessValidate the physical security of relevant facilities by ensuring the following controls are in place:Layered perimeter controls and interior barriersManaged access to keysEntry and exit logsAppropriate response plan for intruder alerts
4.2 Logical accessLimit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such accessDeactivate redundant accounts and expired access grants in a timely mannerPerform regular reviews of access to validate need to know
4.3 SubprocessorsPublish a list of third-party companies with access to customer data on your websiteAssess third-party companies annually against this baseline