Thoughts on Incentives Driving Bad Security Behavior

Harry Truman once said “Give me a one-handed economist! All my economists say, ‘on the one hand…on the other hand…'” I am quite frustrated by the state of affairs in the IT world, and I gave a presentation on it at the Tactical Edge conference in Colombia. (Note: this was my first conference presentation and I consider my thoughts on the matter to be half-baked, at best right now, so adjust expectations appropriately). The premise of my presentation is that we need more sophisticated IT and IT security people, who are able to effectively understand and communicate risk. In particular, I believe that many IT people, and even many IT security people, do have have imaginations sufficient to envision the ways things can fail, and the extent of harms that can come.

Since giving the presentation, I’ve talked with many people about my ideas and their experiences in various organizations and I’m beginning to realize that there may not be much desire to improve the situation. In many organizations, performance is judged by accomplishments and efficiency, rather than on some obscure, hard to measure thing like “security”. Spending too much time on assessing risks slows progress on important projects, and trying to account for the many “bad things” that can happen to a system, but probably won’t, is not efficient. This situation is a gamble; trading off the perceived remote possibility of a bad thing happening for the certainty that comes with not meeting business objectives. Viewed through this lens, the less IT managers know about risks, the better off they are, since ignoring known risks moves a person out of the realm of “ignorance” and into the realm of “negligence”.

I’ve had this view that we collectively want and try to improve, but now I am not so sure.

If you’re interested, here is the video and the slides from my presentation. I am going to make some significant updates to the content in the coming months, as well as improve my presentation abilities, and hopefully deliver this again at some upcoming conference.

I think the bigger problem is communication. I don’t know of any C-levels that care much about the nuances of data-at-rest or data-in-transit and how those things impact the risk inherent in an application for an organization. I know a ton of C-levels that care about a 4% fine against revenue or a risk of loosing a significant percentage of trust through bad publicity.

That being said, I don’t think we’ve come up with a great way to communicate the need for security to be part of the architectural design and implementation of solutions for the organization. DevSecOps is getting there, but DevOps seems to have the priority in most organizations. Your post regarding better, more action and architecturally focused policies seems to be on the right track. We need to communicate the real need in a way that those who will be responsible for making decisions and taking actions related to that need understand what needs to be done.

For a C-Level that becomes communicating the solutions to business risk in way that emphasizes security’s need to be heavily engaged in the process from beginning to end. For the day-to-day techs it is writing policies and that give them tangible actions to take when building or deploying solutions while also giving them access to security engineers who can point out and support holes in the security of their solutions.

I’m sure this is barely scratching the surface and since I haven’t watched your presentation yet I could be a million miles away from your point. But your posts and thoughts always have me thinking and I thought I’d throw my hat into this discussion!