Dana Gardner's BriefingsDirect: Software security pays off: How Heartland Payment Systems gains steep ROI via software assurance tools and methods

Wednesday, April 30, 2014

Software security pays off: How Heartland Payment Systems gains steep ROI via software assurance tools and methods

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: HP.

Heartland Payment Systems has successfully leveraged software-assurance tools and best practices to drive better security within its IT organization -- and improve their overall business performance.

In this first of a two-part series -- Does Software Security Pay? -- hear directly from Ashwin Altekar, Director of Enterprise Risk Management at Heartland, as he shares his insights and knowledge with Amir Hartman, the Founder and Managing Director at MainStay, a marketing and IT advisory services firm in San Mateo, California.

We’ll learn how Heartland, based in Princeton, New Jersey, has improved governance results in innovative ways across the organization, thanks to both security best practices and HP Fortify tools.

Hartman, who recently completed a software-assurance return-on-investment (ROI) study, also shares details from that study on how HP Fortify has impacted Heartland’s IT organization.

Here are some excerpts:

Amir Hartman: The research that we did found some very interesting results from the companies that we interviewed.

Hartman

We found three main benefits to employing and institutionalizing a strong software security-assurance program with supporting tools. One was a saving that organizations are seeing. Second, it’s a risk-management benefit to the organization. Last, we actually saw some revenue protection benefits as well.

So I'm pretty excited to have Ashwin on the call today and have Ashwin share with us his experiences in deploying HP Fortify solutions and these practices within Heartland. Ashwin, give us a little bit of background, a little bit about yourself, and then describe the software security landscape at Heartland.

Ashwin Altekar: I've been working in information security for over a decade and have spent a large portion of my time performing application penetration tests and managing software-assurance efforts.

At Heartland, we take software security very seriously. We strive to be the trusted transaction provider, the trusted partner of the large number of merchants who depend on our payments and payroll services. With application security being such a large vector for attack, we’re very aware of the multiple controls necessary to keep our customers’ data secure.

We lean quite heavily on HP Fortify, first to understand, and then improve, our level of software assurance.

Previous scenario

Hartman: Let's take people back a little bit. Please describe what the software-security scenario was like at Heartland before institutionalizing some of these practices and before implementing and rolling out Fortify. What did things looked like before? Then, talk to us about why you went in a new direction.

Altekar: Prior to Fortify, or any automated tools, we relied mostly on manual inspection by developers using common security guidelines like the Open Web Application Security Project (OWASP) or assessments done by third parties.

Altekar

As our enterprise grew, it became harder and harder to be confident in our application-security posture with just manual inspection by development teams. Software assurance is very important to us, not just finding vulnerabilities, but understanding what percentage still remains. With manual efforts, there was just too much to do and not enough time.

We liked the breadth of programming languages supported by Fortify and we really liked the direct integration to the integrated development environment (IDE) for common IDEs like Visual Studio and Eclipse. So Fortify was just a natural fit for the need at the time.

Hartman: I would imagine that with the space that Heartland plays in, obviously these issues are quite sensitive. And if you look at the marketplace, you’re seeing this explosion of mobile devices and mechanisms by which consumers are transacting. It makes this issue even more front and center.

Altekar: Absolutely. Our primary product or service of facilitating transactions is provided through software. So Fortify is definitely a key product that helps us position ourselves as a secure company. And to do so, we need to understand what security issues we have in our software.

Hartman: What are some of the benefits that you've been able to deliver to the organization and to its customers through institutionalizing these practices and tools?

Altekar: At Heartland, we risk-rank our numerous applications and have various requirements on what each development team has to do to meet internal requirements.

One of our basic requirements is that all software applications be scanned using Fortify. From the information-security perspective, that has allowed us to understand what it is that we’re up against when we talk about software-security assurance. So, a large challenge is trying to figure out what it is we don’t know. Fortify allows us to quantify our level of effort and get the attention software security requires.

Also, we've been able to show the successes of many teams that embrace Fortify. They’ve been able to do more and learn more about software security in much less time.

