감사자의 관점: IS 감사자처럼 생각하기

IS 감사자는 시스템의 모든 버그나 잘못된 구성을 찾기 위해 고용되는 것이 아니다. 일의 범위는 더 좁고, 솔직히 말해 더 어렵다: 현재 마련된 통제가 비즈니스 위험이 관리되고 있다는 합리적 확신을 제공하는지 판단하는 것이다. 이 구분은 방화벽 규칙을 읽는 것부터 시스템 담당자를 인터뷰하는 것까지 거의 모든 업무 접근 방식을 바꾼다.

위험 우선, 기술 차선

침투 테스터는 "이걸 깨뜨릴 수 있을까?"라고 묻는다. 감사자는 "이게 중요하고, 실패하면 비즈니스에 무엇이 일어날까?"라고 묻는다. 어떤 통제에도 손을 대기 전에, 감사자는 시스템이 무엇을 하는지, 어떤 데이터를 다루는지, 기밀성, 무결성 또는 가용성이 침해되면 무엇이 잘못될지 이해하려고 노력한다. 이것이 감사 프로그램이 보통 취약점 스캔이 아니라 위험 평가 또는 워크스루로 시작하는 이유이다.

구체적으로: 급여 시스템에 대한 접근 제어를 감사할 때, 첫 번째 질문은 "MFA가 활성화되어 있는가?"가 아니다. 그것은 "권한이 없는 사람이 급여 데이터를 변경하거나 PII를 볼 수 있다면 영향은 무엇인가?"이다. 영향을 알게 되면, 기존 통제(MFA, 승인 워크플로우, 직무 분리)가 적절한지 판단할 수 있다.

주장보다 증거

시스템 담당자들은 업무가 잘 진행된다고 말할 것이다. 감사자의 일은 신뢰하는 것이 아니라 검증하는 것이다. 이는 증거물을 요청하는 것을 의미한다: 구성 화면의 스크린샷, 사용자 접근 권한의 내보내기, 승인 타임스탬프가 있는 변경 티켓, 통제가 실제로 작동했음을 보여주는 로그 항목. 누군가 "우리는 분기별로 접근을 검토한다"고 말하면, 감사자는 정책이 규정한 것만이 아니라 최근 3개의 검토 기록을 보도록 요청한다.

이 증거 기반 습관은 감사 발견사항을 복도 대화와 구별하는 것이다. 발견사항은 정밀조사를 견뎌야 한다: 무엇을 테스트했는지, 어떤 모집단을 샘플링했는지, 어떤 기준을 사용했는지, 그리고 실제로 무엇을 관찰했는지. "통제가 적절해 보인다"와 같은 모호한 진술은 경영진과 규제 당국이 읽을 보고서에서 설득력이 없다.

설계 대 운영 효과성

이 분야에서 가장 유용한 정신적 분리 중 하나는 통제 설계와 통제 운영을 분리하는 것이다. 14자 이상의 비밀번호와 MFA를 요구하는 비밀번호 정책은 종이상으로는 잘 설계되어 있다. 하지만 마지막 접근 검토가 11개월 전이었거나, 서비스 계정이 문서 없이 제외되었다면, 통제는 의도대로 운영되지 않고 있다. 감사자는 둘 다 테스트한다: 통제가 설명된 대로 존재하는가, 그리고 실제로 매일 따르고 있는가?

이것이 샘플링이 중요한 이유다. 한 사용자의 접근을 테스트하는 것은 많은 것을 말해주지 않는다. 해제된 직원 25명을 샘플링하고 그들의 계정이 SLA 기간(예를 들어 24시간 또는 48시간) 내에 비활성화되었는지 확인하면 결론을 위한 방어 가능한 근거를 제공한다.

직무 분리의 반복되는 주제

감사 발견사항의 대부분은 직무 분리(SoD)로 거슬러 올라간다: 변경을 요청하는 같은 사람이 승인하거나, 개발자가 배포 권한과 함께 직접 프로덕션 데이터베이스 접근을 가진다. 감사자들은 이러한 중복을 계속 찾는다. SoD 실패는 사기와 의도하지 않은 오류가 두 번째 검토를 통해 적발되지 않고 통과하는 방식이기 때문이다.

환경을 검토할 때 다음을 묻자: 누가 조치를 시작할 수 있고, 누가 승인할 수 있으며, 누가 실행할 수 있는가? 한 사람이 보상적 통제(예: 다른 사람이 검토한 상세 로깅) 없이 두 개 이상의 역할을 보유하고 있다면, 그것은 문서화할 가치가 있는 격차이다.

수정되는 발견사항 작성

기술적으로 정확하지만 아무도 조치하지 않는 발견사항은 낭비된 감사이다. 좋은 발견사항은 상태(관찰된 것), 기준(위반하는 정책 또는 표준), 원인(왜 일어났는지), 그리고 영향(이것이 어떤 위험을 만드는지)을 명시한다 — 많은 감사 부서가 사용하는 고전적인 4C 구조. "접근 통제를 개선해야 한다"와 같은 모호한 발견사항은 무시된다. "샘플링된 해제된 직원 25명 중 14명이 해제 날짜로부터 5일 이상 VPN 접근을 유지했으며, 이는 정책 SEC-014의 24시간 프로비저닝 해제 SLA를 위반한다"와 같은 구체적인 발견사항은 소유자가 정확히 무엇을 수정할지 알기 때문에 개선된다.

습관 구축

정식 계약이 아니라 일반적인 시스템에 대해 이 관점을 실습함으로써 이를 개발한다. 매일 사용하는 애플리케이션을 골라서 다음을 묻자: 실패하면 위험은 무엇인가, 어떤 통제가 존재하는가, 그리고 어떻게 그것이 작동하는지 증명할 것인가? 이를 충분히 자주 하면 감사자의 본능 — 회의주의와 증거에 대한 요구가 결합된 — 이 자동이 된다.

이 같은 통제와 위험 사고에 관심이 있다면, 접근 통제 모델과 보안 거버넌스 프레임워크에 대한 Korra Studio의 세그먼트를 확인하여 더 깊은 기술적 기초를 얻자.