DOCSEARCHbyAlgolia
Submit Docs

Minimum Viable Secure Product (MVSP)

repository·master·Indexed 42 days ago

https://github.com/vendorsec/mvsp

A minimalistic application security baseline for enterprise-ready products, providing a concise checklist of business, application design, application implementation, and operational controls. The project also provides machine-readable OSCAL (Open Security Controls Assessment Language) content for NIST SP 800-53 Revision 4 and Revision 5 in XML, JSON, and YAML formats to support automated security assessments and compliance mapping.

Tokens
10.8K
Snippets
5
Records
52
Agent score
52%

What's inside MVSP

  1. What is Minimum Viable Secure Product (MVSP)?

    master
    MVSP is a minimum application security baseline designed for enterprise-ready products and services. It provides a concise checklist of application security controls that can be applied throughout the sales cycle, from the initial Request for Proposal (RFP) stage to final contractual agreements. For a detailed reading of the baseline, visit mvsp.dev.

  2. Access NIST SP 800-53 OSCAL content

    master
    This repository provides machine-readable OSCAL (Open Security Controls Assessment Language) content for NIST Special Publication 800-53. The content is available in XML, JSON, and YAML formats to support different tooling stacks. These files are designed to faithfully represent control-related content from published NIST documents.

  3. What is the Minimum Viable Secure Product (MVSP)?

    master
    The Minimum Viable Secure Product (MVSP) is a framework consisting of essential application security controls designed for enterprise-ready products and services. It provides a foundational set of controls to help companies building software or handling sensitive information build secure and resilient systems. The controls are categorized into four main domains: Business controls, Application design controls, Application implementation controls, and Operational controls.

  4. Comparing MVSP to traditional security standards

    master

    MVSP is designed as a flexible, lightweight alternative to heavy compliance frameworks.

    FeatureMVSPTraditional Standards (ISO, SOC 2, PCI DSS, CAIQ-Lite)
    CostFree (Creative Commons)Often expensive to implement and maintain
    ComplexitySimple, baseline controlsBroad and often difficult to apply internally
    Audit RequirementsNo mandatory regular auditsRequire regular, time-consuming audits
    Usage RestrictionsNo restrictions on useStrict compliance and reporting requirements
    Data PrivacyNo requirement to share dataOften involves sharing data with auditors/third parties

  5. Understand Minimum Viable Secure Product (MVSP) Control Categories

    master

    The MVSP baseline is organized into four primary control categories that define the security posture of a product or service:

    1. Business controls: Focus on organizational processes such as vulnerability reporting, customer testing, self-assessments, external testing, training, compliance, incident handling, and data sanitization.
    2. Application design controls: Focus on technical implementation patterns like Single Sign-On (SSO), HTTPS-only enforcement, Content Security Policy (CSP), password policies, use of security libraries, patching, logging, disaster recovery, and encryption at rest.
    3. Application implementation controls: Focus on documentation and developer practices, including maintaining a list of data types, data flow diagrams, vulnerability prevention training, and timely vulnerability remediation.
    4. Operational controls: Focus on access management, including physical security of data centers, logical access (least privilege), and the security validation of third-party subprocessors.

  6. Understand SP 800-53 Part and Property schemas in OSCAL

    master

    When consuming OSCAL files for SP 800-53, the following schema elements are used to structure control data:

    Control Parts

    Controls are composed of several part elements identified by the @name attribute:

    • statement: The primary text of the control.
    • guidance: Implementation or advisory guidance.
    • objective: Specific goals or requirements.
    • assessment: Information related to assessing the control.
    • object: The target of the control.

    Properties

    Properties are defined via prop elements with specific @name values:

    • label: Provides the 'name' or 'number' of the control, enhancement, or component part (e.g., AC-3). These are derived from data and expanded into full values.
    • method: Describes the method associated with the property.
    • status: Indicates the lifecycle state. A value of Withdrawn is used specifically for controls/subcontrols designated as withdrawn from earlier versions of SP 800-53.

  7. Understand the purpose and scope of MVSP

    master

    MVSP (Minimum Viable Secure Product) is a basic framework and minimum checklist designed to serve as a stepping stone for security assessments.

    Key Characteristics:

    • Focus: Unlike enterprise-wide standards (like ISO), MVSP focuses specifically on the security of applications. It is intended to be applied to a single application or service rather than an entire company.
    • Goal: It fills the void in standardized RFPs and contractual language by providing a low-effort signal for risk management processes.
    • Not a Replacement: It is not intended to replace comprehensive standards like SOC2. If a more stringent standard (like SOC2) meets your needs, you should use that instead.
    • Simplicity: It is a straightforward baseline where controls are typically marked as either 'met' or 'not met', without requiring the collection of complex audit artifacts.

  8. Use the SP 800-53 ID protocol for canonical identifiers

    master

    Elements in the SP 800-53 catalog have unique id attributes derived from their labels. These IDs are systematic and can be used as canonical identifiers, but they are 'sticky' across versions. To ensure absolute uniqueness, combine the element id with the catalog/@id value.

    ID Transformation Rules

    Parenthetical Notation

    Parentheses in labels are converted to dot (.) delimiters and the entire string is lowercased.

    • Example: AC-3(1) $\rightarrow$ ac-3.1

    Mixed Parentheses and Brackets

    When labels combine parentheses and brackets (common in 'objective' elements), the segments are separated by dots to facilitate matching objectives to statements.

    • Example: AC-3(3)[6](b)(3)[a] $\rightarrow$ ac-3.3.b.3_obj.6.a
      • Matches statement: AC-3(3)(b)(3)
      • Matches objective: [6][a]

  10. Interpret Link elements and 'rel' attributes in SP 800-53

    master

    Link elements in the SP 800-53 OSCAL files are used for implicit/explicit links or inferred relationships. The rel attribute defines the relationship type:

    • rel="related": Indicates related controls (explicitly provided in source).
    • rel="reference": Indicates a citation of a reference (explicitly provided in source).
    • rel="corresp": Shows where a control or enhancement objective corresponds to an item in its statement.
    • rel="incorporated-into": Used on Withdrawn controls/enhancements to indicate the superseding controls.

    Validation Note: Internal links (where href starts with #) are validated against existing id values in the document.

  11. Implement Application Design Controls

    master

    To meet MVSP application design requirements, implement the following technical controls:

    • 2.1 Single Sign-On (SSO): Offer customers the option to use federated identity providers for centralized account control and reduced credential exposure.
    • 2.2 HTTPS-only: Encrypt sensitive data in transit. Use Strict-Transport-Security (HSTS) and ensure cookies use the Secure flag.
    • 2.3 Security Headers: Implement browser protections like Content-Security-Policy (CSP) to mitigate XSS and framing vulnerabilities.
    • 2.4 Password policy: For non-SSO authentication, enforce strong password policies (no arbitrary length/charset limits, but encourage lower bounds). Support password managers and copy-pasting. Use memory-hard or CPU-hard one-way hashes (salted) for storage. Avoid relying solely on security questions for resets.
    • 2.5 Security libraries: Standardize on established, tested security libraries and frameworks to prevent implementation weaknesses.
    • 2.6 Dependency Patching: Maintain up-to-date components. Use regular vulnerability scanning and ensure security patches are deployed within a reasonable timeframe. Treat end-of-life (EOL) libraries as unpatched.
    • 2.7 Logging: Store detailed logs for debugging and incident response. Record both failed and successful logins. Warning: Do not log sensitive information like passwords or credentials. Ensure logs are retained for an extended period.
    • 2.8 Encryption: Encrypt sensitive data at rest. Manage cryptographic keys securely (secure generation, storage, and deletion) and ensure secret keys are never accessible in source code.

  12. Review Business Controls for MVSP Compliance

    master

    The MVSP baseline includes several business-level controls designed to manage security processes and external communications. Key controls include:

    • 1.1 Vulnerability reports: Establish processes to accept and process security issue reports from external parties.
    • 1.2 Customer testing: Provide customers with a designated, non-production test environment (replicating production but using non-production data) for security testing. Testing should be performed without blocking technologies like WAF or IDS.
    • 1.3 Self-assessment: Perform annual reviews of the security program against the MVSP baseline to identify gaps.
    • 1.4 External testing: Schedule and perform independent third-party penetration testing at least once per year.
    • 1.5 Training: Provide regular security awareness training (e.g., data handling, reporting suspicious activities, phishing response).
    • 1.6 Compliance: Identify and complete relevant industry-specific compliance obligations.
    • 1.7 Incident handling: Implement processes for smooth incident handling, including an initial notification to customers within 72 hours of discovery.
    • 1.8 Data handling: Ensure appropriate sanitization of data on removable or decommissioned hardware.