Ninjas and Accountants

We’ve talked about reasons IT security can fail and suggested the industry needs to do more. So what else can be done and why is the industry not stepping up?

I’d say it comes down to misunderstanding of what security is, an underestimation of risk, and misapplied resources. Organizations are deploying ninjas and accountants to solve their security problems and while these roles are important, they’re insufficient to secure a decent sized organization. I think we need a broader approach. Organizations can apply with a security framework like  ISO 27001, which includes items like leadership alignment, planning, and risk assessment to jumpstart the process.

Guidance helps because even experienced IT leaders don’t understand security very well. They tend to regard security as another technical problem in their technical environment. So they buy and configure technology, and as with other technologies, they’ll find a technician to run it.

They’ll look for the most technically proficient engineer they can find with broad understandings of the components of security – a ninja. From the organization’s perspective, this ninja should be skillful, protective, and most importantly, silent. For many organizations, it’s most convenient if the ninja not ask people to change areas like applications, architectures, operations, or human behavior to be more secure. Better that they do their work in the shadows and not bother anybody.

IT leaders often give minimal guidance and support to these ninjas. This isn’t so much because they don’t want to, but rather because the leaders don’t know what support is required. Ninjas tend to say little because, speaking in broad generalities, they’re not always the most social type. They enjoy security and like to focus on their jobs, which means they prefer to minimize talks with the boss. This creates an environment of de facto benign neglect.

OK, to be fair, it’s not total neglect. IT leaders often apply the IT security aspects of regulations like Sarbanes-Oxley, PCI, GLBA, and HIPAA, not least because they’re required to and they’re told it’s the right thing to do. These regulations include guidance that represents a minimum bar for security configuration. They’ll use accountants, i.e. security auditors, to create a “security by checkbox” approach to verify what the ninjas have done.

While this is useful, it is insufficient to ensure security of an environment. Truthfully, the bad guys know all about the regulations, see their weaknesses, and are expert in exploiting organizations that stop there.

To see why security by checkbox isn’t enough, let’s imagine we’re leaders of a country that wants to defend itself.

If we were to take a similar approach to defending our country, we might imagine that we want to be safe from an enemy army. We look at other armies and see they have a lot of people with guns. We decide to mirror them by buying guns, training people, and deploying our army on the frontier. We’ve spent a lot of money and see people with guns so we assume we’re safe.

Simultaneously, we have a previously unknown enemy who sees our activity and looks for weakness.

We haven’t thought about who our enemy could be or created an intelligence community to find out. We haven’t considered what’s most at risk in our country or established foreign relations with our neighbors for support. And finally, we have the army but we haven’t really committed to being safe, which means we’ve underfunded the effort.

Essentially, we’ve spent a lot of money to give ourselves the perception of being safe.

This means nothing to our enemy. He easily finds a weakness and we’re surprised when he’s rolling through our capital city. Worst of all, we knew about this weakness but were unwilling to fix because it was too much trouble.

This what happened with the Maginot Line, France’s ineffective defense against Germany, leading to their quick loss at the beginning of World War II. Sad story.

Does this remind you of some of the massive surprise data losses we’ve seen recently?

Our takeaway is that a false sense of security is worse than no security at all, and that deploying assets without a  strategic plan – security by checkbox – is an invitation to loss.

Most organizations already know this, even if they don’t appear to. After all, skilled business managers wouldn’t apply only ninjas and accountants to new product development, customer service, distribution, or sales. Instead, he would create a structure around those business processes to ensure their resiliency and ability to adapt to changing conditions. He knows this is necessary because he’s been steeped in capitalism’s competitive culture. He also knows that he will go out of business soon if he doesn’t take care of his business processes.

Computing has become the backbone of many organizations’ business processes, yet it has not been subject to the same discipline as other processes. I’ll discuss this in detail in a future post, but it basically boils down to that benign neglect. IT workers and consultants often know there are problems and could do more, yet they often find it easier to keep quiet, mostly because they’ve found business leadership isn’t open to the discussion. Business leaders have not awakened to the need to apply the same discipline to computing as the rest of their processes. And in the end, ninjas and accountants won’t get it done.

I recognize that it’s hard to do something like this from scratch and security frameworks are a helpful way to start. Even so, they still only provide some basics and organizations must apply their own discipline to ensure proper security, both protecting and enabling the business.

The Myth of Security Governance

Security governance has become a hot term within the IT industry as people awaken to security threats presented by the internet. Yet the meaning of this term varies depending on whom one talks to, which often leads to confusion.

One meaning pertains to the application, maintenance, and continued risk evaluation of people’s access to information within an organization. This is about answering “who has access to what, why do they have it, and what have they done with it?,” which is a component of a compliance programs for regulations like SoX, HIPAA, and PCI.

In this context, governance is about enforcing accounting-style rules within IT environments to ensure proper data access. At a higher level it helps ensure legitimate system use. This is a useful and necessary process so information consumers stay on the straight and narrow. It is also how the IT industry most vocally discusses security, especially with regulated businesses.

However, it is a mistake to believe these processes, and regulatory compliance overall, is sufficient to ensure system security. There are numerous examples of regulation-compliant organizations that have fallen victim to massive hacks, clearing demonstrating this point.

I believe it’s more useful to regard security governance as an approach, structure, and rules for stewardship. Effective governance should protect an IT environment from unexpected behavior, be it human or technological, with the goal of protecting the organization using this technology.

