Questioning Information Security: A couple of examples

We've discussed the necessity in information security of asking good questions (Questioning Information Security - Part 1) and how to answer those questions using data and analytics (Questioning Information Security - Part 2).  Now apply this approach to answer two questions for a hypothetical enterprise.

Which employees have the worst security behavior?

Ever wonder which employee has the worst security behavior? New employees come in to the organization and get training in information security. They are instructed about the hazards of clicking on links in email messages from unexpected senders, the risks of using web mail and file sharing sites at work, and the potential liability of storing sensitive data on external media.

You send them out into the world to do good things, but you know that one of them is really going to cause big security problems. Looking at them as they leave the class, you are certain it is going to be one of the guys in the far left column.

 Back in the trenches, the security engineers and analysts are fighting the good fight of malware infections, bot nets, unsecured servers and hosts, broken security software, lost devices, attacks against the perimeter. Lots of activity. From whom is it stemming? If you could just get to the root ....who is causing these problems? Then you remember reading those cool posts on www.dieselcafe.com where you learned that you have all the data you need to answer your security questions.

Rolling up your sleeves, you determine that in order to identify the person who has the worst security behavior is going to require Active Directory (for employee information), the web gateway event logs (who is hitting high risk categories), the AV logs (who is getting the malware alerts), the system management logs (tells you patch levels and apps installed on systems), and the network vuln scan data.

You set up ETL jobs to periodically pull this data from its various sources in to your PostGres database and you bind the data together using hostnames and IP addresses from the DNS logs.

You crunch the data - looking at a simple count of security events by employee over the last three months and are surprised but not surprised that 90% of your security problems come from 1% of your users.

So you dive in and create the reports that will drive action in the organization and come up with something like this...

Armed with this, you know who the worst security actors are in the company. Starting with the biggest offenders, your team provides individual training to get the worst right. You see the curve flatten over time. You are proud of yourself. But then, you ask yourself, "Am I asking the right question?"

Which employees expose the organization to the greatest risk?

What you really care about is which employees expose the organization to the greatest risk. To figure that out you decide you need to tie in the security behavior score you've developed with the user access permissions and the system risk ratings. You have a centralized store of user system access permissions because you do periodic access permission certifications. And you have a database of the risk profile for each of those systems because of your risk management program.

Adding these together with the security behavior scoring that you already did...

Some tweaks to your report. Done! As it turns out, some of the people with better security behavior do need some attention, like Enoch Root, your CFO!

And by the way, it turns out that this guy is the one who was causing you all the grief :)

Questioning Information Security - It's all about the data

In Questioning Information Security Part 1, I argued that your security is only as good as the questions you ask.  If you never ask the question - is my network exposed to compromise through third party connectivity or how can my password reset function be defeated or who is using unauthorized systems on my network - you will never know the answer.

But great questions are only the seed of the answer. Just as a scientific hypothesis necessitates a quest of rigorous experimentation, an Information Security question requires data and analytics.

Data Collection

Fortunately, your environment has all the data needed to answer your security questions. Let me say it again - your environment has all the data you need to answer your security questions. The diagram below shows some of the data that is commonly available in enterprise network environments.

Mixed together properly, tour DNS activity, web logs, firewall logs, endpoint events, malware events, AD data, and net flow holds rich treasures to answer numbers of questions - ones that you are asking and ones that you haven't yet asked.

But how do you collect it? How do you process it? If your last attempt at wrangling and analyzing large amounts of data was back in 2005, you probably felt a bit like this guy.  The relational databases just didn't scale. It was expensive. It was a lot of work. And queries took forever.

The world of data processing began to change in 2005 when the Apache Software Foundation released Hadoop, an implementation of Google's MapReduce technology for parallel processing of huge data sets. As Hadoop because more accessible and associated technologies such as Hive and Pig wrangling this data wasn't so difficult any more. Now data analytics can occur on an industrial scale.

Massive data sets can be loaded in to commodity hardware running open source software and analyzed effectively, processing complex queries in reasonable time that was previously unthinkable. The shackles and overhead of relational data structures are off with the NoSQL paradigm and the structured and unstructured data can processed from all kinds of sources.

Of course, you don't have to collect all of the data in your environment to answer really meaningful security questions. Just start with the data necessary to answer well the core questions.

Data Correlation

Some cool questions can be answered by simply analyzing a single dimension of data that spans a long period of time, such as firewall or DNS logs. Things get exponentially more interesting when you correlate the different data sources together. How do you do this though with data from a variety of sources that was really never 'designed' to be together?

