The Consumerization of IT
It's an interesting time for IT and cybersecurity. We have more threats. We hear about breaches in large organizations like Sony and Google, but at the same time IT organizations are being asked to make themselves more like Google or Amazon, the so-called consumerization of IT.
So how do IT organizations become more open while being more protective? Are these goals mutually exclusive, or can security enhancements and governance models make risks understood and acceptable for more kinds of social, collaboration, mobile and cloud computing activities?
Listen to the podcast (24:03 minutes).
Here are some excerpts:
Dana Gardner: Raf, what comes in your mind when we say "consumerization of IT?"
Rafal Los: I think of the onslaught of consumer devices, from your tablets to your mobile handsets, that start to flood our corporate environments with their ever-popular music, photo-sharing, data-gobbling, and wireless-gobbling capabilities that just catch many enterprises completely unaware.
Gardner: Is this a good thing? The consumers seem to like it. The user thinks it's good productivity. I want to do things at the speed that I can do at home or in the office, but this comes with some risk, doesn't it?
Los: Absolutely, risk is everywhere. But you asked if it's a good thing. It's a good thing, depending on which platform you're standing on. From the consumer perspective, absolutely, it's a great thing. I can take my mobile device with me and have one phone, for example, on which I get my corporate email, my personal email on, and not have four phones in my pocket. I can have a laptop from my favorite manufacturer, whatever I want to use, bring into my corporate environment, take it home with me at night, and modify it however I want.
That's cool for the consumer, but that creates some very serious complexities for the enterprise security folks. Often you get devices that aren't meant to be consumed in an enterprise. They're just not built for an enterprise. There's no enterprise control. There's no notion of security on somebody's consumer devices.
Now, many of the manufacturers are catching up, because enterprises are crying out that these devices are showing up. People are coming after these big vendors and saying, "Hey, you guys are producing devices that everybody is using. Now they are coming up into my company, and it's chaos" But, it's definitely a risk, yes.
Gardner: What would a traditional security approach need to do to adjust to this? What do IT people need to think about differently about security, given this IT consumerization trend?
Los: We need to evolve. Over the last decade and a half or so, we've looked at information security as securing a castle. We've got the moat, the drawbridge, the outer walls, the center or keep, and we've got our various stages of weaponry, an armory and such. Those notions have been blown to pieces over the last couple of years as, arguably, the castle walls have virtually evaporated, and anybody can bring in anything, and it's been difficult.
Companies are now finding themselves struggling with how to deal with that. We're having to evolve from simply the ostrich approach where we are saying, "Oh, it's not going to happen. We're simply not going to allow it," and it happens anyway and you get breached. We have to evolve to grow with it and figure out how we can accommodate certain things and then keep control.
In the end, we're realizing that it's not about what you let in or what you don't. It's how you control the intellectual property in the data that's on your network inside your organization.
Gardner: So, do IT professionals in enterprises need to start thinking about the organizations differently? Maybe they're more like a service provider or a web applications provider than a typical bricks and mortar environment.
Los: That's an interesting concept. There are a number of possible ways of thinking about that. The one that you brought up is interesting. I like the idea of an organization that focuses less on the invasive technology, or what's coming in, and more on what it is that we're protecting.
From an enterprise security perspective, we've been flying blind for many years as to where our data is, where our critical information is, and hoping that people just don't have the capacity to plug into our critical infrastructure, because we don't have the capacity to secure it.
Now, that notion has simply evaporated. We can safely assume that we now have to actually go in and look at what the threat is. Where is our property? Where is our data? Where are the things that we care about? Things like enterprise threat intelligence and data storage and identifying critical assets become absolutely paramount. That's why you see many of the vendors, including ourselves, going in that direction and thinking about that in the intelligent enterprise.
Gardner: This is interesting. To use your analogy about the castle, if I had a high wall, I didn't need to worry about where all my stuff was. I perhaps didn't even have an inventory or a list. Now, when the wall is gone, I need to look at specific assets and apply specific types of security with varying levels, even at a dynamic policy basis, to those assets. Maybe the first step is to actually know what you've got in your organization. Is that important?
Los: Absolutely. There's often been this notion that if we simply build a impenetrable, hard, outer shell, the inner chewy center is irrelevant. And, that worked for many years. These devices grew legs and started walking around these companies, before we started acknowledging it. Now, we've gotten past that denial phase and we're in the acknowledgment phase. We've got devices and we've got capacity for things to walk in and out of our organization that are going to be beyond my control. Now what?
Well, the logical thing to do is not to be reactionary about it and try to push back and say that can't be allowed, but it should be to basically attempt to classify and quantify where the data is? What do we care about as an organization? What do we need to protect? Many times, we have these archaic security policies and we have disparate systems throughout an organization.
We've shelled out millions of dollars in our corporate hard-earned capital and we don't really know what we're protecting. We've got servers. The mandate is to have every server have anti-virus and an intrusion prevention system (IPS) and all this stuff, but where is the data? What are you protecting? If you can't answer that question, then identifying your data asset inventory is step one. That's not a traditional security function, but it is now, or at least it has to be.
Gardner: I suppose that when we also think about cloud computing, many organizations might not now be doing public cloud or hybrid cloud, but I don't think it's a stretch to say that they probably will be some day. They're definitely going to be doing more with mobile. They're going to be doing more with cloud. So wouldn't it make sense to get involved with these new paradigms of security sooner rather than later? I think the question is really about being proactive rather than reactive.
Los: The whole idea of cloud, and I've been saying this for a while, is that it's not really that dramatic of a shift for security. What I said earlier about acknowledging the fact that our preconceived notions of defending the castle wall has to be blown apart extrapolates beautifully into the cloud concept, because not only is it that data is not properly identified within our "castle wall," but now we're handing it off to some place else.
What are you handing off to some place else? What does that some place else look like? What are the policies? What are the procedures? What's their incident response? Who else are you sharing with? Are you co-tenanting with somebody? Can you afford downtime? Can you afford an intrusion? What does an intrusion mean?
This all goes back to identifying where your data lives, identifying and creating intelligent strategies for protecting it, but it boils down to what my assets are. What makes our business run? What drives us? And, how are we going to protect this going forward?
Gardner: Now thinking about data for security, I suppose we're now also thinking about data for the lifecycle for a lot of reasons about storage efficiency and cutting cost. We're also thinking about being able to do business intelligence (BI) and analytics more as a regular course of action rather than as a patch or add-on to some existing application or dataset.
Is there a synergy or at least a parallel track of some sort between what you should be doing with security, and what you are going to probably want to be doing with data lifecycle and in analytics as well?
Los: It's part-and-parcel of the same thing. If you don't know what information your business relies on, you can't secure it and you can't figure out how to use it to your competitive advantage.
I can't tell you how many organizations I know that have mountains and mountains and mountains of storage all across the organization and they protect it well. Unfortunately, they seem to ignore the fact that every desktop, every mobile device, iPhone, BlackBerry, WebOS tablet has a piece of their company that walks around with it. It's not until one of these devices disappears that we all panic and ask what was on that. It's like when we lost tape. Losing tapes was the big thing, as was encrypting tapes. Now, we encrypt mobile devices. To what degree are we going to go and how much are we going to get into how we can protect this stuff?
BI is not that much different. It's just looking at the accumulated set of data and trying to squeeze every bit of information out of it, trying to figure out trends, trying to find out what can you do, how do you make your business smarter, get to your customers faster, and deliver better. That's what security is as well. Security needs to be furthering and enabling that cause, and if we're not, then we're doing it wrong.
Gardner: Based on what you've just said, if you do security better and you have more comprehensive integrated security methodology, perhaps you could also save money, because you will be reducing redundancy. You might be transforming and converging your enterprise, network, and data structure. Do you ever go out on a limb and say that if you do security better, you'll save money?
Los: Coming from the application security world, I can cite the actual cases where security done right has saved the company money. I can cite you one from an application security perspective. A company that acquires other companies all of a sudden takes application security seriously. They're acquiring another organization.
They look at some code they are acquiring and say, "This is now going to cost us X millions of dollars to remediate to our standards." Now, you can use that as a bargaining chip. You can either decrease the acquisition price, or you can do something else with that. What they started doing is leveraging that type of value, that kind of security intelligence they get, to further their business costs, to make smarter acquisitions. We talk about application development and lifecycle.
There is nothing better than a well-oiled machine on the quality front. Quality has three pillars: does it perform, does it function, and is it secure? Nobody wants to get on that hamster wheel of pain, where you get all the way through requirements, development, QA testing, and the security guys look at it Friday, before it goes live on Saturday, and say, "By the way, this has critical security issues. You can't let this go live or you will be the next ..." -- whatever company you want to fill in there in your particular business sector. You can't let this go live. What do you do? You're at an absolutely impossible decision point.
So, then you spend time and effort, whether it's penalties, whether it's service level agreements (SLAs), or whether it's cost of rework. What does that mean to you? That's real money. You could recoup it by doing it right on the front end, but the front end costs money. So, it costs money to save money.
Gardner: Okay, by doing security better, you can cut your risks, so you don't look bad to your customers or, heaven forbid, lose performance altogether. You can perhaps rationalize your data lifecycle. You can perhaps track your assets better and you can save money at the same time. So, why would anybody not be doing better security immediately? Where should they start in terms of products and services to do that?
Los: Why would they not be doing it? Simply because maybe they don't know or they haven't quite haven't gotten that level of education yet, or they're simply unaware. A lot of folks haven't started yet because they think there are tremendously high barriers to entry. I'd like to refute that by saying, from a perspective of an organization, we have both products and services.
We attack the application security problem and enterprise security problem holistically because, as we talked about earlier, it's about identifying what your problems are, coming up with a sane solution that fits your organization to solve those problems, and it's not just about plugging products in.
We have our Security Services that comes in with an assessment. My organization is the Application Security Group, and we have a security program that we helped build. It's built upon understanding our customer and doing an assessment. We find out what fits, how we engage your developers, how we engage your QA organization, how we engage your release cycle, how we help to do governance and education better, how we help automate and enable the entire lifecycle to be more secure.
It's not about bolting on security processes, because nobody wants to be invasive. Nobody wants to be that guy or that stands there in front of a board and says "You have to do this, but it's going to stink. It's going to make your life hell."
We want to be the group that says, "We've made you more secure and we've made minimal impact on you." That's the kind of things we do through our Fortified Application Security Center group, static and dynamic, in the cloud or on your desktop. It all comes together nicely, and the barrier to entry is virtually eliminated, because if we're doing it for you, you don't have to have that extensive internal knowledge and it doesn't cost an arm and a leg like a lot people seem to think.
I urge people that haven't thought about it yet, that are wondering if they are going to be the next big breach, to give it a shot, list out your critical applications, and call somebody. Give us a call, and we'll help you through it.
Gardner: HP has made this very strategic for itself with acquisitions. We now have the ArcSight, Fortify and TippingPoint. I have been hearing quite a bit about TippingPoint here at the show, particularly vis-a-vis the storage products. Is there a brand? Is there an approach that HP takes to security that we can look to on a product basis, or is it a methodology, or all of the above?
Los: I think it's all of the above. Our story is the enterprise security story. How do we enable that Instant-On Enterprise that has to turn on a dime, go from one direction strategically today? You have to adapt to market changes. How does IT adapt, continue, and enable that business without getting in the way and without draining it of capital.
If you look around the showroom floor here and look at our portfolio of services and products, security becomes a simple steel thread that's woven through the fabric of the rest of the organization. It's enabling IT to help the CIO, the technology organization, enable the business while keeping it secure and keeping it at a level of manageable risk, because it's not about making it secure. Let me be clear. There is no secure. There is only manageable risk and identified risk.
If you are going for the "I want to be secure thing," you're lost, because you will never reach it. In the end that's what our organizational goal is. As Enterprise Security we talk a lot about risk. We talk a lot about decreasing risk, identifying it, helping you visualize it and pinpoint where it is, and do something about it, intelligently.
Gardner: Is there new technology that's now coming out or being developed that can also be pointed at the security problem, get into this risk reduction from a technical perspective?
Los: I'll cite one quick example from the software security realm. We're looking at how we enable better testing. Traditionally, customers have had the capability of either doing what we consider static analysis, which is looking at source code and binaries, and looking at the code, or a run analysis, a dynamic analysis of the application through our dynamic testing platform.
One-plus-one turns out to actually equal three when you put those two together. Through these acquisition's and these investments HP has made in these various assets, we're turning out products like a real-time hyperanalysis product, which is essentially what security professionals have been looking for years.
It's looking at when an application is being analyzed, taking the attack or the multiple attacks, the multiple verifiable positive exploits, and marrying it to a line of source code. It's no longer a security guide doing a scan, generating a 5,000-page PDF, lobbing it over the wall at some poor developer who then has to figure it out and fix it before some magical timeline expired. It's now a collaborative effort. It's people getting together.
One thing that we find broken currently with software development and security is that development is not engaged. We're doing that. We're doing it in real-time, and we're doing it right now. The customers that are getting on board with us are benefiting tremendously, because of the intelligence that it provides.
Gardner: So, built for quality, built for security, pretty much ... synonymous?
Los: Built for function, built for performance, built for security, it's all part of a quality approach. It's always been here, but we're able to tell the story even more effectively now, because we have a much deeper reach into the security world If you look at it, we're helping to operationalize it by what you do when an application is found that has vulnerabilities.
The reality is that you're not always going to fix it every time. Sometimes, things just get accepted, but you don't want them to be forgotten. Through our quality approach, there is a registry of these defects that lives on through these applications, as they continue to down the lifecycle from sunrise to sunset. It's part of the entire application lifecycle management (ALM) story.
At some point, we have a full registry of all the quality defects, all the performance defects, all the security defects that were found, remediated, who fixed them, and what the fixes were? The result of all of this information, as I've been saying, is a much smarter organization that works better and faster, and it's cheaper to make better software.