Phase I: Analyze


Inventory

The first step in any risk management process is to take stock of what you must protect and to not make the mistake of looking at just what you want to protect. This involves establishing what systems and networks you're working with and the way data flows between those systems, domains, or enclaves you're trying to compartmentalize by inventory of your systems, defining what they do, and detail regarding who should have access to what specific resources on those systems. This includes all the pieces to your system or enterprise that must be protected and how they are deployed today. This is a critical distinction because too often when constructing risk management programs, organizations become very myopic in their analysis of what they think they need to protect. Many organizations will zero in on only those assets that they want to protect, while ignoring all the other pieces of their network that might contribute to a reduced security posture for that asset. The problem becomes one of omission through ignorance.

For instance, we have seen customers overlook that modems are an easy vector of penetrating an organization's security perimeter (the proverbial Belgium to the firewall's Maginot Line). In these cases it was felt that the systems the modems were attached to were of low importance and, hence, not a high security priority. Further, there was a general lack of operational awareness of how these systems connected to the rest of the network.

The problem is that the low value or unimportant system with the modem connected to it was really just a vector into something far more valuable, the network itself. After you are inside an organization's network, you have free run of the place. In short, too many computer security models tend to look like an egg, hard on the outside, liquid on the inside. If you get past the shell, through a modem for instance, you can move around with impunity throughout the entire organization.

The point here is to recognize the dependencies in your organization's security plan. Just because your organization has an excellent Internet security plan provided by a state of the art Linux firewall does not mean that you do not have to consider other vectors into your security enclave. Look at everything and consider how it could be used to defeat a security counter measure. Laptops are another example. Assume for a moment that you have fantastic perimeter security and you have every way into your organization accounted for and properly compartmentalized, such as modems and wireless access points. However, the users on your network take their laptops outside your network, to their homes, school, or a coffee shop, and those laptops become infected with worms or Trojans while connected to the not so secure network they are temporarily attached to. These users then reconnect their laptops to your network and without realizing it, unleash those worms on your networkdefeating your perimeter security model.

You cannot manage these risks by only looking at what you want to protect. You have to expand your horizons, so to speak, and look at the whole picture. Be creative and think about the threats and vectors that bring those threats onto your network. If you have some critical assets in your network, then consider what it is that those assets trust and don't make assumptions about your security model that are not based on fact. A good rule of thumb: When in doubt, don't trust it.

To wrap up this thread, the first step is to take stock of what your network is composed. How is it laid out, what systems are connected to it, who runs those systems, and what are all the paths from outside the network to your critical assets? Then consider how much you can trust the assets inside your network. You might have to compartmentalize certain systems off from others by deploying internal firewalls. For more critical systems, you have to do more than that, such as isolating those systems so that they are not connected to your main network. Some organizations do this with their accounting systems, and the military is supposed to isolate classified systems onto their own networks, physically separated from the non-classified systems.

Another problem we have seen is organizations that look at what they want their networks to be or hope them to be. Reality, cold unfiltered reality, is the only ingredient that will work here. Don't assume that your roll out of that fancy new "secure" network will be deployed on time or that your wire or logic diagrams correspond to the physical layout of the network. In one fascinating example we ran into with a large organization, they had one of the most elaborate security models we had ever seen. This organization had seven separate networks, all separated by firewalls with Network-based Intrusion Detection Systems (NIDS) at each entry point. The products they chose were all top of the line, to include trusted Operating Systems and, at that time, brand new Host-based Intrusion Detection Systems (HIDS) products. Everything looked great on paper and even logical when mapped out with our tools. But when we did wire traces, we realized that they had hooked everything up to the same switch. They were relying on this one switch to create their carefully separated networks, to include having external networks plugged into the same switch! To their overall team, this was a perfectly reasonable solutionand this was far and away one of the more well read and intelligent customers we had encountered. The problem was that their networking team was not part of the security design team, and the security design team was not part of the deployment team. So, when all was said and done, the system in logical terms was exactly as the designers had said it should be, but in physical terms, it was a different story. The moral of the story is to assume nothing when taking stock of your assets. Documentation is useful only to get you started. Check everything manually and physicallyand assume nothing.

