보안

성공적인 레드팀 운영을 위해 필요한 11가지 정책

Maril Vernon | CSO 2022.08.09
레드팀(Red Team)은 요즘 같은 사이버 위협 환경에서 필요악 같은 존재다. 외부 해커 역할을 맡아 모의 해킹에서 공격을 주도하는 레드팀은 규제 검증, 인증 획득 등 여러 목적을 위해 공격을 시도한다. 보안 예방 조치를 강력히 취하거나 남들보다 앞선 보안 기술을 구축하려는 곳일수록 레드팀을 보안 정책 수립 초기부터 활용한다. 

레드팀은 취약성을 먼저 파악하고 침투 테스트(펜테스팅, Pentesting)를 진행한다. 즉 취약성을 추측하는 것에서 한 걸음 더 나아가 취약성을 구체적으로 파악해 공격이 정확히 어떻게 발생할 수 있을지 입증한다. 레드팀의 활동은 간혹 침투 테스트라고 불리기도 하는데, 엄밀히 말하면 잘못된 표현이다.
 
ⓒ Getty Images Bank

침투 테스트는 명확한 목표를 염두에 두지 않고 가능한 많은 문제를 찾는다. 취약점 공격 또는 공격 이후 벌어지는 활동의 성공과 실패를 확인하기 위해 광범위하게 공격을 해보는 식이다. 또한 침투 테스트는 일반적으로 초기 액세스 벡터를 수행하지 않는다. 모의 해킹에서는 레드팀 말고 공격과 방어를 종합적으로 활용해 보안성을 높이는 퍼플팀이 존재하는데, 퍼플팀은 침투 테스트와 레드팀 활동 결과를 함께 살펴본다. 여러 단계에서 보안 문제를 찾아 해결 능력을 검증하는 것이다. 

레드팀은 초기 액세스부터 데이터 유출에 이르기까지 해킹 구조 전체를 파악하고 고도로 표적화된 작전을 실행한다. 기업은 레드팀으로 마치 APT 공격처럼 특정 직원이나 프로세스, 기술을 은밀하게 공격하면서 궁극적으로 보안 수준을 단계 더 높인다. 다시 말해 레드팀은 모의 해킹 작전 중 위협이 커지기 전에, 퍼플팀 작전에 이어서 선제적으로 위협을 방어하는 일을 맡는다.

어콰이어(Aquia)의 CISO인 크리스 휴이는 “CISO의 관점에서 보면 레드팀을 사이버 보안 프로그램에 통합하면 체크리스트와 일반적인 보안 평가를 넘어 우선순위가 가장 높은 리스크를 파악하고, 실제 취약성이나 허점을 파악하면서 정교한 방어 기술을 만들 수 있다. 외부에 알려진 일반적인 컴플라이언스 프레임워크를 활용해 침투 테스트를 진행할 경우 문제를 모두 발견하지 못한다. 실제 적과 싸우는 것처럼 생각하고 훈련하고 적보다 먼저 공격 경로를 파악해야 한다”라고 설명했다.

기업 입장에서는 레드팀의 중요성을 알고 있어도 제대로 도입하기 쉽지 않을 수 있다. 특히 레드팀의 성공적인 운영을 위해서는 의사 결정권을 가진 경영진의 지원이 중요하다. 다음은 레드팀의 성과를 높이기 위해 임원진이 참고하면 좋은 정책이다. 
 

1. 레드팀의 활동 범위 제한하지 않기

실제 적이 해킹하는 방식을 레드팀이 선택할 수 있어야 한다. 코지베어, 딥 팬더, APT11로 알려진 해커는 모든 방식을 활용해 공격한다. 물론 적이 특정 범위만 공격하려고 한다면 레드팀도 해당 범위안에 있어야 한다. 필자는 회의를 하다 한 임원이 “레드팀 작전 중 일부 사용자의 생산성은 어쩔 수 없이 줄어들 수 있다는 점을 알고 있어야 한다. 만약 취약점이 있다면, 레드팀이 원하는 대로 활동할 수 있게 하면서 실제 해커가 공격하기 전에 문제점을 파악해보자”라는 말을 들은 적이 있다. 필자를 대신해서 해준 말 중에 가장 힘이 되는 말이었다. 해당 임원이 가진 생각 덕에 필자가 속한 레드팀은 의미 있는 성과를 얻고 중요도에 따라 필요한 조치를 시행할 수 있었다.  
 

2. 꼭 필요한 회의에만 레드팀 부르기

레드팀의 핵심 업무는 적을 모방해 공격하는 것이다. 보안 부서에서 일어나는 모든 일을 아는 것이 아니다. 레드팀은 작전 직후 경영진에게 상황을 간략히 보고하거나 심층 기술 분석을 논의하기 위해 회의에 참여할 수 있다. 하지만 그런 회의 참여가 주 업무가 돼서는 안 된다. 따라서 공격 소개, 목표, 발견 사항, 평가에 대해서는 레드팀과 협업 중인 임원에게 맡기면 좋다. 담당 임원이 전체 레드팀을 대신하여 필요한 결과를 상부에 보고하는 방식이 훨씬 효율적이다. 레드팀의 팀원은 ‘막후에 있는’ 운영자로 간주해야 한다. 레드팀 전체가 회의에 참석하는 방식은 회사와 부서에 큰 부담이 된다. 

그렇다고 레드팀을 완전히 차단해서도 안 된다. 사실, 보안팀을 비롯해 기업 내 다른 직원들과 친밀한 관계를 맺는 과정에서 레드팀은 작업을 보다 수월히 처리할 수 있다. 레드팀이 다른 직원처럼 회사의 성장을 원하는 사람으로 보일수록, 테스트 기간 동안 타팀으로부터 받는 저항도 줄어들 것이다. 하지만 전략, GRC, 제어 매핑, CI/CD 같은 부분을 논의할 때 레드팀이 굳이 개입할 필요는 없다.
 

3. 경영진별로 분리해서 보고받기

기술적인 심층 내용을 다룰 때는 경영진이 관심을 둘 만한 수준과 범위를 생각해봐야 한다. 어떤 임원은 공격 내용, 성과 측정 기준, 발견 사항, 향후 리스크 완화 또는 수용 여부에 관심을 가진다. 또 다른 임원은 포트, 서비스, 구문, 공격 기법, 공격 목적에 관심을 보일 수 있다. 시간 절약 측면에서 모든 임원을 하나의 회의에 부르는 것보다 보고 내용별로 나눠서 회의를 운영하는 편이 낫다. 레드팀도 기술적 배경을 알지 못하는 임원을 위한 보고서와 기술 내용 중심의 보고서를 분리해 준비하면 좋다.  
 

회원 전용 콘텐츠입니다. 이 기사를 더 읽으시려면 로그인 이 필요합니다. 아직 회원이 아니신 분은 '회원가입' 을 해주십시오.

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.