The 451 Group Grid security: ?

1. Nick Selby, Senior Analyst Director, Enterprise Security Practice The 451 GroupGrid security: ? OGF20 May 2007

2. The 451 Group • Technology industry analyst company • Agenda: enterprise IT innovation • Analysis that is timely; insight that is dynamic • Network of 700+ client organizations globally • Vendors • Investors • Bankers • Early-adopters OGF20 May 2007

3. OGF20 May 2007 EARN-IT: Early Adoption Research Network - IT • GARS - Grid Adoption Research Service • CAOS - Commercial Adoption of Open Source • ESP – Enterprise Security Practice • mobile, enterprise, networks, media, storage ....

4. OGF20 May 2007 Key Issues of Grid Security GARS Survey shows two key user sentiments regarding security on the Grid:

5. OGF20 May 2007 Key Issues of Grid Security GARS Survey shows two key user sentiments regarding security on the Grid: “We're not too concerned, because we're behind the firewall.”

6. OGF20 May 2007 Key Issues of Grid Security GARS Survey shows two key user sentiments regarding security on the Grid: “We're not too concerned, because we're behind the firewall.” “Security is a primary concern [of the CIO] when rolling out any grid deployment.”

7. OGF20 May 2007 Grid Security Questions Internal threats are an organizational and strategic issue. In measuring and balancing risks/returns, how does your organization see security? To what extent is security a 'Below the Waterline' item? Are you comfortable that you understand the key issues relating to security in an enterprise that runs a grid?

8. OGF20 May 2007 We asked users: What are the top-ten security concerns you consider when thinking about rolling out a new grid or application on a grid?

9. OGF20 May 2007 We asked hackers: You wish to mess with a grid: either break it, or steal code, or use it against itself, or run code of your own without getting caught - exactly how is unimportant. What are the first ten things you will do?

10. OGF20 May 2007 Users said.... 1 Support by third party vendors2 Segregation between UAT, Dev, Production (not always easy to match with the need to optimize resources usage)3 Security and monitoring agents implementation on Calculation Nodes: needed but generate overload and extra costs, significant with huge volume After that it is more operational security with things such as:4 How to survive a Datacenter loss with minimum impact ? 5 Agility to move an application from one Grid to another, with clear priority

11. OGF20 May 2007 Users said.... 1. Nature of the workload (batch or interactive)‏ 2. Credentials (authentication & entitlements) of the workload source 3. Source repository(s) of the input information 4. Credentials of the input sources 5. Destination repository for results 6. Credentials of destination 7. Nature of information being processed - for use in determining whether certain workloads can be co-mingled on the same grid 8. Logging of all activity related to the workload 9. General concerns about network security in the direct area the grid is deployed 10. General concerns about physical security (data center)‏

12. OGF20 May 2007 Users said.... (1) We are running only Linux and Solaris OS in our grid environment, the risk of intruders is low. S/W operating within the supported operating systems already implies a high level of security. (2) All applications run in separate area, writable for administrators, and from a limited number of hosts only. We do not support software requiring a fixed mount point (such as /usr or /opt) thus mixing up with OS applications. (3) This is a minor issue but we prefer applications using their own wrapper (in case of one installation for all operating systems). The alternative is writing a wrapper of our own, which we try to avoid. However, this is not a killing point.

13. OGF20 May 2007 Users said.... Usage of workstations as compute resources: Most of the users have administrative privileges to their workstations and that exposes all of the resources or software deployed on the Grid. Second concern is that the Grid User access rights provided by the Grid vendor are rudimentary. In other words, sometimes you have to give a User access to either everything or nothing. The vendors (DataSynapse in our case) are going to address this issue in the upcoming version which uses LDAP. The Grid software should also report (and alert if needed) unauthorized or unusual access patterns.

14. OGF20 May 2007 Hackers said.... - Examine the sandboxing mechanism and look for holes to get around its restrictions. Specifically I'm looking for ways to get to other user's (the bank, for instance) code and data, with data being a lot more important than the code. This is, in my opinion, the obvious angle to play from an attacker's perspective on a grid. Since we are all ultimately sharing the same resource (processing power) it makes sense to look for holes in the way the sandboxing is implemented. There are many different implementations, some based on software VMs such as Java and others in hypervisors like vmware / xen. In both cases there is enough complexity to warrant the existence of holes you can exploit.

15. OGF20 May 2007 Hackers said.... - Examine grid-specific APIs. Similar to the point above, the grid will probably provide services to its customers in the form of APIs to manage utilization automatically, or to access grid-specific services. This is another area where there's complexity and new code where exploitable holes might exist that lead to taking control of the grid's mgmt or to escape the restrictions of our sandbox. - Study the shared network access. Look for ways to read data (and potentially intercept and modify) in transit, as it travels from the grid to the user organization. Again, access to the network is also a shared resource where the grid has to implement proper segmentation to protect its users.

16. OGF20 May 2007 Hackers said.... - Look for vulnerabilities in the grid management application. While the sandboxing is the obvious target, it only enforces what the mgmt application says. If we can control the mgmt app then we may be able to play with resource allocation and maybe even access privileges. Additionally, the mgmt application probably also does user provisioning for the grid's users, a vulnerability here may give access to a user's credentials which we could later user to do whatever we want with his code and data. BTW, the interesting thing here is that this is not technologically groundbreaking stuff, but probably just about exploiting bugs in another web application and the underlying infrastructure. - In some specific scenarios it may be interesting for an attacker to prevent another application to get the cycles they need, causing a DoS situation.

17. OGF20 May 2007 Hackers said.... 1. Examine the network protocol of the grid agent for implementation flaws (aka, simple buffer overflows) 2. Look at the authentication mechanisms of the grid to see if its possible to easily inject code 3 Look at the grid management network and infrastructure, to see if that can be penetrated (typically with implementation flaws such as buffer overflows, but also from a standard network pentesting side) 4 Look at the cryptographics to see if they are used properly. 5 Look to see if the data on the wire can be copied or spoofed and how the grid software is updated over the network - perhaps there is a window of opportunity here

18. OGF20 May 2007 Hackers said.... 7 Look at replay attacks - can I have the node running code constantly and thereby wasting time/cycles? 8 Look to see how many compromised nodes would compromise the grid's results 9 Look at the way a new grid node is deployed 10 Look at what happens to a grid node on someone's laptop that leaves the secure perimeter

19. OGF20 May 2007 And you say? nick.selby@the451group.com Nick Selby Enterprise Security Practice 52 Broad St, 2nd Floor Boston, MA 02109 http://the451group.com/security