좋은 레드팀은 무엇인가레드팀의 실력을 이야기할 때 우리는 거의 반사적으로 기술을 말한다. EDR을 우회했는가.\ Active Directory를 장악했는가.\ Cloud 환경에서 권한을 끌어올렸는가.\ 탐지되지 않은 채 목표 자산에 도달했는가.\ 실제 위협 행위자 수준의 TTP를 재현할 수 있는가. 틀린 기준은 아니다. 레드팀은 공격자의 관점에서 조직을 검증하는 팀이다. 공격 기술이 부족한 레드팀은 조직의 방어 체계를 충분히 검증할 수 없다. 따라서 기술력은 레드팀의 기본 자격에 가깝다. 하지만 기술력만으로 좋은 레드팀을 설명할 수 있는지는 별개의 문제다. 최근 Red Team Capability Maturity Model, 이하 Red Team CMM을 다시 보면서 이 질문을 다시 생각하게 됐다. **실력있는 레드팀과 좋은 레드팀은 같은 말인가.** 결론부터 말하면, 둘은 자주 겹치지만 같은 말은 아니다. 실력있는 레드팀은 공격을 성공시킬 수 있다.\ 좋은 레드팀은 그 공격을 조직의 변화로 연결할 수 있다. 이 차이를 설명하는 데 Red Team CMM은 꽤 유용한 기준을 제공한다. --- # 실력있는 레드팀이라는 함정 레드팀의 실력을 평가할 때 사람들은 대부분 기술적 성과를 본다. - EDR / XDR 우회 - Active Directory 장악 - Kerberos, NTLM relay, AD CS, DCSync 공격 - Cloud IAM 권한 상승 - 탐지 회피 - 실제 위협 행위자 TTP 재현 - 목표 자산 접근 이 능력들은 중요하다. 조직이 실제 공격자에게 당할 수 있는지를 검증하려면, 레드팀 역시 실제 공격자 수준의 기술적 역량을 갖춰야 한다. 기술적으로 부족한 레드팀은 조직에 잘못된 안정감을 줄 수 있다. 문제는 여기서 멈출 때 발생한다. “우리는 Domain Admin을 획득했다.” 이 문장이 곧 “우리는 좋은 레드팀이다”로 번역되는 순간, 레드팀은 기술적 성공과 조직적 성공을 혼동하기 시작한다. 조금 극단적인 예를 들어보자. 레드팀이 수 주에 걸친 작전 끝에 초기 침투, 권한 상승, 횡적 이동을 거쳐 Domain Admin 권한을 획득했다. 핵심 시스템에도 접근했다. 작전 내내 SOC는 의미 있는 탐지를 발생시키지 못했다. 공격 체인은 정교했고 OPSEC도 깔끔했다. 보고서가 작성되고 프로젝트는 종료됐다. 1년 뒤 실제 위협 행위자가 거의 동일한 경로로 동일한 목표에 도달했다. 같은 초기 침투 벡터, 같은 권한 상승 경로, 같은 탐지 공백이었다. 이 레드팀 활동은 성공한 것인가. 기술적 관점에서는 성공이다.\ 목표를 달성했고, 조직의 취약한 지점을 증명했다. 하지만 조직 보안의 관점에서는 실패에 가깝다.\ 같은 문이 1년 동안 열려 있었고, 같은 탐지 공백이 그대로 남아 있었다. 레드팀은 문이 열려 있다는 사실을 보여줬지만, 그 문이 닫히도록 만들지는 못했다. 여기서 실력있는 레드팀과 좋은 레드팀의 차이가 발생한다. --- # 먼저, 우리가 말하는 레드팀은 무엇인가 논의를 위해 인접 개념을 정리할 필요가 있다. 현장에서는 Vulnerability Assessment, Penetration Test, Red Team, Adversary Emulation, Purple Team이 자주 섞여 쓰인다. 하지만 성숙도를 논할 때는 구분이 중요하다. **Vulnerability Assessment**는 약점을 넓게 식별하는 활동이다. 깊이보다 커버리지가 중요하다. **Penetration Test**는 식별된 약점을 실제로 익스플로잇해 영향을 증명하는 활동이다. 일반적으로 스코프가 명확하고 제한적이다. **Red Team**은 특정 목표를 두고 실제 위협 행위자의 TTP를 모사해 조직의 예방, 탐지, 대응 역량 전체를 검증하는 활동이다. 단순 취약점 목록이 아니라 “이 조직은 이 공격을 막거나 탐지하고 대응할 수 있는가”에 답한다. **Adversary Emulation**은 특정 위협 행위자의 알려진 TTP를 MITRE ATT&CK 등에 매핑해 충실히 재현하는 방식이다. **Purple Team**은 레드팀과 블루팀이 같은 목표를 두고 탐지 로직과 대응 절차를 검증하고 개선하는 협업 방식이다. 핵심은 이것이다. 펜테스트의 주요 산출물이 취약점이라면, 레드팀의 주요 산출물은 조직 역량에 대한 검증 결과다. 레드팀의 가치는 “들어갔다”가 아니라, “들어가는 동안 무엇이 작동했고 무엇이 작동하지 않았는가”에 있다. 이 정의를 진지하게 받아들이면, 레드팀의 성숙도가 공격 기술만으로 측정될 수 없다는 결론이 자연스럽게 따라온다. --- # Red Team CMM은 무엇을 평가하는가 Red Team CMM은 내부 레드팀을 운영하는 조직이 현재 수준을 평가하고 발전 방향을 수립할 수 있도록 만들어진 커뮤니티 기반 프레임워크다. 보안 분야에는 성숙도 모델이 많다. SOC를 위한 모델이 있고, Incident Response 조직을 위한 모델이 있으며, 조직 전체 보안 역량을 평가하기 위한 프레임워크도 있다. 반면 레드팀 자체를 대상으로 한 성숙도 모델은 상대적으로 드물다. Red Team CMM을 볼 때 가장 눈에 띄는 점은 기술이 전체 모델의 일부에 불과하다는 점이다. 레드팀 성숙도 모델이라고 하면 일반적으로 다음 항목을 떠올리기 쉽다. - Exploit 개발 - Malware 개발 - EDR 우회 - OPSEC - Cloud 공격 - Adversary Emulation 하지만 Red Team CMM은 레드팀 성숙도를 크게 네 영역으로 나눈다. - Program - Process - People - Technology 그리고 각 영역 안에는 Planning, Authorization, Documentation, Reporting, Findings Management, Metrics, Knowledge Sharing, CTI Integration, Leadership Relationship 같은 항목이 포함된다. 이 중 많은 항목은 공격 기술과 직접적인 관련이 없다. 오히려 조직 운영, 협업, 지속성, 측정 가능성에 가깝다. 이 구조는 Red Team CMM만의 특이한 관점이 아니다. 금융권에서 정착된 intelligence-led red teaming 프레임워크인 CBEST, TIBER-EU도 같은 방향을 가진다. 단발성 테스트가 아니라 프로그램으로 운영하고, 위협 인텔리전스를 기반으로 시나리오를 도출하며, 최종 목적을 조직 회복력의 개선에 둔다. EU DORA의 TLPT 요구사항 역시 같은 맥락에 있다. 레드팀은 더 이상 단순 이벤트가 아니라, 측정 가능하고 반복 가능한 보안 검증 프로그램으로 다뤄지고 있다. 즉 Red Team CMM이 비기술 영역에 무게를 두는 것은 이례적인 주장이 아니다. 성숙한 레드팀 운영에서 이미 합의되고 있는 방향에 가깝다. 이유는 단순하다. 레드팀의 목적은 공격 성공이 아니다.\ 조직의 보안 수준 향상이다. --- # Program — 레드팀은 이벤트가 아니라 프로그램이다 Red Team CMM에서 가장 먼저 봐야 할 영역은 Program이다. 많은 조직에서 레드팀은 프로젝트 단위로 운영된다. 정해진 기간 동안 작전을 수행하고, 결과 보고서를 제출한 뒤 종료된다. 다음 분기나 다음 해에 또 다른 작전이 열린다. 이 방식에서는 작전과 작전 사이의 연속성이 약하다. 성숙한 레드팀은 프로젝트가 아니라 프로그램으로 움직인다. 프로젝트 중심 조직은 이렇게 묻는다. “이번에는 무엇을 공격할 것인가.” 프로그램 중심 조직은 다르게 묻는다. “이번에는 어떤 가정을 검증할 것인가.” 두 질문은 전혀 다르다. 첫 번째 질문은 공격 자체에 초점을 둔다.\ 두 번째 질문은 조직 리스크에 초점을 둔다. 예를 들어 조직이 “MFA가 있으니 계정 탈취 리스크는 충분히 통제되고 있다”고 믿고 있다면, 좋은 레드팀은 그 가정을 검증해야 한다. AiTM 피싱을 통한 세션 탈취가 가능한가.\ Device code phishing이 통하는가.\ OAuth consent abuse가 가능한가.\ 조건부 접근 정책이 실제 공격 경로에서 작동하는가.\ 탐지팀은 이러한 행위를 구분할 수 있는가. 이것은 단순히 “피싱을 해보자”가 아니다. 조직이 가진 보안 가정을 실제 위협 모델로 검증하는 활동이다. Program 영역이 중요한 이유는 여기에 있다. 성숙한 레드팀은 우발적으로 공격하지 않는다. 조직의 리스크, 위협 인텔리전스, 비즈니스 중요도, 방어팀의 검증 필요성을 기반으로 작전을 설계한다. 또한 Program은 경영진과의 정렬을 포함한다. 많은 조직에서 레드팀은 보안팀 내부의 기술 조직으로 취급된다. 그러나 성숙한 조직에서 레드팀은 리스크 검증 조직에 가깝다. 레드팀 결과는 보안 투자 우선순위, 아키텍처 의사결정, 탐지 전략, 권한 정책에 영향을 줘야 한다. 따라서 좋은 레드팀 프로그램은 다음 질문에 답할 수 있어야 한다. - 올해 어떤 위협 가정을 검증할 것인가 - 어떤 비즈니스 핵심 자산을 기준으로 시나리오를 설계할 것인가 - 어떤 공격 경로를 반복 검증할 것인가 - 지난 작전의 findings가 실제로 개선되었는가 - 레드팀 결과가 보안 투자와 정책 결정에 반영되었는가 레드팀이 이벤트에 머물면 매번 침투는 할 수 있다.\ 하지만 프로그램이 되지 못하면 조직은 누적해서 성장하지 않는다. --- # 변화한 공격 표면과 Program의 중요성 Program 관점이 중요한 또 다른 이유는 공격 표면이 크게 바뀌었기 때문이다. 과거에는 외부 웹 서버와 내부 Active Directory가 주요 표면이었다. 지금은 그렇지 않다. 첫째, Identity가 새로운 경계가 됐다. Okta, Entra ID 같은 IdP는 조직의 중앙 통제점이 되었다. 공격자의 무게중심도 이쪽으로 이동했다. - AiTM 피싱을 통한 세션 토큰 탈취 - MFA 우회 - Device code phishing - OAuth consent abuse - SAML / OIDC 신뢰 관계 악용 - 조건부 접근 정책 우회 이제 “도메인을 장악하는 공격”만이 아니라 “아이덴티티를 장악하는 공격”을 검증해야 한다. 둘째, Cloud control plane이 핵심 표면이 됐다. Cloud 환경에서는 네트워크 내부 침투보다 권한 관계가 더 중요할 수 있다. - iam:PassRole - sts:AssumeRole - 교차 계정 신뢰 악용 - Instance metadata credential 탈취 - Workload identity 악용 - Non-human identity 관리 실패 - On-prem과 Cloud 사이의 trust abuse Cloud에서의 권한 상승은 전통적인 로컬 권한 상승과 다르게 동작한다. 따라서 레드팀 프로그램 역시 이 차이를 반영해야 한다. 셋째, SaaS와 SaaS 사이가 새로운 횡적 이동 경로가 됐다. 하나의 계정 침해가 Okta, Slack, GitHub, AWS, Google Workspace, M365로 이어질 수 있다. 서드파티 OAuth 앱과 SaaS integration은 생산성을 높이지만 동시에 신뢰 관계를 길게 만든다. 공격자는 조직도를 보지 않는다.\ 공격자는 신뢰 관계를 따라 움직인다. 넷째, CI/CD와 Source Repository가 공격 경로가 됐다. 빌드 파이프라인은 프로덕션으로 가는 고속도로다. - Repository secret 유출 - GitHub Actions OIDC trust misconfiguration - Runner compromise - Build artifact tampering - Dependency confusion - Supply chain attack 좋은 레드팀은 단순히 서버를 뚫는 것이 아니라, 코드가 프로덕션에 도달하는 경로도 검증해야 한다. 다섯째, AI Application이 새로운 표면으로 열리고 있다. 아직 미성숙한 영역이지만 빠르게 실재하는 위협이 되고 있다. - Prompt Injection - Agent tool abuse - RAG data poisoning - Sensitive data leakage - Model supply chain - Over-permissioned AI workflow AI를 쓰는 조직이 늘어날수록, 레드팀은 AI를 공격 자동화 도구로만 볼 것이 아니라 새로운 공격 표면으로 봐야 한다. 좋은 레드팀은 이러한 기술 목록을 유행처럼 따라가지 않는다.\ 우리 조직이 실제로 어디에 노출되어 있는지 확인하고, 그 노출을 기준으로 시나리오를 설계한다. 이것이 Program이다. --- # Process — 재현 가능하고 설명 가능한 공격 레드팀 업계는 개인 역량 의존도가 높다. 특정 오퍼레이터만 수행할 수 있는 공격이 있다.\ 특정 팀원만 알고 있는 우회 기법이 있다.\ 특정 사람의 머릿속에만 남아 있는 작전 노하우가 있다. 겉으로는 강점처럼 보일 수 있다. 하지만 조직 관점에서는 리스크다. 그 사람이 떠나면 역량도 함께 사라진다. Red Team CMM은 이 문제를 Process 영역에서 다룬다. 주요 항목은 다음과 같다. - Planning - Authorization - Documentation - Reporting - Findings Management 처음 보면 행정적인 항목처럼 보일 수 있다. 그러나 실제로는 레드팀을 조직의 자산으로 만드는 핵심 장치다. 특히 Authorization은 단순 결재 절차가 아니다. 프로덕션 환경에서 실제 공격을 모사하려면 명확한 Rules of Engagement가 필요하다. 작전 범위, 금지 행위, 영향도 허용 범위, 디컨플릭션 채널, 사고 오인 시 에스컬레이션 경로, 법무 승인, 긴급 중지 조건이 정리되어야 한다. 이것은 레드팀을 제한하기 위한 절차가 아니다.\ 레드팀이 안전하게 더 깊은 작전을 수행할 수 있도록 만드는 운영 기반이다. Documentation도 마찬가지다. 좋은 레드팀은 공격을 수행하는 팀이 아니라, 공격을 설명할 수 있는 팀이다. 설명할 수 있어야 할 질문은 다음과 같다. - 왜 성공했는가 - 왜 실패했는가 - 어떤 통제가 우회되었는가 - 어떤 통제가 정상적으로 작동했는가 - 어떤 탐지가 발생했는가 - 어떤 탐지가 발생하지 않았는가 - 각 공격 단계는 ATT&CK의 어떤 기법에 해당하는가 - 각 단계에서 탐지 기회는 어디에 있었는가 미성숙한 레드팀의 산출물은 “DA 획득”이라는 한 줄과 스크린샷 몇 장이다. 성숙한 레드팀의 산출물은 공격 경로 내러티브다. 예를 들면 다음과 같다. 공격 체인의 7개 단계 중 5개 단계에서 탐지 기회가 존재했다.\ 그중 2개 단계에서는 알람이 발생했지만 triage 과정에서 무시되었다.\ 3개 단계는 로그가 존재하지 않았거나 상관분석이 되지 않았다.\ 각 누락 지점에 대한 탐지 로직과 로깅 개선안은 다음과 같다. 이 차이가 중요하다. 레드팀 결과가 설명 가능하지 않으면 블루팀은 개선할 수 없다.\ 레드팀 결과가 재현 가능하지 않으면 엔지니어링 조직은 수정할 수 없다.\ 레드팀 결과가 추적 가능하지 않으면 경영진은 투자 판단을 할 수 없다. Findings Management는 이 지점을 더 명확히 한다. 보고서 PDF 안에 박제된 finding은 조직을 바꾸지 못한다. 성숙한 조직에서 finding은 살아 있는 백로그여야 한다. - Owner 지정 - 우선순위 산정 - Remediation 계획 - Retest - Regression 관리 - 반복 발생 여부 추적 작년에 발견된 문제가 올해도 동일하게 발견된다면, 그것은 단순히 블루팀의 실패가 아니다. 레드팀 결과가 조직의 개선 프로세스로 연결되지 못했다는 신호다. Process는 레드팀을 느리게 만드는 행정 절차가 아니다.\ 레드팀 결과를 조직의 변화로 연결하는 파이프라인이다. --- # People — 좋은 레드팀은 혼자 존재하지 않는다 Red Team CMM에서 가장 인상적인 영역은 People이다. 모델은 다음 관계들을 성숙도 평가 항목으로 다룬다. - Responder - Threat Hunter - Detection Engineering - Security Engineering - Architecture - CTI - Leadership - Legal - GRC 처음 보면 의외일 수 있다. 왜 Legal과의 관계가 레드팀 성숙도에 포함되는가.\ 왜 Leadership과의 관계가 기술 역량만큼 중요하게 다뤄지는가. 답은 단순하다. 레드팀이 조직을 바꾸려면, 조직을 움직일 수 있어야 하기 때문이다. 레드팀이 탐지 공백을 발견해도 Detection Engineering 팀이 탐지 로직을 만들지 않으면 아무것도 달라지지 않는다. 레드팀이 권한 관리 문제를 발견해도 IAM 정책이 변경되지 않으면 동일한 공격 경로는 유지된다. 레드팀이 Cloud Architecture의 구조적 문제를 지적해도 엔지니어링 조직이 설계를 고치지 않으면 다음 작전에서 같은 문제가 반복된다. 작전의 허용 범위와 리스크 수용 수준은 Legal과 Leadership이 결정한다. 예산과 프로그램의 지속 여부도 결국 Leadership이 결정한다. 따라서 좋은 레드팀은 기술 조직이면서 동시에 영향력 조직이어야 한다. 여기에는 정치적 자본이 필요하다. 여기서 정치적이라는 표현은 부정적인 의미가 아니다. 조직 내에서 신뢰를 확보하고, 레드팀 결과가 실제 의사결정으로 이어질 수 있는 상태를 의미한다. 탐지 엔지니어가 레드팀 findings를 신뢰한다.\ 엔지니어링 조직이 설계 단계에서 레드팀 의견을 참고한다.\ 경영진이 레드팀 결과를 투자 우선순위에 반영한다.\ GRC 조직이 레드팀 결과를 통제 개선과 리스크 관리에 연결한다. 이 상태가 만들어져야 레드팀은 조직을 바꿀 수 있다. 반대로 블루팀을 망신 주는 데서 만족하는 레드팀은 오래가지 못한다. 협조는 줄어들고, findings는 방어적으로 반박당하며, 다음 작전의 스코프는 좁아진다. 좋은 레드팀은 SOC를 이기는 팀이 아니다.\ 좋은 레드팀은 SOC를 성장시키는 팀이다. 레드팀이 사용하는 언어도 중요하다. 기술자에게는 기술 언어로 설명해야 한다. “이 공격은 Kerberos delegation 설정과 ACL misconfiguration의 조합으로 성립한다.” 하지만 경영진에게는 다른 언어가 필요하다. “현재 통제 상태에서는 단일 계정 침해가 도메인 전체 장악으로 이어질 수 있으며, 핵심 업무 시스템 중단과 데이터 유출로 연결될 수 있다.” 같은 사실도 대상에 따라 다르게 번역되어야 한다. 좋은 레드팀은 공격을 잘 설명하는 팀이다.\ 더 정확히 말하면, 공격 결과를 조직의 언어로 번역할 수 있는 팀이다. --- # Technology — 가장 눈에 띄지만 가장 작은 영역 Technology는 레드팀에서 가장 눈에 잘 띄는 영역이다. 도구, 인프라, 우회 기법, C2, 페이로드, 자동화. 레드팀을 떠올릴 때 가장 먼저 생각나는 것들이다. Red Team CMM에서도 Technology 영역은 존재한다. 주요 항목은 다음과 같다. - Tooling - Infrastructure - Test Environment 물론 중요하다. 좋은 레드팀은 좋은 도구를 필요로 한다. OPSEC을 고려한 공격 인프라도 필요하다. C2, redirector, domain, profile, certificate, infrastructure-as-code 기반의 배포 자동화도 필요하다. 프로덕션 보안 스택을 충실히 반영한 테스트 환경도 필요하다. TTP를 운영 환경에 적용하기 전에 검증할 수 있어야 작전 리스크를 줄일 수 있다. 하지만 Technology는 Program, Process, People 위에 있는 것이 아니다. 오히려 이들을 지원하는 기반에 가깝다. 레드팀 업계에서는 기술 자체가 목적이 되는 경우가 흔하다. 새로운 C2를 만든다.\ 새로운 EDR 우회 기법을 연구한다.\ 새로운 공격 프레임워크를 구축한다.\ 새로운 loader를 작성한다. 이 활동들은 중요하다. 나 역시 이런 작업이 레드팀의 핵심 역량 중 하나라고 생각한다. 하지만 도구의 성숙도는 팀과 프로세스의 성숙도를 따라가야 한다. 프로세스 없는 자동화는 효율이 아니라 노이즈를 만든다.\ 운영 규율 없는 공격 인프라는 OPSEC이 아니라 리스크를 만든다.\ 조직적 개선으로 이어지지 않는 우회 기법은 기술 시연에 가깝다. 기술은 목적이 아니라 수단이다. 좋은 레드팀은 기술을 통해 조직의 보안 상태를 검증하고, 그 결과를 개선으로 연결한다. --- # Metrics — 좋은 레드팀은 자신을 증명할 수 있다 Program, Process, People, Technology를 가로지르는 중요한 축이 Metrics다. 미성숙한 레드팀은 자신의 가치를 일화로 증명하려 한다. “이번에도 DA를 획득했다.”\ “이번에도 SOC가 못 봤다.”\ “이번에도 EDR을 우회했다.” 하지만 이것은 측정이 아니라 사건이다. DA 획득은 KPI가 될 수 없다. 공격자가 Domain Admin을 획득했다고 해서 조직이 반드시 전체적으로 취약하다는 뜻은 아니다. 반대로 레드팀이 Domain Admin을 획득하지 못했다고 해서 조직이 안전하다는 뜻도 아니다. 레드팀의 가치는 특정 권한을 획득했는지가 아니라, 조직이 어떤 공격 경로를 탐지하고 대응할 수 있는지를 검증하는 데 있다. 성숙한 레드팀은 추세로 말해야 한다. - 시간에 따른 탐지 커버리지 변화 - ATT&CK 기법별 탐지 가능 여부 - MTTD / MTTR 변화 - Findings 종료율 - Findings 재발률 - Retest 통과율 - 반복 작전에서 동일 공격 경로가 차단되었는지 여부 - SOC triage 정확도 - Cloud / SaaS / Identity 로그 가시성 개선 정도 중요한 점은 사고 지표와 역량 지표를 구분하는 것이다. 침해 사고 건수는 후행 지표다. 이미 일이 발생한 뒤에 측정된다. 레드팀이 측정해야 하는 것은 선행 지표다. 조직이 공격을 막고 탐지하고 대응할 수 있는 역량이 시간에 따라 어떻게 변하고 있는가. 이것이 측정되어야 한다. 그리고 이 숫자가 있어야 레드팀은 Leadership과 대화할 수 있다. 예산을 설득할 수 있고, 보안 투자 우선순위를 바꿀 수 있으며, 프로그램의 지속성을 확보할 수 있다. 좋은 레드팀은 “우리가 뚫었다”고 말하는 팀이 아니다. 좋은 레드팀은 “이 공격 경로에 대한 조직의 방어 역량이 이렇게 변했다”고 말할 수 있는 팀이다. --- # 그래서, 좋은 레드팀은 무엇인가 Red Team CMM을 기준으로 보면 결론은 명확하다. 좋은 레드팀은 공격을 잘하는 팀만을 의미하지 않는다.\ 공격을 잘하는 것은 필요조건이지만 충분조건은 아니다. 좋은 레드팀은 조직이 암묵적으로 믿고 있는 가정을 검증한다. “우리 MFA는 안전하다.”\ “클라우드는 분리되어 있다.”\ “SOC는 주요 공격을 탐지할 수 있다.”\ “CI/CD 파이프라인은 안전하다.”\ “중요 SaaS는 적절히 통제되고 있다.”\ “AI 도구는 내부 문서를 안전하게 다룬다.” 이런 가정들을 실제 공격 경로로 검증하고, 맞는 것과 틀린 것을 구분한다. 좋은 레드팀은 실제 위협 행위자가 사용할 수 있는 경로를 찾아낸다. 좋은 레드팀은 방어 조직이 보지 못한 사각지대를 드러낸다. 좋은 레드팀은 그 결과를 개선 활동으로 연결한다. 좋은 레드팀은 조직 전체의 보안 수준을 측정 가능하게 끌어올린다. 반대로 아무리 뛰어난 기술력이 있어도 결과가 조직의 변화로 이어지지 않는다면 가치는 제한적이다. 레드팀은 공격 조직이다.\ 하지만 공격이 목표는 아니다. 공격은 검증 수단이다. 검증을 통해 조직의 보안 상태를 이해하고, 개선 방향을 제시하고, 실제 변화를 만드는 것. 그것이 좋은 레드팀의 역할이다. --- # 마치며 레드팀은 본질적으로 기술 중심 분야다. 나 역시 새로운 공격 기법, 우회 기술, 인프라 자동화, 현실적인 공격 시나리오를 연구하는 일을 좋아한다. 하지만 Red Team CMM을 기준으로 레드팀 성숙도를 다시 보면, 좋은 레드팀을 만드는 요소는 기술 밖에 훨씬 많이 존재한다. Program.\ Process.\ People.\ Technology.\ Metrics. 이 항목들은 결국 하나의 메시지로 수렴한다. 레드팀은 단순 공격 수행 조직이 아니라, 조직의 보안 가정을 검증하고 개선을 유도하는 프로그램이어야 한다. 공격 기술은 중요하다.\ 그것 없이는 시작할 수 없다. 하지만 그것만으로는 충분하지 않다. 실력있는 레드팀은 시스템을 장악한다.\ 좋은 레드팀은 조직을 성장시킨다. 그리고 조직의 보안 수준은 침투 성공 여부가 아니라, 그 이후에 축적되는 변화로 결정된다. --- ## 참고 - Red Team Capability Maturity Model — [redteammaturity.com](http://redteammaturity.com) - CBEST — Bank of England - TIBER-EU — European Central Bank, 2018 - DORA TLPT — EU Digital Operational Resilience Act