I’m still out at SANS, in a session dedicated to PCI and web application security.
Now, as you readers know, I’m not the biggest fan of PCI. The truth is (this is the “bad” part) it’s mostly a tool to minimize the risk of the credit card companies by transferring as much risk and cost as possible to the merchants and processors.
On the other hand (the “good” side), it’s clear that PCI is slowly driving organizations which would otherwise ignore security to take it more seriously. I’ve met with a bunch of security admins out here who tell me they are finally getting resources from the business that they didn’t have before. Sure, many of them also complain those resources are only to give them the bare minimum needed for compliance, but in these cases that’s still significant.
When it comes to web application security, it’s also a mixed bag. On the “good” side, including web application defense in section 6.6 is driving significant awareness that web applications are a major vector for successful attacks. On the “bad” side, 6.6 places code review and WAFs as competing, not complementary, technologies. These tools solve very different problems, something I hope PCI eventually recognizes. I don’t totally blame them on this one, since requiring both in every organization within the compliance deadlines isn’t reasonable, but I’d like to see PCI publicly recognize that the “either/or” decision is one of limited resources, not that the technologies themselves are equivalent.
One take-away from the event, based on conversations with end users and other experts, is that WAFs are your best quick fix, while secure coding is the way to go for long-term risk reduction.
Reader interactions
10 Replies to “The Good (Yes, Good) And Bad Of PCI”
Mike, aside from being pretentious, that’s just illinformed for someone running a PCI site (pcianswers.com). I’‘ve worked with hundreds of organizations dealing with PCI.
Besides, speaking of truth aren’‘t you the one that posted on Scanless PCI, realized you were made a fool of, and deleted your post instead of issuing a retraction/correction?
Just wondering.
Controversy will get you readers, but not the truth. Seek first to understand and then to be understood.
The Good (Yes, Good) And Bad Of PCI
Oops, wrong link (although that’s also a good one). Check out our latest post (Marcin wrote it up based on real-world experience with the very products that we normally talk about):
Web application firewalls: A slight change of heart
TS/SCI Security Blog
@ rmogull:
Yes, but I’‘m convinced that I’‘ll convince you otherwise.
I’‘m going to give ADMP and WAF some breaks once I see that they are doing the right things. As an example, see our latest post on WAF egress technology. However, the way that WAF and ADMP work today is a complete waste of money and time. If you want to talk specific products, we can really get into it—but let’s do that offline.
However, “shield and patch” is really just the wrong way to say it in the first place. If you want to prevent attacks, you want to prevent them from exiting your network (like DLP)—not entering (like a shield). Re-coding applications is really about Refactoring, proper use of AOP or DI as well as interative programming (often seen in newer paradigms as XP, Agile, SCRUM, CI, and/or TDD). There is nothing “patch”-like about it.
I have no intention of talking about old vulnerabilities or times past unless they are relevant to attacks today. Attacks which cause data breaches; attacks which cause turmoil.
“The operational realities of the dozens to hundreds of end user organizations I talk to every year are just too down and dirty for what you’re suggesting”—Honestly, I don’‘t see how the same could not be said about WAF or ADMP. Do they or don’‘t they have operational problems? How easy is it just to drop WAF or ADMP into an existing architecture?
Let me add one more question to my list of questions that you haven’‘t yet answered: “How long does it typically take to implement a WAF? Which vulnerabilities do they protect against?”—”Which software weaknesses does WAF/ADMP fail to protect against?”
Dre,
We’‘re never going to agree on this. Between our in-person and online discussions we’‘ve spent hours on it now.
Today’s WAFs are not the long term solution; as I’‘ve written before they need serious help. By the same token, I’‘m absolutely convinced we can’‘t just solve this with a better SDLC. Too many old vulenrabilities, too much machine generated code, too many chances for human error.
My vote is firmly in shield then patch- preferably with the next generation web applciation anti-exploitation tools I call ADMP. If we were having this argument 10 years ago (more like 12-13) I might agree with you, but it’s too late.
The operational realities of the dozens to hundreds of end user organizations I talk to every year are just too down and dirty for what you’‘re suggesting.
@ rmogull:
I’‘ll continue to disagree that we have the time or resources to implement WAF to block any of those vulns quickly enough that we could have spent more time and resources on identification of root-cause and steps towards a better, more secure SDLC.
How long does it typically take to implement a WAF? Which vulnerabilities do they protect against? I think I know these answers. Do you?
We don’‘t need both WAF and secure coding… this is not correct.
Dre,
I’‘ll continue to disagree that we have the time or resources to fix all of those vulns quickly enough that we don’‘t need to put something in from of the web apps.
I used to think we could solve this all with good code development practices, but not any more for the reasons I outlined above. We need both.
@ rmogull:
Gary was picking on Max, not me. Nobody picks on me and gets away scot-free. I’‘ll keep trolling their blog until they go crazy. I have bots to help me and everything.
Also, on a very happy note, I really do think that Imperva SecureSphere is not only a silver bullet, but it’s also a magical silver bullet. In fact, I’‘d go as far to say that not using Imperva SecureSphere should be illegal, wouldn’‘t you?
I mean, it takes at least a year or two to fix any given SQL injection vulnerability, and developers are stupid, lazy, and annoying. Developers will never understand security, so we have to implement security IN THE NETWORK. The network is the computer, and network security is a magical silver bullet.
Note: someone on the Internet will fail to find any of the sarcasm in the above.
1) I never use the words “silver bullet” in thie post, so not sure of the reference.
1) Plenty of people ask for them or claim to sell them, every single day. Except they usually call them, “black boxes”. Usually it’s people that don’‘t understand the issues, because it’s outside of their domain expertise. Can’‘t blame them for that if their job is something else.
3) Or were you picking on Andre? I’‘m totally okay with that 🙂