Risk Analysis and Final Presentation
213
can understand what it will take to implement them. The recommendations should
be documented in such a way that each recommendation or group of recommenda-
tions can be identified as separate initiatives, where costs and resources can be
defined. Ideally, the set of recommendations you present in the final report should
be used as a master plan for the company’s information security program.
In the context of the security assessment methodology, developing recommen-
dations is the final step but
something that is happening throughout the assessment
as you identify findings. Some findings you discover may be very clear, and as a
result, the recommendations might also be very clear. In other cases, the findings
might be more complicated, and the recommendation might not be very clear. In
these instances, you might start thinking about some options for recommendations.
In any case, you probably have some idea of what the recommendations are going
to be by the time you get to this phase of the security assessment. Note that in
previous phases, recommendations were to be documented to the extent you formu-
lated them. These preliminary recommendations are important because they lay the
groundwork for refining and finalizing them in the final phase of the assessment.
Developing recommendations is an iterative process when you are conducting
a security assessment because of the way you are gathering information and because
of how the business processes and technology are integrated. During Phases 2
through 4 — Initial Research, Business Process Review, and Technology Review —
information is gathered and findings are discovered. As these findings are discovered,
you will naturally start to think about potential ways to address the given risks. As
you gather more information, the previous recommendations might change because
of new information. This cycle keeps going during the assessment.
For example, you might discover a security weakness related to a firewall and
its configuration. The weakness happens to be related to the firewall rules and how
the firewall is set up incorrectly from an architecture perspective. At first glance, the
recommendations for changes to the rules and architecture might seem straightfor-
ward. Upon meeting with IT management, however, you might learn that there is
going to be a server consolidation, and new software including a new firewall is
going to be purchased in the next six months. If you originally had significant
recommendations regarding the firewall architecture or rule base configuration, this
might change. With this new information, you should inquire about the proposed
changes to the network and specifically the firewall. At this point, it is not appropriate
to spend a lot of time on the current firewall because of the upcoming changes. It
is, however, worth looking at what firewall is going to be purchased and the proposed
changes to the network. The recommendations will now have a slightly different
focus, as they will also reflect the planned changes to the environment.
The iterative process in developing the recommendations helps you sort through
the range of potential solutions and determine the best option. Part of this iterative
process is receiving input from the client during status meetings. During the regular
status meetings with the client, you can discuss recommendations as you develop
them. Client feedback during the assessment is very valuable because it can give
you an indication of what the client is prepared to do or whether there are things
with which the client disagrees. For example, some clients will not deal with certain
vendors, or there might be cultural issues that might make some recommendations
AU1706_book.fm Page 213 Tuesday, August 17, 2004 11:02 AM
214
A Practical Guide to Security Assessments
not feasible. Another example is where you might be proposing a recommendation
that the client has already tried. This is all valuable information, and the iterative
process involving the client will help surface these issues. It is important to remem-
ber, however, that you must still independently advise the client, as you feel neces-
sary. You need to strike the right balance between obtaining the client’s input and
feedback and still retaining your independence. This is a key concept; the quality
of the assessment can be diminished if there is an impression that you are not
independent and that you are simply writing based on what the client is telling you.
The purpose of client input is so they can provide you with information you might
not have uncovered when conducting the assessment — not for them to tell you
what they want to see. Remember that the final decision as to how you advise them
is yours.
This iterative process is beneficial for both you and the client. From your
perspective, you have an opportunity to bounce various options off the client and
let the client give you further insight and information that you might not have
obtained otherwise. From the client’s perspective, they begin to see the types of
recommendations that are being generated and have the opportunity to offer their
input on them. This is very important for clients because they will ultimately need
to get buy-in from their management to implement the recommendations. If your
client contact is not comfortable with the recommendations, it will be more difficult
for that person to convince his or her own management to implement the recom-
mendations.
Similar to the importance of wording when documenting findings and risks, it
is equally important to phrase the recommendations the right way. Several charac-
teristics that you should keep in mind when documenting recommendations are
discussed in the next section.
C
HARACTERISTICS
OF
G
OOD
R
ECOMMENDATIONS
The importance of good recommendations cannot be overstressed. To clarify, good
recommendations are not necessarily the cheapest or easiest solutions nor are they
something that the client is necessarily going to be happy with. The recommendations
should, however, be what is best for the client based on your judgment and what
you learned during the assessment. Every recommendation should:
• Address the risk
• Provide enough detail
• Be cost effective (i.e., show a return on security investment)
Address the Risk
The need for recommendations to address the risk sounds very obvious, but this is
not always the case. It is very easy to let discussions go off on tangents and lose
focus on what the risk is and what it is you are trying to address. There is often a
tendency to start with an idea for a recommendation and let that lead into a discussion
of bigger and grander solutions. At that point, if you take a step back, you realize
that the recommendation being proposed not only fixes the problem, it also does
AU1706_book.fm Page 214 Tuesday, August 17, 2004 11:02 AM
Risk Analysis and Final Presentation 215
many other things that the client does not necessarily need. As the solutions become
more involved and extensive, they cost more to implement and maintain. Many
clients view security as a cost, and their general philosophy is to spend what is
necessary and nothing more. One of the ways of adhering to this philosophy is to
make sure the recommendation is addressing the risk. The structure of the report
facilitates this because you have a separate section for the findings, with a separate
risk and recommendation for each finding. With this structure, it is easy to check
whether the recommendation makes sense based on the finding and risk. This goes
back to the importance of documenting the finding and risk in a clear and concise
way.
You should be prepared to talk about any of the recommendations in the final
report and specifically, how they address the risks identified. It is highly unlikely
that the client will implement recommendations that do not address the risk.
Provide Enough Detail
One of the comments often heard from clients is that security recommendations are
so high level that they are useless. This is a legitimate issue that you should be
mindful of when writing recommendations. There must be enough detail in the
recommendations to allow management to determine the cost, time, and resources
that will be required for a given security initiative. If management can do this, the
recommendations will have served their purpose as a “security roadmap.”
Documenting risks, however, is a balancing act. You need to strike the right
balance between providing too much detail and too little detail. If you keep the
recommendations too high level, they are of little use to the clients. If you provide
too much detail, you are probably going out of the scope of the engagement — i.e.,
if you are providing step-by-step solutions in a recommendation, you are probably
doing too much for a security assessment. You probably do not have the time to do
the necessary research to provide in-depth detailed recommendations. You also
should not take time away from other parts of the security assessment that require
attention. A good rule of thumb to remember when documenting recommendations
is that they should convey enough information to determine relevant tasks and the
resources required to implement the recommendation.
Cost Effectiveness (Return on Security Investment)
As was stated earlier, security is a cost, and most of the recommendations you make
will have some cost associated with them. One of the first questions in the minds
of client personnel when you make recommendations is the cost of implementing
the recommendations and any costs related to ongoing maintenance. The costs related
to security recommendations will face the same level of scrutiny as other expendi-
tures do. Spending decisions for information security or any other initiative are based
on the value it will bring to a company. With some security recommendations, the
cost justification is easy if it can be tied to revenue. For example, if a company
invests money in obtaining a certification to its e-commerce site, that might bring
in a sizable number of additional customers. In this case, the justification for such
a recommendation is based on potential revenues that will come into the company.
AU1706_book.fm Page 215 Tuesday, August 17, 2004 11:02 AM
216 A Practical Guide to Security Assessments
In most cases, however, it is difficult to tie information security spending to
incremental revenues — e.g., if I spend $100,000 on implementing an intrusion
detection solution, I cannot point to any additional revenues that the company will
receive as a result of it. Information security spending is viewed in the same way
as spending on insurance, except that insurance is normally required and security is
not. Information security initiatives are viewed as planning for something that might
happen and not something that necessarily impacts the bottom line. The benefits of
investing in security have always been characterized as mushy concepts that live far
from the bottom line. Successes like avoiding bad press or not losing productivity
to a virus — these are important but they don’t translate into profits. The best
argument you could make is that you may have prevented an unknowable amount of
losses. Think of it this way: If you had to pay $100 for the right to access your seatbelt
every time you got in a car, but you never got in an accident, what’s your ROSI
(Return On Seatbelt Investment)?
1
For cases where the link cannot be established between information security and
profits, it is sometimes very difficult to see the value in it. As a result, it is often
difficult to make a business case for information security. For many, the attitude is,
“if nothing has happened to me so far, why would anything happen now” or “if its
not broken, don’t fix it.” With this attitude, it is very difficult to convince client
management of the value of security. Keep in mind that these decisions regarding
whether or not to proceed with a security initiative often rest with individuals outside
the security organization. Depending on the potential cost of a security recommen-
dation, the cost could be high enough that chief financial officer (CFO) approval is
required. With almost any decision there is potential cost — i.e., external cost (this
does not include internal costs where it is just a matter of additional work taken on
by employees). Before most executives will approve an expenditure, they want to
know the reason for the expense and whether the cost is justified.
Any executive who approves expenditures will ask questions about the ROI
(return on investment). In the information security arena, this is referred to as the
ROSI or return on security investment. When developing recommendations in a
security assessment, it is essential to do a high-level cost-benefit analysis to ensure
that the recommendation makes sense for the client. With cost-benefit analysis, there
is a rule of thumb that you should always keep in the back of your mind as you
make recommendations — the cost to secure an asset should not exceed the value
of the asset. This very basic concept can screen out recommendations that are not
appropriate, and it is often overlooked.
The question then is how do you do a cost-benefit analysis and demonstrate an
acceptable ROSI relative to a recommendation? The first thing is to try to link an
information security initiative to revenue-generating activity — i.e., show that infor-
mation security can help increase revenue. For example, consider a company that
performs outsourced services for companies via an application service provider
(ASP) model. Imagine that for the outsourcer to continue to do business with this
customer, the company must spend on some information security initiatives
demanded by the customer. In fact, other customers may demand the same security
measures, making the case for the security initiatives even more compelling. Assuming
AU1706_book.fm Page 216 Tuesday, August 17, 2004 11:02 AM
Risk Analysis and Final Presentation 217
the cost is not exorbitant, the information security initiative will probably be
approved to continue doing business with the business partner.
Other cases are more complicated, and convincing client management of the
cost benefit of implementing recommendations can be difficult. In these cases, no
direct revenue can be tied to the security initiative. With these recommendations,
the discussion focuses on the likelihood of a security incident related to the finding,
the impact of the security incident, and how much the recommendation mitigates
the risk associated with the finding. Essentially, you are trying to predict what might
happen and the associated probability and impact. This calculation is the ROSI.
Ways to do the cost-benefit analysis and determine the ROSI are explained below.
One of the methodologies for calculating ROSI was developed by a team of
Idaho researchers and was published in CIO magazine in February 2002.
2
This is a
very straightforward calculation that uses the concept of Annual Loss Expectancy,
similar to disaster recovery planning. The calculation that was published is docu-
mented below and applied to an example of a recommendation proposing the use
of intrusion detection.
(R – E) + T = ALE
T is the cost of the intrusion detection tool.
E is the dollar savings gained by stopping of intrusions through the introduction of an
intrusion detection tool.
R is the cost per year to recover from an estimated number of intrusions.
Doing this equation yields the Annual Loss Expectancy (ALE).
R – ALE = ROSI
To determine the return on security investment (ROSI) we simply subtract what we
expect to lose in a year (ALE) from the annual cost of intrusion.
In the calculation above, the formula was intended for intrusion detection, but
other security initiatives can be used instead to determine the ROSI for a given
security initiative. This is a good formula because it is straightforward and it is
something that can be translated into dollars, which is important for decision-making
purposes. Although this is a specific formula, some elements in the equations are
very subjective. For example, the cost to recover from intrusions (R) is a very
subjective number, which is what it should be. Intrusions can vary in severity, and
the associated cost to recover might range from nothing to something fairly sub-
stantial. Similarly, the dollar savings resulting from proactively stopping intrusions
(E) is also very subjective, as there are many variables in calculating this number.
As you can see, there is still a fair amount of subjectivity when calculating ROSI.
As difficult as it is, you must work with the client to determine dollar values for
these subjective items needed to calculate the ROSI or cost-benefit analysis. Any
past experience with security incidents and publicly available statistics can be used
to help estimate numbers in this calculation or can be used as a benchmark.
AU1706_book.fm Page 217 Tuesday, August 17, 2004 11:02 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.