Home > Information Security > What’s New is Old, Actually

What’s New is Old, Actually

October 25th, 2010

So much like many geeks, I’m a packrat. And like any good obsessive personality type, I have some vaguely defined mental threshold where I need to go through a bunch of shit and evaluate what I can *possibly* throw away. “ISDN for Dummies”? No way! That stuff is coming back in a big way, I can feel it.

This past weekend, I apparently hit the weird mental threshold and had one of those mildly obsessive episodes where I started rooting through my home office looking to see if I could toss anything. In the process I discovered a small box of 12-15 Information Security magazine issues dated between mid-2001 and early 2003. And what a field day I had – from vendor ads (CyberGuard! NFR! Pentasafe! Bindview!) to great interviews (a favorite was one with Brian Martin (aka Jericho from Attrition) wearing a *black* bowler hat, and holding a *white* one…oooooh – is it Clockwork Orange, Jericho-style? Or a serious point we’re making!?), that trip down memory lane was a blast.

But then…things changed. I started reading, and became a) concerned, b) depressed, and c) pensive and confused. Why? What, pray tell, could get Shack in such a state? Easy – the realization that we are sucking. SUCKING, PEOPLE. A few article titles:

  • “New Directions in Intrusion Detection” (August 2001): Problems with false positives? Yep, we still have those.
  • “Mastering Your Own Domain” (August 2001): A plea to adopt DNSSEC. Heh, guess we missed that one.
  • “Feeling Vulnerable?” (Feb 2002): Sound vulnerability management practices can help cut down on alerts. Yep, this has really taken hold.
  • “IDS at the Crossroads” (June 2002): Marty, Ranum, etc talk about how the IDS is evolving. Yep. It’s evolving.
  • “The Web’s Future Passkey” (June 2002): SAML will save us all on the InterWebs. Really – it’s simple.

Also mentioned were the Cisco SAFE “blueprint” (snort), the criticality of patching and configuration management, “best practice” firewall architectures using a “3-legged DMZ” design, etc.

So, back to sucking.

We are not innovating. We’re changing implementation tactics, sure. We knew about firewalls, patching, encryption, IDS, etc in 2001. And almost 10 years later, we’re still talking about them. And doing an arguably terrible job of implementing, tuning, and maintaining all of them. Do we have new threats? Gawd yes. Web app blah-blah-blah, Botnet blah-blah-blah, DNS is broken, SSL is broken, etc. The majority of which…wait for it…we KNEW ABOUT IN 2001. Modified? Sure. New? No.

I went to a customer site in the last week to go over a pen test report. 12 people in the room. Some choice comments:

“We know we’re not doing a good job of patching”

“How did we miss those VNC installs?”

“Wow, we didn’t even know that box was out there”

What are we doing? You may argue that our greatest failure is technological in nature. I’d argue otherwise. Our greatest failure is our ineptitude to actually convey the magnitude of the issue, what is wrong with IT in general from a security perspective, and then really get people on board with what it will take to fix it. In other words, it’s a people problem. And until we get better at dealing with people, we will stay in this vicious cycle of very basic security practices being debated endlessly, while some dumbass out there thinks WEP stands for “Widespread Exceptional Protection” and keeps using it. Ugh.

Categories: Information Security Tags:
  1. philA
    October 25th, 2010 at 20:44 | #1

    Oh Dave. You’re missing it.

    What doesn’t work, doesn’t get adopted.
    What is ahead of it’s time, gets reinvented and then adopted.

    So much of what we thought *should* work back in the day, didn’t. And other approaches are just now catching on.

    Heck, look at application security. I remember Caleb mentioning a Cobol book from the 70s basically referencing the SDL. Boom. It only took at 30 years and here it is. Easy sneezy right?

    Have faith.

    Be like water.~Bruce Lee
    http://www.youtube.com/watch?v=iO3sBulXpVw
    “Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Now water can flow or it can crash. Be water, my friend.”

  2. Andre Gironda
    October 25th, 2010 at 21:35 | #2

    And yet OpenBSD has only had 2 security-related bugs in 15 years.

    And yet the DJB tools have had a very small amount of security-related bugs.

    How many infrastructures have you seen lately that run fully CIS-benchmarked Apache-SSL on OpenBSD? djbdns on OpenBSD? How many ISV OSes and apps that run common infrastructures have implemented the principles and/or controls inherent in OpenBSD or djbdns?

    We have OSes and apps that are easy to secure (mostly because they are “default secure”), but they are not popular. The concepts used to build them are also unpopular. OpenBSD keeps its claim to fame because of the hours of secure code review that went into it. djbdns got its fame because of its relation to qmail. What qmail did was very fascinating.

    After reading, “Thoughts on Ten Years of qmail Security”, Daniel Bernstein outlined 3 steps to secure software: 1) Eliminate bugs from code, 2) Eliminate code, and 3) Eliminate trusted code.

    Steve McConnell, author of Code Complete, Rapid Development, Software Estimation, etc — has outlined exactly how to significantly reduce bugs in code. The summary: get eyes on the code; get the developers thinking about the code. This can be done with code review, static analysis, design-driven testing, test-driven development, behavior-driven development, design review, desk checking, pair programming, prototyping, integration testing, system testing, regression testing, low or high volume beta tests, etc. PICK ONE — or better, pick a few.

    Here are some other suggestions that I just came up with for common application security vulnerabilities:

    Got SQL injection? Try NoSQL.

    Got Cross-Site Scripting? Try moving all of your Javascript onto its own subdomain (js.domain.com) and payment gateway portals to their own subdomain (ssl.domain.com).

    Got authentication issues? Try OpenID.

    Want to get ideas about how to implement data validation, contextual encoding, or whatever other appsec control? Try OWASP ESAPI.

    Got buffer overflows? Move to Ruby/Python compiled bytecode, Mono/.NET, or Java Standard Edition.

Comments are closed.