Difference between revisions of "Valence Threat Model"

Latest revision as of 10:55, 10 January 2017

Valence

Valence is a collection of functionality to ease consuming disaggregated rack resources, compute, storage, and network that are accessible via the DMTF Redfish RESTful API, to launch a cloud and dynamically grow/shrink an OpenStack cloud. The Redfish API is implemented, in our case, by Intel Rack Scale Design PodManager. The functionality is exposed to registered users.

Valence is composed of 3 components, a Web-UI, An API + Controller component, and a collection of plugins for OpenStack that shall allow dynamic grow/shrink of an OpenStack cloud. In the above figure, these are to the extreme left, colored in green and boxed with “Valence” label.

Valence assets

• Web UI -- application that provides the graphical user interface

HTML, javascript, style sheets associated with the Web application

• An API Server and Controller component that is comprised of:

API server that provides a RESTful interface to compose and decompose nodes and list them

1. A Controller component that makes the appropriate backend calls to the Rack Controller implementation using Redfish REST API calls, authenticates users, manages user quotas, and more
2. A database to track registered users, user quotas, allocation of resources, hardware flavors and more.
3. Connection credentials and address to the Rack Controller,, which controls the rack scale resource pool. Connection details could be provided in a config file or obtained and stored from form input data.

• OpenStack Plugins that essentially shall enable an existing cloud, if configured to do so, to acquire and release resources from a disaggregated pool of resources. In particular these plugins will allow OpenStack/nova to add/release compute hosts, OpenStack/ironic to add/release bare metal nodes, and OpenStack/horizon. This aspect as it evolves will be covered by a separate security review.

The composed nodes are used to float a cloud using a deployment tool such as Fuel, Kolla, or other. In the crawl phase, the cloud is static in size/capacity. The OpenStack plugins will be developed in a future phase to allow dynamic addition and release of nodes into an existing OpenStack cloud and will need logic to first determine that the node is not in use.

Threat Summary

Standard threat surface and handling mechanisms as with any web application and database. Below we present an architecture overview, threat details and countermeasures to protect from the same.

Chief Web server threats:

• Profiling
• Denial of service
• Unauthorized access
• Arbitrary code execution
• Elevation of privileges
• Viruses, worms, and Trojan horses

Chief Database threats:

• SQL injection
• Network eavesdropping
• Unauthorized server access
• Password cracking

Web UI - Design and deployment strategy'

   The Web UI application will consist of static pages and  dynamic content generated using scripts (React) and making calls to the API by code (such as list of available node flavors, list of composed nodes etc)

1. Web Application running with least privilege possible, so threats from privilege escalation reduced.
2. Its files and executables owned and accessible only by the web application (no group or world read)
3. To prevent arbitrary code injection, all user input to be sanitized (length of input, neutralizing scripting content before executing or saving in database, example > converted to > etc). Cross site scripting
4. Will be logging all accesses to aid in any forensics.
5. Returning an error message for url paths that are anything but to the application, such as “/” and “../” to prevent access to other resources on the system.
6. Opening only port 443 for https access and closing all others (if no other desired processes running on the host) to reduce vulnerability
7. Uses post as opposed to get/url for passing all credentials
8. Host machine protection cover more in detail in the API+Controller section below

API + Controller - Design and deployment strategy

1. RESTful API
2. Network access -- prevent man in the middle attacks and snooping by making the application accessible only securely ( HTTPS/TLS, installing certificate). Using a firewall.
3. Using post to carry all credentials (versus in the url as with get)
4. User registration requirements - strong passwords. Shall be saved hashed in the database (discussed later)
5. Provide a configuration parameter that allows us to enable/disable log level.
6. Logs not to leak usernames/passwords -- replacing them in logs with fixed length constant string.
7. Host Machine protection

• Protect from denial of service with iptables rules (number of incoming connection requests accepted in some time window, which IP addresses, protocols etc)
• Preventing bad actor access -- use of sudo during maintenance operations, removal of unnecessary accounts. Shall retain any password policy on other hosts in cloud system for uniformity.
• Reducing vulnerability via installing only required software and daemons. https://msdn.microsoft.com/en-us/library/ff648653.aspx.
• Have in place a process/mechanism to apply applicable security patches on the host. Where security patches become part of the Linux kernel or other software package, they shall be recorded as version dependencies in the code base to prevent regressions.
• Turn off unwanted protocols, ports, Netbios, SMB etc (protects from profiling attacks), that is ICMP -- no fodder for port scans, ping sweeps etc http://www.softpanorama.org/Net/Transport_layer/hardening_tcp_stack_in_linux.shtml

Database - Data persistence for Controller

1. Database to be accessed only from the IP of the API+Controller server. IP addresses can be spoofed, but as a first step in the right direction is to limit access to the database machine using an IPTable rule that allows access to the same from only limited machines.
2. Host machine protection same as in API+Controller

Accessing Pod-Manager REST API Service

Pod-Manager has already undergone security review. Use configured credentials to access from the Web UI the Pod-Manager. Should the two applications be running on the same machine all the above Host protections apply. Should they be on a separate servers, we anticipate the machines will be in a private network and adequately protected via firewalls from the public network.

Plugins - OpenStack

To enable the dynamic grow/shrink of a cloud, we shall be enabling cloud admin only enabled calls into the Valence Restful APIs. While the plugins do not affect Valence security, by their inclusion in OpenStack and other cloud solutions, shall affect the attack surfaces therein. The plugins and client handles shall be covered in a separate security review as they evolve.

Some examples of OpenStack plugins: .

1. A Valence-client that uses the configured credentials and proxies calls into the Valence API/Controller component.
2. A Redfish driver/plugin in Ironic to control/manage a composed node that in turn leverages the Valence-client.
3. Usage monitoring rules that trigger admin-only approved or automated actions that grow/shrink a cloud, which may make calls for cloud “shrink” that evacuates a host and then power-offs a node, followed by a release node, while for “grow” composes a node of the desired hardware flavor, deploys the required image on the same and finally registers it with the cloud to host cloud workloads.