보안 사고 로그: GDPR과 규제 기관의 요구 사항을 충족하는 로그 작성 방법

보안 사고에서 가장 어려운 부분은 대개 사고 자체가 끝난 후에 발생합니다. 기업이 무슨 일이 있었는지, 언제 발견했는지, 어떤 데이터가 관련되었는지, 누가 영향을 받았는지, 왜 특정 결정을 내렸는지 설명해야 할 때 말입니다.

많은 중소기업에는 이러한 기록이 완전한 형태로 존재하지 않습니다. 세부사항은 채팅 메시지, 받은 편지함, 헬프데스크 티켓, 스크린샷, 팀원의 기억 등에 흩어져 있을 수 있습니다. 기업은 이러한 임시 기록으로 사고 중에도 버틸 수 있지만, 감독 기관, 보험사, 고객 또는 이사회 구성원이 명확한 타임라인을 요구할 때 문제가 됩니다.

모든 규모의 기업에는 철저한 보안 사고 로그가 필요합니다. 이 로그는 무슨 일이 있었는지, 사고가 어떻게 처리되었는지, 그리고 과정에서 내린 결정을 뒷받침하는 증거가 무엇인지 기록하는 단일 진실 공급원이 되어야 합니다.

사고를 신고할 필요가 없을 때도 기록은 가치가 있습니다. 보안 사고 로그가 비즈니스에 왜 도움이 되는지, 직접 로그를 만드는 방법을 설명하겠습니다.

보안 사고 로그가 중요한 이유

사고 로그와 사고 대응 계획의 차이

보안 사고 로그에 포함해야 할 내용

중소기업을 위한 간단한 사고 로그 템플릿

알림 결정을 기록하는 방법

감독 기관이 보안 사고 로그에 기대하는 것

자격 증명 접근 로그

보안 사고 로그가 중요한 이유

보안 사고 로그는 기업이 세부사항을 놓치기 가장 쉬운 순간에 책임성을 부여합니다. 사고 중에는 조치가 빠르게 이루어집니다. 비밀번호가 재설정되고, 계정이 비활성화되며, IT 업체에 연락하고, 고객 데이터를 확인하고, 경영진에게 보고합니다. 이러한 단계는 당시 기업에 꼭 필요한 것일 수 있지만, 각 조치가 언제 일어났고 누가 승인했으며 어떤 증거가 결정을 뒷받침했는지 아무도 기록하지 않으면 나중에 설명하기가 훨씬 어려워집니다.

유럽에 기반을 둔 기업에게 이는 단순한 모범 사례가 아닙니다. 영국과 EU 모두에서 일반 데이터 보호 규정(GDPR)에 따라 개인 데이터와 관련된 보안 사고를 평가해야 하며, 일부는 해당 감독 기관에 보고해야 합니다.

영국에서는 ICO의 침해 신고(새 창)⁠ 지침에서 조직이 사람들의 권리와 자유에 대한 예상 위험을 평가하고, 그 위험이 발생할 가능성이 높으면 ICO에 알리도록 요구한다고 설명합니다. 제33조는 또한 컨트롤러가 개인 데이터와 관련된 보안 사고를 문서화하도록 요구하며, 여기에는 사고의 사실, 영향, 취한 시정 조치가 포함됩니다. 동일한 요건이 EU GDPR에도 적용됩니다.

예를 들어, ICO는 모든 중소기업이 엔터프라이즈급 시스템을 갖추기를 기대하지는 않지만 적절한 기록은 기대합니다. ICO의 침해 대응 및 모니터링 프레임워크에 따르면 조직은 개인 데이터 사고와 보안 사고를 탐지, 관리, 적절히 기록할 수 있는 절차를 갖춰야 합니다. 즉, 심각한 침해가 이미 발생한 경우에만 사고 로그를 작성해서는 안 됩니다. 정상적인 대응 프로세스의 일부가 되어야 합니다.

좋은 기록은 보험 청구도 뒷받침합니다. 사이버 보험사는 사고가 언제 발견되었는지, 어떤 격리 조치를 취했는지, 어떤 계정이 영향을 받았는지, 기업이 사고 대응 프로세스를 따랐는지에 대한 증거를 요구할 수 있습니다. 잘 관리된 로그는 기업이 신속하고 일관되게 조치했음을 보여줄 수 있습니다.

