Firewall request gets third degree

Other departments frequently ask me to approve firewall modifications to allow applications to "talk" to one another. This past week, one of the business units asked permission to open our external firewall to enable a business partner to transfer data to one of our quality assurance (QA) servers for testing.

This request was related to our education sales Web site. We sell online, in-house and computer-based training materials, as well as books and other publications, all geared toward teaching customers how to use our products. When revenue generation is involved, my review is more thorough, and that was my approach this time, even though it was for a QA environment.

I asked to see the network diagrams, data flows and the nature of the data to be transferred. While these are vital elements for deciding whether an external entity will be allowed to transfer data to our company, I usually ask for this information even when the request is internal.

By reviewing the network diagrams, I was able to learn about the other resources that are trusted by the QA server and environment. Sometimes network diagrams show that other critical servers or networks trust the affected system. If a server that's trusted by another sensitive resource is compromised, it's a trivial thing for a hacker to take advantage of that trust relationship. For this environment, the QA server was on a segregated network shared only by another QA server, which had been set up as a standby.

As for data flows, they depict how data moves from one entity to another within an application. They usually show information about things such as encryption, data in transit, data at rest and backup. In this case, I wanted to understand how the data would get from the external partner to our infrastructure, where the data would move to within our environment and, of course, the nature of the data.

From a legal and privacy perspective, the nature of the data that will be transmitted is probably one of the most important factors. The business units always play this down, suggesting that it's "just some data." But "just some data" usually turns out to include private information. In this case, there were customer names, mailing addresses, e-mail addresses and phone numbers. We have agreements with other vendors to sell our training materials, and this particular request entailed the vendor sending enrollment data from its site, where the training was purchased, to our site.

For this application, I insisted that the data in transit flow from the external business partner to our QA server over an encrypted format such as Secure Sockets Layer (the HTTPS protocol). And I was uncomfortable with the idea of all the customer data residing in plain text within the database, so several of the fields have to be encrypted.

In addition, I ordered a vulnerability assessment to be performed against our QA environment. The QA environment is supposed to mirror the production environment, so an assessment of the QA server would indicate what to expect within production.

Assessing Vulnerability

The vulnerability assessment entails running a couple of tools against the QA server. The first is Nessus, a freely available port scanner that typically indicates how vulnerable the server is to some common threats as a result of configuration errors, outdated patches or other vulnerable services. The other is an application security scanning tool that assesses the application (as opposed to the server and operating system) for improperly coded applications or improperly configured Web servers.

The vulnerability assessment found that the only glaring hole for this application was in the Apache Web server, which was configured to display directory listings. This is a common configuration error within the Web server software. With directory listings displayable, a would-be hacker could find some files containing sensitive data and gain unauthorized access. The fix is simple: You create a file called .htaccess and place a certain directive within that file that prevents the directory listing. The directive is something similar to "IndexIgnore *" with the asterisk serving as a placeholder for any of many approaches to limit access or viewing of directories using the browser.

I also asked to see the business partner's network diagram. Not surprisingly, the company didn't want to reveal its inner workings, so it required me to sign a nondisclosure agreement, which I readily did after it was reviewed by our legal department. I also requested information that would assure me that the vendor's infrastructure was secure. In cases like this, I would really like to conduct an assessment of the partner's site, but our legal department has said no to that type of thing, apparently not wanting to chance that we might mistakenly "scan" or run penetration testing against the wrong site.

We could have hired a third party to do an assessment for us, but the vendor had just received a WebTrust certification. That's an attestation by management that the systems in question are protected against unauthorized access. Typically, a company will hire a Big Four consulting company to come in, complete a thick questionnaire and run a couple of security scans. If everything looks good, and you've paid your $20,000 bill, the consulting firm will allow you to put the WebTrust logo on your Web site.

After all was said and done, I was satisfied with the results from the follow-up assessment and I allowed the firewall rule change. The next step is to assess the production instance of this application, since I can't assume that the production environment is configured identically to the QA.

Join the newsletter!

Error: Please check your email address.

More about Apache

Show Comments

Market Place