레드팀은 취약성을 먼저 파악하고 침투 테스트(펜테스팅, Pentesting)를 진행한다. 즉 취약성을 추측하는 것에서 한 걸음 더 나아가 취약성을 구체적으로 파악해 공격이 정확히 어떻게 발생할 수 있을지 입증한다. 레드팀의 활동은 간혹 침투 테스트라고 불리기도 하는데, 엄밀히 말하면 잘못된 표현이다.
 |
ⓒ Getty Images Bank |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
침투 테스트는 명확한 목표를 염두에 두지 않고 가능한 많은 문제를 찾는다. 취약점 공격 또는 공격 이후 벌어지는 활동의 성공과 실패를 확인하기 위해 광범위하게 공격을 해보는 식이다. 또한 침투 테스트는 일반적으로 초기 액세스 벡터를 수행하지 않는다. 모의 해킹에서는 레드팀 말고 공격과 방어를 종합적으로 활용해 보안성을 높이는 퍼플팀이 존재하는데, 퍼플팀은 침투 테스트와 레드팀 활동 결과를 함께 살펴본다. 여러 단계에서 보안 문제를 찾아 해결 능력을 검증하는 것이다.
레드팀은 초기 액세스부터 데이터 유출에 이르기까지 해킹 구조 전체를 파악하고 고도로 표적화된 작전을 실행한다. 기업은 레드팀으로 마치 APT 공격처럼 특정 직원이나 프로세스, 기술을 은밀하게 공격하면서 궁극적으로 보안 수준을 단계 더 높인다. 다시 말해 레드팀은 모의 해킹 작전 중 위협이 커지기 전에, 퍼플팀 작전에 이어서 선제적으로 위협을 방어하는 일을 맡는다.
어콰이어(Aquia)의 CISO인 크리스 휴이는 “CISO의 관점에서 보면 레드팀을 사이버 보안 프로그램에 통합하면 체크리스트와 일반적인 보안 평가를 넘어 우선순위가 가장 높은 리스크를 파악하고, 실제 취약성이나 허점을 파악하면서 정교한 방어 기술을 만들 수 있다. 외부에 알려진 일반적인 컴플라이언스 프레임워크를 활용해 침투 테스트를 진행할 경우 문제를 모두 발견하지 못한다. 실제 적과 싸우는 것처럼 생각하고 훈련하고 적보다 먼저 공격 경로를 파악해야 한다”라고 설명했다.
기업 입장에서는 레드팀의 중요성을 알고 있어도 제대로 도입하기 쉽지 않을 수 있다. 특히 레드팀의 성공적인 운영을 위해서는 의사 결정권을 가진 경영진의 지원이 중요하다. 다음은 레드팀의 성과를 높이기 위해 임원진이 참고하면 좋은 정책이다.
1. 레드팀의 활동 범위 제한하지 않기
실제 적이 해킹하는 방식을 레드팀이 선택할 수 있어야 한다. 코지베어, 딥 팬더, APT11로 알려진 해커는 모든 방식을 활용해 공격한다. 물론 적이 특정 범위만 공격하려고 한다면 레드팀도 해당 범위안에 있어야 한다. 필자는 회의를 하다 한 임원이 “레드팀 작전 중 일부 사용자의 생산성은 어쩔 수 없이 줄어들 수 있다는 점을 알고 있어야 한다. 만약 취약점이 있다면, 레드팀이 원하는 대로 활동할 수 있게 하면서 실제 해커가 공격하기 전에 문제점을 파악해보자”라는 말을 들은 적이 있다. 필자를 대신해서 해준 말 중에 가장 힘이 되는 말이었다. 해당 임원이 가진 생각 덕에 필자가 속한 레드팀은 의미 있는 성과를 얻고 중요도에 따라 필요한 조치를 시행할 수 있었다.2. 꼭 필요한 회의에만 레드팀 부르기
레드팀의 핵심 업무는 적을 모방해 공격하는 것이다. 보안 부서에서 일어나는 모든 일을 아는 것이 아니다. 레드팀은 작전 직후 경영진에게 상황을 간략히 보고하거나 심층 기술 분석을 논의하기 위해 회의에 참여할 수 있다. 하지만 그런 회의 참여가 주 업무가 돼서는 안 된다. 따라서 공격 소개, 목표, 발견 사항, 평가에 대해서는 레드팀과 협업 중인 임원에게 맡기면 좋다. 담당 임원이 전체 레드팀을 대신하여 필요한 결과를 상부에 보고하는 방식이 훨씬 효율적이다. 레드팀의 팀원은 ‘막후에 있는’ 운영자로 간주해야 한다. 레드팀 전체가 회의에 참석하는 방식은 회사와 부서에 큰 부담이 된다.
그렇다고 레드팀을 완전히 차단해서도 안 된다. 사실, 보안팀을 비롯해 기업 내 다른 직원들과 친밀한 관계를 맺는 과정에서 레드팀은 작업을 보다 수월히 처리할 수 있다. 레드팀이 다른 직원처럼 회사의 성장을 원하는 사람으로 보일수록, 테스트 기간 동안 타팀으로부터 받는 저항도 줄어들 것이다. 하지만 전략, GRC, 제어 매핑, CI/CD 같은 부분을 논의할 때 레드팀이 굳이 개입할 필요는 없다.
3. 경영진별로 분리해서 보고받기
기술적인 심층 내용을 다룰 때는 경영진이 관심을 둘 만한 수준과 범위를 생각해봐야 한다. 어떤 임원은 공격 내용, 성과 측정 기준, 발견 사항, 향후 리스크 완화 또는 수용 여부에 관심을 가진다. 또 다른 임원은 포트, 서비스, 구문, 공격 기법, 공격 목적에 관심을 보일 수 있다. 시간 절약 측면에서 모든 임원을 하나의 회의에 부르는 것보다 보고 내용별로 나눠서 회의를 운영하는 편이 낫다. 레드팀도 기술적 배경을 알지 못하는 임원을 위한 보고서와 기술 내용 중심의 보고서를 분리해 준비하면 좋다.4. 리스크 수준을 지정하고 연계 팀에 알리기
레드팀 팀원은 문제의 위험성 수준을 지정하고 어떻게 문제를 처리해야 할지 예측할 수 있다. 여기에 어떤 부서가 리스크를 소유하고 있으며, 어떤 팀이 해당 문제를 해결하기 위해 주도적으로 후속 조치를 취해야 하는지도 파악하고 있어야 한다. 레드팀은 종종 경영진에게 보고하는 상황에서 “이런 발견이 어떤 결과를 만드는가? 문제를 해결하기 위해 어디서부터 시작해야 하는가?”라는 질문을 받는데, 사실 레드팀이 답변할 만한 질문은 아니다. 레드팀은 공격을 실행할 뿐이지 문제 해결이나 검토 같은 후속 조치를 담당하지 않는다. 따라서 경영진은 모의 해킹 후 알아낸 리스크를 기반으로 연계된 담당자를 레드팀과 연결해줘야 한다.5. 결과물 평가 및 리스크 등급 표준화하기
이제 공통 취약점 등급 시스템(Common Vulnerability Scoring System, CVSS) 등급을 넘어설 때다. CVSS 등급은 일반적으로 악용되는 취약점의 어려움과 가능성을 아는 데는 좋지만 각 기업에서 심층적으로 활용기에는 부족한 도구다. 레드팀에 이에 대한 평가를 맡기면 자체적인 기준에 따라 낮음, 중간, 높음 또는 중요 등급을 지정할 것이다.사실, 결과물 평가는 주관적이기 때문에 최대한 객관적인 요소를 활용하면 좋다. 그런 과정 속에 리스크 등급은 기업에 맞춤화되고 계속 활용될 수 있다. 고유한 리스크 등급은 반복적으로 나타나는 가능성과 영향 수준을 알려주는 기술 및 시간적 요인을 고려해 계산해야 한다.
이런 등급은 어떤 면에서 필터링되지 않은 CVSS에 가깝지만 메타 데이터가 더 다양하다는 점에서 차이가 있다. 고유한 리스크 등급을 비롯해 네트워크 및 완화 요소를 활용하면 제어 등급을 만들 수 있다. 제어 등급에 다시 고유한 리스크 등급 값을 곱하면 특정 취약성에 대한 남아있는 가중 리스크, 즉 굉장히 가치 있는 정보를 알 수 있다.
6. 작전 주기 파악하기
레드팀은 침투 테스트 팀이 아니다. 레드팀의 작전주기는 침투 테스트팀의 작전주기와는 완전히 다르다. 침투 테스트는 결국 최상의 방어 환경과 기회를 주기 위해 특정 취약점 요소와 잘못된 설정의 표준 집합을 활용한다. 또한 침투 테스트 팀은 적극적으로 경보를 발령하고 EDR 및 SIEM 솔루션이 선택한 긍정적인 결과물에 대해 보고하려고 노력한다.침투 테스터 입장에서 볼 때, 침투 테스트 참여는 2주~3주간의 테스트 기간을 갖고, 일주일에 걸쳐 보고서를 작성하고, 그다음 주에 다시 돌아와서 새롭게 참여한다. 고객 입장에서는 일반적으로 테스트를 1년에 한 번 하고, 그다음 12개월 동안 문제를 해결한다.
그와 반대로 레드팀은 범위가 좁으면서 명확하게 정의된 목표를 가지고 있다. 레드팀은 모든 것을 수행하려 하지 않는다. 레드팀의 모든 활동은 방어팀에게 경각심을 주기 때문에, 레드팀은 목표를 달성하기 위한 행동만 수행하며, 시간에 쫓기지 않는다. 또한 레드팀은 비밀스러운 방식으로 운영되고, APT 공격을 현실적으로 구현하고, 킬 체인을 연구 및 준비하고 테스트하는 데 시간을 주로 보낸다.
따라서 공격 범위가 전체 조직이기 때문에 레드팀 작전의 주기와 라이프사이클은 더 느려지고 길어진다. 레드팀의 연간 목표와 주요 결과(OKR)를 수립할 때 이 점을 유념해야 한다. 말할 것도 없이, 많은 결과물이 대개 레드팀 작전에서 나오며, 모든 결과물이 TTP와 연관 있거나 직접적인 위험 완화를 가져오는 것은 아니다. 보안 대책을 마련하는 팀이 공격 결과를 검토하고 최대한 위험성을 완화하기 위해서는 시간이 걸린다. 이런 상황 속에 모의 해킹에서 방어하는 역할을 담당하는 블루팀에 업무가 지나치게 많아지는 것을 방지할 수 있다. 블루팀은 작업할 양에 따라 레드팀에게 한 분기 동안 추가 작전을 취소하거나 연기해 달라고 요청할 수 있다.
7. 모든 지표 추적하기
공격 프로그램의 성공을 보여주는 지표가 모두 레드팀에서 나오는 것은 아니다. 테스트 및 그에 따른 해결의 성공 여부를 추적하는 데 사용되는 레드팀 지표에는 평균 체류 시간이 포함된다. 즉 레드팀은 경고를 받지 않고 검색 및 피봇 작업을 수행하는 환경에서 얼마나 오래 지속할 수 있는지 확인한다.SIEM 규칙 및 EDR 탐지와 같이 새로 생성된 완화 조치 외에 블루팀 측 지표에는 경보가 발령된 후 사고 조사에 착수하고 사건의 단계를 분류하는 데 얼마나 걸렸는가 같은 내용을 확인할 것이다. 다른 요인은 사이버 위협 인텔리전스(CTI) 및 리스크팀으로부터 결과물에 대한 잔류 리스크 점수 감소, 모방된 위협 행위자에 대항하는 복원력에 대한 지식 향상, 일반적으로 볼 수 있는 플레이북의 성공 가능성 등의 형태로 나올 것이다. CTI팀은 누구의 전술이 방어될 수 있고 방어될 수 없는지를 확실히 파악함으로써 관련 위협 행위자를 특정할 수 있을 것이다.
그런 다음 보안 인식 및 복원력 교육을 이러한 방법에 맞게 조정할 수 있다. 또한, 이러한 방법에 대한 수동 조사는 더 가치 중심적이다. 가긍정적 판단 또는 가부정적 판단에 대한 추측과 확인 게임이 아니다.
마지막으로, 보안 조치와 프로세스를 실제로 확인한다는 것은 보안 부서가 문서, 보고서 및 결과를 감사팀에게 전달하고 다른 질문은 따로 받지 않는다는 것을 의미한다. GRC는 또한 제로데이가 발생하는 불가피한 날에 규제 조사관 및 사이버 보안 보험 회사에 대한 실사를 입증할 수 있다. 레드팀의 활동이 성공하면 그 효과는 비즈니스 부서와 기능으로 전환된다.
8. 레드팀 역할 및 책임 분리하기
최적화된 레드팀 작전은 기업의 추구하는 목표에 맞춰 CTI, 레드팀, 탐지 엔지니어의 지속적인 피드백을 반영해 수행된다. 각 팀의 역할은 다 다르지만, 필자 생각에는 그런 책임을 분리하는 것이 가장 좋다.보통 보안 기업은 규모가 작아서 한 사람이 여러 개의 직책을 수행한다. 하지만 적어도 한 명의 상근 직원이 특정 업무에 전념한다면 운영의 질이 크게 향상된다. 그런 면에서 보안 팀은 COO, CRO 또는 CISO 소속으로 분리해야 하는 반면에, 취약성 관리, 교정 관리 및 IT 운영은 CIO 또는 CTO 소속으로 분리해야 한다.
9. 현실적인 기대치 설정하기
레드팀은 작전 계획을 설명할 때 관련 목표와 대략적인 접근 방식을 제시한다. 대개 ‘RCE를 통한’ 또는 ‘MiTM을 통한 자격 증명 캡처’ 같은 내용이다. 주요 경영진은 그런 공격 과정에서 발생하는 생산성 손실 또는 서비스 거부(DoS)를 우려한다. 이것이 목표는 결코 아니지만, 레드팀은 사용하려는 모든 단계와 방법을 나열하지 않는다.사실 레드팀은 취약점을 공격하면서 원래 계획했던 페이로드를 디버깅하거나 원활한 TTP 실행을 보장하는 것에서 벗어나야 할 때가 있다. 작전 전, 작전 중, 작전 후 레드팀으로부터 얻을 수 있는 정보에 보다 현실적인 태도를 취해준다면, 레드팀의 부담을 줄여줄 것이다.
10. 레드팀에게 오프네트워크 공격 장치 제공하기
좋은 결과를 만들기 위해 레드팀은 작전마다 자체 인프라를 정신없이 공격한다. 모든 작전에 대해 해당 공격 경로의 요구사항이 조정되고 새로 테스트된다. 관리 측면에서는 엔터프라이즈 EDR, AV 및 SIEM 에이전트와 분리된 장치를 제공하면, 피싱 캠페인, 랜딩 페이지 및 페이로드를 테스트하고 버그를 해결할 수 있으므로 취약 기간 동안 운영 시간이 낭비되지 않는다.이는 반직관적인 것처럼 보이지만, 레드팀은 민감한 회사 데이터를 이러한 장치에 저장하지 않으며 보안 지침(20자리 암호, MFA, 디스크 암호화 등)을 따라야 하는 상황을 맞이한다. 레드팀은 보안 클라우드 환경상 작전에서 얻거나 유출된 정보를 저장할 것이다. 따라서 이 장치는 명령이 원격 서버에도 기록되어야 하는 콜백의 터미널 역할을 한다. 이는 레드 팀에게 매우 유익하다. 작전이 시작되기 몇 주 전에 테스트에서 실수로 IP 주소나 악성 도메인을 없애도록 해서, SOC에서 가긍정적 승리로 작전이 종료되는 것은 회사의 시간과 자원의 낭비이기 때문이다.
11. 작전 중 레드팀 목표 확장하지 말기
목표가 전달되고 시나리오가 설계된 후에 갑자기 다른 목표가 나타나는 경우가 종종 있다. 감사가 발표되거나 갱신이 다가와서 목표 목록에 몇 가지 사항을 추가하는 것이다. 이런 상황에서 목표를 추가해도 될까? 대답은 ‘안된다’이다. 다시 한번 말하지만, 레드팀이 어떤 환경에 놓여 있을 때는 많은 리소스에 액세스할 수 있고 많은 작업을 수행할 수 있지만, 직접적인 목표가 아닌 것은 지나친다. 작전 중에 범위가 서서히 움직인다는 것은 CTI 기반 동작 제한을 주는 작전 계획을 더 이상 준수하지 못한다는 것을 의미한다. 어떤 목표는 밀접한 관련이 있는 것처럼 보일 수 있지만, 레드팀의 작전 기술에 충실하기 위해서는 레드팀이 스스로 작전의 끝낼 수 있게 해야 한다.
보안이 모든 사람의 책임인 것처럼, 레드팀의 성공은 팀원뿐만 아니라 경영진 및 정책 기획자에게 달려있기도 하다. 기업 경영진은 여러 의견 속에서도 자신의 레드팀의 편을 들어줄 수 있는 능력이 있다. 레드팀은 모든 사람이 항상 좋아하는 부서는 아니라는 것을 알고 있지만, 레드팀은 효율성을 너무 추구하거나 지나치게 통제받아서도 안 된다.
editor@itworld.co.kr
Maril Vernon editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
