DarkMatters Threat Thursday: Number One on My Top Ten List for Security Executives: History’s Lessons

View Live Map
10/22/2014

This week we’re going to take a break from our usual Threat Thursday fare of malicious IPs and other threats uncovered by the Norse DarkMatter platform. This week we’ve got the first of a ten part series by Norse Chief Security Strategist, Brian Contos on his Top Ten Priorities for Security Executives. This week Brian takes us back to the history we learned in school and talks about lessons from history that can be applied to our thinking about security. Enjoy.

I've been getting a number of inquires regarding by blog. More the the point, folks have been wanting to know why I haven't published recently. Two major factors contributed to my lack of contribution in recent months.

One, I've really been a road warrior as of late -- even for me, the guy that is always blogging about Singapore, Brazil, Australia, etc. In fact, for the first time in a professional lifetime of heavy travel I was averaging more than 150,000 miles a quarter. I don't suggest this as a lifestyle choice — unless that choice is to emulate George Clooney in Up in the Air.  Two, I recently changed jobs; you can learn more about that by checking out my updated profile. But now I'm back.

Besides helping stimulate the top lines for the good people at United Airlines, Starwood, and Hertz, all that travel has culminated in an interesting top 10 list. About 90 percent of my time has been with executive-level decision makers with government and Fortune 500 companies. I listened to their concerns, I took notes, and I aggregated the material. This has culminated in a list of technical and non-technical elements that seem to be a high priority of security executives regardless of vertical or geography.

Over the coming weeks and months I will address each of the top 10 priorities as an individual blog. Some of these priorities will be predictable while others will seem a bit left of center. At least that what my impression after correlating my data.

So let's kick off the series with this number - here is part one: History's lessons.

In security, such is the universe, change is constant. If we were able to watch the Earth change, adapt in fast-forward over the last several billion years, we would quickly come to the conclusion that stability is an illusion.

Continents come and go and oceans rise and fall. Some species are extant while others become extinct. Our written history is only about 6,000 years old and an individual might live around a century. Simply put, we have a very narrow and somewhat static perspective on things.

In just the last two decades that I’ve been involved in information security we’ve seen security change from being a hobby, to a good idea, to a regulatory mandate and most recently a strategic, business imperative.

We must constantly evaluate how we are approaching security:

  • Are our existing controls still providing value; can it be measured?
  • Do we have the right level of tools, talent and techniques?
  • Are we being proactive or just reactive by waiting to be attacked?
  • Are our incident response programs able to scale in the face of IoT, mobile, cloud and other IT trends?
  • Do our security controls have context and intelligence that make them aware of the constantly changing threat landscape outside our environment?

Shifts in advantage

There are some events in history where one side is simply “outgunned.” The following may seem pretty obvious to us now, but the advantages were likely more opaque when happening.

The Greeks ruled the ancient world with iron spears and used a close-order infantry formation called a Phalanx to fight as a single unit that while historically effective, especially on flat terrain moving in one direction, required the enemy to attack them, and for the Phalanx to react.

The Romans leveraged a steel Gladius sword allowing them to fight not only with stronger weapons but be on the offensive, more agile and more effective on diverse terrains. This Roman advantage culminated in Rome defeating Greece in 146 BC.

While this is an extreme over simplification of the factors that lead to the fall of Greece, the technology (metal) and the process (battlefield hand-to-hand combat) played a significant role. Some would argue that the inability for the Greeks to identify the Roman advantages defeated the Greeks before any battle began.

How similar is this to information security? Do we continue to throw the same types of security products and processes at the problem because they worked historically even though we know the enemy has changed tactics?

We have to do something. We can’t simply give up. The fact is there are a lot of great security products. There are integration points such as APIs between many of these products, or platform-based solutions that are more inclusive. But they still fail, and that failure is largely predicated on two definable gaps.

First, our industry has trained security administrators. These administrators understand how to configure a firewall, set up IPS signatures, deploy anti-virus and manage a wealth of other products. They may even have an incident response program in place. But we don’t have enough training and focus on security analysis – partly because it isn’t tied to any one product and much of the training today is based on vendor training.

While security administration and vendor training has value, if that’s where one’s security capabilities ends, it means the people looking for nefarious activity might actually have the right tools at their disposal, but they lack the techniques to be effective and efficient.

Second, security products might be operating in a silo; this is an antiquated methodology. If you are going to connect something in your environment, it better have hooks into other parts of your environment to increase the ROI of your existing controls. If not, give it a couple years before it becomes shelved.

Beyond integration across devices and between controls addressing the areas of prevention, detection and response, there needs to be a greater level of awareness and context.

  • Some of this context needs to be derived from the inside. For example, you would want to know about critical assets, their OS, their applications, their subnets, what users have access and their data at rest, in motion and in use.
  • Some of this context needs to be derived from the outside. For example, if you see an IP address hitting your network you may want to know
    • Is it a known bad source; if so, how bad and for how long
    • What country it’s coming from
    • Is it associated with something like malware, botnets, anonymous proxies or other risky variables

Admitting that the current approaches are failing doesn't mean we've failed. We need to adapt. We need to make better use of our existing security controls. We need to enrich those controls. We need to make better use of our security administrators. We need to help turn security administrators into security analysts.

History has taught us that change is constant. We must first recognize that so we are aware and proactive. Then we must evaluate to determine where the failures are and with whom the advantage resides. Finally we must adapt to mitigate those failures and shift advantage back. Then it all starts again – change is after all constant and unforgiving.

Originally Published on CSO Online

About the Author: Brian Contos is a security company entrepreneur and published author with over two decades of experience building some of the most successful and disruptive security companies in the world. In addition to working in over 50 countries across six continents, Contos has been interviewed by industry and business press and is a regularly invited speaker worldwide. He is also a graduate of the University of Arizona, Distinguished Fellow with the Ponemon Institute and blogger for CSO Magazine.