E/OpenStack Threat analysis

OpenStack Vulnerability and Threat Analysis

OpenStack currently has a reactive process for dealing with security issues. A vulnerability team takes reports of security vulnerabilities from developers and users and issues alerts identifying those to the OpenStack community. A more proactive approach could help to reduce the number of reported vulnerabilities and, perhaps more importantly, avoid potentially severe security issues that are not identified and result in a serious incident.

This proposal is to start a threat analysis evaluation of the OpenStack system components. A threat analysis takes a comprehensive look at the system at hand – components, protocols and code - against the existence and capability of an adversary looking for known vulnerabilities. When a threat is identified, it is tallied and reported to the development team. In some cases, the threat analysis team may also include a suggestion to fix the vulnerabilities and related threat. According to our view, the threat analysis of OpenStack components can proceed in three steps:

1. A brief discussion within the OpenStack community regarding the threat analysis process and methodology, in the light of current best security practice. The intent of this phase is to ensure that everyone understands the process, since by its nature a threat analysis can seem adversarial (it is after all looking for vulnerabilities an adversary might take advantage of).
2. Apply the result of (1) to an OpenStack service. We propose to start the threat analysis with Keystone, since it is a critical security component of OpenStack and an obvious target for an adversary to attack.
3. Depending on the results of (2), i.e. which threats are found, produce a blueprints to address the most urgent threats (e.g., by patching the vulnerabilities, process improvement, or design improvement). An additional outcome might be to institute some kind of required security review for projects prior to their inclusion into the OpenStack core. This will ensure that future services included in the OpenStack code base do not open up serious vulnerabilities

While the details of the analysis methodology needs to be discussed among the community members, we can expect that two types of threats will be encountered based on the vulnerabilities of the system:

1. High-level logical design issues, e.g. component interaction with varying trust boundaries, failure to authenticate/authorize certain requests, sub-optimal protocol flows leading to venues for denial-of-service attacks, etc.
2. Lower level implementation issues such as failure to check inputs, buffer overruns, etc.

Thus, we envision that analysis is needed both on logical protocol and API level, as well as code analysis (at least for security critical parts). Two main types of work can be expected:

1. Manual analysis of protocols and selected (e.g. security critical) code segments. This may possibly require creation of additional design documentation in case existing documentation is too meager.
2. Use of automated security test tools and SW verification tools for vulnerability identification.

Depending on the success of the first service (i.e., Keystone), we expect the threat analysis process to be an ongoing activity, which covers core OpenStack services.