Analytics
8/26/2013
05:31 PM
Mike Rothman
Mike Rothman
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Incentives And Organizational Alignment (Or Lack Thereof)

The lack of incentives for security effectiveness remains a problem for security professionals. Until we define legitimate success criteria as the basis to align the organization around security, nothing will change

Salespeople are very predictable. They will act in the best interest of their wallets, at all times. I don't say that in a judgmental or critical fashion; I'm just stating fact. That's why corporate executive teams painstakingly spend weeks generating sales compensation plans each year. The comp plan defines how the sales force will behave, what they will sell, and, more importantly, what they won't. If a senior team gets the comp plan wrong, the chances for success are limited.

It's just human nature. Incentives drive behavior. And such is the problem of doing security. What's the incentive for doing security well? How do you even know if you're doing security well? If you beat back the attackers, what happens? Nothing. Actually, you don't get kicked in the teeth that day. So there's that. If you miss something and it results in data loss or downtime, get ready to take your lumps. It's a thankless job. And your incentive to excel is keeping your job -- which on most days doesn't feel like an incentive, right?

So how do we solve this problem? We have to define proper incentives for a security team. It certainly can't be stuff that doesn't impact the business. So if your MBO is based on shortening patch windows or full AV coverage, that's a huge fail. How about a bonus for achieving PCI compliance? Yeah, since PCI is such a high bar for security, you should definitely be incenting the security team to achieve mediocrity.

Likewise, if your success criteria (and associate bonus plan) hinges on having no data losses or breaches, you are being set up for failure. The fact is incidents happen. Whether we like it or not. You could do everything right and still get pwned. You want an incentive plan that doesn't ignore failure, but also puts a bulk of the incentive on things within your control.

Given that fact, what would be most impactful to the business? Maybe time to remediate an incident? Set a baseline and set objectives for improvement. That would impact the business, no? Of course, that can be a little squishy, but you have to start somewhere. How about something that prevents train wrecks before the train leaves the station? By that I'm referring to application security. Maybe something like number of security defects identified and fixed before applications go to production. That's not exactly in your control, but it's pretty important to the business.

You can quibble all you want about whether your security awareness training helps secure your environment. Yet with rampant social engineering attacks, how can you not spend some time training the weakest link in the chain -- your users? How about tracking the results of your internal social engineering simulations and providing incentives for improvement in the rank and file?

And it's not just the security team who need incentives to achieve security objectives. What about the operations folks who drag their heels on a firewall change (or, even worse, make a mistake), causing a potentially exploitable situation? What is their incentive to take a chance the firewall change causes downtime by closing a critical port? And how do you expect developers to write secure code when their incentive is to ship working code on time and within the budget? Right, they won't. Incentives create alignment within organizations as well. Without that alignment, achieving security goals is mission impossible.

This sounds an awful lot like a metrics discussion -- and it is. We, as an industry, have done a poor job of standardizing on a set of success criteria that indicate acceptable security posture. Without that success criteria and accompanying metrics to drive that behavior, you can't really design incentive programs to get both the security team, operations, developers, and the employee base to do the right things.

By the way, it's not like I have a lot of answers to address this issue. In my varied travels, it's hard to find folks who are happy with the incentive programs for the security team. Incentives are either nonexistent or based on activity that doesn't really reflect security posture or help the business. Until we get a much better handle on these incentives, folks will continue to ignore the need to secure things. That means we'll continue to repeat Groundhog Day over and over again.

Although I guess we could go all Game of Thrones and parade the head of the latest phishing victim on a stick in the cafeteria. That would certainly get everyone's attention, no? Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
8/28/2013 | 12:29:54 AM
re: Incentives And Organizational Alignment (Or Lack Thereof)
Glad to see you raising this discussion. You're right that the current incentive infrastructure (i.e., nothing bad happened today so you get to keep your job) is a poor one. I'd love to see folks weigh in with some examples of successful incentives they've rolled out at their own organizations.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0103
Published: 2014-07-29
WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files.

CVE-2014-0475
Published: 2014-07-29
Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.

CVE-2014-0889
Published: 2014-07-29
Multiple cross-site scripting (XSS) vulnerabilities in IBM Atlas Suite (aka Atlas Policy Suite), as used in Atlas eDiscovery Process Management through 6.0.3, Disposal and Governance Management for IT through 6.0.3, and Global Retention Policy and Schedule Management through 6.0.3, allow remote atta...

CVE-2014-2226
Published: 2014-07-29
Ubiquiti UniFi Controller before 3.2.1 logs the administrative password hash in syslog messages, which allows man-in-the-middle attackers to obtains sensitive information via unspecified vectors.

CVE-2014-3020
Published: 2014-07-29
install.sh in the Embedded WebSphere Application Server (eWAS) 7.0 before FP33 in IBM Tivoli Integrated Portal (TIP) 2.1 and 2.2 sets world-writable permissions for the installRoot directory tree, which allows local users to gain privileges via a Trojan horse program.

Best of the Web
Dark Reading Radio