Security testing web applications and systems in the modern enterprise

When author Ric Messier approached his publisher about writing a book on security testing labs, he pitched it as a solution to two challenges security professionals experience every day: a lack of documentation and minimal funding.

"Documentation around performing tasks is useful for anybody who wants to set up systems -- either for themselves or for a business -- but documentation is really weak," Messier said. This is commonly seen in open source projects where significant changes from one version of the library or software are rarely reflected in documentation but can also be present in commercial options as well, he added.

The other issue is security is always seen as a cost center. "It costs money, and it never generates revenue," Messier said. As such, many security admins are left to set up their own security testing labs. But, again, doing so without proper documentation makes it a difficult -- if not impossible -- task to accomplish.

With these roadblocks in mind, Messier wrote Build Your Own Cybersecurity Testing Lab: Low-cost Solutions for Testing in Virtual and Cloud-based Environments. The book is geared toward people conducting security testing and setting up associated systems without a big budget.

Here, Messier explains why security testing web applications and systems presents a challenge to today's enterprises, as well as how security testing fares as DevSecOps, cloud and automation continue to take hold.

Why is the critical task of security testing so difficult for companies today?

Ric Messier

Ric Messier: A lot of companies push their own web applications, many of which contain some type of interactive component with a programmatic element that can lead to vulnerabilities and exposures.

Fortunately, companies are recognizing the potential liability and realizing they need to start paying more attention to security. We're starting to see a shift left in the software development lifecycle, where security is getting placed earlier in the cycle.

Unfortunately, not every company has the resources to apply expensive security controls, though they need to be testing to see whether their web applications or infrastructure are potentially exposed to vulnerabilities.

Along with this, we need more people to perform security testing tasks. But, if you don't have thousands of dollars to attend training courses, you need to learn in other ways. If you're capable of learning on your own, there are ways of setting up inexpensive systems and performing security testing to understand it more deeply.

Speaking of the shift left, how is DevSecOps changing the task of security testing web applications?

Click to learn more about
this title.

Messier: I've advocated going left from a software development standpoint for many years now, and I'm glad companies are starting to do it. Getting security earlier in the process is great. But companies must understand that it's not just 'OK, get a security person to look over requirements,' but rather understanding what the role of security is.

Security teams need to evolve, too. For a long time, security pros thought it was their job to just say no, which is not realistic or helpful. Security people need to see themselves as business enablers and understand that the company's going to go do this. So, let's figure out the best way to reduce exposures and vulnerabilities.

Another major shift in the past decade has been cloud. How does this affect security and systems testing?

Messier: To me, cloud is another form of outsourcing. What is different from a testing perspective is you are working in somebody else's infrastructure. Know that, when testing against somebody else's infrastructure, even though you're paying that rental of those systems, it's still their network. Make sure you have coordinated with the provider if you're doing any type of security testing against your cloud resources.

One of the major advantages of going to cloud providers is they give you abilities you may not have in-house. Cloud providers have many resources companies don't have. With cloud provider tools, you can do things like simple compliance checks or security audits.

From a testing lab perspective, if you want to learn about security testing or secure deployments, it's fairly inexpensive to get started, as an individual, with a cloud provider. You don't have to buy hardware or OS licenses or figure out how those works. For example, say to a cloud provider, 'I want a MongoDB instance to understand NoSQL,' and it's easy to have that system set up for you.

Another major trend today is the move toward automation. How is automation used in security testing?

Messier: A drive toward more automation ensures testing gets done in a repeatable, consistent manner. We can validate a) that it's been done, and b) that it was done the same way the last time. Once you know that's been done the same way each time, you can compare results and see what your progress is.

However, I keep seeing customers who want to buy an automated tool, press the button and go. That's not really security testing because there's all sorts of things an automated tool simply can't test. Don't get me wrong: Automated tools are awesome, but they're only a start. They don't know the code, which a person embedded into the software development lifecycle -- like a DevSecOps team -- would know. There are always going to be places automated tools don't get, which is why learning security testing at a deeper level is so important. You can do the manual work that's essential after the automated tools are done.

Cloud and DevSecOps are really driving us toward automation. Cloud providers have resources businesses don't have -- they can bring automation and nice interfaces. That's really the advantage of it: using somebody else's resources with all the automation and functionality that you probably wouldn't get on your own.