레드팀 훈련은 기술적 통제부터 사용자 교육, 대응 절차에 이르기까지 보안에 대한 투자가 실제로 표적 공격하에서 어떤 효과를 거두는지 파악하고자 할 때 실시하는 것으로, 공격적 보안 테스트에서 사실상의 표준이다. 종합적인 시스템 평가를 목적으로 하는 침투 테스트, 또는 탐지 및 대응 역량을 평가하는 퍼플팀과 달리 레드팀의 목적은 초기 거점에서 핵심 자산으로 이어지는 공격 경로를 찾는 데 있다.

레드팀 실행 방식이 지난 10년 동안 크게 발전했음에도 불구하고 많은 경영진이 레드팀에서 원했던 만큼의 가치를 얻는 데 어려움을 겪는다. 보안 책임자가 레드팀 활동을 최대한 활용하기 위해 계획부터 교정에 이르기까지 프로세스 전반에서 따라야 할 몇 가지 원칙을 소개한다.

범위는 넓게 설정

레드팀 훈련에서 잘못되는 가장 대표적인 점은 ‘너무 제한적인 범위’다. 이 문제는 범위에서 제외할 시스템, 사용자, 네트워크를 정의하는 담당자가 레드팀이 사용할 수 있는 공격 경로를 지나치게 제한할 때 발생한다. 이로써 현실과 동떨어진 왜곡된 결과가 발생하고 팀 활용도가 떨어지게 된다. 원인은 많지만 가장 주된 2가지는 레드팀에 대한 불신 또는 공포다. 두 감정 모두 상황을 통제하고자 하는 욕구로 이어지면서 잠재적으로 위험해 보일 수 있는 모든 요소를 제외하기 위해 범위를 좁히는 현상으로 나타나게 된다.

기본적으로 범위에 제한을 두지 않는 것이 좋다. 다만, 가능성은 희박하지만 테스트로 인해 오프라인이 될 경우 기업에 심각한 피해를 줄 수 있는 시스템만 범위에서 제외해야 한다. 제조 시스템, 금융 기관 SWIFT 관련 시스템, 또는 초단타 트레이딩 인프라 등이 이런 범주에 속한다.

레드팀 활동을 방해하지 않으면서 제한해야 할 시스템을 범위에서 빼기 위해 필자가 본 매우 효과적인 방법은 레드팀이 민감한 시스템에 직접 손을 대지 않고도 액세스할 수 있음을 증명하는 체크포인트를 사용하는 것이다. 예를 들어 레드팀이 민감한 시스템에 접근할 수 있는 사용자 계정을 침해하고, 해당 계정의 인증 정보가 유효하다는 사실을 입증하는 방식이 이에 해당한다.

공격자에게는 범위가 없다는 것을 기억하라.

창의성 포용

다소 논란의 여지는 있지만, 특정 위협 행위자 또는 캠페인을 충실히 모방하도록 레드팀 활동을 제한할 경우 레드팀이 제공하는 가치를 온전히 얻지 못할 가능성이 높다. 공격 모방, 즉 우려되는 위협 행위자가 이용하는 TTP를 반영하는 방법은 실제 환경에서 관찰된 부분에 노력을 집중한다는 면에서 문서상으로 보면 매우 합리적이다. 그러나 이런 방식에는 위협 보고의 ‘인지된 인지(known-known)’ 문제부터 ‘공격자가 방법을 변경하지 않는다’라는 잘못된 전제에 이르기까지 태생적으로 많은 논리적 결점이 있다.

필자의 의견으로는 위협 행위자의 특정 행동을 재현하려는 경우 BAS 툴을 사용하는 편이 더 적합하다. 궁극적으로 그 영향은 이전 섹션에서 설명한 문제와 동일하지만, 이번에는 표적으로 삼을 수 있는 대상이 아니라 사용 가능한 기법을 제한하게 된다.

결과적으로 팀의 창의성이 억제되면 레드팀 훈련의 효과가 반감되며, 보안 태세에 대한 이해도 부족해질 수 있다. 팀에 인위적인 제한을 가하면 팀은 환경과 비즈니스에 대한 이해를 통해 여러 기법을 연결하는 새로운 방법을 떠올리지 못하고, 훈련 중 나타날 수 있는 새로운 기회를 활용할 능력도 갖지 못한다.

보안 프로그램의 초점을 위협 중심 테스트에 두고 있다면 다른 프로젝트를 사용해 위협의 특정 행동을 모방하거나(예를 들면 위협의 관련 기법에만 테스트를 집중하는 퍼플팀), 레드팀의 활동을 설명된 내용으로만 제한하지 말고 위협 보고서를 사용해서 레드팀 활동의 계획을 이끌어 보라.

후자의 예를 들면, 위협 보고서의 매크로 포인트만 사용하는 것이다. 재무 부서 사용자의 윈도우 워크스테이션에 침입해 지속성을 확보한 다음, 민감한 파일 공유를 검색하고 AWS 인스턴스로 데이터를 빼내기 시작한 관련 위협 행위자를 기술하는 위협 보고서를 사용해서 적절한 활동을 계획할 수 있을 것이다. 이는 특정 지속성 메커니즘을 사용하거나 특정 파일 공유 유형을 표적으로 삼아야 한다는 제약을 가하지 않으므로 이사회나 경영진이 궁금해하는 위협이라는 전체적인 테마를 유지하면서 팀에 창의력을 발휘할 여지를 줄 수 있다.

침해 전제