The common denominators of the data is an ip address or a hostname. All your data that interacts with the network can be tied pretty easily to one of these two attributes. With data collected over time and correlated, really interesting questions can start to be answered.  Take Active Directory - useful to correlate stuff to that because that is where you can tie in to the users behind the events. AD doesn't have the IP address of each user, but the domain authentication logs do. Tie that to your DNS logs and you can get down to a hostname. Similar process for just about any other data source. I have found that doing this data enrichment is useful to do during the data load processing.

Data Contextualization

Data contextualization is simply the process of taking that security data and putting it within the context of its place in the business, the environment, the overall risk of the enterprise. Then, something as lonely as a vulnerability report can be really useful. Then you can know how important that vuln is because of the risk profile of the system it resides in, and you can report vulnerabilities by business unit or, better, by business process. You can tie vulns to specific people within specific business units. Lots of places you can go with other data.

Communication

Ultimately, these answers to the questions you've asked are valuable in so much as they result in action, which requires good communication. One of the goals is to make it valuable to the business and create a meaningful business-specific dashboard that isn't color-coded based on swags.

Rather, the dashboard is based on real data such that you can dive in to its dimensions and layers, such as the data behind outsider fraudulent Transaction in the retail division. Or employee accidental data loss in the R&D group. Being driven and derived from data, you might see rates of non-compliance with use of encryption on laptops and host-based external media controls and perhaps promiscuous policies related to use of cloud storage.

In the last post in this series, I'll expand on ideas for questions to answer using data collection, correlation, and analytics. 

Questioning Information Security - You are only as good as your questions

Your security is only as good as the questions you ask. It is the questions that drive the search for answers. And the answer drives informed action or inaction. Anything else is a random, uninformed walk.  So, as you shape your security strategy to support the innovations of the business, it is in asking good questions and creating correct answers through which effective security is achieved. No one else but the enemy will tell you the questions you should have asked and the answers you should have come up with. But by then it is too late. Because they told you by running all over your systems.

Before we jump in to the information security side of this, let's take a look at the historical implications of leaders who didn't ask effective questions about their own security.

Wars and Empires Lost 

Wars and Empires have been lost because those charged with defending their country did not ask the questions needed to correctly determine the defenses necessary to defeat their enemy. Darius III ruled Persia from 380 - 350 BC. At its height, the Persian Empire reached in to three continents, spanning over 8 million square kilometers. Alexander, King of Macedonia, had eyes on creating a vast empire. To do that required conquering Persia.

Darius knew that Alexander had designs on his empire. Unfortunately, Darius' spies failed to provide him good intelligence about the weaponry of Alexander's army. They didn't ask the question, 'is my military weaponry sufficient to defend against an attack by Alexander?' As it turned out - no. His spears were just a bit too short.

And what happens when your spear is too short? You lose. And Alexander, instead of being 'Alexander the So-So' became Alexander the Great. And who talks about Darius III?

Questioning Information Security 

Enterprises have sustained massive losses because they didn't ask the right questions. The breaches of the NSA, Target, Neiman Marcus, TJ Maxx, 7-11, Heartland Payment Systems, RBS WorldPay and others are rooted in not asking good questions and properly analyzing them and acting on the answers. 

Here is a framework from which we'll discuss this idea of 'Question Security'. It is really simple. Ask questions, answer the questions through data collection and analytics, and act on the answers.

Lame Questions

Think about your own enterprise within this framework. How good are you? Honestly. Most companies are doing something like this (below) where they are only collecting some limited, silo-ed data and acting on it. 

And what are the questions being asked? Pretty weak ones and, frankly, ones that aren't terribly useful on their own. What vulnerabilities does this scanner tell me that I have? What vulnerabilities does this security consultant (who is likely running the same scanner) tell me that I have

Lame Answers
The type of answers you get of questions like this - what vulnerabilities does this scanner tell me that I have - aren't too useful for protecting an enterprise. Nothing against scanners, but really, how useful is this?

On top of that, the frequency at which the data is collected in many cases is not frequent enough. For example, many organizations only scan their perimeter once a quarter. A lot can change in a quarter. That is the equivalent of only doing security event monitoring once a quarter. 'Any attacks? No. I looked at traffic for a few days a couple of months ago. Didn't see anything. Who would do that? Well...

So, not only are the questions being asked and answered weak, but the questions aren't being answered very frequently so the information is STALE!

Good Questions Lead to Good Answers
Answers all start with a question. And good questions lead to good answers. So what questions are you asking?

