Home > Information Security > “That’s Too Hard” Syndrome

“That’s Too Hard” Syndrome

November 19th, 2010

How many things DON’T we do because they’re “too hard”? For years, we’ve all thrown around “security best practices,” some of which are deeply embedded in the common infosec psyche (separation of duties) and others totally subjective in nature (Web app firewalls). I’ve had lots of discussions with smart people recently, though, that make me wonder – what “big gaps” are left? Have we solved most of the fundamental technical issues that plague security? I’ll go out on a limb and say yes. I think we have.

Keep in mind, there’s a big difference between solving the fundamental issue and implementing the solution. For example, we can inspect network traffic of any kind – there are plenty of tools (proxies, deep application-inspection firewalls like Palo Alto, etc.) However, getting those tools in place, working properly, and tuned correctly is a different issue. What about really high speeds? Easy to miss things there, too. That aside, though, what are we *capable* of doing that most of us are not, simply because it’s a lot of work? There’s a few areas I can think of right off the bat:

  • Application whitelisting: Even in a limited fashion (ie NOT replacing A/V entirely, just augmenting), most people aren’t doing this. Reasons I’ve heard include “too many different profiles”, “politics”, “maintaining changing applications” and too many others to count. Everyone in infosec acknowledges that A/V is not working well anymore (if it ever really did). We have solutions that could shore up our malware defenses, protect us from client-side exploits, etc. But…too hard.
  • Secure coding: A big part of the problem here is that developers are not security people. They don’t think the same way most of the time, and no amount of effort will probably change that. However, there are some fundamental things that keep showing up, time and time again. Buffer overflows and lack of bounds checking. Lack of input validation. Excessive privilege use. Dumb-ass comments and info in code. Josh Corman and crew are trying valiantly to instill some sense of responsibility with the whole Rugged movement, but it’s still a difficult thing to pull off in multiple ways. First, security people usually hate dealing with developers. Reason? Developers typically don’t like us. Second, developers are focused on functionality and speed. NOT security. Changing those priorities may take more than random acts of kindness. Random acts of ass-kicking may be more warranted.
  • Encryption: Encrypting hard drives with sensitive data should not be optional. We have SO MANY TOOLS to do this with now, this should be viewed as a mandatory exercise for organizations who give even the semblance of a %&*#. However, the deployment and management of this (and of course cost) often puts this one into the “too hard” bucket as well.
  • Outbound network ACLs and filtering: This is not, in fact, hard. But in order to do this, people will have to get off their ASSES, put DOWN the %*&#(% MOUNTAIN DEW, and go put a few rules in the ASA, Check Point, Fortinet, or whatever they’re running. “But it will break things!” Uhhhh, really? You’re going to “break” outbound IRC traffic? You really NEED people connecting outbound to SSH? If nothing else, filter on all IP ranges other than your own NAT’d space, so no one can spoof from inside. Filter out file sharing stuff, and unused or unallocated address space. Do NOT just allow everything out, that is bordering on irresponsibility, if you ask me.
  • Anal-retentive change management: Yeah, there should be an exception process. Shit happens. But unless you support a cowboy culture in IT, this should be at the very top of security’s priority list. You need approval workflow, audit trails, and details on what will happen, when it will happen, why it is happening, and what folks plan to do if things do not go as planned. Again, anything less than this in a production environment is flat-out pathetic.

There are plenty of others. What am I missing? What other areas do people write off as “too hard” that we should fight harder to get done?

Categories: Information Security Tags:
  1. Andre Gironda
    November 19th, 2010 at 16:43 | #1

    No. You’re not missing anything. You’ve very effectively cannibalized all of my ideas without credit. Thanks! (this is a joke because it’s really rare and very cool to see someone with the EXACT thinking that I do).

  2. November 20th, 2010 at 07:02 | #2

    metrics not automagically fed to us by A/V, Scanners, Patch Mgmt systems.

  3. Mike
    November 22nd, 2010 at 05:28 | #3

    Training. Too hard…too expensive….

  4. November 22nd, 2010 at 07:52 | #4

    How about just removing Admin rights from users… If I hear another “we can’t do that” I am going to explode!

  5. November 22nd, 2010 at 20:51 | #5

    Eliminando los derechos de administrador aseguras la red/sistema pero perjudicas al usuario al limitar su interactividad con la pc man

  6. December 2nd, 2010 at 08:17 | #6

    I like Pescatore’s term-“cult of the difficult problem”.

Comments are closed.