Information Security's Silver Bullet: There Isn't One

Back on June 27, 2008 ComputerWorld published an article "Web firewalls trumping other options as PCI deadline nears" just before the well known June 30, 2008 PCI 6.6 deadline. In February of 2008, the PCI Council published clarification on the PCI DSS section 6.6 and what the intent of it was. Over a year later, I frequently encounter Web applications that are far from compliant and this is no surprise. What is (sort of) surprising, is the false sense of security people have with PCI after completing their self-assessment questionnaire (SAQ) and dropping in a Web application firewall (WAF) thinking they are secure that is still ubiquitous.

Year after year I interface with individuals that think there is a single silver bullet to solve their information security concerns. Have they been misled somewhere in the past? Are they simply uninformed about security and the attacks out there? In a past web application review, my user ID was passed through the URL (example: http://www.website.com/index.php?uid=swhite) and I trivially changed it in my browser to "admin". This in turn allowed me to view over 11,500 files containing sensitive information on customers. A Web application firewall more often than not would not have caught this more than likely valid request, and allowed for identity theft with the information I was able to obtain.

ComputerWorld's article makes me nod my head, but at the same time, question the expertise of who is writing it. For example, they mention that web application firewalls can protect against things such as sql injection, buffer overflows, and cross-site scripting. The OWASP Top 10 list (2007 and 2004) doesn't mention buffer overflows and the PCI DSS section 6.6 specifically calls out Web applications. Buffer overflows in Web applications themselves are very unlikely to be exploited outside the capacity of a denial of service attack, but would more likely target a web server or other service running. As one who hosts web applications, I would worry about injection flaws and XSS before buffer overflows. I'm not sure why the author of the article included buffer overflows other than it is a buzzword for some people that makes them think security.

As a security professional, I commonly have to describe very technical issues in "normal people" terms. For information security, a field that has very techical aspects, non-technical individuals should understand that there is no single silver bullet to solve your security issues. Just as throwing up a WAF in front of your Web application that handles PCI data isn't the best (not necessarily least expensive) approach to complying with PCI DSS 6.6, that seemingly simply and one-time solutions to write off security concerns are not in accordance with industry best practices.

Defense in depth should be employed so that your resources are protected when preventative measures may fail, to ensure that you are protected from zero-day to patch day or until the controls are operating properly again. If at the end of the day, you learn one thing, let it be that there is no single solution to information security, or everyone would be doing it and the solution would be spreading like wildfire.

Read more!

Quick Trac Backup and Upgrade Script

Trac is an open source, web-based project management and bug-tracking tool. The program is inspired by CVSTrac, and was originally named svntrac due to its ability to interface with Subversion. It is developed and maintained by Edgewall Software.

When using trac, its often that you will have to upgrade to different versions, create backups and everything else. I just wrote a quick little script to do it all for you. Enjoy.

#!/usr/bin/python
import subprocess
from time import time
# TRAC LOCATION HERE
trac=("/var/local/trac/trac.website.com/")
# BACKUP DIR HERE
backup=("/home/yourname/tracbackups/")
# set time for directory
timesave=time()
print "Upgrading Trac..."
# Easy Install Trac just in case (wont erase anything)
subprocess.Popen("sudo easy_install Trac", shell=True).wait()
# STOP APACHE
subprocess.Popen("/etc/init.d/apache2 stop", shell=True).wait()
# BACKUP TRAC
subprocess.Popen("trac-admin %s hotcopy %s%s" % (trac,backup,timesave), shell=True).wait()
# UPGRADE TRAC
subprocess.Popen("easy_install --upgrade Trac", shell=True).wait()
# START APACHE
subprocess.Popen("/etc/init.d/apache2 start", shell=True).wait()
print "Finished upgrading Trac..."

Read more!

Data Analytics to Detect Fraud

Some say that detecting fraud is fraud is like finding needle in a haystack. Often times this is true, but more often you don’t even know what the needle looks like or what haystack to look in. To overcome these obstacles data mining techniques can be used. One of the ways that is very powerful is data visualization. Using this technique you can “see” the anomalies much easier than just staring a list of numbers.

One of the earliest, but still powerful analytic like this is called “Benford’s Law” – also called “Digital Analysis”. The basic premise of this law is that certain leading digits in any random set of data will appear in a specific non-uniform manner or in a certain frequency. Anything that is outside that frequency indicates a non-compliant anomaly. For example, if an employee has a limit of approval of $5000, you might see a spike in the first two digits of “48” or “49” that is beyond what Benford’s law says it should be.

There are some great tools out there that can let you apply this to your data – including MS Excel (click here).

Read more!