Here are some examples of good questions:

• How did my Internet footprint change between yesterday and today?
• Who is using unauthorized systems on the network?
• Which of my users has the worst security behavior?
• Which of my users exposes the organization to the greatest risk?
• What is the security profile of my customer care business unit across all people, applications, and infrastructure?

With some good questions staged, we'll dive in to the data stuff required to answer these good questions here.

Temple Mountain Moto

From time to time I get the craving to race around the desert at high speed. There is just something about putting on the body armor and helmet and racing for hundreds of miles around the desert at break-neck speed with my buddies. Temple Mountain is our most common destination.

Why do I like it so much? Because it is the exact opposite of my 'regular' life. Two days in the dirt and I am good for two months. Really, it is the perfect weekend. It relieves all the stresses of modern, monitored life.  It goes down like this.

Pick up friends. Drive South to Temple Mountain. Set up camp. Moto past dark. Build big fire. Sleep. Moto. Drive home.

Location and Routes
We base camp at Temple Mountain where there are good bathroom facilities and there is plenty of space to spread out. Temple Mountain has great trails immediately around the base of the mountain. The area has a very old, cool mine and related ruins and junk.  Temple Mountain was formerly the big supplier of uranium for Uncle Sam's nukes. Now it is BLM land loaded with old dirt roads and trails that lead to hundreds of the old mines. And no cell signals - bonus!

This is one of the larger abandoned mines in the area.

Temple Mountain to Muddy River / Caneville
This is a good ride. Straight from camp, you ride on the paved road about 14 miles to Little Wild Horse Canyon where you hit dirt and ride a really fun, fast sandy road through canyons and through super cool landscapes to the Muddy River. The only reason to cross the Muddy is to get to Caneville (made famous by Nitro Circus) where you can ride what is essentially God's skate park for dirt bikes. Think 200 foot-high hard sand half-pipes and you get the idea.

I *believe* off road vehicles are allowed on the highway between Temple Mtn and Little Wild Horse. At least that is what I keep telling myself…

Back of the Swell
This is a really fun ride. The first half is wide enough for Jeeps, but then it gets narrow and much more technical. Don't be intimated by the first climb on the trail, which has a 100 foot drop on one side, is steep, and has lots of rocks. If you get through that you can easily enjoy at least the first half of the trail. Keep going and you'll enjoy a very technical, but doable ride. It ends up at Hidden Splendor Mine, which sports a gravel airstrip in the middle of nowhere. Really…an airstrip in the middle of nowhere! Surreal.

Information Security Explained in One Simple Diagram

Assets motivate adversaries to exercise threat realized through attack vectors against assets. Controls protect assets and reduce exposure to threat by counteracting attack vectors.

How to Construct a Threat Statement

Scientists begin experiments with a hypothesis. Researchers begin their papers with a thesis statement. It is similarly useful to begin a threat analysis with a threat statement. The threat statement establishes the scope of the threat and guides the analyst in his threat research. Consider this threat statement, “Unauthorized disclosure of sensitive data.” Partially mapping out the scope of this statement, it looks something like this diagram shown below.

This scope of analysis is a bit large. Consider how large it would be for an enterprise with sensitive information spread across hundreds of systems! However, it is not unapproachable. Every journey, however long, begins with a single step. In this case, that step is to define the threat into a series of more narrow threat statements, such as this one, “Unauthorized disclosure of sensitive data through theft or loss of off-site stored data backup tape by outsider.” The map of this statement is much narrower.

