Cloud Security

A NASA CTO Professes Faith in the Cloud

"I'll probably be hung for this, but I really believe the cloud can be more secure than what we do today," Soderstrom, chief technology officer at NASA's Jet Propulsion Laboratory, said in an interview with GovInfoSecurity.com. "Because based on more resources, they certainly have a lot of redundancy, and redundancy comes in all shapes and sizes. And, it's fairly uniformed, so if you apply a patch, you can apply it to everything at once."

In the second of a two-part interview, with GovInfoSecurity.com's Eric Chabrow, Soderstrom also addressed the:

• Challenges of negotiating contracts with cloud service providers,
• Knowledge gained by prototyping cloud projects and
• Value of involving the enterprise in cloud initiatives.

In part 1 of the interview, Soderstrom discussed the benefits the space agency realized from its cloud computing initiatives.

ERIC CHABROW: What are some of the drawbacks JPL faced in executing its cloud initiative?

TOM SODERSTROM: When you're an early explorer, and we do a lot of that, you have some unintended consequences, often good, sometimes bad and also unexpected obstacles. We truly expected the security to be the biggest obstacle, and it really was not because we could work around it. Our security team at JPL is very much in the mood of what do we do next and when. That has been a very possible experience.

I will probably be hung for this, but I really believe that the cloud can be more secure than what we do today because spend more resources, they have certainly a lot of redundancy, and redundancy comes in all shapes and sizes and it's fairly uniform so if you apply a patch, you can apply to everything at once. That is different than our internal data center. I believe it can be more secure at one point.

What we didn't expect was how difficult it would be for an institution that is used to negotiate individual contracts, to live with vendors, commodity vendor's paper. We had a really difficult time getting the license agreement signed with the big vendors like the Amazon and Apple for the iPhone, and things like that. It turned out to be an educational process of all of ours from anybody from the engineers to the procurement organizations to the lawyers, to the CIO. That took much longer than we had expected. Comparing stories with other enterprises, it is a very common challenge across industry. We're actually one of the first to get it done. We weren't particularly pleased with our progress. We thought we should have done it sooner, but it's done and it's working.

What we did learn is if we were to do it again, which we will, we would have everybody sit down in the room at the same time, all the stakeholders and say, here is what we're trying to do on the strategic side and we're just prototyping. We're not going to put any mission data in the cloud until we all agree that its ready, but in the meantime we want to prototype and move forward so let's get some of those agreements signed. I think that would have cut months off of the eventual time line.

CHABROW: And a couple of things here, one is just a concept of prototyping. You can see how things work before you get into a final agreement?

SODERSTROM: Yes, so there's three phases. There is prototyping, where you are really testing the waters. You haven't decided you are going to take this into operations yet. Think of it as a large funnel, lots of ideas, some of those ideas are worded to be prototype, quick results, quick measurements, but you need hands on experience. The second phase is piloting. When we pilot something we decide, we think this is worthy of going into operations. We're going to take it through its paces, but we expect it to be into operations one day. And then the third one is into operation. Each of those three stages cost successively more time and money. If you start with the piloting, you can only do a few. If you start with the prototyping, you can do many more because you really experimenting in getting hands on experience. But that has been a really good approach for us and that is one reason we have been able to do so many things.

Not everything was good, but we could let go of that pretty early and take the lessons learned and apply them to the next effort.

CHABROW: From a prospective like Amazon, where it was more time consuming than you thought, what were their objections? What did you want them to do that they were kind of reluctant?

SODERSTROM: Great question. If we want to take advantage of commodity hardware and software pricing, which is cheap, right? Commodity means volume means usually inexpensive. We need to figure out how to live with those end-user licensed agreements. We're used to negotiating back and forth because they are usually much larger procurements. The contract itself, if there was a disagreement, where would it be litigated and things like that. These are very different. When you rent a computer for a couple of hours, it is a very different thing than buying spacecraft components, and that is an area for all of enterprise industry to learn and try to understand. Get something going rather quickly so we can test it out, before we go to the next big stage. It is a learning experience. I'm not sure in the end that anything really changed, except fro the education on both sides. Amazon and the others learned a little bit more about how we think and what we worry about, and we learned what they think and worry about. Having that discussion had a more inclusive level upfront would have saved some time.

CHABROW: Is there any takeaway about IT security when it comes to a cloud that people should have from NASA's experience?

SODERSTROM: If I may be so bold as to give a few recommendations, I would say don't wait. Prototype now, try it now because then you will learn what IT security issues you have and then you can figure out which data you want to put in the cloud and not put in the cloud. So that would be one.

The reason we did the whole cloud experimentation that we did, is we could learn all the lessons and all the best practices from the outside and apply them on the inside if we needed to. So we could take those same lessons learned and apply them to a private cloud just as easily as we could to the public cloud, but not have to reinvent everything.

Another recommendation would be to make sure that the mission of the company is engaged. This is not an IT win, it's a business win. Whatever the business or organization is, so we don't use IT terms but we use business terms. In our case it is exploring space. I would get all those stakeholders together for the strategy session and that would include security. Which data do we feel comfortable putting in the cloud now and how can we protect it? How can we see if somebody is accessing it inappropriately, etc.? Maybe the biggest one of all is to partner. Partner with everyone who will engage with you, and that's been really good for us, both with the mission side and other IT-type partners, and the vendors themselves. I guess when everything is that new everybody is learning, but it has been a very good experience.

Also, we put some education events together here at JPL, so we had anything from high-level strategy sessions to innovation seminars, to IT innovation seminars across the lab to actually have a cloud day, first of many, where everybody at JPL comes and hears from the mission people what missions we have put into space and what were our lessons learned, and kind of get that dialog going. And then most of all is to be visible and have fun with it, because it has to have potential benefits and it is fun. It is exciting to be able to do things quicker than you could before and potentially at much less cost. The energy kind of creates more energy if you will.