This document discusses the importance of ongoing risk assessment for companies. It recommends that risk assessment consider not just IT networks and computers, but also physical security and employees. A comprehensive risk assessment process involves identifying assets, threats, vulnerabilities, likelihood of threats, potential impacts, existing controls, and recommendations. It is important that risk assessment be an ongoing and recurring process to account for changing business needs and environments.

1. »McDonald’s founder Ray
Kroc once said, “If you’re
notarisktaker,youshould
get the hell out of business.” Today, tech-
nology provides golden opportunities of
which yesterday’s entrepreneurs would
never have dreamed. The flip side is that
companies willing to take the leaps nec-
essary to thrive in a competitive global
economy expose themselves to hazards
unheard of even 10 years ago. To survive,
enterprises must continually use risk
assessment methods. Otherwise, they
could unwillingly follow the second half
of Kroc’s advice.
Specifically, IT professionals can’t
limit their risk assessment activities to
Rethink
Risk
TO BUILD EFFECTIVE
SECURITY POLICIES, IT'S
TIME TO INVOLVE NON-IT
BUSINESS STAKEHOLDERS
IN ASSESSING AND
ADDRESSING THREATS
BY CHAD KOROSEC
A SPECIAL SECTION FROM THE NWC GROUP
STRATEGIC
SECURITY
jun08_strat 5/24/06 5:14 PM Page 1

2. IT networks and computers. Physical security must be
considered, as well as employees—people aren’t just a
company’s most valuable asset, they’re also the easiest to
compromise. That means you must ensure that risk-as-
sessment practices are codified within your organization
through policy, standards and guidelines.
A Neverending Process
The risk-assessment process can be anything from a
quick walk-through and analysis of known hazards, in
the case of a small business, to a lengthy process involv-
ing multiple teams and consultants. But one thing is al-
ways true: Risk assessment must be recurring—revisited
at least twice a year to ensure that new dangers are not
overlooked and old risks are managed effectively. Addi-
tionally, your policies must be reviewed and updated
continually to account for changes in business methods
and processes.
Risk assessment, which we define as the process of
identifying factors that can influence operations nega-
tively and a decision maker’s ability to make informed
choices, has been around for years as a means to gauge
the status of a company’s assets versus potential risks—
like most activities in business, it focuses primarily on
the bottom line. An infosec professional’s role in risk as-
sessment is to determine the cost to the organization if
particular vulnerabilities are exploited.
The first step in this process is to know your organiza-
tion’s view of, and tolerance for, risk. In addition, note
that requirements to manage, mitigate or eliminate risk
no longer depend only on your company’s tolerance
level. Uncle Sam has gotten into the act, and risk assess-
ment is intertwined with an ever-growing set of regula-
tions that mandate or “strongly recommend” specific
risk-management methods. Make the regulations that
apply to your company part of your vocabulary, if they
aren’t already.
In a business that escapes most regulatory oversight?
Undertake risk assessment anyway. All too often, IT pros
who should know better function in an, “It won’t hap-
pen to us” mindset. When “it” does happen, we’re
caught off guard. Wait until a crisis hits to plan, and
your ability to react effectively will be impaired. Look at
the daily news reports about organizations experiencing
loss due to attacks against systems with known vulnera-
bilities—even a half-hearted risk-management effort
would have caught these basic vulnerabilities.
Risk assessment is comprises asset identification and
evaluation, threat and vulnerability identification, con-
trol identification, determination of the likelihood of a
threat, impact on the CIA (confidentiality, integrity and
availability) of an asset, risk determination, control rec-
ommendation, and documentation and policy (see illus-
tration at left). These steps may be consolidated or com-
pressed, as long as they’re all present.
Identify Your Assets
No auto insurance company will issue a quote unless it
knows the type of car to be covered, and who will be
driving. It’s the same story in organizational risk assess-
ment. Business units must be forthcoming on what as-
sets they have on hand, who the users are, and the re-
placement costs associated with those assets. IT’s job is
to evaluate this information for potential loss.
The task of asset identification and evaluation, as with
most processes, starts with a comprehensive information-
gathering process. Consider forming a multidiscipline
risk-assessment team involving a cross section of your or-
ganization. Our experience shows that this team ap-
proach is most effective. And, you’ll see ongoing benefits
from cross-departmental IT-to-business relationships.
Assets are those things that are required to make your
business successful and functional—not only hardware
and software items that have property tags on them, but
also hard-copy reports, data within a database, even crit-
ical employees who can make or break an organization if
they are lost due to competition, retirement or even the
flu. Is the most important asset in your internal intranet
the $20,000 firewall, or the data that’s sitting on a
$2,000, four-year-old box that’s serving as a data reposi-
tory? It’s not easy to put a value on data that may have
taken years to acquire. Is it worth thousands, even mil-
lions of dollars? Business units are the best source for up-
to-date figures.
After you’ve documented the assets in your organiza-
2 STRATEGIC SECURITY | JUNE 8, 2006 | WWW.NETWORKCOMPUTING.COM
jun08_strat 5/24/06 5:14 PM Page 2

