From 5d3adc6a7fb7a6e9c8555d0087929cb849562cff Mon Sep 17 00:00:00 2001 From: Victor Woeltjen Date: Fri, 2 Feb 2018 14:23:08 -0800 Subject: [PATCH] [Documentation] Add security guide (#1900) * [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 --- docs/src/guide/security.md | 121 +++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 docs/src/guide/security.md diff --git a/docs/src/guide/security.md b/docs/src/guide/security.md new file mode 100644 index 0000000000..c6c3b7a560 --- /dev/null +++ b/docs/src/guide/security.md @@ -0,0 +1,121 @@ +# 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)](https://www.owasp.org) +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](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). + + +## 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: + +* [STRIDE model](https://www.owasp.org/index.php/Threat_Risk_Modeling#STRIDE) +* [Attack Surface Analysis Cheat Sheet](https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet) +* [XSS Prevention Cheat Sheet](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)