The next
BriefingsDirect discussion explores improving
cyber security
in applications across their entire lifecycles. Such trends as the
Internet of Things (IoT),
hybrid cloud services,
mobile-first, and
DevOps
are increasing the demands and complexity of the overall development
process.
Key factors to improving both development speed and security despite these new challenges
include new levels of collaboration and communication across formerly
disparate teams -- from those who design, to coders, to testers, and on
to continuous monitoring throughout operations. The result is security being integrated into software design, even as the pressure builds to
bring more apps to market faster.
We're here now with two experts from a
Capgemini and Hewlett Packard Enterprise (HPE) Alliance
to learn how to create the culture, process, and technologies needed to
make and keep today's applications as secure as possible.
Please join me now in welcoming our guests,
Gopal Padinjaruveetil, Global Cyber Security Strategist for
Capgemini, and
Mark Painter, Security Evangelist at Hewlett Packard Enterprise. The discussion is moderated by me,
Dana Gardner, Principal Analyst at
Interarbor Solutions.
Here are some excerpts:
Gardner:
Let’s start with you Gopal. What do you see as some of the top trends
that are driving the need for improved security for applications? It
seems like we're in the age of "continuous everything" across the entire
spectrum of applications.
Padinjaruveetil: Let me talk about a few trends with some data and focus on why application security is going to become more-and-more important as we move forward.
There's a report saying that there will be 50 billion connected devices by 2020. There was also a
Cisco report that said that 92 percent of the devices today, connected devices, are vulnerable. There was an HPE study that came out last year said that 80 percent of the attacks are now happening at the application layer.
If you put together these three diverse data points coming from three different people, we see that there will be 37 billion devices in 2020 that are deemed to be vulnerable. That’s very interesting, 37 billion devices vulnerable in 2020. We need to change the way that we develop software.
Key trend
The other key trend that we're seeing is that agility is becoming a prime driver in application development, where the business would like to have functionality as early as possible. So the whole
agile development methodology driving agility is becoming key, and that's posing some unique problems.
The other thing that we're seeing from a trend perspective is that apps and data are moving out of the enterprise landscape. So the concept of mobile-first, free the data, free the app, and the
cloud movement are major trends that affects the application security and how applications are being developed and delivered.
The other trend is regulators. In many critical industries regulations are becoming very strict with
cyber crime and advanced actors. We're seeing nation states, advanced actors, coming into the game and we're seeing advanced persistent threats becoming a reality. So that’s driving another dimension to the whole application security.
Last, but not least, is that we see a big shortage of cyber security talent in the market. Those are the trends that drives the need for a different look at application security from a lifecycle approach.
Gardner: Mark, anything to offer in terms of trends that you are seeing from HPE, perhaps getting more involved with security earlier in the process?
Painter: Gopal gave a very good and very thorough answer and he was dead-on. As he said, 80 percent of attacks are aimed at the
application layer. So it actually makes sense to try to prevent those vulnerabilities.
We propose that people implement application security during the development cycle, precisely because that’s where you get the most bang for your buck. You need to do things across the entire lifecycle, and that includes even production, but if you can shift to the left, stop them as early as possible, then you save so much money in the long run in case you are attacked.
We do a study in conjunction with the
Ponemon Institute every year, and since 2010, every year, it shows that attacks increase in frequency, they're harder to find, and they're also increasingly costlier to remediate. So it’s the right way to do it. You have to bake security in. You just can’t simply brush it on.
Gardner: And with the heightened importance of user experience and the need for moving business agility through more rapid iterations of software, is it intuitive to conclude that more rapid development makes it more challenging for security, or is there something about doing rapid iterations and doing security that somehow can go hand in hand, a continuous approach? Gopal, any thoughts?
Rapid development
Padinjaruveetil: There's a need for rapid applications, because we're seeing lot of innovations coming, and we welcome that. But the challenge is, how do you do security in a rapid world?
There is no room for error. One of the things from a trend perspective is IoT. One of the things I tell my clients is that if you look at traditional IT, we're operating in a virtual world, purely a virtual world. But when you talk about things like operation technology (OT), we're talking about physical things, physical objects that we're using in everyday life, like a car, your temperature monitors, or your heartbeat monitors. These are physical things.
When the physical world and the virtual world come together with IoT, that could have a very big impact on the physical layer or the physical objects that we use. For example, the safety of individuals, of community, of regions, of even countries can now be put in danger, and I think that is the key thing. Yes, we need to develop applications rapidly, but we need to develop them in a very secure way.
Gardner: So the more physical things that are connected, the more opportunity there is to go through that connection and somehow do bad things, nefarious activities. So in a sense, the vulnerability increases with the connectivity.
Padinjaruveetil: Absolutely. And that’s the fear, unless we change ways of developing software. There has to be a mindset change in how we develop, deploy, and deliver software in the new world.
There has to be a mindset change in how we develop, deploy, and deliver software in the new world.
Gardner: I suppose another element to this isn't just that bad things can happen, but that the data can be accessed. If we have more data at the edge, if we move computing resources out to the edge where the data is, if we have data centers more frequently in remote locations, this all means that data privacy and data access is also key.
How much of the data security is part of the overall application security equation, Gopal?
Padinjaruveetil: One of the things I ask is to define an application, because we have different kinds of applications. You have
web services and
APIs. Even though those are headless, we would consider that those are applications, and applications without data have no meaning.
The application and the data are very closely tied to each other, and what's the value? There's no real advantage for a hacker just to have an application. They're coming after the data. The private data, sensitive data, or critical data about a client or a customer is what they're coming at.
You bring up a very good point that security and privacy are the key drivers when we are talking about applications. That is what people are trying to get at, whether it's
intellectual property (IP) or whether it’s sensitive data, credit card data, or your health data. The application and the data are tied at the hip, and it’s important that we look at both as a single entity, rather than just looking at the application as a siloed concept.
Solving problems
Gardner: Let’s look a little bit at how we go about helping organizations approach these problems and solve them. What is it that HPE and Capgemini have done in teaming up to solve these problems? Maybe you could provide, Gopal, a brief history of how the app security alliance with these two organizations has come about?
Padinjaruveetil: Capgemini is a services company, and HPE has great security products that they bring to the market. So, very early on, we realized that there's a very good opportunity for us to partner, because we provide services and HPE provides great security products.
One of the key things, as we move into agility or into application development, is that many of the applications have millions of lines of code. These are huge applications, and it's difficult to do a manual assessment. So, automation in an agile world and in an application world becomes important. That's a key thing that HPE is enabling, automation of security through their security products and application space. We bring the services that sit on top of the products.
When I go and talk to my clients about the HPE and Capgemini partnership, I tell them that HPE is bringing a very tasty cake, and we're bringing a beautiful icing on top of the cake. Together, we have something really compelling for the user.
At a high-level, what we're trying to do is expand the application
security scope, and that basically includes three big buckets. Those are
secure development, security testing, and then continuous monitoring
and protection.
Gardner: Let’s go to Mark in describing that cake, I would imagine there are many layers. Maybe you could describe it for some of our listeners and readers who might not be that familiar with what those layers are. What are the major components of the transformation area around security that HPE is focused on?
Painter: At a high-level, what we're trying to do is expand the application security scope, and that basically includes three big buckets. Those are secure development, security testing, and then continuous monitoring and protection.
During the development phase, you need to build security in while the developers are coding, and for that specifically, we use a tool called
DevInspect. It will actually show secure coding to a developer as he is typing his own code. That gets you much, much farther ahead of the game.
As far as security testing, there are two main forms. There is static, which is code analysis, not only for your own code, but open-source components and other things. In this day and age, you really are taking security into your own hands if you trust open-source components without testing them thoroughly. So, static gives you one perspective on application security.
Then there is also dynamic scanning, where you don’t have access to the code, and you actually attack the application just as the hacker would, so you get those dynamic results.
We have a platform that combines and correlates those results. So, you get to reduce false positives and you can trust the accuracy of your results to a much greater detail.
Sustained frequency
We also provide services, but the whole thing is that you have to do this with sustained frequency. Maybe 10 years ago, there was a
stage-gate approach, in which you tested at the end of the development cycle and released it. Well, that’s simply not good enough; you have to do this on a repeatable basis.
Some people would probably consider that the developmental lifecycle ends once the product is out there in the wild, but if anything, my experience in the security industry has taught me that software plus time equals vulnerability. You can’t stop your security efforts just because something has been released. You need that continuous monitoring and protection.
This is a new thing in application security, at least if you call something that’s almost a few years old "new." With something called
App Defender, you can actually put an agent on the application server and it will block attacks in real time, which is a really good thing, because it’s not always convenient to patch your software.
At HPE, we offer a combination of products that you can use yourself and we also offer hybrid solutions, because there's no such thing as one-size-fits-all in any environment.
We also offer expertise. Gopal was talking earlier about the lack of qualified candidates, and
Forbes has predicted that, by 2019, a full quarter of cyber security jobs are going to be unfilled. Organizations need to be able to rely on technology, but they also need to be able to find experts and expertise when they need it. We do a lot at HPE; I will leave it at that.
Gardner: Gopal, how do these products, these layers in the cake, help with the shifting-left concept, where we move more concern about vulnerability and security deeper into the design, earlier into the coding and development process? Where do the products help with shifting left?
Padinjaruveetil: That’s a great question if you decompose or if you analyze application security as a cake. Security vulnerabilities in applications come from three specific areas. One is what I call design flaws, where the application itself is designed in a flawed manner that opens up vulnerabilities. So a bad design, in itself, causes security vulnerabilities.
The second thing is the coding flaws. Take an
Apple iPhone or something like that. If you look at the design of an iPhone, the actual end product, there will be a very close match. A lot of problems we have in software industry are because there is a high level of mismatch between the design and the actual product itself as coded.
Software is coded by the developers, and if the developers aren't adding good code, there's a high possibility that that vulnerability is introduced because of poor coding.
Configuration parameters
The third thing is that the application isn't running in a vacuum. It's running on app servers and database servers and it’s going through multiple layers. There are a lot of configuration parameters, and if these configuration parameters are not set, then it leads to open vulnerability.
From a product perspective, HPE has great products that detect coding flaws. Mark talked about DevInspect. It's a great tool from a dynamics perspective, or hacking. There are great tools to look at all these three layers from a design flaw, from a configuration flaw, and a coding flaw.
As a security expert, I see that there is a great scope for tooling in the design flaw, because right now, we're talking about threat modeling and risk determination. To detect a design flaw requires a high level of human intelligence. I'm sure that in the future, there will be products that can detect design flaws, but when it comes to coding flaws, these tools can detect a coding flaw at 99 percent accuracy. So, we've seen a very good maturity in the application security areas with these products, with the different products that Mark mentioned.
Gardner: Another part of the process for development isn’t just coding, but pulling together components that have already been coded: services,
SDKs, APIs, vast libraries, often in an open-source environment. Is there a way for the alliance between Capgemini and HPE to give some assurance as to what libraries or code have already been vetted, that may have already been put through the proper paces? How does the open-source environment provide a challenge, or maybe even a benefit, when done properly, to allow a reuse of code and this idea of componentized nature of development?
Another part of the process for development isn’t just coding, but pulling together components that have already been coded.
Padinjaruveetil: That’s a great point, because most of the modern applications are not valid applications. They talk with other applications. They get data from other applications, data through Web service interface, a
REST API, and open source.
For example, if you want to do login, there are open-source login frameworks available. If there are things that are available, we'd like to use them, but just like custom code, open source is also vulnerable. There are vulnerabilities in open source.
Vulnerability can come from multiple things in an application. It can be caused by an API. It can be caused by an integration point, like a Web service or any other integration point. It can be caused by the device itself, when you're talking about mobile and all those things. Understanding that is a very critical aspect when we're talking about application security.
Gardner: Mark, anything to offer on this topic of open source and/or vetting code that’s available for developers to then use in their applications?
Painter: Well, it’s not an application, but it’s a good example. The
Shellshock vulnerability was due to something wrong with the code of an open-source component, and that’s still impacting servers around the world. You can’t trust anybody else’s code.
There are so many different flavors of open-source components.
Red Hat obviously is going to be a little better than your mom-and-pop development team, but it has to be an integrated part of your process for certain.
Cyber risk report
There is something Gopal was saying. We do a cyber risk report every year at HPE, and one of the things we do is test thousands and thousands of applications. In last year’s results, the biggest application flaw we found were basically configuration flaws. You could get to different directories than you should be able to.
Application security is not easy. If application security were easy, then we still wouldn’t be having cross-site scripting vulnerabilities that have been around almost as long as the web itself. There are a lot of different components in place. It’s a complex problem.
Gardner: So it’s important to go to partners and tried and true processes to make sure you don’t fall down into some of these holes. Let’s move on to another area, which is also quite important and difficult and challenging. That is the cultural shift, behavioral changes that are forced when a shift left happens, when you're asking people in a traditional design environment to think about security, operations, configuration management, and business-service management.
Gopal, what are some of the challenges to promulgating cultural and behavioral changes that are needed in order to make a continuous application security culture possible?
Padinjaruveetil: That’s a key aspect, because most of the application development is happening in a distributed team, and things are being assembled. So there are different teams building different things, and you're putting together the final application product and deploying it.
There are very good industry standards coming out, but the challenge
is that having a policy or standard alone is not sufficient.
Many companies have now started talking about security policies and security standards, whether it’s
Java development standards or
.NET development. So, there are very good industry standards coming out, but the challenge is that having a policy or standard alone is not sufficient.
What I tell my clients is that any compliance without enforcement is ineffective. The example that I give is that we have traffic laws in India. If you've been to India and you look at the traffic situation there, it’s chaotic. Here, you see radar detection and automated detection of speed and things like that. So enforcement is a key area even in software development. It’s not enough to just have standards; you need to have enforcement.
The second thing I talk about is that compliance without consequence will not bring the right behavior. For example, if you get caught by a cop and he says, "Don’t do this again; I'll let you go," you're not going to change your behavior. If there's a consequence, many times that makes people change behaviors.
We need to have some kind of a discipline and compliance brought into the application development space. One of the things that I did for a major client was what I call zero tolerance. If you develop an application and if we did find a vulnerability in the application, we won't allow you to deploy it. We have zero tolerance on putting up unsecured code when we use one of these great products that HPE has.
Once we find an issue with a critical or a high issue that’s been reported, we won't let you deploy. Over a period of time, this caused a real behavioral change, because when you stop production, it has impact. It gets noticed at a very higher level. People start questioning why this deployment didn't go.
Huge change
Slowly, over a period of time, because of this compliance and because of the enforcement with consequences, we saw a huge change in behavior in the entire team, right from project managers to business analysts making sure that they are getting the security non-functional requirement correct, by the project managers making sure that the project teams are addressing it, the architect making sure the applications are designed correctly, and the testers making sure that the testing is correct. When it goes into an independent audit or something like that, the application comes out clean.
It’s not enough if you just have standards; you need to have some kind of enforcement with that.
Gardner: Mark, in order to have that sort of enforcement you need to have visibility and measurement. It seems to me that there's a lot more data gathering going on across this entire application lifecycle. And big data or analytics that we have in other areas are being brought into this fold.
Is there something about automation, orchestration, and data analytics that are part and parcel of the HPE products that could help on this behavioral shift by measuring, verifying, and then demonstrating where things are good or not so good?
Over the past 10 years in the security industry, we've changed from the
idea of we're going to block every attack, to one that says the
attackers are already inside your network.
Painter: One thing that HPE uses to build it in is secure coding, but also we talk about detect and response. We have an application product that integrates with our security and monitoring tool from ArcSight.
So you can actually get application information. Applications have been a typical blind spot for
Security Information and Event Management (SIEM) tools, and you can actually get some of those results you are talking about from our SIEM technology, which is really cool.
Over the past 10 years in the security industry, we've changed from the idea of we're going to block every attack, to one that says the attackers are already inside your network. This is part of that detection. Maybe you didn’t find these. You can see active exploitation in other words, and then you can track it down and stop it that way.
Fifteen years ago, you had to convince people that they needed application security. You don’t have to do that know. They know they need it, but they just might not exactly know what they need to do.
It’s all about making this an opportunity for them to get security right, instead of viewing it as some sort of conflict between the need for speed and agile development and the need to release balanced against the needs of the enterprise to actually be secure and protect themselves from potential data breaches and potential data loss and all the compliance issues and now legal challenges from individual actors and all the way down the line.
Gardner: Gopal, before we close out, let’s look to the future a little bit. What comes next? Do you expect to see more use of data, measurement, and analytics, a science of development, if you will, to help with security issues, perhaps feedback loops that extend from development into production and back? How important do you think this use of more data and analytics will be to the improved automation and overall security posture of these applications?
Continuous improvement
Padinjaruveetil: You need to have data and you need to have measurements to make improvements. We want continuous improvement, but you can’t manage unless you measure. So we need to determine what are the systemic issues in application development, what are the systemic issues that we see constantly coming?
For example, if you're seeing cross-site scripting as a consistent vulnerability that’s coming across the multiple development team, we need to have some way to make sure that we're seeing patterns with the data and looking at how to reduce these major systemic errors or vulnerabilities in systems?
You will see more-and-more data collections, data measurements, and applying advanced methods to look at not just the vulnerability aspect of it, but also the behavioral aspect. That’s something that we're not doing, but I see a huge change coming where we're actually going to see the behavioral aspects being tracked with data in the application lifecycle model.
You need to have data and you need to have measurements to make
improvements. We want continuous improvement, but you can’t manage
unless you measure.
Gardner: Another thing to be mindful of is getting ready for IoT with many more devices, endpoints, sensors, biological sensors. All of this is going to be something coming in the next few years.
How about revisiting the skills issue before we sign off? What can organizations do about maintaining the right skill sets, attracting the right workers and professionals, but also looking for all the options within an ecosystem, like the alliance between HPE and Capgemini. How do you see the skills problem shaking out over the next several years, Gopal?
Padinjaruveetil: If you look at many of the compliance frameworks, like
NIST or
ISO 27001, there's a big emphasis on control being put in place for security awareness and education. We're seeing a big drive for security education within the whole organization.
Then, we're seeing tools like DevInspect. When a developer writes bad code, if you give the feedback instantly that right now you have written a code that is bad, instead of waiting for three months or four months and doing a test, we're seeing how these tools are making changes.
So, we're seeing tools like DevInspect and helping developers to actually make themselves better code writers.
Painter: Developers are not natural security experts. They need help.
Padinjaruveetil: Yeah, absolutely.
Additional resources
Gardner: That was my last question to you, Mark. Can you suggest places that people can go for resources or how can they start to prepare themselves better for a number of the issues that we have discussed today?
Painter: It’s almost on an individual basis. There are plenty of resources on the Internet. We provide training as well. Web application security is actually one of the best places for organizations to leverage Capgemini to do their web application security testing.
The job crunch is the number one concern that enterprises have right now as part of security in the enterprise. There's a lack of qualified applicants, which says a lot when that’s a bigger concern than a data breach. We do a
State of the SOC survey every year, and that was the result from the last one, which was a little surprising.
But apart from outsourcing, you need to find those developers who have an interest in security in your organization, and you need to enable them to learn that and get better, because that’s who is going to be your security person in the future, and that’s a lot cheaper and a lot more cost-effective than going out and hiring an expert.
I know one thing, and it’s a good thing. I tell my boss repeatedly that if you have good security people, you're going to have to pay them to keep them. That’s just the state of the market as it is now. So you have to leverage that and you have to rely on automation, but even with automation, you're still going to need that expert.
We are not yet at the point where you can just click a button and get a report. You still need somebody to look at it, and if you have interesting results, then you need that person who can go and examine those. It’s the 80/20 rule. You need that person who can go to the last 20 percent. You're going to have automation, tools, and what have you to get to that first 80 percent, but you still need that 20 percent at the end.
Listen to the podcast. Find it on iTunes. Get the mobile app. Read a full transcript or download a copy. Sponsor: Hewlett Packard Enterprise.
You may also be interested in:
