Understand and Prioritize Goal
A procedure for handling a conflict of i
Your company goals and priorties may be different than those of the guy next door. The bottom line here is that complex incidents don’t allow time to think about the priorities. Therefore, your goals during a break-in must already be documented and understood before the break-in occcurs.
당신의 회사 목표와 우선순위는 아마도 이웃 회사의 사람들 중 한 분과는 다를 수 있습니다. 말하고자 하는 바는 보안 침해 사고는 그 우선순위에 대해 고려할 여유를 주지 않는다는 겁니다. 그러므로 보안 침해 사고를 당했을 때 당하기 전에 이미 그러한 우선순위에 대한 문서화와 교육이 이루어진 상태여야만 합니다.
Knowing your goals is essential to formulating an appropriate plan of attack. The goals appropriate for your network may include some or all of the following:
보안에 있어 당신이 필수적으로 알아야 하는 것은 공격마다의 적절한 계획을 공식화시키는 것입니다. 네트워크 보안에 대한 적절한 대응과 목표는 아래에 제시된 모든 사안에 포함될 것입니다.
Protect customer information. You might maintain critical customer information on your network. If a hacker steals, modifies, destroys, or even posts the informationt the Internet, you may find me in court.
Contain the attack. Prevent the use of your systems to launch attacks against other companies. Sometimes you may need to disconnect a system from the network to prevent further damage and limit the extent of the attack. For example, if you have a customer network (extranet) connected to your netowrk and a hacker obtains access to the system that connects you to your customer’s extranet, you must protect your customer’s network. If you have to, be prepared (and know how) to pull the leg.
Notify senior management. Management is responsible for the adequacy, accuracy, and reliability of data. If the systems in your company are being broken into, the Chief Information Officer (CIO) should be informed and kept abreast of the situation.
Document the event. Recording all the details may provide management with the information necessary to assess the break-in and could assist in the prosecution of specific individuals.
Take a snapshot of the system. A snapshot is basically a photograph of what a computer’s memory (primary storage, specifie registers, etxc.) contains at a speccific point in time. (Sometimes, a snapshot is called a system dump.) Like a photograph, a snapshot can be used to catch intruders by recording information that the hacker may erase before the attack is completed or repelled. As such, a system snapshot provides crucial audit information.
Contact a Computer Security Incident Response Team (CSIRT). It’s important to contact a CSIRT (e.g., CERT) during the early stage of the intrusion, because they may have information that can help you bring your intrusion to a close. For example, they may know how to fix the flaw in the vendor’s software or hardware that allowed the intruder to access your network. They also complie statistics regarding the total number of break-ins and techniques used by hackers to gain entry. If you have your break-in under control and have fixed the problem that allowed the hacker to gain entry, you should still contact a CSIRT so they can keep accurate statistics. They will not share your company name or tell anyone that you were broken into. Many CSIRTs exist around the globe. For details, see Appendix A, “People and Products to Know.”
Identify the intruder. This entry seems obvious, but it isn’t always at the top of a list of priorities. Sure, it’s nice to get even. But, it’s even more important to get by. Don’t get so caught up in trying to catch the intruder that you compromise the integrity of your data. If you cannot easily trace back an attack on your own network, you need to consider how important it is to be able to do so. Some venders offer software that can easily track back attacks (as long as software is installed upstream). This should be strategized at the executive level of the organization.
Know who’s responsible for what. Having clear-cut responsiblities removes any ambiguity that can arise. Knowing who’s responsible for what facilitates speed and increases the likelihood of identifying the culprit.
Know whom you can trust. The actual break-in was only part of the real problem at First Fidelity. The other part was a lack of trust between key players. If we assume that Mike was guilty, the trust issue becomes a personnel problem. Were appropriate background checks conducted? As much as it seems an invasion of privacy, a thorough background check is essential for anyone who will be responsible for computer security.
If we assume that Mike was innocent, the trust issue resurfaces as a communications problem. Why didn’t anyone call Mike early on? Was Dave uncomfortable speaking to Mike because Mike was from security? A phone call could have opened up communication channels and perhaps avoided the finger-pointing that ended up obscuring the investigation. Perhaps there was a history of unspoken mistrust between the system administartors and security team. Employee resentment or mistrust of the company’s security team is a serious issue that needs direct attention. Ignoring such a problem puts the company at risk. A procedure for handling a conflict of interest would also have helped Dave. He would have been able to sidestep the security team by escalating the investigation to a higher level of authority.
