사이버 보안 분야에서 20년간 얻은 감사에 관한 교훈

저는 사이버 보안 분야에서 20년을 보냈고, 그 시간의 상당 부분은 감사에 쓰였습니다. 감사를 준비하고, 참석하고, 발견 사항을 두고 논쟁하고, 드러난 문제를 고치는 일이었죠. 프레임워크는 여러 차례 바뀌었지만, 이 교훈들은 바뀌지 않았습니다.

1. 증거가 서술을 이긴다

가장 흔한 감사 발견 사항은 통제가 빠져 있는 것이 아닙니다. 수행은 되었지만 입증할 수 없는 통제입니다. 접근 검토는 이루어졌지만 목록은 아무도 보관하지 않았습니다. 변경은 승인되었지만, 그 승인이 담긴 채팅 스레드는 이후 삭제되었습니다. 감사인은 자신이 볼 수 있는 것에만 근거해 판단할 수 있습니다. 통제를 수행하는 과정에서 부수적으로 증거가 남도록 설계하면, 대부분의 발견 사항은 사라집니다.

2. 범위가 모든 것을 결정한다

감사에서 겪는 대부분의 어려움은 범위에서 비롯됩니다. 범위를 너무 넓게 잡으면 모든 시스템이 모든 통제를 충족해야 하고, 너무 좁게 잡으면 인증서가 고객의 질문에 답하지 못합니다. 범위가 모호하면 어떤 시스템이 포함되는지 아무도 알지 못합니다. 범위는 의도적으로 정하고, 문서로 남기고, 그 근거를 끝까지 설명할 수 있어야 합니다. 첫 SOC 2 보고서의 범위 설정에 관한 저희 글은 거의 모든 감사에 적용됩니다.

3. 실패하는 통제는 아무도 책임지지 않는 통제다

통제에 지정된 담당자가 있고 그 사람이 업무의 일부로 통제를 운영하면, 통제는 제대로 작동합니다. 통제가 “IT” 또는 “보안팀”의 몫으로만 되어 있으면, 감사 직전 주가 되어서야 본래 기준에서 벗어나게 됩니다. 담당자를 명확히 하는 것은 가장 저렴하면서도 효과가 큰 통제 개선입니다.

4. 문서는 현실을 반영해야 한다

실제와 다른 회사를 묘사하는 형식적인 정책 문서는, 실제 회사를 정확히 묘사하는 짧은 문서보다 못합니다. 감사인은 작성된 내용을 기준으로 시험합니다. 문서와 실무 사이의 모든 차이는 발견 사항이 되며, 종종 그 밖에 제출하는 모든 자료에 대한 신뢰성 문제로 이어집니다.

5. 감사인은 적대자보다 아군일 때 더 도움이 된다

감사가 가장 순조롭게 진행되는 경우는 팀이 감사인을 상대가 아니라 또 한 쌍의 눈으로 여기는 경우입니다. 통제를 어떻게 시험할지 초기에 물어보세요. 알려진 취약점은 계획과 함께 공개하세요. 직접 제기하고 수정 작업이 진행 중인 발견 사항은, 감사인이 찾아내야 했던 발견 사항과는 전혀 다르게 받아들여집니다.

6. 두 번째 프레임워크는 저렴해야 한다

프레임워크마다 별도의 프로그램을 운영하는 조직은 감사마다 비용을 전액 부담합니다. 대응해야 하는 모든 프레임워크에 매핑된 하나의 통제 세트를 구축한 조직은 대부분의 비용을 한 번만 지불합니다. 매핑 작업은 지루하지만, 그 효과는 누적됩니다. 제가 ControlMapping을 만든 큰 이유도 여기에 있습니다.

7. 프레임워크는 달라도, 질문은 같다

충분히 많은 감사를 겪고 나면 프레임워크들의 차이가 흐려지기 시작합니다. ISO 감사인, SOC 2 감사인, PCI 평가자, 규제 기관은 서로 다른 용어를 쓰지만, 결국 같은 소수의 질문을 합니다. 무엇이 범위에 포함되는가, 누가 책임지는가, 그것이 작동한다는 것을 어떻게 아는가, 그리고 작동하지 않으면 어떻게 되는가. 이 네 가지 질문에 증거를 갖추어 명확하게 답할 수 있는 조직은 거의 모든 감사에서 좋은 결과를 얻습니다. 대응 범위 매트릭스는 이를 잘 보여 줍니다. 11개 프레임워크에 걸쳐 같은 핵심 주제가 반복해서 등장합니다.

핵심 요약

• 부수적으로 증거가 남도록 통제를 설계하세요.
• 범위를 의도적으로 정하고, 모든 통제에 지정된 담당자를 두세요.
• 감사는 보안을 잘 운영한 결과물로 다루세요.

8. 통과가 목표는 아니다

감사를 깨끗하게 통과했다는 것은, 범위 내 통제가 시험 대상 표본에서 제대로 작동했다는 뜻입니다. 조직이 안전하다는 뜻은 아닙니다. 컴플라이언스는 보안이 아닙니다. 제가 본 가장 뛰어난 팀들은 감사를 보안을 잘 운영한 결과물로 여기지, 보안의 목적으로 여기지 않았습니다.

이 글에서 한 가지만 가져가신다면, 무엇을 할지 정하고, 일관되게 실행하고, 증거가 자연스럽게 쌓이도록 두라는 것입니다. 현재 통제가 어디까지 닿아 있는지 확인하기 좋은 곳은 격차 분석입니다.

질문

감사 발견 사항이 가장 흔하게 나오는 이유는 무엇인가요?

제 경험상, 실제로 수행된 통제에 대한 증거가 없거나 불완전한 경우입니다. 검토는 했지만 기록하지 않았거나, 변경을 구두로 승인했거나, 표본 모집단이 실제와 일치하지 않는 경우가 여기에 해당합니다.

보안 감사는 어떻게 준비해야 하나요?

통제를 지속적으로 운영하면서 그에 대한 증거를 그때그때 보관하고, 문서가 실무와 일치하는지 확인하며, 감사인이 하기 전에 직접 표본을 점검해 보세요.

이미 알고 있는 취약점을 감사인에게 알려야 하나요?

대개는 그렇습니다. 담당자와 개선 계획이 있는 취약점을 밝히면 통제 환경이 제대로 작동하고 있다는 신호로 읽힙니다. 반면 감사인이 직접 찾아낸 취약점은 감독의 공백으로 받아들여집니다.