OWASP Top Ten

Developers should be familiar with the OWASP Top 10 Web Applications Security Risks, and associated best practices to prevent or mitigate them. See also the OWASP Cheat Sheet Series.
This includes subjects such as, but are not limited to:

https://owasp.org/www-project-top-ten/

The OWASP foundation also regularly comes up with additional, specialized projects and top 10s, such as API Security, see the list of OWASP projects (some in flagship or labs status) for more.

Practices

All Magnolia engineers must adhere to the following practices: 


Logging  

  • Log events related to authentication (success or failure), use of privileged functions, administration activities, and system/component starts and stops. 
  • Log security-related events to a separate log file when possible. This provides developers with additional flexibility for any specific rules related to the log file (e.g., special roles/permissions, chain-of-custody, etc.). 
  • Limit information in the log details, especially if security events are commingled with other application events (e.g., do not log sensitive information). 
  • Use file-naming conventions (e.g., rotation, location, etc.) so the Location, Unit SIEM service, or InfoSec professional can ingest the logs. 
  • Store security-related logs separately from the application when possible. 
  • Establish monitoring/logging services of log files from the Location’s central security organization, Service Provider, Supplier, or Unit for Institutional Information classified at Protection Level 3 or higher or Availability Level 3 or higher. 
  • Ensure sufficient storage is available to maintain logs throughout the required retention period. 


TLS and Secure APIs 

  • Force HTTPS for all browser connections. 
  • Disable HTTP. 
  • Use a strict transport security header. 
  • Encrypt using a separate and unique credential for Institutional Information classified at Protection Level 3 or higher. 
  • Authenticate and encrypt the session when software involves the transmission of Institutional Information classified at Protection Level 3 or higher. 
  • Separate public and private application APIs and configure CORS (Cross-Origin Resource Sharing) headers to restrict invocation rights. 


Credentials/Passphrases 

  • Never store user passphrases. 
  • Protect service account credentials with established tools and techniques. 
  • Never hardcode credentials. 
  • Implement lockout after 5 failed authentication attempts. 
  • Use secure protocols for credentials or other secret exchanges (e.g., TLS 1.2 or later). 

Session and Logout 

  • Ensure that session timeout is implemented. 
  • Make sure session tokens are random and long (GUID long). 
  • Change (delete old and create new) tokens at each logon and each privilege escalation. 
  • Delete, remove and invalidate tokens on logout. 
  • Use TLS 1.2 or later for all session tokens and cookies. 
  • Provide a logout function. 
  • Prominently display the logout function throughout the application. 
  • Properly close records, delete temporary objects, and close operations on the server: 
    • As part of the logout process.
    • After a set period of inactivity (e.g., less than one hour).
    • After a browser window close. 

Federated Authentication / SAML / Shibboleth 

  • Assign permissions to user groups (not individual users). 
  • Assign users to user groups. 
  • Ensure the application has a user group with no/minimal privileges assigned. 
  • Assign or default new users to the user group with no/minimal privileges and make the assignment to a group explicit. 
  • Check/recheck authorization at the next logical operation (e.g., for web applications at the next page request). 
  • Log all actions that grant users or groups permissions or rights. 

File Management 

  • Prevent/disable directory traversal/directory listing. 
  • Filter web requests to block access to files with non-approved extensions (e.g., .dll, .config, .java, .cs, etc.). 
  • For IT Resources with Availability Level 3 or higher, set a directory quota or similar control. 
  • Ensure shared volumes/file shares have appropriate access restrictions limited to the application service account. 

Secure Configuration 

  • Use secure configuration options for supporting technology, libraries, packages, and tools. 
  • Perform or have performed a vulnerability scan of the entire solution and appropriately remediate findings based on risk before placing the solution into production. 

  • Secure the components used in an application. 

  • Run components with the least privilege possible. 
  • Keep components patched and up-to-date. 
  • Use vetted and tested hardening guides to ensure the correct application of options and settings. 
  • Define, implement and maintain secure settings (e.g., do not rely on default settings). 
  • Secure the software configuration used in an application. 
  • Set the configuration to define which HTTPS methods (e.g., Get or Post) the application will support and whether HTTPS methods will be handled differently on different pages of the application. 
  • Set Header and Content-Security-Policy when possible.

Documentation 

PD members developing functionalities with Protection Level 3 or higher or Availability Level 3 or higher must create project documentation to: 

  • Record the security features and steps taken to protect: 
    • Confidentiality concerns.
    • Integrity concerns.
    • Availability concerns. 
  • Track defects and fixes to defects. 
  • Note/record testing processes and how testing processes manage cyber risk. 
  • List components used and the security state of the components. 

Version Control 

All Code produced by Magnolia is stored in a centralized secured version control system (GIT) 

  • All deployments (test and production applications) are made from the version control system. 
  • Tag/label/branch versions so that they can be extracted at a later time. 
  • Version control systems are configured to strictly control access (read/write) and prevent and detect unauthorized access. 

Security Group of Interest

Magnolia also has a Security GoI that meets every week to discuss security questions, concerns, reports, testing, and best practices, in order to consolidate our knowledge base in that regard and address issues affecting our product proactively before they are reported by external parties. 

  • No labels