This threat statement, unauthorized disclosure of sensitive data through theft of off-site stored data backup tape by outsiders, is narrowly scoped. It identifies the threat agent (outsider); it specifies the assets in question (data backup tapes; and the method through which the threat may be realized (theft and loss). This narrowly scoped threat analysis can be completed quickly and compared with other related threats analyses for decision-making.

Analyzing narrowly defined threats does not preclude solving larger scope threat questions such as the first one stated above, unauthorized disclosure of sensitive data.  The solution is necessary to protect sensitive information assets.  However, the answer to these broad scope threats is the sum of the solutions to the more narrowly scoped threat statements.

The Threat Statement

A well-bounded threat statement consists of four key elements: the asset category that is the focus of the threat agent’s objective, the end state condition the threat agent seeks to achieve within the context of the asset, the threat agent’s privilege level as it relates to the target, and the compromise approach the agent will use to realize the threat.

Target Asset / Asset Category

The target asset is the focus of the threat agent’s objective.  It is the system or category of systems the adversary seeks to compromise.  By restricting the threat statement to a specific asset or asset category, we establish boundaries for analysis of attack methods and related controls.  While the target may be a specific asset, modeling an asset category allows the analysis to be reused across multiple assets.

Other targets include Internet connection, core router, internal web application, Windows XP operating system, Oracle 10g database, Windows 2003 Server, a specific web application, such as wiremoneynow.abc, Active Directory, or even USB flash drives.

End State

The end state is the condition the threat agent seeks to achieve within the context of the target asset.  It is his goal as it relates to the system he is attacking.  Including the end state in the threat statement narrows the analysis on attack vectors used to achieve the end state. 

Some other end states include application administrator access, network denial of service, unauthorized operating system access, remote system control, physical possession of storage media, and access to internal network communications.

Threat Agent and Privilege Level

The threat statement should specify the threat agent’s privilege level as it relates to the target system. The types of attack methods available to a threat agent and the complexity and risk exposure of executing the attack methods are partially dependent on the agent and his privilege level as it relates to the target system. For example, physical compromise of a system within a secured data center is easier for an administrator with authorized access to the data center than for an outsider who has no data center access privileges.

Other privilege levels include an outsider with no access to non-public target resources, an insider who has access to the target system owner’s private network or physical facilities but no local area network or physical access to the target system, and a privileged insider who has direct physical or local network access to the target system.

Compromise Approach

The compromise approach specifies the category of methods the threat agent will use to realize the threat. The compromise approach in our example threat statement is theft of authentication credentials.  This limits the scope of attack methods to those such as horizontal credential guessing, vertical credential guessing, keystroke logging, phishing, social engineering, and network communications intercept through CAM table flooding or ARP spoofing.

Threat Agent Profile: Government Cyber Warfare

Cyber warfare encompasses nation-state activities taken against enemy computer systems and networks with the intent of controlling, compromising, or disabling function through electronic methods. The potential impact of cyber warfare is perhaps best described by an unnamed Chinese general who stated in 1996, “We can make the enemy's command centers not work by changing their data system. We can cause the enemy's headquarters to make incorrect judgment(s) by sending disinformation. We can dominate the enemy's banking system and even its entire social order.”[1]

In 2007, according to a Gartner report, thirty nations were developing cyber warfare capabilities and predicted that 30% of all nations will have cyber warfare capabilities by 2012.[2]  The United States is leading the world in investment in cyber warfare infrastructure.   In 2006 the U.S. announced the creation of the Air Force Cyberspace Command.  During the announcement of the division, Secretary of the Air Force Michael Wynne said “The aim is to develop a major command that stands alongside Air Force Space Command and Air Combat Command as the provider of forces that the President, combatant commander and the American people can rely on for preserving the freedom of access and commerce, in air, space, and now cyberspace.”[3]

Cyber Warheads – Stuxnet

Until early 2010, what a cyber weapon would actually look like, when it would be first used, and against whom and what it would be launched against remained in the realm of conjecture. On June 17, 2010, the Belarus-based security firm VirusBlokAda Ltd discovered a new piece of malware resident on an Iranian-based client’s system that made cyber warfare manifest. Stuxnet isn’t just a one-off piece of malware. It is a framework for development of future cyber-warheads. 

In short, the function of Stuxnet is to damage the Iranian Natanz nuclear fuel enrichment plant and, possibly, the Iranian Bushehr nuclear power plant. Nuclear fuel enrichment plants use centrifuges to produce low enriched uranium. Stuxnet reprograms the Siemens industrial control system used at the Natanz enrichment facility to cause the IR-1 centrifuges to spin at rates and in patterns harmful to the centrifuges. Stuxnet also shutdown related warning and safety controls that would alert plant operators of the odd centrifuge behavior.

While Stuxnet infections did not remain isolated to Iran, data collected by Symantec through its monitoring infrastructure revealed that Iran hosted 58% of the total infected systems. Indonesia and India followed distantly with 18% and 10% of the total infected hosts.[4] And, it seems to have achieved at least some of its intended effect. In late 2009 to early 2010 Iran replaced about 1,000 IR-1 centrifuges at their Natanz facility.  On November 23, 2010, the leader of Iran’s Atomic Energy Organization, Ali Akbar Salehi, confirmed reports of cyber attacks against Iran’s nuclear facilities: “One year and several months ago, Westerners sent a virus to [our] country’s nuclear sites.” On November 29, 2010, Iranian President Mohmoud Ahmadenejad confirmed the reports in a news conference. “They succeeded in creating problems for a limited number of our centrifuges with the software they had installed in electronic parts.”[5]

Natanz Hijacking Requirement	Stuxnet Solution
The location of the Natanz industrial control systems is not known, so the software would have to crawl systems autonomously and auto detect if it was on one of the control systems.	Stuxnet contains four zero-day vulnerabilities for spreading through network communications and through USB drives and for escalating local privileges. Additionally, it copies itself to remote computers through network shares. Once on a system, Stuxnet examines its host to determine if it in fact is a system used to control IR-1 centrifuges known to be in use at Natanz.
The industrial control systems (ICS) are not connected to any network that is connected to the Internet, so the malware has to jump the network air gap.	Stuxnet contains a zero-day vulnerability for infecting systems through USB media.
The malware has to operate undetected for a long period of time to prevent detection before achieving its objectives.	Stuxnet employs advanced rootkit techniques and malicious binary driver files are signed using stolen valid digital certificates to avoid detection. It also contains features to bypass security products.
The malware would need to be able to update without having to call back to a command and control server.	Stuxnet-infected systems update each other using a peer-to-peer mechanism. Infected systems search for each other on their LAN. When one Stuxnet install detects another, they exchange version information. If the versions are not the same, the older instance is updated from the newer one.
The IR-1 centrifuge attack code would need to work against the exact configuration of the programmable logic controllers used at Natanz.	Stuxnet contains the first-ever programmable logic controller rootkit that hijacks the control system and disables alarms and modifies alerting messages to remain undetected by plant operators.

Compromising the industrial control systems of the Natanz fuel enrichment processing facilities was no trivial task. Once released, the malware had to autonomously achieve some seriously daunting tasks. Ralph Langner, the pre-eminent Stuxnet expert, summed up Stuxnet best. “Stuxnet is like the arrival of an F-35 fighter jet on a World War I battlefield. The technology is that much superior to anything ever seen before, and to what was assumed possible.”[6]

With Stuxnet out of the bag, Governments around the world are scrambling to respond; assessing the exposure of their own critical infrastructure to Stuxnet-like malware and, no doubt, developing their own cyber warheads for use against all sorts of industrial control systems.

Targets

One of the prime target of cyber weaponry is critical infrastructure controlled through electronic Supervisory Control and Data Acquisition (SCADA) systems. The SCADA systems allow remote monitoring and control of a broad deployment of physical world infrastructure. In the hands of asset owners and operators SCADA systems greatly increase operational efficiencies and capabilities. In the wrong hands SCADA systems could disrupt or corrupt delivery of essential services. Consider how SCADA systems are used across a few industries:

Railroad – Automatic Train Control (ATC) systems provide remote computerized monitoring of train position, control of train speed, and rail switching.

Water – Water Works organizations use SCADA systems to monitor water quality, flow, pressure, and operational status. They also use SCADA systems to control water production, distribution, and blending. Back in 2008, a California municipality published details of their SCADA water systems on its web site, going as far as showing a screenshot of their SCADA Human-Machine Interface (HMI).Probably not a great idea.

Nuclear Fuel Enrichment Processing – SCADA systems are used to control the complex nuclear fuel enrichment process.

Power Generation – Power generators use SCADA systems to monitor boiler temperatures, turbine performance, and environmental conditions and to control power generation equipment in real-time.

Power Distribution – Power distributors use SCADA systems to manage power supply into their distribution network, manage flow, and monitor supply and demand.

As most SCADA systems are not directly Internet-accessible, the likely SCADA system compromise path is to compromise a system that has access to the network on which the SCADA system resides and use that as a staging point for the attack against the SCADA system. With advanced malware kits that provide hackers persistent, stealthy remote control this possibility is very real.

---

[1] Cyber Threats and the US Economy, Statement for the Record Before the Joint Economic Committee on Cyber Threats and the US Economy, John A. Serabian, Jr., Information Operations Issue Manager, CIA, February 23, 2000. 

https://www.cia.gov/news-information/speeches-testimony/2000/cyberthreats_022300.html

[2] Gartner, 5 June 2007, Cyberwarrior: Re-examine the Risks as Cyberwarfare Evolves, Herbert Strauss

[3] http://www.af.mil/news/story.asp?id=123030505

[4] Win32.Stuxnet Dossier. http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf

[5] “Iran says cyber foes caused centrifuge problems,” Reuters, Nov 29, 2010.  http://www.reuters.com/article/idUSLDE6AS1J120101129

[6] http://www.langner.com/en/2010/11/19/the-big-picture/