Magellan Final Report - Office of Science - U.S. Department of Energy
Magellan Final Report - Office of Science - U.S. Department of Energy
Magellan Final Report - Office of Science - U.S. Department of Energy
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Magellan</strong> <strong>Final</strong> <strong>Report</strong><br />
Firewalls are a natural tool to protect sensitive infrastructure components from intrusion from unwanted<br />
address space. One <strong>of</strong> the first things done was to isolate the cloud, cluster, and node controller instances<br />
from the address space used by the virtual instances to protect infrastructure from everything except a small<br />
address space. It is also necessary to prevent spo<strong>of</strong>ing <strong>of</strong> infrastructure address space from the set <strong>of</strong> user<br />
initiated images, since the VM instances can create arbitrarily addressed network traffic.<br />
Another simple test is to scan public facing address space for unexpected ssh ports as well as exceptionally<br />
susceptible accounts (such as password-less root accounts). Mandating a full system scan before releasing a<br />
VM for public access was discussed and a method was proposed, but this method was not implemented on<br />
the <strong>Magellan</strong> deployment.<br />
Taking a closer look at user activities—both in terms <strong>of</strong> site security policy as well as machine readable<br />
logging—was another step in making the cloud systems more equivalent to our current batch systems.<br />
Enforcing local computer security policy on dynamic user-run virtual machine systems (such as Eucalyptus<br />
or EC2) is not something that traditional intrusion detection systems excel at, since they tend to be designed<br />
with fairly rigid notions <strong>of</strong> the mappings between systems, users, and addresses. To resolve this problem,<br />
we used data from two locations. First we used the EC2 branch <strong>of</strong> the Python Boto package (via euca2ools)<br />
to query the Cloud Controller for information about registered instances, IP addresses, users, and instance<br />
groups firewall rules. This provided a clean interface and data source for actively querying the Cloud<br />
Controller. The second source takes advantage <strong>of</strong> the Eucalyptus network architecture since all ingress/egress<br />
as well as intra-instance network traffic passes through a choke point on the cloud controller. The data for<br />
both cases was then processed by an instance <strong>of</strong> the Bro intrusion detection system. As already suggested,<br />
this provides two principal benefits. The first is the ability to express local site security policy by configuring<br />
a set <strong>of</strong> scripts we created for this purpose. The data from Bro helps track successful and failed logins, VM<br />
instantiation, inter-cluster scan detection, and rules about system firewall configurations. Once the local<br />
policy is defined, activities which violate that policy can be quickly identified and acted on. In addition, all<br />
activity was logged in a well defined format.<br />
8.2 Challenges Meeting Assessment and Authorization Standards<br />
While the technical aspects <strong>of</strong> computer security tend to gather the most attention, significant work is<br />
required to ensure that any large scale technology can be placed in the context <strong>of</strong> the current language found<br />
in Security Controls and Security Assessment and Authorization (A&A). Since any detailed interpretation<br />
<strong>of</strong> these documents is far outside the scope <strong>of</strong> this project, we will only discuss a few key points. Current<br />
best documentation involving cloud resources and security guidance is the FedRAMP [27] document, which<br />
covers three main areas:<br />
• List <strong>of</strong> baseline security controls for low and moderate impact cloud systems. NIST Special Publication<br />
800-53R3 provides the foundation for the development <strong>of</strong> these security controls.<br />
• Processes in which authorized cloud computing systems will be monitored continuously. This draft<br />
defines continuous monitoring deliverables, reporting frequency, and responsibility for cloud service<br />
provider compliance with the Federal Information Security Management Act.<br />
• Proposed operational approaches for assessment and authorization for cloud computing systems that reflect<br />
on all aspects <strong>of</strong> an authorization, including sponsorship, leveraging, maintenance, and continuous<br />
monitoring, a joint authorization process, and roles and responsibilities for federal agencies and cloud<br />
service providers. This is detailed under the risk management framework in NIST Special Publication<br />
800-37R1.<br />
Since a traditional HPC site will have covered a reasonable number <strong>of</strong> these controls in their regular<br />
A&A work, we will focus on a small number <strong>of</strong> unique issues presented by providers <strong>of</strong> cloud computing<br />
infrastructure.<br />
41