보안 사고 발생 후 첫 몇 시간 동안에는 무슨 일이 일어났는지 기술적 상황을 완전히 파악할 수 없습니다. 팀은 아직 어떤 계정이 유출되었는지, 어떤 데이터에 접근되었는지, 공격자가 어디까지 접근했는지, 사고가 아직 진행 중인지 파악하려고 노력 중일 수 있습니다.
조사와 함께 행동해야 한다는 압박이 즉시 시작됩니다. 직원들은 조각난 정보를 듣고 무엇을 해야 할지 알아야 합니다. 한편, 고객은 서비스 중단, 의심스러운 활동 또는 비정상적인 비밀번호 재설정 요청을 알아차릴 수 있습니다. 비즈니스 파트너는 자신의 시스템이나 데이터가 관련되어 있는지 물을 수 있으며, 리더십은 누가 발언할지, 무엇을 확인할 수 있는지, 언제 침묵이 그 자체로 위험이 되는지 결정해야 합니다.
보안 사고 커뮤니케이션은 기업이 모든 답을 얻기 전에 투명해야 하지만, 추측하지 않을 만큼 충분히 정보를 갖춰야 하기 때문에 어렵습니다. 너무 일찍 보낸 커뮤니케이션은 혼란을 초래할 수 있지만, 너무 늦게 보내면 신뢰를 훼손하고 보호 조치를 지연시키며 규제 관련 문제를 제기할 수 있습니다.
중소기업이 사고 대응 계획을 수립하거나 연습했을 가능성은 낮으며, 이는 추가적인 혼란을 초래할 수 있습니다. 계획이 있는 대기업의 경우에도 기술적 단계가 문서화되어 있을 수 있습니다: 사고를 봉쇄하고, 접근을 재설정하고, 증거를 보존하고, 시스템을 복원합니다. 커뮤니케이션은 나중으로 미뤄지다가 갑자기 사고가 확대되거나 변화할 수 있습니다.
사고에 대비하는 것의 일부는 누가 당신의 말을 들어야 하는지, 그들이 무엇을 알아야 하는지, 누가 메시지를 승인하는지, 조사가 진행 중인 동안 사실을 명확하게 전달하는 방법을 아는 것입니다.
Proton Pass for Business가 어떻게 도움이 되는지
커뮤니케이션 계획은 사고 대응에 포함되어야 합니다
사고 대응은 종종 기술적 프로세스로 설명되지만, 실제 사고는 빠르게 부서 간 협업이 됩니다. IT 팀이 위협을 봉쇄할 수 있지만, 리더십, 법무, 고객 지원, HR, 커뮤니케이션, 운영 부서 모두 무슨 일이 일어나고 있는지, 그리고 무엇을 말할 수 있는지 알아야 합니다.
NCSC의 사이버 사고에서의 효과적인 커뮤니케이션(새 창)에 대한 지침은 영국을 넘어 널리 적용되는 일반적인 모범 사례로, 이 점을 분명히 합니다: 조직은 종종 기술적 대응을 우선시하고 커뮤니케이션을 뒷전으로 밀어냅니다. 비록 커뮤니케이션이 위기 상황에서 직원, 고객, 이해관계자, 미디어가 조직을 인식하는 방식을 형성함에도 불구하고 말입니다.
모든 사고에 공개 성명이 필요한 것은 아닙니다. 하지만 기업은 누가 무엇을 커뮤니케이션할지 결정하는지, 누가 외부 메시지를 승인하는지, 누가 고객에게 말하는지, 누가 규제 보고를 담당하는지 미리 알아야 합니다.
강력한 데이터 유출 대응 계획에는 커뮤니케이션 계층이 포함되어야 합니다. 여기에는 실질적인 세부사항이 포함되어야 합니다:
- 연락처 목록
- 초안 템플릿
- 승인 경로
- 법률 검토
- 고객 지원 대화 요점
- 규제 기관 알림 책임
- 무엇을 언제 누구에게 보냈는지에 대한 기록.
대응을 위한 두 가지 트랙 구조
사고 대응에는 두 가지 트랙이 필요합니다: 기술적 대응과 커뮤니케이션 대응. 이들은 서로 병행하여 진행되며, 사고 책임자/대응 담당자가 둘을 연결합니다.
| 왼쪽 트랙: 기술적 대응 | 오른쪽 트랙: 커뮤니케이션 대응 |
| 사고 봉쇄 | 내부 팀 업데이트 |
| 영향받은 계정 보호 | 영향받은 고객 또는 파트너에게 알림 |
| 증거 보존 | 규제 기관 알림 평가 |
| 시스템 복원 | 사실이 변해도 메시지 일관성 유지 |
이를 통해 대응을 구조화하고 팀원들이 다양한 작업을 수행하는 동안 협업이 계속되도록 할 수 있습니다.
발표가 아닌 대상부터 시작하세요
보안 사고 커뮤니케이션이 실패하는 이유는 하나의 메시지로 모든 사람을 만족시키려 할 때입니다. 직원, 고객, 파트너, 규제 기관은 각기 다른 결정을 내려야 하므로 필요한 세부사항 수준이 다릅니다.
내부 팀에게 먼저 명확성이 필요합니다
모든 세부사항이 필요한 것은 아닙니다. 특히 조사가 진행 중인 동안에는 더욱 그렇습니다. 하지만 무엇이 확인되었는지, 지금 당장 무엇을 해야 하는지, 누가 대응을 이끌고 있는지에 대한 명확성은 필요합니다. 즉, 어떤 시스템이나 계정을 피해야 하는지, 즉시 어떤 조치를 취해야 하는지, 어떤 질문이 아직 열려 있는지 아는 것입니다.
직원들은 또한 하지 말아야 할 일을 알아야 합니다. 예를 들어:
- 사고를 공개적으로 논의하지 마세요
- 승인된 절차 외에 자격 증명을 재설정하지 마세요
- 즉흥적인 설명으로 고객에게 연락하지 마세요
- 지침 없이 의심스러운 메시지를 전달하지 마세요.
고객과 파트너는 자신이 어떻게 영향을 받는지 알아야 합니다
그들은 자신의 데이터, 접근, 결제, 서비스, 운영이 영향을 받는지 알고 싶어 합니다. 좋은 고객 알림은 다음을 설명해야 합니다:
- 알려진 내용
- 어떤 유형의 데이터가 관련될 수 있는지
- 비즈니스가 무엇을 하고 있는지
- 고객이 현재 해야 할 일이 있다면 무엇인지
- 어디에서 업데이트를 받을 수 있는지
어조는 명확하고 직접적이어야 합니다. 고객은 포렌식 세부사항까지 알 필요가 없으며, 자신을 보호하는 데 충분한 정보만 있으면 됩니다.
규제 기관은 사실에 기반한 기록이 필요합니다.
관련 감독 기관(영국의 ICO(새 창), 각 EU 회원국의 국가 데이터 보호 기관)에 대한 GDPR 보안 사고 알림은 마케팅 메시지나 고객 안심 메시지가 아닙니다. 대신, 무슨 일이 있었고, 누가 영향을 받았으며, 이에 대해 무엇을 하고 있는지에 대한 사실적 기록이어야 합니다. 규제 기관에 알리는 방법에 대한 아래 섹션에서 포함해야 할 내용을 정확히 다룹니다.
내부적으로 무엇을 전달할지
직원들은 사고 대응팀에 속해 있지 않더라도 대응의 일부입니다. 혼란스러운 팀은 실수로 더 많은 소음을 만들거나 부정확한 정보를 공유하거나 격리를 지연시킬 수 있습니다. 반대로, 잘 정보를 갖춘 팀은 계정을 보호하고, 고객을 올바른 채널로 안내하며, 추측이 커지는 것을 막을 수 있습니다.
내부 보안 사고 발표에는 다음이 포함되어야 합니다 :
- 지금까지 확인된 내용을 평이한 언어로 명확하게 요약한 것
- 잠재적으로 영향을 받을 수 있는 시스템, 계정, 팀 또는 데이터
- 비즈니스가 현재 무엇을 하고 있는지
- 직원들이 즉시 해야 할 일
- 외부와 소통할 수 있는 사람
- 업데이트가 게시될 위치
- 관련 의심스러운 활동을 신고하는 방법
포함하지 말아야 할 측면도 있습니다. 공격 벡터, 근본 원인 분석, 특정 취약점은 일반적으로 사고가 진행 중일 때 내부적으로 공유되지 않으며, 이후에도 공유되지 않는 경우가 많습니다. 이러한 세부사항은 다른 공격자에게 도움이 되거나 법적 위험을 초래하거나 아직 해결되지 않은 격차를 노출할 수 있기 때문입니다.
첫 번째 내부 메시지는 모든 질문에 답할 필요가 없으며, 질서를 만들어야 합니다. 예를 들어, 직원들은 승인된 절차를 통해서만 비밀번호를 재설정하거나, 특정 시스템 사용을 피하거나, 의심스러운 이메일을 보존하거나, 대응팀이 검토를 마칠 때까지 공유 자격 증명 사용을 중단해야 할 수 있습니다.
기존 접근 제어를 비밀번호 관리 모범 사례와 비교하여 평가하는 것도 필수적입니다. 사고 중에는 구식이거나 비공식적인 자격 증명 공유로 인해 무엇이 노출되었는지 파악하기 어려울 수 있습니다.
Proton의 데이터 유출 보호 및 기업을 위한 데이터 유출 예방 가이드는 계층화된 제어가 유출이 발생하기 전에 노출을 줄이는 방법을 설명합니다. 안전한 자격 증명 관리는 이러한 계층 중 하나인데, 비즈니스가 어떤 계정이 존재하고, 누가 접근할 수 있으며, 무엇을 신속하게 변경해야 하는지 파악하는 데 도움이 되기 때문입니다.
고객에게 보안 사고를 알리는 방법
고객에게 보내는 데이터 유출 알림은 평판과 법적 책임을 수반하기 때문에 더 어렵습니다. 사람들은 신원 도용, 계정 탈취, 금융 사기 또는 개인 정보 노출을 걱정할 수 있습니다. 또한 회사가 사고를 예방하지 못했다는 사실에 좌절할 수도 있습니다.
좋은 고객 메시지는 놀라게 하지 않으면서 정직해야 합니다. 기술 전문 용어를 피하되 명확해야 합니다. 고객은 어떤 데이터가 관련되었는지, 어떤 위험이 발생하는지, 다음에 무엇을 해야 하는지 이해해야 합니다.
유용한 구조는 다음과 같습니다 :
- 고객에게 적절한 수준의 세부사항으로 무슨 일이 있었는지
- 비즈니스가 언제 인지했는지
- 어떤 정보나 서비스가 영향을 받을 수 있는지
- 비즈니스가 취한 조치
- 고객이 현재 해야 할 일
- 비즈니스가 업데이트를 제공하는 방법
- 질문이 있을 때 고객이 연락할 수 있는 사람
조사가 아직 진행 중인 경우, 이를 공개해야 합니다. 정확성과 투명성은 신뢰를 회복하는 데 도움이 됩니다. 영향을 공개적으로 밝히는 것이 공격을 반복하는 데 도움이 될 기술적 세부사항을 공개할 필요는 없습니다.
심각한 사고의 경우, 고객에게 실용적인 지침이 필요할 수 있습니다. 비밀번호 변경, MFA 활성화, 피싱 이메일 주의, 은행에 연락, 공식 채널을 통해 오지 않는 한 회사에서 보낸 것처럼 주장하는 메시지 무시 등이 있습니다. 알림은 이러한 단계를 쉽게 이해할 수 있도록 해야 합니다.
규제 기관에 언제 어떻게 알릴지
모든 보안 사고를 감독 기관에 보고해야 하는 것은 아닙니다. 영국 및 EU GDPR에 따라 보고 의무가 있는 유출은 개인 데이터 유출이 사람들의 권리와 자유에 위험을 초래할 가능성이 있는지에 따라 결정됩니다.
ICO의 개인 데이터 유출 지침(새 창)은 영국과 EU GDPR 모두에 공통된 요구사항을 반영합니다. 조직은 통지 대상 유출을 인지한 후 지체 없이, 늦어도 72시간 이내에 보고해야 합니다. 늦은 보고에는 지연 이유가 필요합니다.
그 72시간의 기간은 특히 조사가 아직 완료되지 않았을 때 압박을 줄 수 있습니다. GDPR은 조직이 첫 72시간 내에 모든 세부사항을 갖추지 못할 수 있음을 인정하므로, 추가 업데이트가 지체 없이 제공되는 한 정보를 단계적으로 제공할 수 있습니다.
관련 감독 기관(영국의 ICO 또는 EU의 국가 데이터 보호 기관)에 대한 알림에는 일반적으로 다음이 포함되어야 합니다 :
- 개인 데이터 유출의 성격
- 영향을 받은 개인의 범주 및 대략적인 수
- 영향을 받은 개인 데이터 기록의 범주 및 대략적인 수
- DPO 또는 다른 연락 지점의 이름 및 연락처 정보
- 유출의 예상되는 결과
- 이를 해결하기 위해 취했거나 제안된 조치
ICO는 또한 유출을 보고(새 창)하고 조직을 적절한 보고 절차로 안내하는 중앙 페이지를 제공합니다.
영향을 받은 개인의 경우 기준이 다릅니다. 개인 데이터 유출이 사람들의 권리와 자유에 높은 위험을 초래할 가능성이 있는 경우, 지체 없이 통지해야 합니다. 이는 법률, 개인정보, 리더십 팀이 조기에 참여해야 하는 상황이며, 소규모 비즈니스에서도 마찬가지입니다.
필요하기 전에 메시지를 준비하세요
커뮤니케이션 프로세스를 설계하기에 가장 나쁜 시기는 사고 중입니다. 업데이트되고 변경되어야 하는 성명이나 지침을 발표하는 것은 도움이 되지 않습니다.
그렇기 때문에 필요하기 전에 메시지의 구조를 준비하는 것이 도움이 됩니다. 최종 문구가 아니라 구조입니다. 모든 사고가 다르기 때문입니다. 누가 메시지를 승인해야 하는지, 어떤 세부사항이 포함되어야 하는지, 업데이트가 어디에 기록될지, 각 대상에 대해 누가 책임지는지 등입니다.
간단한 커뮤니케이션 키트만으로도 첫 한 시간의 혼란을 줄일 수 있습니다. 다음을 포함할 수 있습니다 :
- 내부 사고 공지 템플릿
- 고객 알림 템플릿
- 파트너 또는 공급업체 업데이트 템플릿
- 고객 지원 대화 요점
- 감독 기관 알림 체크리스트
- 승인된 대변인 목록
- 법무, IT, 개인정보, 리더십, 커뮤니케이션을 위한 에스컬레이션 연락처
- 모든 업데이트와 결정을 기록할 수 있는 곳
준비는 속도와 정확성이 모두 중요할 때 팀에게 안전한 출발점을 제공합니다. 준비된 템플릿은 사고의 사실 관계 : 무슨 일이 있었는지, 누가 영향을 받았는지, 무엇이 이미 이루어졌는지, 다음에 무엇을 해야 하는지에 더 많은 주의를 기울일 수 있게 합니다.
Proton Pass for Business가 어떻게 도움이 되는지
보안 사고 커뮤니케이션은 사실에 달려 있습니다. 기업이 사고 전에 접근을 더 명확하게 관리할수록, 무슨 일이 있었는지, 무엇이 영향을 받을 수 있는지, 무엇이 변경되었는지 설명하기가 더 쉽습니다.
Proton Pass for Business와 같은 비즈니스 비밀번호 관리자는 팀이 자격 증명 관련 노출을 줄이도록 돕습니다. 직원들은 강력한 비밀번호를 생성하고, 암호화된 비밀번호 보관함에 저장하고, 자동완성을 사용하고, 자격 증명을 안전하게 공유하고, 패스키를 관리하고, 내장된 2단계 인증을 사용할 수 있습니다. 관리자는 비밀번호 정책을 적용하고, 활동 로그를 검토하고, 역할 기반 제어로 접근을 관리하고, SCIM 및 SSO 통합을 통한 프로비저닝을 지원할 수 있습니다.
사고 중에 이러한 기능은 기업이 더 자신감 있게 행동하도록 도울 수 있습니다. 직원 계정이 유출된 경우, 관리자는 접근을 검토하고, 교체가 필요할 수 있는 공유 자격 증명을 식별하고, 더 강력한 인증을 시행하고, 채팅이나 스프레드시트를 통해 복사된 비밀번호에 대한 의존도를 줄일 수 있습니다.
보안 사고가 발생하기 전에 비즈니스 비밀번호 관리자로 대응할 준비를 하세요.
