5d3adc6a7f
* [Documentation] Add initial security overview content Fixes #1833 * [Documentation] Outline security guide * [Documentation] Retitle Security Guide * [Documentation] Reformat security procedures * [Documentation] Flesh out security notes * [Documentation] Add references to Security Guide * [Documentation] Note role of static analysis https://github.com/nasa/openmct/pull/1900#pullrequestreview-93769470
4.7 KiB
Security Guide
Open MCT is a rich client with plugin support that executes as a single page web application in a browser environment. Security concerns and vulnerabilities associated with the web as a platform should be considered before deploying Open MCT (or any other web application) for mission or production usage.
This document describes several important points to consider when developing for or deploying Open MCT securely. Other resources such as Open Web Application Security Project (OWASP) provide a deeper and more general overview of security for web applications.
Security Model
Open MCT has been architected assuming the following deployment pattern:
- A tagged, tested Open MCT version will be used.
- Externally authored plugins will be installed.
- A server will provide persistent storage, telemetry, and other shared data.
- Authorization, authentication, and auditing will be handled by a server.
Security Procedures
The Open MCT team secures our code base using a combination of code review, dependency review, and periodic security reviews. Static analysis performed during automated verification additionally safeguards against common coding errors which may result in vulnerabilities.
Code Review
All contributions are reviewed by internal team members. External contributors receive increased scrutiny for security and quality, and must sign a licensing agreement.
Dependency Review
Before integrating third-party dependencies, they are reviewed for security and quality, with consideration given to authors and users of these dependencies, as well as review of open source code.
Periodic Security Reviews
Open MCT's code, design, and architecture are periodically reviewed (approximately annually) for common security issues, such as the OWASP Top Ten.
Security Concerns
Certain security concerns deserve special attention when deploying Open MCT, or when authoring plugins.
Identity Spoofing
Open MCT issues calls to web services with the privileges of a logged in user. Compromised sources (either for Open MCT itself or a plugin) could therefore allow malicious code to execute with those privileges.
To avoid this:
- Serve Open MCT and other scripts over SSL (https rather than http) to prevent man-in-the-middle attacks.
- Exercise precautions such as security reviews for any plugins or applications built for or with Open MCT to reject malicious changes.
Information Disclosure
If Open MCT is used to handle or display sensitive data, any components (such as adapter plugins) must take care to avoid leaking or disclosing this information. For example, avoid sending sensitive data to third-party servers or insecure APIs.
Data Tampering
The web application architecture leaves open the possibility that direct calls will be made to back-end services, circumventing Open MCT entirely. As such, Open MCT assumes that server components will perform any necessary data validation during calls issues to the server.
Additionally, plugins which serialize and write data to the server must escape that data to avoid database injection attacks, and similar.
Repudiation
Open MCT assumes that servers log any relevant interactions and associates these with a user identity; the specific user actions taken within the application are assumed not to be of concern for auditing.
In the absence of server-side logging, users may disclaim (maliciously, mistakenly, or otherwise) actions taken within the system without any way to prove otherwise.
If keeping client-level interactions is important, this will need to be implemented via a plugin.
Denial-of-service
Open MCT assumes that server-side components will be insulated against denial-of-service attacks. Services should only permit resource-intensive tasks to be initiated by known or trusted users.
Elevation of Privilege
Corollary to the assumption that servers guide against identity spoofing, Open MCT assumes that services do not allow a user to act with inappropriately escalated privileges. Open MCT cannot protect against such escalation; in the clearest case, a malicious actor could interact with web services directly to exploit such a vulnerability.
Additional Reading
The following resources have been used as a basis for identifying potential security threats to Open MCT deployments in preparation of this document: