[ MUSIC ] Hello, and welcome to a searchsecurity.com podcast: How Security is Well Suited for Agile Development. My name is Kyle Leroy, and I'll be moderating this podcast. I'd like to start by introducing our expert. Joining us today is Patrick Vandenberg, Manager, IBM Rational Security and Compliance. Welcome, Patrick, and thanks for joining us today. VANDENBERG: Happy to be here. This podcast is being brought to you by IBM. For more information on IBM, please visit their Web site at www.ibm.com. All right, so let's jump right in to our discussion. How do you fit in to IT security? VANDENBERG: So, our group, Rational Security Compliance, is actually part of a larger brand in IBM called IBM Security. And that brand has five pillars, and we sit in the application and process security. So really we focus on the vulnerabilities that are present in applications and help organizations address those so that they can improve the overall security in IT. So, for example, if we want to look at Web applications -- -1-
which is a pretty popular concern today -- there is a number of ways in which organizations need to protect Web applications from network protection to the application. And we would focus on the part that looks at the vulnerabilities within the application. And the reason why the multiple pillars exist in IBM Security, a defense indepth approach is very much required. So we need to look at the many different ways that malicious attacks can look at compromising assets in an organization. So we do need to pay attention to the application layer, the network layer, identity and access management, even physical security as well as data and information. So all of these elements combine to a full service approach to IT security. All right, so what should the development team...sorry, I'm going to ask that one again. So, why should the development team care about security? VANDENBERG: Yes, that's an interesting point. As we all know, development is mandated to deliver quality functionality on time, on budget. And some other group in the organizations, typically in IT operations, is responsible for security. -2-
And while the awareness is certainly increasing and the investment is starting in this area, it's predominately owned by IT security and even some new investment around having a security practitioner focus on application security where you have somebody who's aware of the vulnerabilities within the code. And while it's great that somebody in IT security is starting to look at vulnerabilities in the application itself, the real challenge here is that all this code, the software, is actually coming from the development organization and for several different reasons there's the opportunity to address application security does reside with development. So for instance, there are vulnerabilities that are readily identified by a security practitioner, and so much so that it creates a bottleneck for the security practitioner. Well, to have that issue remediated, we have to go back to the development organization, fix that code so that the vulnerability doesn't exist in the first place. And this is why application security is necessary. It's very different from having real-time operational protection of network assets, as an example, with application security. We're talking about issues that are within the code itself, and because of that nature, we rely on the development -3-
community to be able to help improve the security posture of these applications. All right. Could you elaborate? What are the first steps an organization should take? VANDENBERG: Yes, so this is an interesting discussion and it can be quite a lengthy one. And from what we've seen over time in a few thousand customers is that there is a progression. And we sometimes refer to this as the customer maturity model. So, naturally, with an issue that is not as prevalent in the market or it hasn't been historically, there is a commensurate smaller investment by organizations and a smaller number of skilled resources to address application security. So what can typically happen is an organization's first step is to outsource the security testing effort called penetration testing, or even bring this in house, to, as I mentioned, a security practitioner who's going to do the security audit. But what we've seen here, especially for organizations that have a continuous stream of applications that are in development and that they look to deploy is that there is a -4-
bottleneck for typically that one or two people that are responsible for identifying vulnerabilities. What ends up happening is these resources are tasked with protecting the organizational assets. And if they see too much risk in these organizations, they're going to have to say, look, I cannot allow this application to be deployed. It's going to create risk for the organization. And as a result, we get a bottleneck which results in delays, opportunity cost for that project not getting deployed on time, and also we do know that those issues at some point need to get remediated by a development organization. So, they're going to be touching all the hands in the application lifecycle and that process over again. So there's increasing costs for doing this. Now, there is a great opportunity for organizations engaging a development organization, and what can happen here is if we can have security addressed earlier in the development process, then we can alleviate that bottleneck, and we can also remove that effect of having multiple stakeholders touch these issues multiple times -- which is very costly. So, the earlier we can have security addressed, the more cost effective this is. We don't have the bottleneck at the security audit stage, and we don't have that lost -5-
opportunity cost of delayed projects. Now, you might say, why do we need the security practitioners in the first place? Well, there's a tremendous experience with these people who are able, if we can relieve the bottleneck for them, then we can leverage them as an acceptance test to make sure that the security posture of these applications is acceptable to be deployed. And we can use their expertise to find maybe the tougher to find security issues in a deployed state. But at the same time, what we can do by engaging the development organization at the code or build or test stage is we have many more resources to scale to find the volumes of easy to find and fix issues. And we're not suggesting here that you'd be looking at deploying security practitioner tools to these people. That's not something that is practical. That's not something that's going to be successful. What we do condone, though, is helping the education and awareness and adopting some practices to bring in some capabilities that support the existing use cases and environments that are in use. So, solutions that integrate with developer IDEs, with the build system that fully integrate into the test scripts so -6-
that as you're writing a script for functional performance and services testing, an automated security scan happens as well. And then you fold these vulnerabilities into the remediation effort that developers are already engaged in. This is a way to engage security -- the practice of security -- into the existing process, have a governance model that's going to manage these issues and track them through, and support collaboration between development QA and security. So, Patrick, how is security relevant and feasible in an agile model? VANDENBERG: Yes, that's a great question, because a lot of people will feel on first discussions that security requires a lot of heavy lifting. And while adopting existing practices is not an easy...there are a lot of dynamics in play, you've got cultural change, you've got some training and awareness that will need to happen... What is actually interesting and not typically seen up front is that security is very conducive to an agile environment. So as I mentioned earlier, if you're going to have somebody late in the process who's going to stop these projects because it's posing risk for the organization and they don't have a choice but to do that, because that is their job... -7-
Then you're really running counter to an agile environment. In embedding security early into the process what you're doing is you're allowing lightweight quick checks for security just like in the same stream as the rest of the activity that is going to avoid this heavy lifting slowdown that can happen by doing a full security test late in the process. So, it really allows vulnerability testing and remediation to go hand in hand with agile. Right? Let's piece this down, let's have a quick process so that there's a lightweight effort and it's not going to be disruptive and allow us to get a quick response or a quick delivery on our project out the door. All right, and finally, what are some key techniques and practices which need to be adopted to support security in an agile environment? VANDENBERG: So, I think I touched on a few of these already with some of the other questions, and really what this requires is the support of the different communities to embrace this model in the software lifecycle management process. So if you have considerations of collaboration and governance of embedding security into the existing use cases -8-
and tooling that are in place and there is software and solutions available to do this from IBM and the necessary services, then you can go hand in hand with your transformation through an agile process. So, for example, integrating into the IDE, or integrating into the build stage, as an example, to do that, to do that test. And security becomes a regular process. And your security practitioners or your auditors can become, can operate as an admin in the background that can set up standardized scan templates that can be, really all that detail can be extracted from your development community. So we're not derailing all that brainpower and time. They can do the triage of these vulnerabilities to support the developers so that we're stripping out all the noise, as much noise as possible so that the bugs, the security bugs or defects that the developers are receiving and intermediate on are easy to find, easy to fix and are validated as being real issues. In this way, the investment on the part of the developers, but as I said, has been chugged down to being lightweight on a quick turn in the normal process, becomes more of a lightweight effort, a very non-disruptive or non-intrusive approach to leveraging the opportunity to scale with all the resources we have in our development community versus -9-
waiting for one or two people to slow the entire process down and do an exhaustive test late in the cycle. All right, great. Thanks, Patrick. This has been an interesting and informative discussion. Thank you for your time today, and thanks to our listeners for taking time out of their day. I'd like to thank IBM for bringing us this searchsecurity.com podcast. I thank you all so much for joining us. [ MUSIC ] [END OF SEGMENT] -10-