Stop Repeating the Same Mistakes

“That’s how we do it now.”  That bane of security analysts was repeated again this week as I assessed a new backup solution for virtualized servers.  The team implementing the change had already purchased a product, submitted the request-for-change for approval, and was anxiously awaiting my sign-off.  However, when I looked at the solution—a nice one, by the way—one critical piece was missing: encryption.  Not only wasn’t it planned, the team hadn’t even considered it.

It seems they assumed since the current, traditional backups weren’t encrypted, the new backup system didn’t require encryption either.  And it isn’t that these are dumb guys.  These might be the smartest engineers I’ve ever worked with.  They just didn’t think about it. 

So what was the problem?  Acceptance of the status quo.  If not pushed to add additional management tasks, if not encouraged to think outside the box, even the smartest—and typically overworked--network/server engineer will take the shortest route to the implementation of new technology.  The shortest distance often doesn’t include adding additional security.

Breaking these habits isn’t easy, even when you have a product lifecycle process in place like we do.  Assumptions are made based on existing implementations.  Problems arise only during the change approval process where security has to actually sign off.  Without that signoff, these issues might never come to light until a breach, an audit, or an accidental find by a security analyst working on something else.

In any case, here are some things you can do to avoid repeating the same mistakes:

  1. Include in your technical-level security awareness training a repetitive message about questioning what was done before.  Acceptance of previous approaches to implementing like technology should be questioned during any new system design process.
  2. Make sure the security team is involved from inception to implementation.  I know it’s sometimes considered cliché, but the assertion that security should be “built in” is still important and will remain so into the foreseeable future.
  3. Continue to work to make security just another requirement to include in the design process.  Adding security requirements should become automatic, even when a security professional is not at a design or solution selection meeting.
  4. Finally, make sure there is a process gate guarding actual implementation. which requires a security sanity check.  This helps detect design decisions that can slip through even the best solution development processes.

Copyright © 2009 IDG Communications, Inc.

22 cybersecurity myths organizations need to stop believing in 2022