In Part 1 of this series, we touched on some ways to make it so difficult to pull off a hack-attack, that the perpetrator will most likely want to go somewhere else and try their attack.

In this section, we’re going to address testing, maintaining and other important items that deserve your attention.

Testing

Once you have fixed all of the issues, you need to test everything to make sure it works the way it is supposed to. You must first create benchmarks in which you are testing against. Just to run a test for the sake of running a test is futile. Once the benchmark(s) have been set, you are ready to test:

• Run port scans to ensure only required ports and services are open and/or running
• Firewalls detect intrusions
• Switches and routers have only active administrator accounts
• Passwords adhere to compliance requirements etc

Be sure to document your test procedure(s) step-by-step as well as the test results. Note if the outcome of the test was expected or not. If there is anything that fails during your testing, you need to fix those issues and retest. Don’t skimp on testing…hackers are not forgiving and just like in dodge ball, there are no “do-overs”.

Maintaining

Once you have tested everything and are assured that your organization is where they need to be, you now need to create and maintain a testing program. Don’t try creating a maintenance program prior to everything being tested, as you will surely be making changes to the maintenance program, making are previous efforts null. Your maintenance program needs to have firm dates / times set for scheduled maintenance. You need to have multiple maintenance programs set up such as:

• Patch management
• Password management
• Network account management
• System management
• Applications management
• Operating system management
• Security administration etc

By setting up multiple maintenance programs you are able to create “silo’s” for each area and assign personnel who are responsible for each of these areas. This allows for a better view should there be a failure in any of these areas…and makes it easier to see where the failure occurred and to fix the area faster.

Worth Considering

There are a few tricks that you can implement on your network that will make a hacker think twice about trying anything. The more difficult you make it for the hacker to attack, the more likely it is that they will go somewhere else to attack. As someone who has spent the better part of the past quarter of a century protecting companies against attackers, I have listed a few neat tricks you can implement:

Honey Pots

A honey pot is a trap set to detect, deflect, or in some manner counteract attempts at unauthorized use of information systems. Generally it consists of a computer, data, or a network site that appears to be part of a network, but is actually isolated, (un)protected, and monitored, and which seems to contain information or a resource of value to attackers. These honey pots can be used to track and in some cases trap and report a hacker.

Trace Routing

Having the attacker’s IP is all well and good, but what can you do with it? The answer is, a lot more! It’s not enough to have the address, you also need to know where the attacker’s connections are coming from. You may have used automated trace routing tools before, but do you know how they work?

Go back to MSDOS and type tracert *type IP address/hostname here*

Now, what happens is, the Trace route will show you all the computers in between you and the target machine, including blockages, firewalls etc. More often than not, the hostname address listed before the final one will belong to the hacker’s ISP company. It’ll either say who the ISP is somewhere in there, or else you run a second trace on the new IP/hostname address to see who the ISP Company in question is.

Reverse DNS Query

This is probably the most effective way of running a trace on somebody. If ever you’re in a chat room and you see someone saying that they’ve “hacked into a satellite orbiting the Earth, and are taking pictures of your house right now”, ignore them because that’s just bad movie nonsense. THIS method is the way to go, with regard to finding out what country (even maybe what state/city etc.) someone resides, although it’s actually almost impossible to find an EXACT geographical location without actually breaking into your ISP’s head office and running off with the safe.

To run an rDNS query, simply go back to MS-DOS and type netstat and hit return. Any active connections will resolve to hostnames rather than a numerical format.

DNS stands for Domain Name Server. These are machines connected to the Internet whose job it is to keep track of the IP Addresses and Domain Names of other machines. When called upon, they take the ASCII Domain Name and convert it to the relevant numeric IP Address. A DNS search translates a hostname into an IP address….which is why we can enter “www.hotmail.com” and get the website to come up, instead of having to actually remember Hotmail’s IP address and enter that instead.

Well, reverse DNS, of course, translates the IP address into a hostname (i.e., in letters and words instead of numbers, because sometimes the hacker will employ various methods to stop netstat from picking up a correct hostname).