또한 기업이 배우는 데 도움이 됩니다. 기억과 구두 기록은 신뢰할 수 없지만, 사고가 재사용된 비밀번호, 누락된 다중 인증(MFA), 공급업체 접근 권한 또는 지연된 오프보딩에서 시작되었음을 보여주는 기록은 기업에 고칠 수 있는 구체적인 문제와 시간이 지나면서 보안을 강화할 더 명확한 방향을 제공합니다.

사고 로그와 사고 대응 계획의 차이

보안 사고 로그와 사고 대응 계획은 연결되어 있지만 같은 문서는 아닙니다.

사고 대응 계획은 문제가 생겼을 때 기업이 무엇을 해야 하는지 설명합니다. 역할, 에스컬레이션 경로, 격리 단계, 커뮤니케이션 책임, 복구 절차를 할당합니다. 사고 로그는 실제로 일어난 일을 기록합니다. 특정 이벤트에 대한 타임라인, 증거 추적, 결정 기록, 후속 조치 파일입니다.

이러한 구분은 문서화 없이는 좋은 계획도 실패할 수 있기 때문에 중요합니다. 기업이 올바른 단계를 따랐더라도 나중에 이를 입증하는 데 어려움을 겪을 수 있습니다. 로그는 다음과 같은 실질적인 질문에 답할 수 있어야 합니다: 언제 알게 되었는가, 누가 조치했는가, 무엇을 격리했는가, 어떤 데이터가 위험에 노출되었는가, 무엇을 결정했는가, 이후 무엇이 바뀌었는가?

사고 대응 계획: 기업이 해야 할 일	보안 사고 로그: 실제로 일어난 일
대응을 주도하는 사람 IT, 법무, 보험사 또는 규제 기관에 연락하는 사람 격리, 복구, 소통하는 방법	사고가 발견된 시점 영향을 받은 시스템과 데이터 어떤 조치가 누구에 의해 언제 취해졌는지

보안 사고 로그에 포함해야 할 내용

유용한 사고 로그는 기업이 나중에 이벤트를 재구성하고 대응 중 내린 결정을 설명할 수 있을 만큼 일관성이 있어야 합니다.

발견 일시

기업이 사고를 처음 인지한 시점, 누가 발견했는지, 어떻게 발견했는지를 기록합니다. 시간이 대략적인 경우 대략적이라고 표시합니다. 발견 시간은 GDPR 보고 기한과 보험 요건이 기업이 문제를 인지한 시점에 따라 달라지는 경우가 많기 때문에 중요합니다.

사고의 성격

무슨 일이 일어났는지 쉬운 언어로 설명합니다. 맥락 없이 “보안 문제” 또는 “가능한 침해”와 같은 모호한 라벨은 피합니다. 로그는 어떤 시스템이 영향을 받았는지, 그리고 사고에 자격 증명, 이메일, 파일, 고객 데이터, 결제 시스템, 엔드포인트 또는 타사 접근이 관련되었는지 설명해야 합니다.

관련된 데이터

개인 데이터가 영향을 받았을 수 있다면 어떤 종류의 데이터가 관련되었는지 기록합니다. 이름, 이메일 주소, 전화번호, 주소, 계정 세부사항, 금융 정보, 직원 기록, 고객 커뮤니케이션, 로그인 자격 증명 또는 기타 관련 범주가 포함될 수 있습니다. 영향을 받았을 수 있는 개인 수를 추정하고, 그 숫자가 확인된 것인지 아직 조사 중인지 명확히 합니다.

예상 원인

조사가 아직 진행 중이더라도 알려졌거나 의심되는 원인을 기록합니다. 새로운 세부사항이 나타나면 로그를 “원인 불명”에서 “피싱 이메일로 인한 자격 증명 유출” 또는 “이전 계약자 계정이 활성 상태로 남아 있었음”으로 업데이트할 수 있습니다. 로그는 시간이 지남에 따라 기업의 이해가 어떻게 바뀌었는지 보여줘야 합니다.

즉각적인 격리 조치

피해를 제한하기 위해 어떤 조치를 했는지 문서화합니다. 여기에는 비밀번호 재설정, 세션 취소, MFA 적용, 계정 정지, 메일함 규칙 삭제, 기기 격리, 공급업체 접근 권한 삭제, 방화벽 변경 또는 임시 서비스 중단이 포함될 수 있습니다. 가능한 경우 각 조치의 담당자와 타임스탬프를 포함합니다.

