Top Five Things I’ve Learned in Enterprise InfoSec

Thursday, September 30, 2010

Robb Reck


Below are the top lessons I've learned while providing information security to enterprises. The focus here is on people and process. None of them are technical in nature. Technology is the easy part, which almost everyone can get right.

Below are lessons I believe differentiate an average information security department from an excellent one.


Remember, you exist to serve the organization, not to hold it hostage. I have run into many corporations where information security is the bully down the hall who others simply want to avoid. Customer service is not just for customer service representatives.

Effective information security practitioners will be responsive. When a security question/concern/need comes in, it is addressed in a timely manner.

An information security department which is regularly failing to respond to their customers (usually, the rest of the business) within their SLA, can expect the business to start trying to circumvent information security.

While working for a SaaS provider, I saw dozens of buyers from large enterprises attempt to circumvent their own InfoSec team's security assessment of us.

The buying entities in the company wanted the product, but didn't want to deal with the long wait times, large price tag, and project headaches that came along with InfoSec involvement.


Don't be a "Department of No." A collaborative, problem solving attitude can change InfoSec from being perceived as project killers into teammates with the rest of IT. IT staff are generally pretty creative folks.

Whether they're designing new software, new network architecture, or AD schema they want to make something great.

When we continually shoot down their designs and ideas, we either discourage them from using their creativity or we encourage them to find ways to circumvent InfoSec altogether; both of which hurt both the company and the InfoSec department.


Be slow to say "No," but not afraid to say it. As I mentioned before, if we react to new designs and ideas with an immediate "No," we run risks.

But the reverse is also true. Like it or not a part of our job is to stop activities and systems that put our company at greater risk than we're willing to accept. Becoming a rubber stamp department is not acceptable.

I have seen organizations where the information security department exists more for show than to secure the company, and it is just as dysfunctional as places with a "Department of No."

As information security professionals we have an obligation to be more than a figurehead. As a CISSP I am bound by ISC2's Code of Ethics, which requires I "provide diligent and competent service to principles." I can hardly call my work diligent if I am simply approving everything to keep my customers happy.


Learn from your IT technical staff. Listen to them and ask them questions. Engage experts from all IT disciplines in the InfoSec process.

I have found that many of the best security initiatives have not come from folks within the InfoSec department, but from the highly technical staff working directly with their technologies.

Including the IT staff in InfoSec projects will do more than provide you with knowledgeable, creative assistance on your initiatives. It will also help you develop good relationships with those technicians, and get their buy-in for the security solutions you implement.


ROI doesn't always matter. We are taught that risk assessments and IT decisions are financially based decisions. And that's certainly true in most cases. But every organization (and its leaders) has its own set of priorities.

There are areas where the human element comes into play and they don't want to hear about ROI, they simply want it done their way.

Example A: The CIO at your organization previously had power outages that caused massive data loss and reputational damage to him.

That CIO now demands full power redundancy and battery backup on all systems containing data. You can make a case that the ROI isn't there, but in the end, that's not what is powering this decision.

Example B: An organization has tried putting IPS devices inline before and seen it bring all internet connectivity to a stand-still. As a result, they are unwilling to implement them again, even though they see that the cost for the devices is low and the potential impact of an incident high.

The ROI might make sense, but for this organization, it's simply not going to happen.

I am not suggesting that we let an organization remain locked in their personal prejudices. But I've learned that the right solution isn't just throwing up a graph showing how the dollars work out, and how clearly we should follow my plan.

The process takes times and trust from leadership, both of which are important commodities to use wisely.


I am interested in hearing your thoughts on the biggest lessons you've learned in implementing and managing information security. Please share in the comments below.

Cross-posted from Enterprise InfoSec Blog from Robb Reck. 

Possibly Related Articles:
Security Management
Post Rating I Like this!
Andy Willingham Robb, great article. Just in case you're interested we talked about it on our podcast this week. It's in episode 31. Should be out later this week.
Robb Reck Thanks for the kind words Andy. I'll look forward to checking out the podcast.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.