While we’ve given you a very high level look at what needs to be done to better protect yourself from a hack attack, we believe it represents the best place to start in understanding what you need to do.

James Holler is founder of Abidance Consulting.

Part 1 of a 2-part series

First, let me start with the bad news: There is no absolute way to prevent an internal or external hack-attack. With that said, there are some things that you can do that will make it so difficult to pull off a hack-attack, that the perpetrator will most likely want to go somewhere else and try their attack.

Now, there is an old saying, “cleanliness is next to Godliness.” I am sure you have all heard that line at some time in your life. This saying holds true in the security world. If your network is in total shambles (DAT files not updated, Service Packs are so far behind your need an abacus to determine how many versions behind you are, etc.) and your Intrusion Detection System (IDS) is monitored by humans only during business hours, then you have a “dirty” network that needs to either be cleaned, or as my mom used to tell me…let’s just burn your room and start over, it will be easier that way. If your network/server room looks as if a spaghetti factory has blown up, get it cleaned up by rewiring it using tags on each line so you know where each of the cables is assigned.

The first thing you need to understand in preparing to get your network in top form is to not only determine what is wrong with it, but to also be open to criticism from experts. Put away the ego (one of the top reasons why networks are in shambles to begin with) so that you can listen and learn from your internal experts or external consultants – you hired them, now listen to them.

In Part 1, we’ll look at network discovery issues, vulnerability assessments, and discuss ways to fix some of these challenges.

Network Discovery

Before you can determine what’s wrong with your network, you must first know what your network looks like. You will want to conduct a thorough network discovery since you are going to need to know not only what devices are on your network, but also where they are. Please don’t think that you are going to run a piece of software that will show you everything. If you have a wireless or dial-up modem hanging off of your network and the power button is off, you may never discover it. You may need to do a physical inspection of your entire facility…look up in the ceiling…those pesky tiles can support the weight of a modem and even an old sandwich from 4 years ago. I personally use an iPaq handheld device that is capable of “sniffing” out these modems, even when they are turned off. Now that you have a true and correct picture of your network, you will need to conduct a vulnerability assessment to determine what areas are weak and are in need of attention.

Vulnerability Assessment

To ensure that there are no “cover-ups” by your staff, it is recommended that you have an outside consulting firm come in and conduct the assessment for you. Depending on the size of your organization, the fee’s for this could be $15k to $30k or more. The final report to be delivered should be comprehensive in nature. Be sure to ask for sample reports prior to awarding a contract or project to anyone. There are areas that must be looked at closely. Make sure whoever you assign the project to gives you a list of the services they are going to run. My only word of caution here is that you do not allow a penetration attack be made against your Primary Domain Controller (PDC). Once the assessment is completed, make sure that you not only address the issues, but fix the issues.

Fixing The Issues

When you do get the final report, there are going to be a lot of errors that need to be fixed. Don’t worry; the “bark” of the report is much worse than the “bite”. Depending on how bad your network was when the assessment was conducted, you may have a few pages of issues to as much as a thousand pages of issues – one assessment we did a few years back yielded almost 7,000 pages (a government agency…need I say more). When you are reading your final report, one of the first questions you need to ask yourself is, “Where do I begin”? Not to worry, your security staff/consultants should prioritize what needs to be done and at what point in the project does it need to be done. The point at which a certain task is completed is very important since everything has a logical order of semblance to it…you wouldn’t put the seats in a car before you laid down the carpet. Your staff and/or consultants should know this and be able to build out a project plan with a scope of work, keeping you (the stakeholder) in the loop at all times. Never be afraid to ask questions or challenge something if you feel it isn’t the right thing to do or you don’t understand why something is or isn’t being done.

To save time and money, you have to look at all of the different compliance issues you have to deal with (NERC, EPA, OSHA etc) and cross-walk your efforts to all of these compliance requirements. Doing this will ultimately save yourself time and money by not overlapping efforts.