알림 결정

기업이 관련 감독 기관(영국의 ICO 또는 EU 내 다른 국가의 개인정보 보호 당국), 영향을 받은 개인, 고객, 공급업체, 보험사, 법률 자문 또는 법 집행 기관에 알렸는지 기록합니다. 알리지 않기로 결정했다면 그 이유를 문서화합니다. 이러한 설명은 알림 자체만큼 중요한 경우가 많습니다.

시정 조치 단계와 타임라인

격리는 즉각적인 사고를 다룹니다. 시정 조치는 동일한 문제가 다시 발생할 가능성을 줄입니다. MFA 적용, 공유 자격 증명 삭제, 접근 정책 업데이트, 오프보딩 개선, 잘못된 구성 수정 또는 백업 보호 방식 변경과 같은 후속 조치를 기록합니다.

얻은 교훈

기업이 배운 점과 앞으로 바뀔 점으로 마무리합니다. 이는 비난으로 작성되어서는 안 됩니다. 약점, 필요한 개선 사항, 후속 조치를 담당할 사람을 명시해야 합니다.

중소기업을 위한 간단한 사고 로그 템플릿

사고를 문서화하는 데 전문 소프트웨어가 반드시 필요한 것은 아닙니다. 접근이 통제되고 항목이 일관되게 유지된다면 스프레드시트, 보안 내부 양식, 티켓팅 시스템 또는 공유 대장을 사용할 수 있습니다.

효과적인 사고 로그에는 다음 필드가 포함되어야 합니다:

• 사고 ID: 고유 참조 번호.
• 발견 일시: 기업이 사고를 인지한 시점.
• 신고 주체: 직원, 제공업체, 고객, 공급업체, 모니터링 경고 또는 외부 관계자.
• 사고 유형: 피싱, 멀웨어, 자격 증명 유출, 데이터 손실, 무단 접근, 랜섬웨어, 공급업체 사고, 기기 분실, 잘못 발송된 이메일 또는 기타.
• 요약: 무슨 일이 있었는지 알기 쉬운 말로 작성합니다.
• 영향받은 시스템: 관련된 어플리케이션, 계정, 기기, 데이터베이스, 받은 편지함 또는 타사 서비스.
• 관련 데이터: 개인정보가 영향을 받았는지, 어떤 유형인지, 몇 명이 영향을 받을 수 있는지.
• 추정 원인: 확인됨, 의심됨 또는 조사 중.
• 확산 차단 조치: 즉시 수행한 작업.
• 알림 결정: 감독 기관, 개인, 고객, 보험사 또는 알림을 하지 않은 경우 그 이유.
• 증거 링크: 스크린샷, 티켓, 로그, 이메일, 접근 기록, 내보내기 파일 또는 제공업체 보고서.
• 복구 조치: 확산을 차단한 후 수행한 단계.
• 담당자: 후속 조치를 책임지는 사람.
• 상태: 진행 중, 모니터링, 확산 차단, 해결됨, 종료.
• 교훈: 무엇을 바꿔야 하는지.

알림 결정을 기록하는 방법

알림 결정은 사고 이후에 자주 검토되므로 보안 사고 로그에서 별도의 항목으로 다룰 가치가 있습니다.

영국과 EU의 GDPR 모두에서 조직은 개인정보 보안 사고가 발생했을 때 사람의 권리와 자유에 미칠 가능성이 있는 위험을 평가해야 합니다. 위험이 있을 가능성이 있다면 감독 기관에 최대한 빨리, 가능한 경우 72시간 이내에 알려야 합니다. 영국에서는 ICO(새 창), 각 EU 회원국에서는 국가 개인정보 보호 기관이 그 대상입니다. 위험이 높다면 영향을 받은 개인에게도 부당한 지연 없이 알려야 합니다. 기준과 기한은 양쪽 모두 동일하며, 달라지는 것은 기관뿐입니다.

좋은 사고 로그는 기업이 이러한 평가를 수행했음을 보여줘야 합니다. 개인정보가 관련되었는지, 어떤 피해가 발생할 수 있는지, 어떤 보호 조치가 마련되어 있었는지, 그리고 기업이 신고 또는 미신고를 결정한 이유를 기록해야 합니다.

