공격자는 어디까지 도달할 수 있습니까?

인터넷을 통한 테스트는 일반 내부 계정을 이용한 검증과는 다른 질문에 답합니다. 어떤 시나리오를 검토할지, 시작 시점에 어떤 권한이 주어질지는 함께 정합니다. 이러한 초기 상황을 바탕으로 허용되는 범위를 도출합니다. 시스템, 주소, 아이덴티티는 문서화되며, 공유 서비스와 타사 시스템에는 특히 주의가 필요합니다. 이렇게 계획해 두면 불명확한 책임 범위 때문에 조사가 부여된 승인 범위를 의도치 않게 넘어서는 일을 막을 수 있습니다.

운영 조건 역시 준비 과정에 포함됩니다. 담당자, 시간대, 중단 기준을 정합니다. 시스템 변경, 부하 테스트, 그 이상의 조치는 모든 모의해킹에 암묵적으로 포함되는 것이 아니라, 합의된 절차와 명시적으로 일치해야 합니다. 이후 결과는 실제 시작 조건과 검증된 버전을 명시합니다. 이렇게 하면 결과를 해석하기가 쉬워집니다. 이미 관리자 권한을 가진 상태에서 발견된 취약점은 권한이 없는 시작 지점에서 얻은 증빙과는 다른 의미를 가집니다.

네트워크 세그멘테이션만으로는 모든 접근 가능성을 설명할 수 없습니다. 사용자 계정, 서비스 계정, 관리 경로는 시스템 간에 또 다른 연결을 만들어낼 수 있습니다. 그렇기 때문에 이 검증은 승인된 범위 내에서 기술적 경계와 역할이 의도된 모델을 실제로 적용하고 있는지를 살펴봅니다. 개별 설정 오류는 그 영향과 연관지어 평가합니다. 발견 사항은 그것이 귀사의 환경에 왜 중요한지, 그리고 입증된 접근에 어떤 전제 조건이 있는지를 보여주어야 합니다.

IaaS 환경에서는 제공업체와의 경계 설정이라는 요소가 추가됩니다. 고객이 책임지는 리소스와 설정은 조사 대상이 될 수 있지만, 이것이 공유 플랫폼 서비스까지 자동으로 승인하는 것은 아닙니다. 검증에 앞서 필요한 권한과 요구 사항을 확인합니다. 연동된 사업장과 애플리케이션도 영향을 받을 수 있습니다. 따라서 계획 단계에서는 클라우드와 인프라 담당자를 함께 참여시켜, 테스트 과정을 투명하게 파악할 수 있고 그 영향이 합의된 범위 내에서 통제될 수 있도록 합니다.

결과는 확인된 발견 사항, 참고 사항, 검증되지 않은 영역을 구분하여 제시합니다. 증빙은 필요한 전제 조건과 관찰된 영향을 설명합니다. 이는 불필요하게 민감한 데이터를 수집하지 않으면서도 평가를 가능하게 하기 위한 것입니다. 경영진과 기술팀은 각각에 맞는 형태로 정리된 자료를 받으며, 특히 중요한 관찰 사항은 합의된 보고 경로를 통해 전달됩니다. 이로써 모의해킹은 단순한 기술적 알림 목록을 넘어, 담당자가 어떤 조치를 먼저 실행할지 결정할 수 있는 근거가 됩니다.

조치에는 아이덴티티 관리, 네트워크 운영, 애플리케이션 운영 등 여러 팀이 관여할 수 있습니다. 그렇기 때문에 권고 사항은 그 의존 관계와 함께 논의합니다. 재검증은 합의된 변경 버전에 초점을 맞추고, 구체적인 증빙이 여전히 재현되는지를 문서화합니다. 적합하고 명확하게 정의된 목표에 대해서는 Result as a Service를 통해 성과 기반 보수를 정할 수 있습니다. 이 경우에도 허용된 테스트 범위는 계속 구속력을 가지며, 경제적 유인으로 인해 확대되지 않습니다.