Next time, we’ll look at testing, maintaining, and some other important issues that merit your attention.

James Holler is founder of Abidance Consulting.

Complying with the NERC CIP requirements is expected to be a major expense for power producers and the like in the coming years. To date, companies have spent tens of millions of dollars to formally document and test the support for internal control assertions required by CIP and maintaining this documentation will continue to be costly beyond the first round of documentation.

Let’s take a look at some of the most important components of a good NERC CIP compliance program:

Automate The Testing & Reporting Of All Of The Technical Controls

An important concern for power producers is finding a cost-effective method of documenting, storing, and analyzing CIP control assessment work. Management is also looking to meet all the technical requirements spelled out in the requirements. In the first year, many companies have elected to use spreadsheets to tackle CIP documentation because they are familiar with the tool. Moreover, some companies prefer to use spreadsheets because the CIP requirements are still evolving.

Spreadsheets have significant limitations that will increase compliance risks. In addition, depending on spreadsheets for CIP documentation may prevent companies from improving their compliance process and risk management capabilities. In the first year of CIP compliance efforts, many internal auditors and project consultants have advised power producers to use their existing spreadsheet software to document compliance efforts. There is no way that these tools are sufficient to document all relevant accounts, account assertions, risks, controls, and deficiencies. The only way to truly document everything is to automate the process.

Use File Integrity Checks To Assure Your Systems Are In A Desired State

It is very difficult to compromise a system without altering a system file, so file integrity checkers are important. A file integrity checker computes a checksum for every guarded file and stores it. At a later time you can compute a checksum again and test the current value against the stored value to determine if the file has been modified. Some lesser quality file integrity checkers use a 32 bit CRC (Cyclic Redundancy Check). Attackers have demonstrated the ability to modify a file in ways that the CRC checksum could not detect, so stronger checksums known as cryptographic hashes are recommended.

One of the challenges in using a file integrity checker is the false positive problem. When you update files or apply system patches this changes the file. Creating the initial database of signatures is easy; keeping it up to date is much harder. However, even if you only run the checker once (when you first install the system) this can still be very valuable. If you are ever concerned that the system was compromised you can run the checker again to determine which files have or have not been modified.

The other challenge with a file integrity checker is that you have to have a pristine system when you create the first reference database, otherwise you may be creating cryptographic hashes of a compromised system while feeling warm and fuzzy that you are implementing good security. It is also very important that you store the reference database offline or an attacker may be able to compromise the system and hide their tracks by modifying the reference database.

Test System Configurations Against External & Internal Policies

Testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Testing also provides an objective, independent view of the configurations to allow the facility to understand the risks in the implementation of the configurations. Test techniques include, but are not limited to, the process of executing a configuration with the intent of finding “bugs”.

Testing can also be stated as the process of validating and verifying that the configurations:

• meets the business and technical requirements that guided its design and development;
• works as expected; and
• can be implemented with the same characteristics.

Testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the configuration methodology adopted.

Testing can never completely identify all the defects within your configurations. Instead, it furnishes a criticism or comparison that compares the state and behavior of the configurations against principles or mechanisms by which someone might recognize a problem. These principals or mechanisms may include (but are not limited to) specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.

A study conducted by NIST in 2002 reports that bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better testing was performed.

A primary purpose for testing is to detect configuration failures so that defects may be discovered and corrected. This is a non-trivial pursuit. Testing cannot establish that configurations functions properly under all conditions but can only establish that they do not function properly under specific conditions. The scope of testing often includes examination of configurations as well as execution of those configurations in various environments and conditions: does it do what it is supposed to do and do what it needs to do.

There are so many areas that can be addressed for automating that it would take dozens of pages for them all to be discussed. This blog was intended to give you a start on what you need to do if you truly want to ensure total CIP compliance.

James Holler is founder of Abidance Consulting.