3. tion, start again, because you probably missed some-
thing. Did you count client and CRM data, marketing
figures and intellectual property?
Threat Sources
Once you have a feel for your assets, compile a list of IT
threats and threat sources that could exploit vulnerabili-
ties in your systems. In addition to counting outside at-
tackers, consider insider theft, system failure and even
environmental hazards.
Not all threats pose the same risk factor; the severity
of a risk can be mitigated based on need, cost and even
the expendability of departmental assets. It’s typically a
given that an external Web site is invaluable for a market-
ing department in terms of loss of service. However, other
departments may not depend on their sites for sales, so
reduced connectivity may not represent lost business or
revenue. On the same note, sites that could provide ac-
cess to financial information or controversial data are
tempting targets, requiring additional controls. Also con-
sider possible threat motivations. Will it be script kiddies
having fun, organized criminals seeking identity informa-
tion, a disgruntled employee with a vendetta, or indus-
trial espionage where a rival organization is looking to
gain a financial or competitive advantage?
In addition to calling on team personnel who under-
stand the systems and data, use sources of threat data, such
as national estimates for government sources, CERT (Com-
puter Emergency Response Team) reports and even media
reports that highlight trends in information security.
Next, begin to identify vulnerabilities with regard to
both systems and processes. You likely have tools on
hand to assist, including desktop-management applica-
tions and third-party assessment tools—risk calculators,
vulnerability scanners and guides, and checklists, such as
the Security Configuration Checklists from the NIST (Na-
tional Institute of Standards and Technology, checklists.
nist.gov) and the Security Technical Implementation
Guides from the Defense Information Systems Agency
(csrc.nist.gov/pcig/cig.html).
Remember that flaws can lie in internal processes
used to manage data and information. Consider the
source of the threat along with the potential target to en-
sure you keep your assessments in context. A common
process vulnerability we see almost daily happens when
employees print sensitive data, review it and then drop it
in a trash can or recycling bin. It’s at the expense of your
security if waste paper is simply handed over to local re-
cyclers without shredding. And dumpster diving remains
a popular low-tech exploitation method.
Also remember to contact the sysadmins who moni-
tor and manage your corporate firewalls and routers
and ensure that these systems are in a deny-all, permit-
some mode, allowing only approved ports access.
When dealing with corporation-wide systems, it’s al-
ways better to have a standard baseline build that has
removed all unnecessary software. Recent malware at-
tacks have shown a need to have rebuilds streamlined
in the event you need to update multiple infected ma-
chines in a timely manner.
Ensure you have standards for those who travel or
telecommute and require access to your intranet. Even
remote offices should be closely monitored; in many
cases of corporate theft we’ve seen, these are the best tar-
gets given that they usually have access to corporate net-
works but remain out of IT’s direct control.
Finally, determine whether you need outside assis-
tance with vulnerability-scanning tools, even penetra-
tion testing. Both methods have proven useful to organi-
zations in alerting them to vulnerabilities, however, they
come at a cost—both financial and in terms of time. See
“Is Penetration Testing a Good Idea?” at www.itarchitect.
com/showArticle.jhtml?articleID=164901611 for our take.
Vulnerabilities are tamed with controls, which come in
two flavors: technical and nontechnical. Technical con-
trols include firewalls or automated password-protection
features. Nontechnical methods include security training,
separation of duties and even policy implementation.
When analyzing controls, the method of employ-
ment indicates whether they’re preventive or detective.
Preventive methods are those used to keep people from
violating policy—visible access control, use of encryp-
tion or secure servers and authentication—whereas de-
tective controls produce some kind of record of possible
Action Description
Accept the risk When the risk is so unlikely or its impact so low that it warrants no further action, the company can decide
to simply bear the cost of recovery if the need arises.
Avoid the risk When the cost and likelihood of the risk are large, it may no longer be feasible to continue operation in the
area of activity that incurs the risk.
Transfer or share the risk When the risk is part of the business—but the cost is predictable—the company may share or transfer risk
through insurance, contracts and warranties, and joint-venture agreements. The cost of those penalties
belong entirely to the delivery service.
Reduce or mitigate the risk Often, risk must be borne for a core function of the business; however, systems and controls will be needed
to mitigate or reduce the likelihood or the impact of the risk.
Ignore the risk It is very dangerous for executives to do nothing—neither consciously accepting the risk nor mitigating it.
Burying Your Head in the Sand Is Not An Option
Source: Gartner
4 STRATEGIC SECURITY | JUNE 8, 2006 | WWW.NETWORKCOMPUTING.COM
jun08_strat 5/24/06 5:14 PM Page 4

