Manage Learn to apply best practices and optimize your operations.

Web application security best practices: Tips on implementation

Web application security tools and services continue to grow in popularity, thanks in large part to the Payment Card Industry Data Security Standard (PCI DSS). But there's more to Web application security than just complying with PCI.

In this video, Hugh Thompson, founder of People Security, discusses Web application security best practices. Learn how tools like Web application firewalls fit into an overall security effort, how to position Web application security tools to customers, as well as how Web application security tools fit into the regulatory landscape.

Read the full transcript from this video below:

Web application security best practices: Tips on implementation How should VARs position Web application firewalls to their customers, and what kinds of services or add-ons could they provide?

Thompson: I think it is important when you’re positioning a Web application firewall for a customer that you tell them where this fits in with their overall strategy of application security. There’s a tendency to think that application security is one of those problems that there’s a silver bullet for; I can buy a tool, I can buy a process, I can buy something that is going to absolve me of problems. A Web application firewall is an important piece of an overall solution against security vulnerabilities and security risk, but it’s only a piece of the solution.

The way I think they should position it is, “Here is something on the outer edge to protect you against some of the low-hanging-fruit attacks; some of the attacks that we’ve see very often that are very, very common, very generic. But if you’re really looking to get confidence out of your software, you need to couple that with a real software development strategy around security.” When it comes to application security, what should VARs be focused on? Are there particular technologies or certifications that can help them bolster their skills?

Thompson: From a certification standpoint, I think it’s important that they’re familiar with the concepts of security, in general. Unfortunately, there’s not a great one that will give them everything they need to know. The CISSP and development offshoot of that are both very interesting, not because they give you the exact skills that you need to be able to do the job that you’re asked you about, but they at least give you some broad perspective about security and help instill a healthy paranoia, which is a valuable skill when you are talking about security. I think that definitely helps.

From a technology standpoint, I think it’s important to familiarize yourself with the processes of secure software development. There is a fair amount of processes that have been released over the last couple years. One that I think is very broad and very, very useful, especially from an educational standpoint, is to look at Microsoft’s SDL, their Security Development Lifecycle. They’ve gotten a host of elements --like threat modeling, source code scanning, architectural security review -- that will really give you an idea of the types of things that customers should be doing through the software development lifecycle. What is the regulatory backdrop for, or what are the reasons, why users need to lock down applications?

Thompson: From a regulation standpoint, software security is very interesting. There’s some regulations that are starting to explicitly address software security, PCI being one of them. The way it addresses it right now is a little too superficial for us in the software security field, but it’s getting there; it’s a living standard. There [are] clear indications that it’s going to mature even more on that software security angle, so there is definitely a driver from PCI. Some of the other standards that are reasonably vague, even something like Sarbanes-Oxley; if you read the actual law, it’s very, very vague about what you do, even from an IT perspective.

If you think about the implications about what it says: Trust, integrity in data that’s flowing through the enterprise. There is no way you can make any reasonable attestation about that integrity unless you shore up the code of applications that the data is flowing through. From that perspective, software security is critical. I think as we go down the road, you’re going to see a lot more auditors that are going to start asking security-relevant questions as they start reinterpreting some of these standards that already exist. How can VARs sell this issue of the regulatory necessity of software security to their clients?

Thompson: I think one step is PCI, just because it explicitly calls out some sort of security element. Unfortunately, PCI, right now at least, references Web applications. That really is unfortunate, because from a risk perspective, you’re probably looking at many, many more lines of code that you should be concerned about than just a code in a Web application; but it’s a start. I think I would use that as an indicator of things to come.

If you look at how PCI has changed over the last three years, you can see a definite, unmistakable, unambiguous trend to get more specific around software security. It’s definitely not where it should be, but that trend is a valuable piece of evidence when you’re talking to folks about compliance and software security, because it tells us that there’s an overall maturity that’s happening in the industry. If you look at business customers, the questions that they’re asking of their software vendors and providers, we’re starting to see a lot more security-relevant questions show up in things like RFPs and RFIs. That just shows that as an industry we’re maturing; we’re asking good, interesting, important questions. It may not just be compliance that they should be really worried about; it might be even making sales to their customers. It is a big issue. What particular Web application security attacks should VARs focus on?

Thompson: A starting point would OWASP Top-10, but again, that is not the be-all-and-end-all of possible attacks that can be leveraged against the enterprise. If you’re talking to somebody that’s new in software security -- they may be a group that’s building applications internally; they might be part of a CTO’s office, for example -- I think it’s important to at least express to them what the consequences of some of these vulnerabilities are. I’m sure most people have heard about SQL injection, cross-site scripting, buffer overflows, but very few have internalized what those mean from a risk perspective.

As a VAR, I think it’s exceptionally important to take those vulnerabilities and make them concrete, from a risk perspective, to the folks that are looking at their services. Tie it to their business; show them what the potential is, not from a fear, uncertainty and doubt perspective, but just from a reality perspective. I’d also gather some data on attacks that we’ve seen over the last couple of years. The data is really fascinating and really alarming if your goal is to protect a business.

View All Videos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.