SECURITY DOCUMENTATION

Our security strategy should be as comprehensive as possible. This means that we need to consider every piece of the application from top to bottom. Thus, I have diveded the strategy into three "verticals": dev/build, runtime/production, and infrastructure.

This documenmt is certainly incomplete. No system is unhackable and there will always be unkown vulnerabilities, attack surfaces, and bugs that we did not anticipate.

This might sound a little spooky, but information security is, at a fundamental level, an exercise in risk management. We have to make tradeoffs between time spent securing the application and time spent actualling developing new features. The tradeoffs we make should be informed by the amount of risk we are willing to accept.

But lets talk implementation. Presently, our development team should be focused on implementing three main solutions: endpoint protection, asset integrity, and infrastructure configuration.
These solutions don't fully cover all of the verticals. Instead they should be looked at as starting points. We should focus on implementing these things before we can reach satisfactory coverage of all three verticals.

In order to reduce our time to market for the kickstarter campaign, there will be a separate static version of a few pieces of the application that will be hosted on a managed delivery network. This minimizes attack surface and exposes only code that is deemed "safe" for public consumption.

Looking forward, the next key pieces of our strategy will be the build process and production monitoring/intrusion detection.

solutions

endpoint protection

• TODO

infrastructure configuration

• TODO

verticals

Another way of thinking of verticals is as attack surfaces. These are the points in the application that an attack can focus on

1. dev/build

The dev/build vertical covers the process of writing code, compiling it, and moving it to the staging environment.

network of trust

• build sources (signed commits to the production repo)
• build servers (connected to infrastructure)

notes

• frontend build process
  • minifications/obfuscation
  • Content Security Policy
  • javascript code should be moved out into .js files in production repo to remove unneccessary endpoints that need to be protected.
• backend verification process
  • code audit/checklist
    • PHP
      • vulnerabilities
        • XSS
        • CSRF
        • SQL Injection
        • cookie stealing
        • Session hijacking and fixation
        • file uploads
      • attack vectors
        • User authentication
        • Password reset tokens
      • solutions
        • Endpoint protection
          • every endpoint should be protected from malicious attempts to exploit it
          • this is probably the main vulnerability present in our application
        • Encypting and signing cookies
        • Securing uploaded files
        • Throttling brute-force attacks
        • Blacklisting IPs
  • vulnerability scanners
  • cryptographically signed commits/updates
  • automated test suite

2. runtime/production

The runtime/production vertical includes log files, application configuration, and asset integrity.

network of trust

• update approval
  • approval process details/steps
  • individuals authorized to approve updates and sign commits before deploying to production

notes

• testing
  • endpoints
    • unit tests
    • integration tests
    • end to end tests
  • application
    • penetration testing
    • stress testing
    • configuration verification
• software configuration
  • php
  • mysql
  • phpmyadmin
  • others?
• update verification
  • process that confirms that commits are approved and cryptographically signed
• assets
  • frontend
    • images
    • front end code
  • backend
    • database data

3. infrastructure

The infrastructure vertical covers physical (or virtual) servers that our application runs on in production, servers that we develop, stage, and build code on, and the networks we create for these different server to communicate with each other.

network of trust

• Trusted servers
• Infrastrucure access authorization
  • individuals
    • who has access to each of the different servers?
  • credentials
    • how do we manage access to the different servers?
    • how do we identify authorized network requests?
  • application secrets
    • what kind of secrets do we have?
      • database credentials
      • api keys
    • where are these secrets kept?
      • secret vault
      • NOT hardcoded

notes