In the last chapter, we were treated to a brief exposure to Disaster
Recovery Plans in the recovery phase of a Business Continuity Plan. The
biggest difference about a Disaster Recovery
Plan is that it is activated and used once the disaster
is over. In the opinion of our current author, the DRP may actually
be part of the BCP. I think I see his point, that we begin to transition
to normal operations while still using a BCP. However we ended the last
chapter with the thought that we would stop using the BCP when the disaster
ends, and we have just settled on the idea that the DRP starts once the
disaster is over, so the most I think we should allow is a little overlap
from the BCP to the DRP.
On page 372, the text offers five more terms that the author associates with DRPs. However, some of them (like business interruption planning) sound too much like BCP, and not enough like DRP.
The author continues his custom of assuming we did not read the previous chapter by presenting a set of five critical concepts, four of which we have seen before (in this book, blast it!). There is one new one:
The text briefly addresses reasons for having a DRP, which should be known to us by now. If there is a disaster, the other plans we have prepare for it, deal with it, and carry on during it. The DRP covers returning to normal operations, which our organization needs to do. The author complicates the issue on page 373, discussing saving lives and ensuring business continuity, which were covered in other chapters, in other plans. I suppose he is taking the point of view that if we only had a DRP, it would have to include the others plans as well. Aye, and if my grandmother had wheels, she'd be a wagon. When our plan book has a chapter for every type of plan, we are most likely to use a DRP for its intended purpose, which is returning to our pre-crisis operational state.
The text cautions us to include Critical Success Factors (CSFs) when we write a DRP. These are things that make it possible to create a useful DRP. You could argue that they would contribute to the success of any of our plans. These CSFs are focused to help create a good DRP.
The text lists nine elements of a DRP on page 384. It elaborates on them through page 394. You should glance at this material to get an idea about each area that is not familiar to you. Try not to get confused by the overlap with other plans. I believe that the author is working from the point of view that the DRP may be our only disaster plan.
As should be familiar by now, the text cautions us to test and update
a DRP as often as we can. When reviewing a DRP, make sure to review the
systems, assets, and locations that are parts of it, to determine whether
changes in them require changes in the DRP.
The text explains, in more words than it takes, that a DRP reduces risk by reducing the impact of a disaster. A good plan keeps us going, and puts us back in working order as soon as possible.
The best practices mentioned at the end of the chapter should sound very familiar:
The last chapter in our first text presents another opportunity to misunderstand the author. He tells us that there is no difference between a computer incident and a computer security incident. This is not so in all organizations, and it is not so in the one where I work. We call the part of our help desk that handles calls about problems with computers our Incident Response Team. What my organization calls incidents, the text calls events. We have a separate division that deals with computer security issues. Customized terminology is not a useful thing if you and I call the same things by different names. In the context of this chapter, the author is only talking about the people and procedures that address computer security incidents, not the day to day problems that are also called incidents by people taking calls at a general help desk.
So, in the context of the author's terminology, a computer incident is
a violation of a security policy or a security practice. The organizations
where you will work may or may not have the same terminology.
The text offers a short list of examples of security incidents:
In the context of the chapter, we are talking about the creation of a Computer Incident Response Team plan. (Again, he is talking about security incidents. I wish he would use the word more often. Our second text refers to this team as the Security Incident Response Team.) On page 403, the text discusses the purpose of this plan: to prepare for security incidents. That is a very broad concept, considering the variety of security incidents that can occur. The author sensibly proposes that we begin dealing with an incident by seeking to understand what is happening. He suggests using a familiar framework. Explain the situation in terms a reporter would use. A good idea is to memorize a line from Rudyard Kipling about six honest serving men:
(The rest of the poem is not important in this context. Yes, you should read poetry. And science fiction, and detective stories, and lots of other things. In case you don't know, Kipling was a soldier, a poet, a writer, and a reporter. A human being should be able to do many things.)
In the context of this chapter, we are asking:
The text moves on to the elements of a CIRT (SIRT, CERT, etc.) plan.
We are informed that a plan should
list people (or job
roles) that will be involved, and should include information on
the policies that will be enforced
by this staff.
The text describes three models from NIST SP 800-61 Revision 2, which relate to organizing your CIRT staff with different scopes of authority and responsibility.
The list of roles on page 406 may bear no resemblance to the roles you
may see in an actual organization. The lesson to take from the list is
that there are many jobs in large organizations, some of which are quite
specialized, but everyone contributes in some way to the security of those
organizations. CIRT staff are more directly involved in security than
HR staff, but everyone participates in his/her own security experience.
The list of duties on page 407 captures the essence of what people working in this field do:
In addition to these bullets, the text offers three suggestions on page 408 about investigating: acquire evidence, authenticate the evidence (prove it is what you say it is), and analyze the evidence.
The text provides a lengthy discussion of policies and procedures that guide the actions of a CIRT employee. Note the discussion on page 408 about attacking an attacker. This might make sense to many of us, but the reality is that counter attacking may only increase the animosity of the attacker. Our objective is to defend, which is often best done without emotional investment. Some advice is offered for specific types of frequently seen attacks:
The chapter ends with some recommendations for best practices: