2019.11.14

성공적인 레드 팀 운용을 위한 5가지 조언

Roger A. Grimes | CSO
필자는 레드 팀을 적극적으로 지지한다. 그러나 레드 팀은 뛰어난 실력에 대한 과시욕 탓에 본래의 임무, 즉 조직이 사이버보안 위험을 낮추도록 돕는 일을 망각하는 경우가 많다.

레드 팀은 조직의 컴퓨터 자산을 해킹해서 방어선에 존재하는 약점을 드러내는 역할을 하는 직원 또는 계약업체다. 필자가 30년 이상 일해오면서 가장 즐거웠던 때는 레드 팀원으로 다른 회사의 네트워크에 침입하면서 돈을 벌 때였다. 지금은 그 일을 하지 않지만 프레젠테이션을 위한 사실적인 해킹 데모를 만들면서 소소한 재미를 느끼곤 한다. 필자는 돈을 받고도 침입하지 못하면 어떻게 하나 늘 걱정했지만 항상 침입에 성공했다. 사용할 툴과 기법만 알면 해킹은 비교적 쉽다. 보통 해커를 대단한 천재라고 생각하지만 배관공, 전기 기술자와 마찬가지로 그 분야에 숙련된 사람들일 뿐이다.

모든 조직은 환경과 애플리케이션/서비스/사이트를 대상으로 정기적인 레드 팀 훈련을 실시해야 한다. 훈련 빈도는 조직이 결정할 일이지만 연 1~2회도 되지 않는다면 문제가 있다. 아예 하지 않는 조직이라면 미처 모르는 다수의 취약점이 존재할 가능성이 높다.

레드 팀은 윤리적이고 전문적이어야 하며 발견한 모든 취약점을 문서화해서 전달해야 한다. 성공적인 레드 팀 운용을 위한 필자의 조언은 다음과 같다.

1. 레드 팀은 발견한 모든 중요 사항을 최고 부서 책임자에게 보고해야 함
레드 팀은 최고 부서 책임자에게 직접 보고할 수 있어야 한다. IT 관리자, CSO, CISO, CIO에게 직접 보고하는 것도 괜찮지만 보고 결과에 따라 일자리가 좌우되는 사람들이 보고서에 영향을 미치도록 해서는 안 된다.

레드 팀이 발견한 모든 사항은 CEO 또는 이사회에도 전달되어야 하는데, 이 과정에서 CEO나 이사회의 직속 부하에 의해 보고서 내용이 변경되면 안 된다. 필자는 당황스러운 세부 사항이 상부에 보고되는 것을 원치 않는 레드 팀 책임자가 보고서에서 중요한 내용을 죄다 빼는 모습을 많이 봤다. 이렇게 해서 가짜 “정상 증명서”로 변질된 레드 팀 보고서가 경영진에게 전달된다.

심각한 취약점을 발견하고 수정한 다음(가끔 수정하지 않고도) 보고서에서 삭제하는 경우가 많다. 고위 경영진이라면 중간 관리자들이 놓친 것을 알아야 한다. 항상 완벽해 보이도록 조작된 보고서를 받아 보기를 원하지는 않을 것이다. 누구나 놓치는 것이 있다. 받아본 레드 팀 보고서가 너무 깨끗해서 진실인지 의심된다면 보고 과정에 대해 더 자세히 알아보라.

필자는 최종 보고서에 넣을 것과 뺄 것을 CSO가 “협상하는” 레드 팀에서 일한 적이 있는데, 우리 팀이 받는 보상, 또는 다음에 우리 팀이 다시 고용될지 여부는 실제 작업 내용보다는 이 CSO를 유능하게 보이도록 하는 데 달려 있었다. 고양이에게 생선을 맡기면 안 된다.

2. 외부 레드 팀이 필요
내부 레드 팀이 있더라도 외부 업체와 계약해서 방어선 침투를 맡겨봐야 한다. 많은 기업은 내부 팀으로만 모든 해킹을 하는데, 이것으로는 충분하지 않다. 내부 팀은 틀에 박힌 방식으로 특정 방법에만 집중하며 나머지는 무시한다. 내부 레드 팀은 아무리 유능하다 해도 일반적으로 회사 내의 조직과 정치에 발목이 잡힌다. 더 많은 것을 하려는 의지가 있어도 결국 상부의 누군가에게 끌려 그들이 원하는 일에만 집중하게 되는 경우가 많다.

가장 좋은 것은 내부와 외부 레드 팀을 모두 운용하는 것이다. 내부 팀은 전면적인 침투를 실시한다. 외부 팀은 일년에 몇 차례 방문해서 해킹 방법과 대상을 자유롭게 선택해 실제 악의적인 외부 해커 역할을 한다. 물론 외부 팀의 활동 범위를 규정해야 하지만, 실제 악의적 해커처럼 해킹하지 못할 정도로 인위적으로, 부자연스럽게 제한해서는 안 된다.

3. 침투 테스터는 실제 해커처럼 해킹해야 함
레드 팀의 가장 큰 문제 중 하나는 멋지고 “폼 나는” 방법을 사용한 해킹에 많은 시간을 소비한다는 점이다. 이렇게 해서는 실제 해커가 침투하는 방식과는 거리가 멀다. 대부분의 레드 팀에는 항상 성공적인 침투를 이끄는 똑똑하고 창의적인 해커가 한 명 이상 있다. 이들은 일반적으로 나머지 팀원보다, 그리고 더 중요하게는 방어하는 사람들보다 훨씬 더 많은 지식을 갖춘 검증된 리더들이다. 이들은 자주 사용하는 기법과 툴은 실제 해커들 사이에서는 별 인기가 없는 것들이다. 결국 레드 팀 훈련을 실시하는 가장 큰 이유를 놓치는 셈이다.

레드 팀의 주 목표를 성공적인 침투에 둬서는 안 된다. 물론 침투도 좋다. 누구나 항상 고쳐야 할 취약점을 알고 싶어한다. 그러나 레드 팀의 가장 큰 가치는 이들이 대부분의 실제 해커들이 사용하는 것과 같은 방법으로 해킹할 때 얻을 수 있다. 레드 팀의 역할은 해커들이 실제로 사용하는 ‘따기 쉬운 과일’을 찾음으로써 사이버보안 위험을 낮추도록 돕는 것이다. 모든 레드 팀은 악용될 가능성이 가장 높은 틈을 막도록 돕는데 초점을 맞춰야 한다. 다른 모든 것은 그 다음의 일이다.

4. 범위를 잘 정의하기
레드 팀의 활동 범위를 명확히 정의해야 한다. 몇 달 전 미국 아이오와 주 법원에 침투하려던 침투 테스터들이 체포된 사건을 들어봤을 것이다. 규정된 범위가 모호했으며 침투 테스터들은 허락된 수준을 넘어섰던 것으로 보인다. 레드 팀과 이들의 소속 기업은 해커들의 물리적인 침입 시도가 작업 범위에 포함됐다고 주장하지만 아이오와 법원 관리팀과 사법부의 생각은 다르다.

어느 쪽이든 레드 팀 침투 테스터들이 회사가 작업 범위에 있다고 알려준 작업을 하다가 체포된다면 최소한 범위가 제대로 정의되지 않았다는 뜻이다. 범위를 정하는 작업은 지루할 수 있지만 모두가 만족하기 위해서는 제대로 해야 한다.

5. 레드 팀과 블루 팀의 조합
레드 팀이 활동할 때는 항상 블루 팀도 함께 운용해야 한다. 블루 팀은 레드 팀의 공격을 방어하는 팀이다. 블루 팀은 로그 파일을 감시하고 레드 팀 활동에 대한 경보가 울리기를 기다린다. 레드 팀이 성공적으로 침입하는 사이 블루 팀이 확실한 신호나 경보를 받지 못한다면 방어를 더 강화해야 한다.


외부 코드 검토 필요

모든 조직에 외부 레드 팀이 필요한 것과 마찬가지로 조직의 소프트웨어/서비스/사이트를 위한 핵심 코드에는 철저한 검토가 필요하다. 이 프로세스의 첫 단계로 내부 개발 팀이 자체 코드를 검토해야 한다. 프로그래머 수가 많다면 서로 다른 프로그래머의 코드에서 보안 버그를 검토하도록 한다.

코드에서 보안 버그를 검토하는 소프트웨어를 사용하면 큰 도움이 되며, 직접 또는 이 소프트웨어를 사용해서 코드 버그를 찾는 전담 직원을 두면 조직의 맞춤 코드에서 버그를 줄일 수 있다. 레드 팀과 마찬가지로 외부 코드 검토를 통해 내부 팀이나 소프트웨어가 놓치는 부분을 포착해야 한다.

조직에는 레드 팀이 필요하다. 또한 이들이 외부의 실제 악의적인 해커처럼 해킹하도록 허용해야 한다. 레드 팀이 역할을 잘 한다면 조직에서 가장 악용될 가능성이 큰 빈틈을 막는 데 도움이 된다. 그게 핵심이고, 나머지는 모두 부차적인 요소들이다. editor@itworld.co.kr 