It’s useful to think of this stewardship-style of governance like parenthood. A good mother or father wants to know how their child is behaving and who they’re spending time with. Rules are set to keep this behavior within acceptable boundaries. Hopefully these rules will be backed by teaching of good values so the child is motivated to good behavior and not to hurt others for personal gain.  They should be effective at detecting, responding to, and hopefully preventing undesired behavior but not so onerous that they prompt rebellion or crush the child’s life.

I’ve found that the most effective organizations take a similar approach to IT security. They understand their business goals, how they’re IT supports them, the risks presented to the IT environment, and then match their security governance program to protect against those risks. This motivates people’s “good behavior” while discouraging any desire for harm. Effective organizations also take advantage of IT security to drive top-line revenue and lower bottom-line cost, even as the IT environment is well protected.

Security governance as regulatory compliance – the approach software companies and consultants find easiest to sell – helps with some aspects of data protection. Security governance as stewardship enables the organization, even as it’s protected. It takes additional effort, not least in aligning the organization to these goals and in finding people with the right perspective to assist. I’ve found it’s always worth the effort though.

You may enjoy the wonderful article at about the challenge of getting people to take security seriously.

In the end, it falls to each organization to determine the results they’d like and the approach they’d like to take.

Top 10 Reasons Computer Security Fails

With computer security being so critical to people’s daily lives and failures being so prevalent, one might wonder why this is happening. Here’s my take on what’s led to the insufficient protection applied to so many computer systems.

  1. Most people don’t want to know about security and would prefer to live in the belief that they’re safe. The truth is that most people shouldn’t have to be concerned about their security and privacy. Of course this perspective does not apply to people who are responsible for computer systems. Yet I often see it implied in organizations’ priorities.
  2. Many organizations don’t recognize their risk. They believe they won’t be targets if they’re not the government, critical infrastructure, or a defense contractor. The truth is that every organization with money is a target because some people would rather steal it than earn it.
  3. People have a false sense of security. They believe they’ll be safe if they follow regulatory requirements from Sarbanes-Oxley, PCI, or HIPAA. To be sure, these regulations have raised the bar on security and have driven much of the IT security business for the last 15 years. They establish a baseline level of security based on best practice, which naturally drives “security by checkbox.” This leads to a rather static security stance and often doesn’t account for organizational risk.
  4. Even when organizations recognize their risk, they accept a certain amount of exposure. I once ran into a financial organization with a data system that didn’t require a log on to execute transactions. I asked if they had any fraud and suggested this was something worth fixing. They responded that they saw several hundred million dollars of annual loss on the system, probably to organized crime, but it was too much trouble to change. The “leakage” was considered acceptable for the amount of money going through the system.
  5. Attacking is easy and defending is hard. The attackers have the advantage of the initiative and defensive security must cover everything. The security team must protect environments with many complex systems that may be integrated in dodgy ways. Business requirements may preclude software upgrades that include critical security patches.
  6. Security is expensive. There’s constant pressure to reduce cost and business leadership often assumes the computing environment is safe (see item #1). Money spent on security isn’t going to help the CIO’s bonus so there’s little incentive to spend on it – until there’s a huge breach.
  7. Security isn’t sexy. People are told they should do more to secure their computers just like they should floss their teeth, change the filter on their furnace, and clean the cobwebs. Folks are busy and it’s easy to put the chores of daily life on hold, especially if there’s something fun going on. Computer professionals are no different.
  8. Security is hard. There are many moving parts, each of which depend on each other in complex ways. This is hard enough to manage when software is new and becomes even more so as it ages. One often runs into “spaghetti code” where change upon change has been made to a program to the point where nobody quite understands how it works. The more recent move to microservices has made this both better and worse because it allows more powerful programs to be written but at the expense of transparency. Engineers are often unaware of how the programs actually work and this opacity leads to vulnerabilities that can be exploited. All of this gets even harder when you stitch applications together like enterprises do. Yet most enterprises don’t look at software systematically, nor do they actively work to reduce the complexity that increases costs and creates vulnerabilities.
  9. Computer managers have given up and won’t take responsibility. There’s an attitude going through the security industry that hackers can’t be stopped and it’s only a matter of time before a system is hacked. This is probably true at some level, but it shouldn’t excuse a lack of effort. I’ve consistently heard CIOs looking to shift blame to staffers for breaches or buy insurance, neither of which changes behavior of bad actors or protects computers, let alone the people using them.
  10. Management isn’t held accountable. The common response from hacked organizations is to buy their customers credit monitoring for a year. At one time my credit was covered by three of these policies due to hacks. Target, Premera, Kmart, Anthem, Neiman Marcus, OPM, Home Depot, T-Mobile/Experian, and Equifax represent a few organizations who have taken this approach. It’s interesting that these credit monitoring services are provided by companies like Experian and Equifax, who have been hacked themselves. It’s more interesting that organizations are finding this is sufficient to get them off the hook, even when they’re not all that helpful.
  11. And a a bonus 11th item: The IT industry needs to do more. Most security professionals know about these challenges and lament that not enough is being done. They complain about management misunderstandings, budget constraint, and a lack of interest. They feel placed in a box they can’t get out of. This may be true, but it’s also an excuse. We security professionals are hired to protect environments because our employers don’t understand the details. It’s our collective responsibility to explain situations so others take the situation seriously. If people don’t listen then we must find better ways to communicate the risk and motivate action. The industry has made big strides and frameworks like the NIST and ISO frameworks are fantastic steps but they are insufficient by themselves. Organizations must be motivated by security professionals to adopt and apply these frameworks. Then organizations must realize that simply adopting a security framework does not make them secure. I’ll talk more about this next time.