Similar results

Hartman: In the research that we did, we found similar results. We found quite a number of organizations that were able to reduce the amount of time the developers were spending identifying and remediating. Because of the automated mechanism, they focused their attention on developing new value-add applications.

It's reallocating their time. It’s not that this stuff isn’t important. Obviously it's essential, but if we've got a way to do this faster and then focus the developers’ attention on different areas that are more value add, that was a big win. I don’t know if that’s something similar what you’re finding as well, as developers are making it part of their DNA.

Altekar: We absolutely do find that. There’s an old expression for spell check that if you see the correct spelling seven times, you would finally get it right on the eighth.

Our developers are bit quicker in learning about security best practices, but Fortify allows us to do a very similar type of reinforcement when it comes to specific software-security issues. They’re able to see the right way to do secure development through Fortify and then learn from that.

They’re able to see the right way to do secure development through Fortify and then learn from that.

Hartman: Some of the things we noticed were a little bit unexpected. When we went into the study trying to figure out how companies are benefiting from effective software security practices, we were going in with certain assumptions.

One of the assumptions was that some of these automated tools and practices are going to obviously save time and save money on the developer side. Certainly, if I can address and remediate things early in the development cycle, that’s going to save me a tremendous amount of resources and money, versus down the road in post production.

But there were a couple of areas that we found in terms of benefits that companies were experiencing that were a little bit unexpected, and there were some innovative uses.

Can you share with us a little bit from your perspective, and from Heartland's experience, some of the more innovative uses of these practices and Fortify related to software assurance?

Altekar: We provide broad warnings about software security issues in general at the enterprise level, and Fortify allows us to really target our training efforts on the issues we see at the project level.

We can discuss those specific topics with the development teams when we interact with them and we can even point out the specific remediation tips within Fortify. That’s very helpful.

Secure development

Something else we’re looking to roll out right now is how we can visualize the different development teams and how they compare to each other in terms of software security. So we’re looking to see if we can incentivize secure development even before a line of code has been written.

Through some minor gamification, leveraging Fortify statistics between the various development teams here at Heartland, we hope to better train developers and, in turn, improve the overall development productivity.

There’s another interesting use that we have. At Heartland, from time to time, we acquire various companies or seek to be partners with them. During the evaluation phase, often we’ll use HP Fortify to determine the amount of work that we may need to do to get the acquired software into a production-ready state.

That has been helpful sometimes in negotiating the acquisition price or making sure that we factor that in and do and appropriate level of due diligence ahead of time.

When you start articulating and dictating to developers things that they should do, the reaction isn’t always positive.

Another common scenario for us is that we’re able to understand the quality of any third-party developers that we contract with and we can force strict standards on what secure development means.

Traditionally we enforce security through a legal contract that says the third party has to follow secure coding guidelines based on best practices, but with the implementation of Fortify we can say that they have to have a clean Fortify scan prior to finalizing a certain amount of work.

Lastly, our secure software development lifecycle (SDLC) process, which includes HP Fortify, signals to our partners -- especially our partners that value security -- that we’re very serious about software security and that we take a lot of the right steps, if not all the right steps, doing whatever we can to understand our vulnerabilities in software and to eliminate them.

Hartman: How this has differentiated, or been used to differentiate, Heartland? Obviously, in the space that you play in, security is at a premium, as is being able to ensure your customers that you've got a terrific approach. Can you talk to us about that in terms of whether this capability helps you differentiate in the marketplace?

Altekar: As I'm sure you know, security is more important than ever in our customers’ minds. When it comes to transactional security, we've heard of a few high-profile reports about payment security and breaches lately. That has really raised awareness and that’s great, especially since many of Heartland’s products and services focus on security.

Confidence in the quality and security of our software product is absolutely a differentiator. It allows our customers to focus on their business without having to worry about technical security issues in their day-to-day operations.

Having trust in a brand, having trust in a company and its products and services, is very important for our customers.

Having trust in a brand, having trust in a company and its products and services, is very important for our customers, and our secure SDLC allows us to articulate why it is they should have that confidence in us.