2019.11.14

성공적인 레드 팀 운용을 위한 5가지 조언

Roger A. Grimes | CSO
필자는 레드 팀을 적극적으로 지지한다. 그러나 레드 팀은 뛰어난 실력에 대한 과시욕 탓에 본래의 임무, 즉 조직이 사이버보안 위험을 낮추도록 돕는 일을 망각하는 경우가 많다.

레드 팀은 조직의 컴퓨터 자산을 해킹해서 방어선에 존재하는 약점을 드러내는 역할을 하는 직원 또는 계약업체다. 필자가 30년 이상 일해오면서 가장 즐거웠던 때는 레드 팀원으로 다른 회사의 네트워크에 침입하면서 돈을 벌 때였다. 지금은 그 일을 하지 않지만 프레젠테이션을 위한 사실적인 해킹 데모를 만들면서 소소한 재미를 느끼곤 한다. 필자는 돈을 받고도 침입하지 못하면 어떻게 하나 늘 걱정했지만 항상 침입에 성공했다. 사용할 툴과 기법만 알면 해킹은 비교적 쉽다. 보통 해커를 대단한 천재라고 생각하지만 배관공, 전기 기술자와 마찬가지로 그 분야에 숙련된 사람들일 뿐이다.

모든 조직은 환경과 애플리케이션/서비스/사이트를 대상으로 정기적인 레드 팀 훈련을 실시해야 한다. 훈련 빈도는 조직이 결정할 일이지만 연 1~2회도 되지 않는다면 문제가 있다. 아예 하지 않는 조직이라면 미처 모르는 다수의 취약점이 존재할 가능성이 높다.

레드 팀은 윤리적이고 전문적이어야 하며 발견한 모든 취약점을 문서화해서 전달해야 한다. 성공적인 레드 팀 운용을 위한 필자의 조언은 다음과 같다.

1. 레드 팀은 발견한 모든 중요 사항을 최고 부서 책임자에게 보고해야 함
레드 팀은 최고 부서 책임자에게 직접 보고할 수 있어야 한다. IT 관리자, CSO, CISO, CIO에게 직접 보고하는 것도 괜찮지만 보고 결과에 따라 일자리가 좌우되는 사람들이 보고서에 영향을 미치도록 해서는 안 된다.

레드 팀이 발견한 모든 사항은 CEO 또는 이사회에도 전달되어야 하는데, 이 과정에서 CEO나 이사회의 직속 부하에 의해 보고서 내용이 변경되면 안 된다. 필자는 당황스러운 세부 사항이 상부에 보고되는 것을 원치 않는 레드 팀 책임자가 보고서에서 중요한 내용을 죄다 빼는 모습을 많이 봤다. 이렇게 해서 가짜 “정상 증명서”로 변질된 레드 팀 보고서가 경영진에게 전달된다.

심각한 취약점을 발견하고 수정한 다음(가끔 수정하지 않고도) 보고서에서 삭제하는 경우가 많다. 고위 경영진이라면 중간 관리자들이 놓친 것을 알아야 한다. 항상 완벽해 보이도록 조작된 보고서를 받아 보기를 원하지는 않을 것이다. 누구나 놓치는 것이 있다. 받아본 레드 팀 보고서가 너무 깨끗해서 진실인지 의심된다면 보고 과정에 대해 더 자세히 알아보라.

필자는 최종 보고서에 넣을 것과 뺄 것을 CSO가 “협상하는” 레드 팀에서 일한 적이 있는데, 우리 팀이 받는 보상, 또는 다음에 우리 팀이 다시 고용될지 여부는 실제 작업 내용보다는 이 CSO를 유능하게 보이도록 하는 데 달려 있었다. 고양이에게 생선을 맡기면 안 된다.

2. 외부 레드 팀이 필요
내부 레드 팀이 있더라도 외부 업체와 계약해서 방어선 침투를 맡겨봐야 한다. 많은 기업은 내부 팀으로만 모든 해킹을 하는데, 이것으로는 충분하지 않다. 내부 팀은 틀에 박힌 방식으로 특정 방법에만 집중하며 나머지는 무시한다. 내부 레드 팀은 아무리 유능하다 해도 일반적으로 회사 내의 조직과 정치에 발목이 잡힌다. 더 많은 것을 하려는 의지가 있어도 결국 상부의 누군가에게 끌려 그들이 원하는 일에만 집중하게 되는 경우가 많다.

