Red Team & Blue Team
레드팀/블루팀/퍼플팀/그린팀
많은 기업과 서적에서 레드팀과 관련된 이야기를 많이 하고 있다. 레드팀이란 간단하게 말해 일을 진행함에 있어 헛점이나 잘못된 부분을 찾아내는 조직을 통칭하여 이르는 경우가 많다. 레드팀의 개념은 세계 1차 대전중에 군대에서 부터 시작 되었다.
전쟁 중에 실제 적군의 공격을 예상하고 레드팀이 공격을 수행하는 시뮬레이션을 해본다. 이를 통해서 아군의 피해 정도를 사전에 파아할 수 있다. 또한 기업은 레드팀을 운영 함으로서 제품이나 프로젝트에서 발생할 여러가지 문제를 사전에 파악할 수 있고 나아가서는 제품의 문제를 먼저 파악하고 수정할 수 있다.
즉 조직에서 이를 적용하여 레드팀을 간단하게 이야기 한다면 무조건 따르는것이 아닌 무언가를 냉철하고 객관적으로 틀린 부분을 이야기 하는 조직이나 사람을 들수 있다. 다만 기술적/정책적으로 문제에 대해서 어떠한 잘못된 부분도 설명하지 못한다면 이는 부정적인 견해일 뿐이며 정확한 사유를 나열하고 프로젝트나 업무에서 레드팀으로서 정확한 문제를 인지하고 이에 대한 문제를 이야기 할 수 있어야 한다.
블루팀은 레드팀과는 반대로 이러한 헛점 혹은 잘못된 점을 방어 하는 역할을 한다. 즉 전쟁에서 모든 지역을 다 완벽하게 방어할 수 없듯이 모든 취약점과 헛점을 보완할 수는 없다. 즉 취약점과 헛점이 있는 것을 얼마나 잘 보완하는 역할을 하는 가의 역할이 블루팀이다.
다만 사이버 보안에서는 레드팀과 블루팀 두가지만으로는 모든 공격과 방어를 예측하고 방어할 수 있는 시대는 끝났다고 생각한다. 아래와 같이 레드/블루가 아닌 다른 색깔의 업무가 함께 융합되어서 이루어 져야만 된다고 생각하며 조금 더 자세한 이야기는 아래에서 다룬다.
레드팀과 블루팀에서 사용할 수 있는 지표는 아래와 같다.
레드팀 지표
MTTC (Mean Time to Compromise) : 공격 시작 시간 부터 목표에 침투를 성공한 시간을 측정 (분단위)
MTTP (Mean Time to Privilege Escalation) : 공격 시작 시간 부터 목표에 대한 관리자 권한을 얻는대까지 걸린 시간을 측정 (분단위)
블루팀 지표
ETTD (Estimated Time to Detection) : 공격을 탐지 하는데까지 소요된 추정 시간
ETTR (Estimated Time to Recovery) : 공격을 복구하는데까지 소요된 추정 시간
1. 레드팀/블루팀 지식 영역
공격자들은 혼자서 공격하기 보다 팀이나 여러명이 공격할 것이며 하나의 서비스에 한개의 팀만이 공격하는 것이 아닐 것이다. 만약 공격자(레드팀)가 가진 IT 지식이 아래와 같다고 한다면 공격자는 WAS와 관련된 부분 이외에는 전 영역에 걸쳐 공격이 가능하다. 그렇다면 방어자(블루팀)의 경우에는 어떠할까 ?
방어자 즉 블루팀의 지식 항목에는 APP과 DB가 제외되어 있다. 즉 모바일 앱을 서비스 하는 기업에서 만약 블루팀에 APP을 하는 사람이 없다면 과연 앱을 역공학을 통해서 분석한 다음 이를 공격한다면 탐지 할 수 있을까 ? 그리고 DB에 대해서 충분한 지식이 없는 사람이라면 과연 어떤 데이터가 DB에서 나갔는지 쿼리만을 보고 알 수 있을까 ? 아마도 알기 힘들거나 알아내는데 많은 시간이 걸릴것이다.
여기서 레드팀은 2-3명의 멤버만으로도 충분히 효과를 거둘수 있다. 하지만 블루팀의 경우에는 한가지 영역만 빠져도 구멍이 될 수 있다. 아무리 다양한 영역을 알고 있는 사람이라도 전체 영역에 대해서 깊게 알기는 힘들다. 그러므로 최소한 각각의 영역에 대해서 기본 지식 이상을 알고 있는 사람으로 블루팀을 구성해야만 위의 모든 공격을 탐지라도 할 수 있을것이다. 즉 레드팀이 2-3명이라면 블루팀은 최소 5-6명 이상으로 구성하는게 좋을거라고 생각한다.
% Ex 실제 오픈소스를 많이 사용하고 있는데 만약 Redis나 Hadoop에 대한 지식이 전혀 없다면 과연 Hadoop의 MapReduce 포트를 외부에 노출하는것이 얼마나 위험한 일인지 바로 알수 있을까 ? 아마도 해킹 사고가 발생한 이후에나 알수 있을것이다.
2. 블루팀의 역할 한계
위에서 레드팀이 헛점을 찾고 이를 공격하는 조직이라고 보았을때 블루팀은 수비수라고 볼수 있고 조직 구성으로 본다면 CERT팀이 될수 있을것이다. 관제팀과 함께 연결되어 동작하는 블루팀은 침해 이벤트의 분석/대응 역할이 주어진다. 하지만 이벤트를 분석/대응 하는 역할에 집중하게 되면 실제로 블루팀이 해야 하는 역할이 약해 질수 있다. 블루팀은 이벤트를 보는 것 이외에도 아래와 같은 역할을 해야 한다.
1. 취약점의 동향 파악 및 분석
2. 침해 탐지를 위한 패턴의 개발
3. 최신 침해 기술의 파악
4. 방어 대상에 대한 최신 기술 파악 및 스킬업
5. 방어를 위한 보안 장비의 운영
블루팀이 방어에만 집중하여 침해가 어떻게 이루어지는지에 대한 최신 동향과 스킬업을 게을리 한다면 당연히 사고는 날 수 밖엔 없다. 이 모든걸 하기 힘들다면 외부 보안 회사의 도움을 받을 수도 있지만 정말 방어 대상에 대한 취약점 정보와 최신 기술에 대한 정보를 제대로 주는 회사는 존재하지 않는다고 생각해도 무방하다.
즉 단순히 블루팀이 모든 공격을 막는 방패가 되고자 한다면 위의 그래프에서 나온 퍼플팀과 그린팀이 되어야만 한다. 물론 레드팀도 마찬가지이다. 해킹이 어떻게 이루어지는지에 대한 교육을 해야 하고 방어를 고려한 공격을 수행하여 어떻게 하면 이를 우회할지를 심각하게 고민하고 공격을 해야 한다.
3. 단기 훈련 목적의 레드팀/블루팀
인력이 많고 적고를 떠나서 당장 레드팀과 블루팀으로 조직을 구성하고 운영하는것은 불가능하고 인력은 10명 남짓의 조직에서 레드팀과 블루팀을 육성해 볼 수 있을까 ? 그에 대한 해답은 아마도 단기적인 훈련으로 레드팀/블루팀을 구성하고 훈련이나 프로젝트를 수행하는것으로도 아주 의미있는 일이 될 수 있다.
아래는 해외 모 사이트의 레드틈/블루팀의 훈련시의 구성시 필요한 부분에 대해서 설명한 글을 번역한 글이다.
-- Red/Blue 대응 훈련 소개 -- (해외 사이트)
(아래는 해외 모 사이트에서 소개하는 자료임을 밝힌다.)
외부에서의 침투 테스트나 모의 훈련시에 Red팀과 Blue팀으로 이를 나누어서 진행할 수 있다.
Red Team은 외부의 공격자 관점으로 공격을 수행하고 Blue팀은 내부의 대응자의 관점에서 대응을 수행한다.
이를 통해서 얻을수 있는 이익은 아래와 같다.
% 얻을수 있는점
침해 대응시의 취약한 부분을 파악할수 있다.
사고 대응의 각 단계에서 침해 대응 프로세스를 향상시킬수 있는 범위를 결정할수 있다;.
차단과 탐지 능력을 향상 시킬수 있는 기회를 확인 할수 있다.
침해 상황에서 보안된 환경으로 복구하기 위한 대응책을 문서화 할수 있다.
% 훈련의 진행
-정찰
Red팀은 훈련대상 인프라를 스캔하고 취약점을 찾으며 Blue팀은 이를 탐지하고 취약한 부분이 있을수 있는 부분을 찾습니다.
-공격
Red팀은 실제 서비스에 공개된 인프라를 손상시키거나 서버에 침투하고자 합니다. Blue팀은 대상자를 식별하고 호스트 및 네트워크 기반 분석을 수행하며 공격의 출처와 대상, 악용 방법, 악성 프로세스 및 권한 있는 엑세스 수준을 식별합니다.
-명령 및 제어
Red팀이 침투를 성공하여 공격 상황이 탐지 된다면 Blue팀은 탐지된 트래픽을 식별하고 다른 잠재적인 공격 지점을 검색하여 공격자의 접근을 포괄적으로 파악합니다.
-운영
Red팀은 권한을 상승시키고 내부 환경에서 엑세스를 확장하고자 하며 이를 통해 사용자 데이터를 유출하고자 합니다. Blue팀은 이러한 공격을 추적하고 공격자의 목표를 평가하고 공격자가 침투할만한 요소를 식별하고 대응합니다. 이를 통해 Blue팀은 조직의 위험을 더 잘 이해하고 향후 실제 공격 발생시 공격 활동을 예측하고 봉쇄 및 치료 전략을 수립할 수 있습니다.
-검토
훈련이 종료된 이후에는 호스트 및 네트워크 기반으로 분석을 수행하고 발생한 공격 내역에 대한 타임 라인을 정리합니다. Red팀은 공격에 대한 기술적인 모든 세부 사항을 제공하며 Blue 팀과 함께 전체 훈련에 대해서 정리합니다.
% 결과물
훈련이 끝나고 난 결과물은 아래의 사항을 포함한다.
-훈련중 사용된 취약점의 요약
-훈련중 사용된 전략, 기술, 절차의 요약
-훈련중에 수행되는 사고 대응과 관련된 관찰 및 권장 사항
-전체 훈련중 팀에서 관찰한 프로세스, 방법론 및 기술 결함에 대한 권장 사항
4. 결론
전통적인 레드팀/블루팀은 이미 한계에 온지 오래다. 최신 오픈소스는 보안인력의 머리를 어지럽히고 마이크로 아키텍쳐는 보안 사고 발생에 대한 데이터 유출 포인트 조차 파악하기 힘들게 만든다. 이를 모두 파악하고 대응하는 보안 조직이 되기 위해서는 레드팀/블루팀을 그 성격을 유지한 상태로 그린과 오렌지, 퍼플로 만들어 나가는 일련의 과정이 필요하다. 회사의 보안 구성을 단순화 시키고 모든것을 한개의 지점으로 만들수 있는 회사라면 쉽게 몇개의 포인트만을 테스트 하거나 방어하여 보안을 최적화 시킬수 있다. 하지만 일반적인 인터넷 기업에서는 이는 불가능하다고 생각된다. 즉 최소의 인력으로 거대한 보안 인프라를 지켜 주세요 라는 말보다는 규모에 맞는 최적의 인력으로 구성한다고 생각하면서 인력을 구성하여 업무를 수행할 수 있도록 고민해 나가는것이 가장 중요하다고 생각된다.
% 본 내용은 개인적인 견해를 서술한 것이며 어떠한 기업이나 기관의 입장이 아닙니다.
참고 자료
https://en.wikipedia.org/wiki/Red_team
http://www.yes24.com/Product/Goods/69669178?scode=032&OzSrank=2
https://www.ablativesecurity.com/single-post/2016/11/30/The-Purple-Team-Pentest
