Information Criticality

It’s important to begin by looking at information criticality.You’ll find that this is a common theme throughout most security texts, because there’s no point in securing something no one wants. Information criticality is an assessment of what your network holds and how important that is in the overall scheme of things. Not all data is created equal, and if your company manufactures steel troughs for horse feed, there’s a good chance your network data is not nearly as interesting to a potential attacker as the data in an online stock brokerage firm or a bank or credit card processing house network.Therefore, you need to look at the criticality of your information and decide how much you’re willing to spend to secure that information. No one wants a security breach, but it would not make good business sense to spend $15 million to secure a network for a company that pulls in $5 million annually and doesn’t store sensitive personal data such as credit card numbers or medical records. That said, just because your company makes $5 million annually doesn’t mean that you shouldn’t look seriously at the criticality of your data, to be sure you don’t have excessive exposure. If you are storing credit card numbers or medical records, you’d better be sure your security solutions are up to standards, because your legal liability could significantly outstrip that $5 million annually in a big hurry.

Impact Analysis

You’ll notice as you read the articles for the individual security area plans that some of the information overlaps. It’s hard to perform an impact analysis on an infrastructure breach without also seeing how it would affect your wireless network components, your Web site, or your policies and procedures. However, in looking at the impact to your infrastructure, you’ll need to understand how a breach could affect the very foundation of your organization.The impact analysis should include:

- Cost of network infrastructure failure (downtime) Server down, database server down, routers down, etc.

- Cost of network infrastructure unavailable (slow or unresponsive) Denial-of-service (DoS) attacks, packet flooding, etc.

- Cost of network infrastructure breach data confidentiality, integrity, availability Man-in-the-middle, spoofing, phishing, etc.

- Cost to company reputation Lost sales, lost customers, loss of longterm business relationships.

- Cost to company Cost of remediation, cost of litigation. You should combine information criticality with the findings of your impact analysis to form a clear picture of what you’re trying to protect and why. When you understand the impact, you can see where the important areas are in your organization, and can use this information, in part, to prioritize your approach to securing the network.

System Definitions

Infrastructure systems clearly include the “backbone” services, including DHCP servers, DNS servers, Directory Services servers, e-mail servers, database servers, firewalls, DMZs, routers/switches, operating systems,Web servers, and security applications (antivirus, antispyware, IDS/IPS, etc.). If it’s helpful, you can also look at your systems from the OSI model perspective from the physical layer up through the application layer, whatever makes the most sense to you and your team. Creating (or updating) network diagrams can also be included in the system definitions overview, since the way everything fits together is part of understanding the whole.

Information Flow

One area that is sometimes overlooked in the assessment phase is the flow of information through the infrastructure.This area can be used in conjunction with your systems definitions to help map your network and to discover the key areas that need to be protected and how an attacker would get to those assets. It sometimes helps to look at information flow from different perspectives. For example, how does information from a user computer flow? How does DNS or DHCP traffic flow through the network? How is external traffic coming into the network managed, and where and how does it enter? How is traffic leaving the network for the public network (Internet) managed? Creating a map of your network infrastructure and information flow will help you visualize your network and identify potential weak spots.

Scope

You might want to limit the scope of your infrastructure security project for a variety of reasons.“Scoping” is often done when you’re engaging an external security consultant. However, if you’re doing this work internally, you may limit your scope here, or you may choose to do a full assessment and then limit the scope after you see what’s what.

People and Process

Clearly, people and processes will also impact network security in a big way. Most security breaches occur from the inside, not the outside, despite the media’s sensationalized focus on external security breaches.The people in your organization can be your defenders or your downfall, depending on how they approach security. Savvy, well-informed users can augment the technical security measures by avoiding becoming victims of social engineering, reporting suspicious activity, avoiding phishing e-mail, or not leaving their computer logged in and unattended. All the security in the world can’t prevent problems if users are not pulling their weight. There are many ways to inform and involve users, and unfortunately, many IT departments don’t leverage these opportunities very successfully, because they often fall victim to a “user as pain in the hind quarters” mentality. Let’s look at how users and organizational processes should be reviewed during an infrastructure assessment.

User Profiles

What kinds of users do you have? Where and how do they work? If you begin by looking at your user population, you will see segments that have higher and lower risk profiles.The clerk in the mailroom might only have access to e-mail and the mailroom application, but does he or she also have Internet access and the ability to download and install programs? What about the marketing staff who travel worldwide? What kinds of information do they keep on their laptops (usernames, passwords, domain names, sensitive documents, contacts, and the like), and how does this affect your network security? Users can be categorized in whatever ways work for you in your organization, but here’s a list of potential risks by employee type, to get you thinking:

- Executive High-profile targets, often not “tech savvy,” potentially easy to get information about (from press releases, public filings, legal filings, and so on).

- Director High-profile targets, may travel extensively with sensitive information, may need to connect to the network in a variety of insecure locations.

- Finance, marketing, HR, legal Access to extremely sensitive data, may be high-profile targets due to their access to sensitive data, may travel extensively and be desirable targets of social engineering.

- IT staff Access to network resources, ability to grant/deny access, potentially desirable targets of social engineering (especially via help desk), highly desirable targets (IT usernames and passwords with administrative privileges are the Holy Grail for hackers).

- Users Access to sensitive company information, often targets of social engineering. In addition to these categories, you may have user groups defined in your network security management system (which manages access control) you want to use. Microsoft defines users as administrators, power users, and the like, which might work for you. Again, the point is to use a categorization method that’s meaningful to the way your company and your existing network infrastructure are organized, so you can understand the risks users bring into the organization and the strategies for keeping the network secure in light of the way various users work.

Policies and Procedures

Infrastructure policies and procedures touch on the day-to-day operations of the IT staff, including the way security is monitored (auditing functions, log files, password policies, alerts) and how it is maintained (backups, updates, upgrades). Policies regarding user behavior are also crucial to ensuring that the network infrastructure remains safe. Finally, corporate policies regarding the use of data, computer and electronic equipment, and building access, to name just three, are areas that should be reviewed and revised to support and enhance security across the enterprise. Organizational Needs The internal environment is shaped by the organization’s business profile, including the type of business, the nature of sales and marketing functions, the types of customers, the kinds of employees, and the flow of work through the company. What does your company require from the network services you provide, and how can these needs be secured? If you believe your organization’s network, data, and computer needs are being met, delineate what they are, and check with a few users to see if you’re on the mark. Make sure you understand how the network fits into the organization, not the other way around, and then design your security solution accordingly.

Regulatory/Compliance

Any infrastructure assessment and security plan must incorporate regulatory and compliance requirements.These vary greatly from state to state and country to country, and keeping up with them can be more than a full-time job. Many companies are hiring compliance officers whose primary job is to manage corporate compliance. If your company has a compliance officer, make sure he or she is a member of your IT project team, at least during the definition phase, when you’re developing your functional and technical requirements, since these are often the method by which compliance occurs.We’ve included a short list here with a few Web site links, but it’s not exhaustive; you should seek legal advice regarding regulatory and compliance requirements for your firm if you don’t have a knowledgeable and experienced compliance officer in place.

Establishing Baselines The point of performing these assessments is not to prove that your network is secure or insecure, but to find out exactly what level of security you actually have and to establish baselines. When you know the starting point, you can improve security incrementally and document it as you go. Baselines are created by establishing a known starting point, in this case your current settings. It might be tempting to correct problems as you perform this assessment, but it’s not the best way to proceed. As you know, making a configuration change at Point A can cause a ripple effect through your network and show up at Point C in a strange and unexpected way. As you develop your project plan, be clear with your project team that they need to document existing configurations, settings, versions, and so on, without making changes. If a team member finds a serious security hole, it should be brought to your attention immediately for action.The problem should be quickly assessed and addressed in a calm, rational, thoughtful manner, and possibly incorporated into your project plan. Does that mean that you wait until your project planning is complete to address a serious security hole? Absolutely not.You should, however, use a well thought-out strategy for addressing it outside the project planning cycle, and then document the changes and incorporate them into your project plan. What you want to avoid is having every person looking at the network making small tweaks here and there to “tighten up security” as they go, because you’ll end up with a mess at the end of your evaluation period. Serious problems should be brought to your immediate attention, and minor issues should be well documented. Addressing Risks to the Corporate Network Once you have created a prioritized list of risks to your network and their associated costs, your next step is to determine a course of action in handling each risk. When deciding how to address risks to your network, you typically have one of four options:

- Avoidance You can avoid a risk by changing the scope of the project so the risk in question no longer applies, or change the features of the software to do the same. In most cases, this is not a viable option, since eliminating a network service such as e-mail to avoid risks from viruses is not an appropriate measure. (Network services exist for a reason; your job as a security professional is to make those services as secure as possible.) One example of how avoidance would be a useful risk management tactic is if a company has a single server that acts as both a Web server and a database server housing confidential personnel records, when there is no interaction whatsoever between the Web site and personnel information. In this scenario, purchasing a second server to house the employee database, removing the personnel database from the Web server entirely, and placing the employee database server on a private network segment with no contact to the Internet would be a way to avoid Web-based attacks on personnel records, since this plan of action “removes” a feature of the Web server (the personnel files) entirely.

- Transference You can transfer a risk by moving the responsibility to a third party.The most well-known example of this solution is purchasing some type of insurance let’s say flood insurance for the contents of your server room.Although the purchase of this insurance does not diminish the likelihood that a flood will occur in your server room, it does ensure that the monetary cost of the damage will be borne by the insurance company in return for your policy premiums. It’s important to note that transference is not a 100-percent solution in the flood example, your company will likely still incur some financial loss or decreased productivity in the time it takes you to restore your server room to working order. As with most risk management tactics, bringing the risk exposure down to zero is usually an unattainable goal.

- Mitigation Mitigation is what most IT professionals think of when implementing a risk management solution. It involves taking some positive action to reduce the likelihood that an attack will occur or to reduce the potential damage that would be caused by an attack, without removing the resource entirely, as is the case with avoidance. Patching servers, disabling unneeded services, and installing a firewall are some solutions that fall under the heading of risk mitigation.

- Acceptance After you have delineated all the risks to your infrastructure that can be avoided, transferred, or mitigated, you are still left with a certain amount of risk that you won’t be able to reduce any further without seriously impacting your business (taking an e-mail server offline as a means to combat viruses, for example).Your final option is one of acceptance, where you decide that the residual risks to your network have reached an acceptable level, and you choose to monitor the network for any signs of new or increased risks that might require more action later. There is no one right way to address all risks to your infrastructure; you’ll most likely take a blended approach to security.There are some risks you absolutely need to avoid, other risks you can reasonably transfer or mitigate, and still others that you simply accept because the cost of avoiding them is just not worth it.