We can tell them that we have secure development training, we have a static source code analyzer, we use dynamic tools, we have manual inspection, we have third-party assessments. These are all things that especially our larger customers appreciate. They understand that this is what you need to do in today’s day and age to have secured products.

We’re able to elaborate on the multitude of things that we do, and many of our partners are very thrilled to partner with us because of that.

Hartman: Can you help us understand what were some of those key factors throughout this journey, and it is a journey? It's not just one quick little implementation and then you are off and running. It's definitely a journey from the customers we've talked to. What are some of those key success factors in institutionalizing such tools and practices across an organization?

Changing variables

Altekar: Journey is a great word for it. There have been so many times when I thought that we were finally at a place where we need to be, and then, one of the variables changed.

The first thing that you can do is be very clear about what development teams need to do for internal compliance when it comes to software assurance. That could mean setting specific metrics or making sure that they have well defined processes. But whatever is right for your organization, you have to repeat that message often.

I used to think that I was just constantly talking about security, and everyone was tired of it, but one of the key lessons I learned was that it's impossible for you to repeat that message too often. So be very clear about what it is you want them to do and say it often to anyone who will listen.

The second is to make it easy. Make it very simple for various development teams that integrate into your software assurance processes. So understand the challenges that individual teams face in implementing security during the development life cycle. One team’s problem, if they are doing an agile development process versus waterfall, could be very different depending on those scenarios.

The key success factors are just to be clear about the message, make it easy for people to integrate, and then measure how well everyone is doing.

Make sure you understand their challenges, whether it's process, time, or the right tools, and make sure that you’re able to solve for those. Thankfully, for us, Fortify has been very easy to integrate into the IDE. We've been able to automate with it, so it's been flexible in a number of different scenarios for us.

Finally, quantifying, measuring progress over time. It's very easy to sit back and say, “These guys implement Fortify” or “We have manual tests for them” or “They take all the required training,” but it's great to quantify each, so that you provide feedback to senior management and talk about many of the success stories.

If you can provide quantitative information and share those success stories everywhere throughout the organization, you’re able to reward everyone’s efforts. In summary, the key success factors are just to be clear about the message, make it easy for people to integrate, and then measure how well everyone is doing.

Hartman: That’s a great summary, and last one, especially to your point, sounds easy. It's not that trivial of an activity. It's being able to communicate to leadership as well as to the troops.

Leadership, especially in a set of measures or metrics that resonate with them, is not an easy task. There are a lot of activities that get done as far as software security and software assurance practices go, but translating that into a language that a senior business leader is going to understand is not an easy task. That’s a very good point.

A couple of last questions for you. If you could take a look back for us with this journey and when it started and the success you've had, is there anything you would do a little differently?

Be repetitive

Altekar: One of the things I already mentioned was to be repetitive about the importance of software security and what needs to be done. There is always someone who hasn’t heard that message, and it's important for them to hear it as well.

The other thing is that it's okay to be a bit more realistic in what an organization can do. Just because there's lots of security work ahead of you, it doesn’t mean that the organization is able to get it all done immediately.

So it's important to create realistic goals and time frames that the organization can meet, versus trying to get everything done all at once. It changes from organization to organization on what that means, but I've learned to have realistic goals, rather than ideal goals.

Hartman: Going forward then, what's next for Heartland and specifically in this space? Can you paint us a picture for what's next in the horizon from an SSA standpoint, let's say, the next 12 months or so?

My next goal is to combine all our different tools and get even more value out of them running in sync with each other.

Altekar: I'm really excited for the next year at Heartland. We’re at a place where we have many of the right tools. We have many of the right controls at the right time during the software development lifecycle.

My next goal is to combine all our different tools and get even more value out of them running in sync with each other - trying to add one and one to get three, versus just the two that we have today.

Going forward, I’d really like to continue to automate and leverage the individual tools and get them working together so that we get, one, richer information about our security posture, but two, to get more actionable and precise information on what various development teams need to do, or what the security team needs to do to better support software assurance efforts.