침투 테스트(모의해킹)와 취약점 스캔의 차이

무엇인가

취약점 스캔은 호스트, 웹사이트 또는 애플리케이션을 대상으로 도구를 실행하고, 인식할 수 있는 문제를 보고합니다. 누락된 패치, 오래된 소프트웨어 버전, 노출된 서비스, 취약한 TLS 설정, 흔한 잘못된 설정 등이 이에 해당합니다. 스캔은 빠르고 반복 가능하므로 정기적인 보안 위생 관리에 적합합니다. 한계도 잘 알려져 있습니다. 스캐너는 오탐을 만들고, 비즈니스 로직에 의존하는 문제를 놓치며, 낮은 등급의 발견 사항이 다른 발견 사항과 결합될 때 심각해지는지 판단하지 못합니다. 침투 테스트는 서면 범위와 수행 규칙(Rules of Engagement)에서 시작합니다. 테스터는 스캐너를 포함한 도구를 사용하지만, 이후에는 수작업으로 진행합니다. 발견 사항을 검증하고, 인증과 권한 부여를 테스트하며, 역할과 테넌트가 어떻게 분리되어 있는지 확인하고, 공격자가 시도할 수 있는 현실적인 경로를 따라갑니다. 결과물은 도구 출력의 원시 목록이 아니라 증거, 심각도, 조치 지침을 담은 보고서입니다. 요컨대 스캔은 무엇이 잘못되었을 수 있는지를 알려 주고, 침투 테스트는 합의된 범위에서 무엇이 실제로 잘못되었음을 입증할 수 있는지와 그것이 왜 중요한지를 알려 줍니다.

누구를 위한 것인가?

이 비교는 다음과 같은 팀에 유용합니다.

• 고객, 파트너 또는 보험사로부터 '보안 테스트' 요청을 받았고, 실제로 무엇을 요구받는지 이해해야 하는 팀
• 이미 정기적으로 스캔을 실행하고 있으며, 수동 테스트가 의미 있는 통찰을 더할지 알고 싶은 팀
• 새로운 웹 애플리케이션, API 또는 모바일 앱을 출시하며 출시 전 테스트를 어느 깊이까지 할지 결정해야 하는 팀
• '테스트' 견적 두 건의 작업량과 결과물이 왜 크게 다른지 경영진에게 설명해야 하는 팀

무엇을 명확히 하는 데 도움이 되는지

두 가지를 나란히 살펴보면 다음이 명확해집니다.

• 질문이 알려진 문제의 위생 관리(스캔)에 관한 것인지, 특정 시스템의 악용 가능한 리스크(침투 테스트)에 관한 것인지
• 기존 스캔 보고서의 발견 사항 중 어떤 것이 노이즈일 가능성이 높고 어떤 것이 수동 검증이 필요한지
• 비즈니스 로직, 접근 제어, 다단계 공격 경로가 자동화 도구가 일반적으로 탐지하는 범위 밖에 있다는 점
• 이해관계자가 최종 보고서에서 어떤 증거를 기대하는지

포함된 내용

• 스캔 체크리스트: 자산 목록을 정의하고, 정기적으로 스캔을 예약하며, 결과 분류 담당자를 지정하고, 조치 현황을 지속적으로 추적
• 침투 테스트 체크리스트: 작업 시작 전에 대상, 환경, 테스트 기간, 접근 방법, 지정 연락처, 중단 조건을 서면으로 합의
• 시스템 소유자와, 범위 내 시스템을 운영하는 호스팅 업체나 공급업체로부터 서면 승인을 확인
• 접근 제어 문제를 검토할 수 있도록 인증된 테스트(역할별 테스트 계정)가 필요한지 결정
• 발견 사항의 등급 부여 방식과 지정 연락처와 증거를 안전하게 공유하는 방법을 합의
• 조치 후 수정된 발견 사항을 확인할 수 있도록 재테스트 기간을 계획

포함되지 않은 것

• 스캔만으로 애플리케이션이 안전하다는 것을 입증한다는 주장
• 침투 테스트가 모든 약점을 찾아낸다는 주장(합의된 시간 내에 합의된 범위를 검토합니다)
• 악용 방법 안내, 또는 소유하지 않았거나 테스트 권한이 없는 시스템에 대한 테스트
• 인증, 컴플라이언스 승인 또는 공식 감사 의견

선택해야 할 때

많은 자산에 대해 정기적이고 폭넓은 가시성이 필요하고, 보고된 내용을 분류하고 수정할 프로세스가 있다면 스캔을 선택하십시오. 특정 시스템이 비즈니스에 중요한 경우, 고객이나 파트너가 수동 테스트의 증거를 요구하는 경우, 중요한 출시 전, 또는 인증, 결제, 데이터 처리에 큰 변경이 있은 후에는 침투 테스트를 선택하십시오. 많은 조직이 둘 다 활용합니다. 정기 스캔으로 위생 상태를 꾸준히 유지하고, 주기적인 침투 테스트로 가장 큰 리스크를 지닌 시스템을 검토합니다. 아직 자산이나 담당자 목록을 작성할 수 없다면, 둘 중 어느 것보다 더 폭넓은 기준선 검토가 더 유용한 첫 단계일 수 있습니다.

우리의 접근 방식

먼저 내려야 할 결정에서 출발하십시오. 고객 설문지가 연 1회 침투 테스트를 요구한다면, 스캔 보고서로는 대개 이를 충족할 수 없습니다. 인터넷에 노출된 서버에 패치가 적용되었는지만 알고 싶다면, 전면적인 수동 테스트는 필요 이상일 수 있습니다. 다음으로 범위를 확정합니다. 어떤 애플리케이션, API, 환경, 사용자 역할을 포함하고 무엇을 명시적으로 제외하는지 정합니다. 테스트 기간과 작업을 일시 중지할 수 있는 사람을 합의합니다. 당사의 Penetration Testing 서비스는 이 방식을 따릅니다. 범위 설정, 서면 승인, 합의된 수행 규칙 내에서의 테스트, 우선순위가 매겨진 조치 지침을 담은 서면 발견 사항 보고서, 결과 설명회, 그리고 포함된 경우 합의된 발견 사항에 대한 재테스트입니다. 어떤 업체를 이용하든 계약 전에 샘플 보고서를 요청하고, 검증된 발견 사항과 참고용 관찰 사항이 구분되어 있는지 확인하십시오. 마지막으로 조치에 필요한 시간을 확보하십시오. 아무도 고칠 시간이 없는 발견 사항만 남기는 테스트는 가치가 적으므로, 테스트 일정을 팀이 결과에 대응할 수 있는 역량에 맞추십시오.

Penetration Testing 서비스

자주 묻는 질문

관련 기사