예를 들어 관리자 비밀번호가 노출된 사고의 경우 개인정보에 접근했는지 여부가 즉시 드러나지 않을 수 있습니다. 로그는 이러한 불확실성을 반영해야 합니다. 최초의 우려 사항, 조사 단계, 계정 활동 검토, 그리고 증거가 확보된 후의 최종 결론을 기록할 수 있습니다.

이 단계에서 많은 기업은 기술적 수정을 정리하는 데 집중한 나머지 규정 준수 판단 근거를 기록하는 것을 잊습니다. 비밀번호는 재설정되고 계정은 안전하게 보호되며 업무는 계속됩니다. 몇 주가 지나면 기업은 해당 사고를 신고 대상이 아니라고 판단한 이유를 설명하지 못합니다.

감독 기관이 기록에 기대하는 것

감독 기관은 보안 사고가 신고되었는지만 확인하지 않습니다. 다음과 같은 점도 질문할 수 있습니다.

• 사고를 식별했는지
• 위험을 평가했는지
• 알림이 필요한지 결정했는지
• 수행한 조치를 문서화했는지

좋은 기록은 사고의 전말을 처음부터 끝까지 명확하게 보여줘야 합니다. 무슨 일이 있었는지, 어떤 개인정보가 관련되었는지, 어떤 피해가 발생할 수 있는지, 기업이 문제를 차단하기 위해 무엇을 했는지, 그리고 보안 사고를 신고했거나 신고하지 않은 이유를 보여줘야 합니다.

세부사항의 수준은 사고의 심각성에 맞춰야 합니다. 잘못 발송된 이메일에는 랜섬웨어 공격과 같은 기록이 필요하지 않지만, 기업이 이를 적절히 평가했음을 보여주기 위해 기록은 남겨야 합니다.

이러한 기록도 안전하게 저장해야 합니다. 사고 로그에는 영향을 받은 개인, 노출된 시스템, 직원의 조치, 스크린샷, 접근 로그 또는 복구 단계에 관한 민감한 세부사항이 포함될 수 있습니다. 접근은 필요한 사람으로 제한해야 하며, 보존 기간은 회사의 전반적인 데이터 보존 정책과 일치해야 합니다.

자격 증명 접근 로그

많은 사고에는 자격 증명이 관련됩니다. 재사용된 비밀번호, 공유 계정, 유출된 받은 편지함, 노출된 관리자 로그인, 의심스러운 MFA 프롬프트 또는 제대로 오프보딩되지 않은 직원이 원인이 될 수 있습니다.

그렇기 때문에 자격 증명 접근 기록은 사이버 보안 사고 문서에 직접 입력되는 자료가 될 수 있습니다. 사고에 공유 로그인이나 민감한 계정이 관련된 경우, 기업은 누가 접근 권한을 가졌는지, 접근 권한이 어떻게 공유되었는지, 권한이 변경되었는지, 사고 후 자격 증명이 교체되었는지를 알아야 합니다.

Proton Pass for Business와 같은 비즈니스 비밀번호 관리자⁠는 팀이 암호화된 보관함에서 자격 증명을 관리하고, 고유한 비밀번호를 생성하고, 자동완성을 사용하고, 자격 증명을 안전하게 공유하고, 패스키를 관리하고, 기본 제공되는 2단계 인증을 사용하도록 돕습니다. 사고 문서화에서 가장 큰 가치는 자격 증명과 관련된 접근 이력입니다. 즉, 누가 공유 보관함과 계정에 접근할 수 있었는지, 접근이 어떻게 관리되고 누가 사용했는지, 사고 후 무엇이 바뀌었는지입니다.

IT 팀을 위한 비밀번호 관리자는 정책, 보고, 로그, 역할 기반 접근 제어, SCIM 프로비저닝, SSO 연동과 같은 관리자 기능을 추가합니다. 이러한 기능은 기업이 자격 증명 접근이 어떻게 통제되는지 보여주고, 자격 증명 관련 사고를 조사할 때 증거를 제공하는 데 도움이 됩니다.

비밀번호 관리자는 사고 로그, 법률 검토, 규제 알림 절차 또는 사고 대응 계획을 대체할 수 없습니다. 하지만 이러한 절차에 활용할 수 있는 자격 증명 증거를 제공합니다.

비즈니스 비밀번호 관리자⁠로 자격 증명 접근에 대한 완전한 감사 기록을 유지하세요.