ITS 4350 - Disaster Recovery

Chapter 6, Organizing and Preparing the CSIRT

Objectives:

This lesson is about chapter 6. Objectives important to this lesson:

1. Building a CSIRT
   
2. Generic policy and procedures
   
3. 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.

1. 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.
   
2. 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.
3. 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.
4. 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.
   
   
   
   
5. 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.
   
6. 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.
7. 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.
8. 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 new contractor 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?