정보보안 침해 위험 대응 전략
IT security: risking the corporation
무단 번역(비공인) 및 복사 관련 아래의 원저작물의 글은 공적으로 아닌 개인적 목적으로 발췌하였고 저작권법 다음 30조를 참조해서 사업적 이익을 도모하기 위함이 아님을 미리 밝힙니다. 저작권법 제30조(사적 이용을 위한 복제) 공표된 저작물을 영리를 목적으로 하지 아니하고 개인적으로 이용하거나 가정 및 이에 준하는 한정된 범위 안에서 이용하는 경우에는 그 이용자는 이를 복제할 수 있다. 다만, 공중의 사용에 제공하기 위하여 설치된 복사기기에 의한 복제는 그러하지 아니하다.
Understand and Prioritize Company’s Goal
Your company goals and priorities may be different than those of the guy next door. The bottom line here is that complex incident 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 occurs.
당신의 회사 목표와 우선순위는 아마도 이웃 칸의 직원 한 분과의 그것들과는 다를 수 있습니다. 여기서 말하고자 하는 바는 보안 침해 사고는 그 우선순위에 대해 고려할 여유를 주지 않는다는 겁니다. 그러므로 보안 침해 사고를 당하기 전에 이미 그러한 우선순위에 대한 문서화와 교육이 이루어진 상태여야만 합니다.
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 information 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 network 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.
공격을 방지하십시오. 다른 회사에 맞서 당신의 시스템을 침투하여 공격을 시작하는 것을 막으십시오. 때때로 당신은 시스템을 네트워크 접속으로부터 차단해야 할지도 모릅니다. 왜냐하면 더 진행할 수 도 있는 위험과 2차 공격의 확산을 막기 위해서입니다. 예를 들면, 만약 당신이 회사의 네트워크에 접속하는 고객의 외부 인트라넷을 관리하는 도중 해커가 그 시스템의 접근권한을 탈취하기 위해 회사의 네트워크를 통해 고객망으로 접속할 수도 있기 때문입니다. 그러므로 고객망의 네트워크를 보호해야 합니다. 만약 당신이 그렇게 해야 한다면 해커가 어떻게 네트워크를 쉽게 침입하는지에 대한 대비를 가져야 합니다.
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.
윗선의 관리자에게 통보하십시오. 관리는 데이터의 적절함, 정확성, 신뢰성에 대한 책임을 져야 합니다. 만약 당신 컴퓨터의 시스템이 뚫렸다면 CIO 혹은 CSO(Chief of Security Officer)는 상황에 대한 가장 최신의 정보를 확실히 통보받아야 합니다.
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.
사고에 대해 문서화하십시오. 관리자에게 제공될 정보의 세부사항을 기록한 것은 침해사고를 접근하고 KISA(한국 인터넷진흥원)의 담당자들로부터 감사 및 분석의 지원을 받기 위해 필요합니다.
Take a snapshot of the system. A snapshot is basically a photograph of what a computer’s memory (primary storage, specific registers, etc.) contains at a specific 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 compile 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.”
회사 내외부의 보안 사고 대응팀에게 연락하십시오. 회사에서 구성한 보안긴급대책팀과의 의사소통은 침해의 초기 단계에서 중요한 역할을 합니다. 왜냐하면 그들은 당신이 당한 보안사고의 해결책을 제시해 줄 수 있는 정보를 가지고 있을지도 모르기 때문입니다. 예를 들면, 해커가 당신의 네트워크에 침입하였다고 가정합시다. 네트워크 접근은 보안회사의 소프트웨어와 하드웨어의 취약점을 통해서도 가능합니다. 보안사고대응팀은 그것들을 어떻게 고칠 수 있을지 알고 있을지도 모르기 때문에 그들에게 연락을 취해야 합니다. 그들은 또한 침해한 총 횟수와 해커가 침입 가능한 지점을 얻기 위해 사용한 기술 등을 고려해서 통계 수치를 조합하기도 합니다. 만약 당신이 해커가 뚧은 지점의 문제를 통제권 내에서 해결했더라도 보안 사고 대응팀에 연락해서 그들이 정확한 통계를 낼 수 있도록 해야 합니다. 그들은 당신의 회사명을 언론에 공개하지 않을 것이며, 누구에게라도 당신이 보안 침해사고를 당했다는 것을 알리지 않을 겁니다. 많은 보안 사고 대응팀은 전 세계 각지에 분포하고 있습니다. 부록 A의 알아야 할 인명과 제품을 보시면 상세히 나와 있습니다.
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 vendors offer software that can easily track back attacks (as long as the software is installed upstream). This should be strategized at the executive level of the organization.
공격자를 밝혀내십시오. 이 사안은 명확합니다. 그러나 이것은 항상 우선순위의 가장 중요한 부분은 아닙니다. 물론 이룬다면 굉장합니다. 심지어 이것을 실행하는 것은 더 중요하기도 합니다. 중요 데이터의 무결성을 해칠 정도로 침입자를 쫓는데 혈안이 될 필요는 없습니다. 만약 당신이 회사 내부 네트워크의 공격에 대한 추적을 쉽게 할 수 없다면 당신은 이것을 이루는 게 얼마나 중요한지 고려해 보는 것조차도 필요합니다. 보안업체에서는 스트리밍으로 설치하지 않는 이상 침입자를 쉽게 추적할 수 있는 소프트웨어를 추천합니다. 이것은 조직의 간부급에서 구체적인 전략으로 이루어져야 합니다.
Know who’s responsible for what. Having clear-cut responsibilities 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 personal 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.
당신이 신뢰할 수 있는 주변인을 명확히 밝히십시오. 실제 First Fidelity의 사고는 실제 문제 중 일부에 불과했습니다. 나머지는 핵심 사용자들 간의 신뢰가 부족해서 발생한 경우(즉 내부자의 침범)였습니다. 만약 마이크가 의심스럽다면 직장 내 신뢰문제는 인사문제가 됩니다. 적절한 배경조사가 이루어졌습니까? 사생활 침해로 보이는 만큼 철저한 신원조회는 컴퓨터 보안을 책임질 사람이라면 필수적입니다.
If we assume that Mike was innocent, the trust issue resurfaces as a communication 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 administrators 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.
만약 침해사고가 마이크와는 관계없는 것으로 밝혀진다면 그 직장 내 신뢰 문제가 의사소통 문제로 또다시 불거질 것입니다. 왜 아무도 마이크와 일찍 통화하지 않았었나요? 마이크가 보안 담당자이기 때문에 데이브는 그에게 말하기가 불편했나요? 전화 한 통화로 보안사고에 관한 소통은 매끄러울 수도 있었을 겁니다. 그리고 결국 조사를 모호하게 만든 비난을 피했을 겁니다. 아마도 시스템 관리자들과 보안팀과의 소통 부재로 인한 신뢰결여의 역사가가 있었을 겁니다. 보안팀에 전적으로 불만이 많은 직원들에 대해서는 직접적인 주의 관찰이 필요한 심각한 문제가 됩니다. 이러한 문제를 방치하는 것은 오히려 회사를 위험에 빠뜨리는 것입니다. 이해 상충을 처리하는 절차가 있었다면 또한 데이브를 도와줄 수도 있었습니다. 그는 보안팀이 더 높은 권한으로 조사를 확대함으로써 보안 팀을 피할 수도 있었습니다.
참조 및 번역한 도서 |
McCarthy, L. (2003). IT security: risking the corporation. Upper Saddle River, NJ: Prentice Hall.
