Month: December 2015

Bored with Tufte? Looking for new horizons in data visualization? Bunky, look no farther than FiveThirtyEight’s “47 weirdest charts of 2015.” Including a pictographic of a marijuana leaf, multiple uses of lifeline charts and some stuff that must make Edward Tufte hold his head and groan, like the Twitter visualization above.

I miss writing here. I write a lot on Facebook, some on Twitter, and a few things on my company’s blog. But it’s very rare that I write anything under my own name any more.

My New Year’s resolution is to change that. Gonna see if I can write something every (week) day here. Starting with today’s post (which could have gone on my company’s blog) but hopefully with a broader focus as time goes on. Let’s see how we do!

Admittedly, I come to the topic of information security with a very narrow perspective—a pretty tight focus on application security. But within that topic I think I’ve earned the right to cast a jaundiced eye on new offerings, as I’m going to celebrate my eighth year at Veracode next month. And I’m a little disappointed in this aspect of the book.

Why? Simple answer: it’s not practical. The authors (Umesh Hodeghatta Rao and Umesha Nayak) spend an entire chapter discussing various classes of threats, trying to provide a theoretical framework for application security considerations, and discussing in the most general terms the importance of a secure development lifecycle. But the SDLC discussion includes exactly one mention of testing, to wit, in the writeup of Figure 6-2: “Have strong testing.” And an accompanying note: “Similarly, testing should not only focus on what is expected to be done by the application but also what it should not do.”

Really?

It’s pretty widely understood in the industry that “focus(ing) on what is expected” and “[focusing] on what [the application] should not do” are two completely different skill sets and that even telling a functional tester what to look for does not ensure that they can find security vulnerabilities. The problem has been well known for so long that we’re nine years into the lifespan of the definitive work on the subject, Wysopal et al’s The Art of Application Security Testing. But there’s no acknowledgment of any of the challenges raised by that book, including most notably the need to deploy automated security testing to ensure that vulnerabilities aren’t lurking in the software.

As for the “eight characteristics” that supposedly ensure that an application is secure, take a look at the list for yourself:

Completeness of the Inputs

Correctness of the Inputs

Completeness of Processing

Correctness of Processing

Completeness of the Updates

Correctness of the Updates

Maintenance of the Integrity of the Data in Storage

Maintenance of the Integrity of the Data in Transmission

Really? Nothing about availability. Nothing about authorization (determining whether a user should be allowed to access information or execute functionality). Nothing about guarding against unintended leakage of application metadata, such as errors, identifying information, or implementation details that an attacker could use. And nothing about ensuring that a developer didn’t include malicious or unintended functionality.

The chapter also includes no mention of technologies that can be deployed against application attacks, though this may be a blessing in disguise given the poor track record of web application firewalls and the nascent state of runtime application self-protection technology.

All in all, if this is what passes for “state of the art” in a security curriculum from the second biggest textbook publisher in the world, I’m sort of relieved that information security isn’t a required curriculum in a lot of CS programs. It might be better to learn about application security in particular from a source like OWASP, SANS, or your favorite blog than to read a text as shallow as this.