This lesson is about chapter 6. Objectives important to this
lesson:
Building a CSIRT
Generic policy and procedures
Outsourcing issues
Concepts:
Chapter 6
The chapter begins with a phrase that it will use
frequently: Computer Security
Incident Response Team (CSIRT).
It tells us that the same concept may be called different names in
various environments, but we should be clear that we are discussing the
staff who will address security
incidents relating to computer systems.
The text begins a set of eight sections about developing a
CSIRT. This is from a plan proposed by the respected Computer Emergency Response Team
at Carnegie Mellon University. (The link in the previous sentence will
take you to one of their websites, which explains who they are and what
they are responsible for.) Some thought has been put into a few of
these sections, so we should consider them.
Obtain management support and buy-in
- I am getting a little tired of this concept. How many organizations
put together their own teams and divisions and then
get approval to do so? It is far more likely that someone "upstairs"
had a reason to reorganize the outfit, leading to the creation of a
new business entity. Let's assume that someone in authority had decreed
that such a team should and will exist. Huzzah.
Determine the CSIRT strategic plan
- Oh, great, we had a decree, so now we need a proclamation. It's going
to have a lot of details.
Assuming this is a new group, we declare that it will by created
by (fill in a date), and we will need to hire
(list of specialties and number of employees).
Services will be provided
as we promise, so we need to specify operating hours,
or specify a way to provide 24/7
coverage. Hiring staff to work around the clock is expensive, but
so is paying overtime for too few staff. Make your choices.
Staff will need particular skills.
The text offers a list: malware identification/elimination, system
recovery, system administration, network administration, firewall
management, IDPS usage, cryptography skill, and documentation. If
you don't spend time and effort here, you will have no product and
no service to offer the organization. Either you hire skilled people,
or you hire good learners who can become skilled people. Note: this
concept is about staffing,
not about proclaiming that you have a great staff.
An organizational structure
for the CSIRT will be needed, one that fits into the existing organizational
structure of the business we work for. This will include a plan based
on the size of our organization,
its geographic scope, and
decisions that will be made about full
time staff, part time
staff, contract staff, and
outsourced staff.
Ongoing training will be
needed as time goes on, regardless of the skill our employees have
when they start. We should make plans to provide training
or provide incentives to induce
employees to take necessary training, education, and skill building
courses.
Gather relevant information
- This is a background task to be done when the team forms, but gathering
information about IT is always relevant because the landscape and the
landmarks are always changing. Ask me about a story I heard this week
about MAC addresses and assigned IP addresses. Sounds simple, doesn't
it? Not any more.
Design the CSIRT vision -
This one is too much like item 1. Do you think we are creating this
team in a vacuum? Surely the points in this section have been determined
before anyone was put in charge of it, much less hired to do the work.
Dilly Dilly.
Communicate the CSIRT's vision and
operational plan - Let's just agree that no one pays any attention
to anything unless it comes from their own management (their boss).
Some information needs to come through appropriate channels, starting
at the top and hitting all levels. That's the part you need to follow
up. Did everyone get the memo? You won't know until you contact someone
who does not work with or for you. When you do, and they have never
heard of you, have your credentials ready, meaning the authorization
from upper management that you can and should have cooperation while
doing your job.
Begin CSIRT implementation
- The text includes hiring, initial training, form creation, and software
selection in this step. Some of these tasks will be ongoing. All need
to be done before services are provided.
Announce the operational CSIRT
- Step 5, rinse and repeat. Tell the world. The world, if it has been
paying attention, will probably say it's about time this service actually
started.
Evaluate CSIRT effectiveness
- You should be doing this with all your teams, so you should expect
to do it with this one. Continuous
Quality Improvement.
The text revisits the idea of outsourcing.
It may be necessary, for example, to hire contract staff who are
experts about new equipment or software for a transitional period in
which our existing staff should learn about the new assets. It may be
cost effective to use contract staff if they are paid from a different
budget. The overall cost of operation increases, but the separate
funding can make it possible to have additional staff who are not paid
by your operating budget.
The text offers a list of concerns that should be considered when outsourcing CSIRT duties. These are a few of them:
Quality of work is
a consideration because a contract employee may not be as motivated to
do a good job as an actual employee. This is not always so, but it is
something that should be monitored.
If we are concerned about contract staff making decisions about our security problems, the text suggests we should consider having them make recommendations based on their analysis of incidents. Those recommendations should be considered by our senior CSIRT staff, and appropriate decisions can be made. This may slow down the application of solutions, and that may not be acceptable.
It is inevitable that anyone working on a CSIRT issues will gain knowledge about sensitive
data and operational information. That being so, the question is
whether we want a contract employee learning these things when that
contractor may be working for a competitor when their contract is over. In my day job, it is common for contract employees to have long term relationships
with us, leading to their being familiar with our systems and to their
being trusted as much as regular staff. If this situation is possible,
there is less reason for concern.
As noted above, a contractor with a long association with
our organization will be familiar with our operations, policies, and
equipment. This is not so when a newcontractor joins us, or when a new contract
begins with an outside agency. It is also true that a new full time
employee will not be familiar with our systems, so the question is
again a matter of trust. Do we trust the people we are paying to do our
services? If not, can we rely on legal contracts to keep our secrets
safe? If the concern is about having the big picture of our
organization, do we have an effective onboarding process for new staff,
full time, part time, and contract?
Assignments
The assignment for this week has not yet been determined.