4. violation and include audit trails, event logs, intrusion
detection systems and even integrity tools used to con-
firm alteration of data.
Likelihood of the Threat
Asking the question, “Will it really happen to us?” is the
next step in your process. This exercise lets you assign
probabilities to weigh the likelihood that vulnerabilities
will be exploited and cause harm. In days past, where
risk elimination was the method of operation, this step
wasn’t necessary. But in today’s age of quickly changing
technology, the best we can do is to try to manage the
risks we ID.
NIST’s Risk Management Guide for Information Tech-
nology Systems (csrc.nist.gov/publications/nistpubs/800-
30/sp800-30.pdf) recommends a three-tiered table for as-
signing likelihood measures that a vulnerability will be
exploited. Analyze factors such as your organizational
objectives and the products, sales, marketing or research
you do. Then determine what the nature of an attack
would be, along with the motivation behind an action.
After you’ve analyzed your vulnerabilities and the
threat environment, consider controls and how effec-
tive they’ll be at fending off an incident. Keep your or-
ganizational practices in mind. What’s worse, a severe
vulnerability that can’t be accessed remotely or two
less-critical holes that can be exploited from the out-
side? Do you have employees who work at home on
unsecured WLANs? Always consider the implications
that your network and architecture have on your
threats and vulnerabilities.
For each threat, play the pessimist and assume that
the worst has happened. How bad could it be? What
business areas will be affected? What could it cost your
organization? Although cost is valuable to determine
loss, it’s also be important to consider major security
goals in this analysis. You may be able to work with ex-
isting documentation, such as impact analysis reports
and possibly other cost-benefit studies, to estimate loss.
Although many things in the risk arena have changed
over the years, qualitative and quantitative analysis re-
main the two primary means of assessing risk; the
method you use will depend on the type of assets you’re
analyzing. We typically refer to risk in terms of annual
loss expectancy, so the typical method of risk analysis re-
mains quantitative evaluation, which assigns loss values
in dollar amounts.
In terms of the firewall and server mentioned previ-
ously, we can assign an initial cost to these assets as well
as any ongoing costs they require. Additionally, we can
do an evaluation of any replacement costs for the hard-
ware, standard software suites and initial installation
costs in today’s figures that can be used to determine ac-
tual replacement costs. It’s hard to put a monetary value
on intangibles, such how much a network breach would
cost your company in terms of loss of credibility or con-
fidence. In these cases, you can list the impact as high,
medium or low.
Making Risk a Part of Policy
When you complete your assessment, it’s likely that
you’ll have a tired team and good methods in place to
manage and mitigate risk. So you don’t lose any of this
corporate knowledge, and to ensure that your efforts
remain an ongoing part of your organizational activi-
ties, take the time to fully update your existing risk
analysis policy or create a new set of documents. This
policy will serve as the formal statement by the organi-
zational management team dictating how risk assess-
ment activities will continue, by forming basic rules
for ongoing initiatives. You still have a risk assessment
team in place, so use them to address this issue of
defining and outlining the policy, standards, guide-
lines and procedures that will be needed to continue
these efforts.
To ensure that your hard work doesn’t end up on a
bookshelf gathering dust, develop a plan to properly
train employees in their roles and responsibilities. Fi-
nally, ensure that your policy and risk assessment activi-
ties are assigned in some type of maintenance program
to ensure they are being followed, updated and modified
where needed.
Given the fast pace of change within the IT industry
and the workplace, the threats you address today may be
gone or replaced tomorrow, so be diligent about identify-
ing new threats on a continuing basis. As Dan Quayle
says, “If we don’t succeed, we run the risk of failure.”
6 STRATEGIC SECURITY | JUNE 8, 2006 | WWW.NETWORKCOMPUTING.COM
Chad Korosec is a senior information security engineer/scien-
tist with Mitre Corp. (his affiliation with Mitre is provided for
identification purposes only and does not imply Mitre’s sup-
port for the viewpoints expressed in this article.) Write to him
at ckorosec@nwc.com.
Risk By The Numbers
114,000
Number of new rules and regulations that impact business
introduced by the U.S. federal government since 1981
75%
Fortune 1000 organizations that will have established a formal
enterprise risk management office, with a CRO or equivalent role,
by the end of 2007.
116
Of 141 CIOs, number who said IT risk management and compliance
efforts are integrated with their companies’ overall risk
management and compliance efforts
Source: Forrester
jun08_strat 5/24/06 5:14 PM Page 6