According to the Wall Street Journal (WSJ), computer hackers have designed a virus that targets the industrial control systems, to include power plants, built by German engineering giant Siemens AG. The virus apparently activates a kind of malicious software that analysts say represents a growing corporate-espionage threat. This type of threat has been talked about for years — and it is now a reality.

The virus, Stuxnet, is spread by USB devices plugged into the physically unsecured USB ports on the machine(s) hosting the SCADA systems used by power plants and other types of facilities. The virus is programmed to steal data from computer systems that are used to monitor power plants built for anything from manufacturing to power generation to water treatment.

Researchers analyzing the virus say that they are now seeing several thousand infection attempts daily, though the virus is only activated if it lands on a computer running the Siemens systems software. Analysts warn that the attack on the Siemens’s systems marks an escalation in hackers’ efforts to use viruses for industrial espionage or sabotage purposes. This attack will surely make the NERC CIP regulations become even tighter more quickly than before this story broke.

Smaller, more isolated virus attacks have been attempted before on SCADA systems, but this is the first such infection where a virus is searching specifically for SCADA systems to attack on such a large-scale basis. The worry among security analysts should be that such viruses will, at some point, be used by criminal organizations or even terror groups to sabotage power plants.

The Stuxnet virus specifically exploits an unpatched vulnerability in the Microsoft Windows operating system, allowing it to spread through all USB devices. Once the virus has infected the Siemens system, it uses default passwords that are hard-coded into the Siemens software to upload false control-system data to a remote server. In an advisory that Siemens posted on its website, the company said Microsoft was working on a patch to fix the vulnerability at the USB interface. In its own website advisory, Microsoft has provided a workaround fix to offer some additional protection until a patch, or update, is ready.

Siemens said it expects to approve the updated virus scanners this week and also plans to provide customers with a diagnostic tool to check if their systems have been infected. In the meantime, the company’s website advisory urges customers not to use any USB storage sticks.

Siemens, Microsoft and other security analysts haven’t determined where the virus originated. Many of the infection attempts have originated from India, Indonesia and Iran. The virus likely was created in Asia, given the pattern of attacks and technology used.

James Holler is founder of Abidance Consulting.

With more and more emphasis being placed on the CIP requirements, some NERC registered entities may be tempted to “relax” and decide that  they are not deemed classified as a Critical Asset. A word of advice: Take a deep breath and think carefully. If you think that it is just too hard to get compliant and the easiest solution is to just declare that you are not critical, you are very mistaken.

Several attorneys that work in the NERC space have commented that those who deliberately or appear to have otherwise deemed themselves to not be critical simply to avoid having to comply, will most likely face egregious fines from NERC…and we’re talking in the millions of dollars. On the same side of this coin, if your CIP program is so weak that you are judged to not be in compliance, you could suffer much larger financial losses, in addition to any fines, if you are the victim of a cyber attack or an interruption due to your failure to comply.

NERC and FERC have made it very clear from the beginning that they are serious about having registered entities comply with their rules and regulations. Since June 2007, NERC fines total more than $35 million and the FERC fines are almost $120 million.

If your organization doesn’t have the appropriate staff on hand to get the job done, then you have two valid options: 1) hire the appropriate staff, or  2) hire a competent consulting firm. Don’t think that you, as a registered entity, are going to be able to “slip one by” the auditor. The eight RRO’s as well as NERC and FERC have hired on some very skilled cyber security auditors that know what to look for and also where to look. These auditors are very good and the only way to “beat them” is to have a great CIP compliance program in place.

You may ask, “how long does it take to get compliant…and for how much”. This is not an easy question to answer as there are numerous variables that determine the answers to these questions. A few variables are…what is your current state of readiness; have you leveraged from other compliance effort areas such as Sarbanes-Oxley, HIPPA and PCI; have you tested your current state of readiness against a mock audit? There are dozens of factors that must be considered before you can even guess at the timeframe and associated costs. One thing is for sure though…it will cost you a lot less money to get compliant than it will for you to “keep your head in the sand”.

James Holler is founder of Abidance Consulting.