가장 좋은 것은 내부와 외부 레드 팀을 모두 운용하는 것이다. 내부 팀은 전면적인 침투를 실시한다. 외부 팀은 일년에 몇 차례 방문해서 해킹 방법과 대상을 자유롭게 선택해 실제 악의적인 외부 해커 역할을 한다. 물론 외부 팀의 활동 범위를 규정해야 하지만, 실제 악의적 해커처럼 해킹하지 못할 정도로 인위적으로, 부자연스럽게 제한해서는 안 된다.

3. 침투 테스터는 실제 해커처럼 해킹해야 함
레드 팀의 가장 큰 문제 중 하나는 멋지고 “폼 나는” 방법을 사용한 해킹에 많은 시간을 소비한다는 점이다. 이렇게 해서는 실제 해커가 침투하는 방식과는 거리가 멀다. 대부분의 레드 팀에는 항상 성공적인 침투를 이끄는 똑똑하고 창의적인 해커가 한 명 이상 있다. 이들은 일반적으로 나머지 팀원보다, 그리고 더 중요하게는 방어하는 사람들보다 훨씬 더 많은 지식을 갖춘 검증된 리더들이다. 이들은 자주 사용하는 기법과 툴은 실제 해커들 사이에서는 별 인기가 없는 것들이다. 결국 레드 팀 훈련을 실시하는 가장 큰 이유를 놓치는 셈이다.

레드 팀의 주 목표를 성공적인 침투에 둬서는 안 된다. 물론 침투도 좋다. 누구나 항상 고쳐야 할 취약점을 알고 싶어한다. 그러나 레드 팀의 가장 큰 가치는 이들이 대부분의 실제 해커들이 사용하는 것과 같은 방법으로 해킹할 때 얻을 수 있다. 레드 팀의 역할은 해커들이 실제로 사용하는 ‘따기 쉬운 과일’을 찾음으로써 사이버보안 위험을 낮추도록 돕는 것이다. 모든 레드 팀은 악용될 가능성이 가장 높은 틈을 막도록 돕는데 초점을 맞춰야 한다. 다른 모든 것은 그 다음의 일이다.

4. 범위를 잘 정의하기
레드 팀의 활동 범위를 명확히 정의해야 한다. 몇 달 전 미국 아이오와 주 법원에 침투하려던 침투 테스터들이 체포된 사건을 들어봤을 것이다. 규정된 범위가 모호했으며 침투 테스터들은 허락된 수준을 넘어섰던 것으로 보인다. 레드 팀과 이들의 소속 기업은 해커들의 물리적인 침입 시도가 작업 범위에 포함됐다고 주장하지만 아이오와 법원 관리팀과 사법부의 생각은 다르다.

어느 쪽이든 레드 팀 침투 테스터들이 회사가 작업 범위에 있다고 알려준 작업을 하다가 체포된다면 최소한 범위가 제대로 정의되지 않았다는 뜻이다. 범위를 정하는 작업은 지루할 수 있지만 모두가 만족하기 위해서는 제대로 해야 한다.

5. 레드 팀과 블루 팀의 조합
레드 팀이 활동할 때는 항상 블루 팀도 함께 운용해야 한다. 블루 팀은 레드 팀의 공격을 방어하는 팀이다. 블루 팀은 로그 파일을 감시하고 레드 팀 활동에 대한 경보가 울리기를 기다린다. 레드 팀이 성공적으로 침입하는 사이 블루 팀이 확실한 신호나 경보를 받지 못한다면 방어를 더 강화해야 한다.


외부 코드 검토 필요

모든 조직에 외부 레드 팀이 필요한 것과 마찬가지로 조직의 소프트웨어/서비스/사이트를 위한 핵심 코드에는 철저한 검토가 필요하다. 이 프로세스의 첫 단계로 내부 개발 팀이 자체 코드를 검토해야 한다. 프로그래머 수가 많다면 서로 다른 프로그래머의 코드에서 보안 버그를 검토하도록 한다.

코드에서 보안 버그를 검토하는 소프트웨어를 사용하면 큰 도움이 되며, 직접 또는 이 소프트웨어를 사용해서 코드 버그를 찾는 전담 직원을 두면 조직의 맞춤 코드에서 버그를 줄일 수 있다. 레드 팀과 마찬가지로 외부 코드 검토를 통해 내부 팀이나 소프트웨어가 놓치는 부분을 포착해야 한다.

조직에는 레드 팀이 필요하다. 또한 이들이 외부의 실제 악의적인 해커처럼 해킹하도록 허용해야 한다. 레드 팀이 역할을 잘 한다면 조직에서 가장 악용될 가능성이 큰 빈틈을 막는 데 도움이 된다. 그게 핵심이고, 나머지는 모두 부차적인 요소들이다. editor@itworld.co.kr 


X