5. HOWTO SURVIVE
DATA BREACH LAWS
The regulatory landscape of data security breach laws—in
which an organization must notify those affected by an
unauthorized disclosure of personal information—is rap-
idly evolving. In 2002, California was the only state with a
breach law, and you could keep your head in the sand as
long as you had no customers or employees in the land of
sunshine. Since then, 22 other states enacted breach laws.
Blissful ignorance is no longer an appropriate strategy.
The personal data stored by your organization will al-
ways be subject to some risk. But the level of risk can be
controlled—for a price. The question then becomes—
how much protection is appropriate and at what cost?
The answer requires an assessment of the risk of unau-
thorized access to personal data. (See the article “Per-
forming Analysis to Reduce Risk” on page XX.)
Start the assessment by understanding which of these
22 laws affect you. Whether you are subject to a particu-
lar law may depend on the location of your principal
place of business and the residency of those affected. Al-
though most statutes are based on a couple of common
templates, each law may have different requirements for
the notice trigger, timing, content and recipients. If you
are subject to more than a few laws, the wisest strategy
may be to develop a uniform policy that meets the re-
quirements of the most stringent breach law.
Congress may simplify the mess; it is considering bills
that, if enacted, would preempt state breach laws. A federal
law will impose less-stringent requirements than the state
bills. Consumer and privacy advocates are working to stop
these bills from rolling back the stronger state protections.
A critical component of a risk assessment is to assign
dollar values to assets as well as the impact of threats.
One of the most significant impacts is the breach laws’
requirements to send notices to subjects following an
unauthorized disclosure. Other potential costs of a
breach to include in an assessment are damage to brand
reputation, loss of current/future customers, liability
under other state laws, and of course, possible lawsuits.
Nearly all breach laws provide an exemption if the
personal data was encrypted at the time of the disclosure.
Of course, the encryption exemption provides benefits
only if the data is centralized in one or a few databases. If
the data is dispersed across multiple applications and
business units, or worse—scattered in “unstructured data”
such as word processing and Excel documents, which are
then loaded onto phones and PDAs—then the invest-
ment in database encryption will only benefit the vendor.
Strategic Ignorance
The appropriate level of monitoring, whether by tradi-
tional host and network intrusion detection products or
by specialized database security products, must be deter-
mined in the risk assessment. However, the implications
flowing from this decision are not obvious. For example,
focused monitoring will detect more intrusions. But be-
cause most breach laws provide no explicit guidance on
what type of monitoring is required, you have wide dis-
cretion in choosing the specific technology controls (al-
though you can’t go too low—limitations on lax security
can of course be enforced by your local state attorney
general or the FTC).
Of course, industry-specific regulations such as Gramm-
Leach-Bliley (covering financial organizations) impose in-
formation security requirements. Compliance with these
laws also often provides an exemption from breach law lia-
bility. Preferring to remain oblivious to some types of
unauthorized disclosure may sound ridiculous, but after all
the costs of a notification event are added up, a rational or-
ganization will find itself calculating these tradeoffs.
Do yourself a favor: budget time and money to under-
take a risk assessment, and start making those appoint-
ments to meet with the relevant stakeholders—IT and se-
curity teams, legal, public relations and executive-level
leadership to avoid facing inquisitions from them, not to
mention the press, government regulators, your cus-
tomers and their lawyers.
Patrick R. Mueller is completing his law degree and a master’s
degree in Public Affairs at the University of Wisconsin-Madi-
son, specializing in privacy and data security law and policy.
Write to him at patrick@pmueller.org. Post a comment or
question on this story at www.nwc.com/go/ask.html.
8 STRATEGIC SECURITY | JUNE 8, 2006 | WWW.NETWORKCOMPUTING.COM
BY PATRICK R. MUELLER
jun08_strat 5/24/06 5:14 PM Page 8