The Tech Herald recently caught up with Fortify's Barmak Meftah to discuss various topics including PCI compliance, Fortify Software’s 360 offering, and more. Fortify Software is a security vendor with a twist, its 360 product covers detection, remediation and governance via an all-in-one tool.
The Tech Herald sits down with Fortify Software for a talk about 360 and PCI. (Image: J.Anderson)
[Note: Fortify is a vendor that has been covered in the past. The Tech Herald has spoken to this company with regards to quotes, news, and information. Any security vendors, including those mentioned here, are welcome to take the same set of questions (those that are relevant) and respond to them via e-mail using the security e-mail address.]
Barmak Meftah is the Senior Vice President of Products and Services at Fortify Software. He is responsible for Worldwide Product Development, Product Management, Professional Services, and Technical Support functions of the company.
In the IT field for the last sixteen years, Meftah joined Fortify as one of its first ten employees over four years ago. He became very interested in Fortify because of Fortify’s approach to security, which was fundamentally different than the traditional 'perimeter based' security solutions. Before his time at Fortify, Meftah spent seven years working in Oracle's Server Technologies Division.
The Tech Herald (TTH): PCI has seen so much news coverage lately, it is almost a household name. Yet, this coverage always seem centered on the same topic: companies who fail to comply. Why is PCI compliance so hard? And, if it is not that hard, why are there so many companies who fail to completely comply?
Barmak Meftah (BM): There are three things going on here.
First -- the PCI standards are somewhat vague. They aren’t designed like the health code standard for restaurants, or the fire safety manual for contractors. The requirements aren’t prescriptive rules. They often talk about goals, rather than clear activities that need to take place.
Second -- failing an audit hasn’t meant that much, so most companies haven’t created a sense of internal urgency. However, we see this changing to some degree. The acquiring banks are getting more involved in the process and the threat of a fine has increased, and with PCI getting more press, a failed PCI audit seems to carry more weight.
Third -- some of the requirements are, in fact, difficult. Most companies didn’t design their IT infrastructure for security. They designed it to enable quick development of effective software and applications. As a result, companies have disparate systems with complex architectures. Just getting a full inventory of all applications is not an easy task, let alone securing all of them, but it’s extremely important.
TTH: As a compliance vendor yourself, what are some of the more common problems you see with your customers when you first go in to help them?
BM: We focus on application security, which is a relatively new trend (It’s become a big topic over the last 3-5 years). Given that, some companies are just coming up to speed on the need, and the techniques, for securing applications. Most companies are trying to figure out what application security approach they should adopt -- source code analysis or application firewalls. We have both, so we can help companies think through them.
Some of the biggest misconceptions are that 1) People think their applications are secure. Almost every application we look at has serious vulnerabilities that could lead to a breach, 2) Source code analysis is too difficult -- this is a common complaint at first, but when companies dig deeper they see it’s not that big of a step, and the results are staggering, 3) Becoming PCI compliant will make them secure.
The companies that are making investments just to become PCI compliant are the ones -- like TJX and Hannaford -- that will be breached. PCI compliance is a stepping stone towards better security; it’s not a ceiling to strive for. One example where PCI comes up short for security -- the PCI standards focuses a lot of energy on externally facing applications, but neglects internal ones. With a substantial number of breaches coming from the inside, this is a security shortcoming.
TTH: Without naming the client, think of the one place you helped that needed the most work? What issues was the client facing?
BM: There are two types of companies that stand out. We’ve seen several companies that have critical vulnerabilities in their main application, which could lead to a massive breach. Some understand the threat and engrain security into their process. They start analyzing the source code, training developers and installing application firewalls.
These companies may have made a mistake, but they’re doing something about it. Others decide to take the perceived easy route and stick with their regular pen tests... a strategy that is better than nothing, but really isn’t comprehensive enough for the attacks we’re seeing today. Pen tests are important, and we always encourage people to conduct them, but they can’t find certain types of vulnerabilities.
TTH: This relates to question three somewhat. Tell us a battle story from the field. Has there been one company you worked with or specific issue that you helped to resolve that at first left you wanting to scream or just laugh and walk away?
BM: We had one customer who had an extremely blatant and dangerous vulnerability in their home page. The good thing is that they were responsive. They immediately installed our application firewall, and then rolled our source code analysis technology throughout their development groups. After failing an audit, they have since passed.
TTH: Are there things in the PCI compliance rules that you would want changed or think need more attention?
BM: Let me first say that I think the PCI standards are a good step forward. But, in certain areas, they struggle due to one key element -- they were designed to be strong enough to secure big companies, but easy enough so that small companies could implement them. This is an impossible challenge. The result is either a lot of failed audits, or a weak standard. Section 6.6 has struggled with both elements.
It allows for three general approaches; 1) Analyzing the code, 2) Conducting an application pen test, 3) Installing an application firewall.
The PCI council knows that one of the most impactful actions a company can take is to instill security into the development process: conducting source code analysis throughout the process and teaching developers to write securely. The top banks, government agencies, and leading companies in nearly every industry have realized this and implemented programs. The PCI council stresses these steps in sections 6.3, 6.5 and 6.6. However, at the same time they seem to be backpedaling and saying it’s ok to rely on pen tests and application firewalls.
These are good things to do at the back-end, but they don’t represent a strategic security initiative. I’ve heard the council say, if you have the code, you should test it and fix it, but if you don’t have the code, it’s ok to install an application firewall. This makes sense. The standard doesn’t enforce this but it’s implied. In the subsequent versions of the standard I hope the PCI council stresses the importance of building security in... and also conducting pen tests and installing app firewalls. An effective strategy is to build it securely, test it, and then protect and monitor it.
TTH: You recently added features to Fortify 360 that help with compliance on section 6.6. Why do you think that this section went from a suggested step to a required step?
BM: They always planned on it being a requirement -- they just needed to give companies time to get up to speed. When they released version 1.1 of the standard, this was the one major new item. They couldn’t make it a requirement right away so they built in time for companies to put the right tools and processes in place.
TTH: Briefly, tell our readers about Fortify 360.
BM: Fortify 360 is the only solution available that offers
(1) Static analysis of an application’s source code
(2) Dynamic analysis of an application that is up and running
(3) Real-time protection of an application in the form of a software application firewall
Users can deploy all three approaches at once, or roll out one at a time. If a company deploys all three, Fortify 360 can integrate and correlate the results, providing an extremely accurate and holistic view into the security of your application. In addition, it can provide additional benefits -- the software application firewall can provide detail on what type of attacks are coming in, which can help prioritize the vulnerabilities tested for by the static and dynamic analysis.
Once a company wants to start fixing results, Fortify 360 offers the industry’s only collaborative module, which provides a centralized interface for multiple developers and auditors to interact and fix the code.
The goal of Fortify 360 is to find the most vulnerabilities, prioritize them effectively, and help you fix them quickly and easily.
TTH: Now, here's the hard question. Tell our readers about two companies they can check out and compare your solution to. Another way to phrase this would be to name your two biggest competitors in the field.
BM: No other company offers all three solutions: source code analysis, dynamic security testing, and an application firewall. There are vendors that only do source code analysis, such as ounce labs and klocworks, vendors that do only dynamic security testing, such as HP (SPIDynamics) and IBM (Watchfire), and vendors that have application firewalls, such as Imperva and Breach. It’s worth evaluating all the tools.
Gartner’s latest report put Fortify on top, with the highest market share in the category, and we have more experience in application security than any one on this list.
TTH: Lets talk about Fortify as a company. Fortify was recently named one of the Bay Area’s best places to work, so that’s a positive right off the bat. Does Fortify still try to keep that small company feel?
BM: Absolutely. One of the perks to being a cutting edge technology firm is that there seems to be an energy that’s constant. There’s a lot of excitement when you’re the leader in one of the most up and coming areas of security.
In addition, our approach of integrating static and dynamic analysis is something the market has been asking for over the last few years. Being the first ones to deliver on that is very rewarding.
Lastly, it’s quite rare to work at a relatively small company and be able to call the top banks, healthcare companies, telecom companies, government agencies, and ecommerce companies, customers. It’s an exciting place to be.
TTH: What vendors do you deal with on a day-to-day basis? What compliance regulations do you have to deal with, and how do you do this?
BM: We buy a few tools throughout our organization. Nothing too new and different. As for our compliance regulations, we impose stronger rules on ourselves than any compliance mandate out there. All of our solutions undergo serious security analysis.
[TTH Note: The answer was vague, we were told, because of internal security policy.]
TTH: How layered is your own security on your company network? Do you agree or disagree with a layered defense when it comes to security.
BM: We follow intense security measures. When you’ve done the research we have into the hacking community and the trends, it’s very scary. We see first hand that all of the security measures we push, and that are in the PCI standards are not just “good practices,” but are critical steps to combating what is becoming a very sophisticated and well financed hacking community.
[Note: Again, company policy prevents the disclosure of more detail.]
TTH: Final thoughts. Name five things companies must know about PCI DSS and why?
BM: (1) Being PCI compliant is a stepping stone, not the ceiling. Don’t strive to just meet mandates. Use the mandates as guides on where you should be focusing your time and then develop comprehensive security strategies.
(2) Pen testing and application firewalls alone are not security strategies. Don’t rely on them alone to secure your software. Its good to do a final check with a pen test and put a band aid on at the end, but don’t rely on these alone. Fix the problem at the root cause.
(3) In order to pass section 6.6, auditors will want to see a security strategy, which means repeatable and thorough steps. Just conducting a pen test before deployment is not necessarily getting the job done.
(4) I’ve heard some companies say that finding vulnerabilities is enough, and that fixing them isn’t required to pass an audit. Two responses -- first, if you find vulnerabilities, why would you not immediately fix them? If you were breached and people found out that you knew about the vulnerability and didn’t do anything about it, you -- and your company -- would be in serious trouble. Second, the point of the PCI standards is to increase security -- this means reducing vulnerabilities, not pointing them out.
(5) Hire a good QSA, who is experienced and aggressive.
There are currently no comments for this article. Be the first to comment! (no registration required)
Advertising
There are currently no comments for this article. Be the first to comment! (no registration required)