필자가 레드팀에서 활동하면서 본 가장 큰 구조적 실패는 내부 네트워크 평가를 시작하기 위한 요구사항으로 레드팀에 직접 초기 액세스 권한을 획득할 것을 요구하는 경우다. 이런 요구사항에 극심한 환멸을 느낀 이유는 액세스 권한을 획득하기가 특별히 어려워서가 아니라, 시간을 투자할 가치가 없는 일이었기 때문이다. 6주의 활동 기간 중 5주를 사용자 피싱에 소비할지, 아니면 위험을 파악하고 빈틈을 막는 데 도움이 되는 공격 경로 탐색에 소비할지를 결정해야 한다.

필자는 공격자가 경계를 침해한 이후에 어떤 일이 일어날지에 대한 질문의 답을 찾는 것이 레드팀의 본질에 가장 맞는 일이라고 생각한다. 레드팀에 초기 액세스 평가를 수행할 능력이 없다는 의미가 아니다. 레드팀의 역할이 다른 일에 더 맞다는 뜻이다. 경계 평가는 그 취약성을 효과적으로 측정하는 데 필요한 시간과 리소스를 감안할 때 별도의 프로젝트로 실행하는 편이 더 좋다.

초기 접근 벡터를 평가하는 레드팀을 꼭 구성해야 하는가? 필자가 본 현명한 방법은 액세스 권한을 한 시스템에 양도해서 레드팀 일부가 초기 접근을 시도하고, 또 다른 분대가 경로 탐색 작업을 수행하는 것이다. 이 단계가 완료되면 그룹에 다시 합류해 이후 단계를 진행한다.

더 성숙한 조직은 이 활동을 완전히 별개의 프로젝트로 나누기도 하며, 경우에 따라서는 하나로 연결해 스토리를 전달하기도 한다. 필자가 좋아하는 사례는 한 금융 기관이 2가지 초기 접근 프로젝트(피싱과 외부 공격 표면 탐지)를 8주간 동시에 진행한 경우다. 이런 활동의 결과로 피싱 페이로드를 실행한 사용자와 팀이 코드 실행에 성공한 외부 시스템이 식별됐고, 이것이 레드팀에 대한 접근 지점으로 활용됐다.

자존심 내려놓기

레드팀 활동이 끝난 후의 결과 보고 자리는 불편한 경우가 많다. 레드팀은 아마도 공격 경로상에 존재하는 심각한 문제점을 드러냈을 것이고, 그 실패에 대해 책임 있는 당사자들이 테이블에 모여 앉은 채로 또는 전화를 통해 보고를 듣게 되기 때문이다. SOC에서 레드팀의 횡적 이동을 탐지하지 못한 이유는 무엇인가? 왜 ID팀은 엔터프라이즈 관리자에 대한 MFA를 비활성했는가? 보안 엔지니어링팀이 환경의 모든 호스트에 EDR을 배포하지 않은 이유는 무엇인가? 이런 질문이 오가다 보면 서로를 탓하고 비난하는 상황으로 흘러가면서 모든 참여자가 언짢음과 당혹감에 빠지기 쉽다.

여기서 한 가지 기억해야 할 것은 우리편이 심각한 결함을 적보다 먼저 발견한 덕분에 수정할 기회를 갖게 됐다는 점이다. 솔직하고 겸손하고 공감하는 환경을 조성하는 데 집중해야 한다. 그렇게 해도 불편한 감정을 느끼지 않을 수는 없지만, 우호적인 대화의 분위기는 토론의 질을 크게 향상시켜 줄 것이다.

보안 책임자로서 CISO의 역할은 토론의 초점을 관련된 담당자가 아니라 파악된 문제에 맞추는 것이다. 방어적이거나 논쟁적으로 흘러가는 대화에 개입해서 지금 모두가 한 팀으로 문제를 공략하고 있으며, 사고가 나기 전에 레드팀이 문제를 찾았다는 사실을 상기시키도록 한다. 결국 시간이 지나면 이것이 문화에 배어들고 그룹의 다른 사람도 이런 접근 방식을 전파하기 시작하면서 조직 전반에 퍼지게 된다.

협업 촉진

고립된 레드팀은 종종 나쁜 소식만 전하는 외부 세력으로 여겨진다. 협력자가 아니라 적대자로 취급받는 경우가 많다. 그렇기 때문에 레드팀이 보안 조직 내 다른 팀과 비즈니스 전반의 다양한 팀과 협력하는 데 많은 시간을 투자하는 것이 매우 중요하다.

성공적인 레드팀은 활동의 표적이 되는 시스템을 소유한 사람들을 포함한 이해관계자와 좋은 관계를 유지한다. 필자가 참여한 활동 중에서 가장 가치 있었던 경험은 레드팀 활동 이후 SOC와 함께 둘러앉아 레드팀이 사용한 수법을 탐지하는 방법을 구축하도록 도운 일이다. 수정 프로세스 과정에서 구축한 호의적인 관계는 위험한 상황에서 회사를 구했고, 팀의 업무 부담을 더 공감하게 되는 계기가 됐다.

레드팀은 보안 조직에서 용병이 아닌 선교사 역할을 해야 한다. 레드팀이 이해관계자와 직접적으로 협력하지 않고 있다면, 지금 시작해야 한다. SOC와 친밀한 관계를 맺도록 레드팀을 독려하라. 함께 점심 식사를 하거나 매 분기 일주일 동안 공동 프로젝트를 진행하는 방법도 있고, 두 팀의 리더가 몇 주 동안 서로의 직책을 바꿔 공감을 촉진하고 새로운 활력을 불어넣는 방법도 있다.
dl-itworldkorea@foundryco.com