Quantify the Value of the Asset

As part of the process of taking stock of what you must protect in your organization, it's important to quantify what those assets are worth to your organization. How much would disclosure of that information cost? How much would loss of that asset cost? What if the data was simply tampered with? For each organization, and for each asset, the answers to these questions are different. A public web server might not be as important as the company's accounting systemor vice versa in some cases. Consider the asset, what it does, and what would happen if the asset couldn't continue in its current function.

As part of the analysis phase, conduct a vulnerability assessment of the entire organization to verify this data and help to find vulnerabilities. A vulnerability assessment is defined by the U.S. Government as

  1. "An examination of the ability of a system or application, including current security procedures and controls, to withstand assault. A vulnerability assessment might be used to: a) identify weaknesses that could be exploited; and b) predict the effectiveness of additional security measures in protecting information resources from attack.

  2. Systematic examination of a critical infrastructure, the interconnected systems on which it relies, its information, or product to determine the adequacy of security measures, identify security deficiencies, evaluate security alternatives, and verify the adequacy of such measures after implementation." (U.S. Government, CIAO)

In short, a vulnerability assessment is any means of testing your entire organization, its systems, controls, and personnel, to detect vulnerabilities and to determine if the controls are adequate to protect against threats to your organization.

One of the more critical elements in any risk management program is the vulnerability assessment. Only by critically and scientifically assessing the vulnerabilities and testing the controls in an organization can one hope to improve that organization's security posture, to develop an effective risk management program, and to truly understand the inter-relationships between the elements of an organization. Thankfully, vulnerability assessments have become part of the lexicon for IT and are commonplace across the industry, but they are still not conducted with as much regularity or vigor as we would like to see. For IT assessment, there are now open source tools, such as nessus (www.nessus.org), that make it possible to automate vulnerability scans for IT resources from Cron. We highly encourage you to do this wherever possible. Think of as a tripwire for your network.

Threat Analysis

The final step in the analysis phase is to analyze the threats that might want to gain access to, damage, or deny access to your assets. Recall from Chapter 1 that there are three general classes of threats that we can look at for quick reference. Not all threats fall into those three categories, but as a whole they tend to cover the threats most organizations will face. Different assets might be exposed to different threats; a low value asset might just be a stepping stone to a higher value asset for one class of threats. For instance, an unimportant public web server with no important data or accounts is allowed to connect back into the organization's internal network through a hole in the firewall so that it can authenticate to a Primary Domain Controller (PDC). The web server is broken into, and the attacker then uses the unimportant web server to break into the PDC through a vulnerability in the RPC services. The PDC is then used to break into all the critical systems on the internal network. In this example, the threats perceived to exist against the web server, unstructured threats, are not the full range of threats the system might experiencebecause of its relationship to a higher value target. This goes back to the issue of understanding the inter-relationships between systems, networks, assets, and even people. When analyzing for threats (i.e. who would want to break into this system?), consider the down stream effects of breaking into the assets. This also brings up an emerging risk to organizations that goes beyond the scenario painted here and is directly related to the problem of analyzing threats; that risk is down stream liability.

Down Stream Liability

A not so new concept that is garnering a good deal of attention is "down stream liability." This concept relates to the notion that your organization is liable for any damage done to a third-party system because your systems were used to effect this damage. For example, in the previous case, your unimportant web server is broken into and used to break into a bank. The bank could sue your organization for failing to take appropriate measures to properly protect your systems. In layman's terms, basically this means that you can be sued for failing to effectively manage the security posture of your systems.



    Troubleshooting Linux Firewalls
    Troubleshooting Linux Firewalls
    ISBN: 321227239
    EAN: N/A
    Year: 2004
    Pages: 169

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net