정보보안 업계에서는 침투 테스트와 버그 바운티, 침투 테스트와 취약점 평가, 레드팀 활동 가운데 무엇을 선택할지, 그리고 신뢰할 수 있는 조언자가 어떤 역할을 해야 하는지를 두고 논의가 이어지고 있다. 각 방식의 차이와 적용 시점을 제대로 이해하는 사람이 너무 적다는 것이 문제다. 이를 영업 탓으로 돌릴 수도 있지만, 문제는 그보다 깊다.

각 개념의 자세한 설명은 보안 평가 유형 안내에서 볼 수 있다. 간단히 정리하면 다음과 같다.

  • 취약점 평가는 가능한 한 많은 결함을 찾아 우선순위가 매겨진 수정 목록을 만드는 방식이다.
  • 침투 테스트는 성숙한 방어 체계가 공격자의 구체적인 목표 달성을 막을 수 있는지 확인한다.
  • 버그 바운티는 여러 참여자가 모이는 이점을 활용해 가능한 한 많은 취약점을 찾는다.
  • 레드팀 활동은 실제 공격자를 흉내 내며 블루팀의 대응 효과를 지속적으로 시험하고 개선한다.
  • 보안 분야의 신뢰할 수 있는 조언자는 조직의 보안 성숙도와 목표를 고려해 그 시점에 어떤 접근을 선택할지 안내해야 한다.

조직 성숙도에 맞는 평가

어떤 보안 평가를 언제 할지 정할 때 가장 중요한 요소는 해당 조직의 성숙도다. 여기서 성숙도란 회사가 보안 패치를 적용했는지, 보유 자산과 접근 권한자 및 마지막 권한 검토 시점을 파악하고 있는지, 데이터의 위치와 보호 방법을 알고 있는지, 업무 과정에서 데이터가 환경 안을 어떻게 이동하는지 알고 있는지를 뜻한다.

이 질문들에 ‘아니요’라고 답한다면 성숙도가 낮을 가능성이 크다. 이런 조직은 하이브리드 클라우드나 여러 외부 참여자를 동원하는 레드팀 평가를 고민하기보다 기본부터 챙겨야 한다. 보유 자산을 목록으로 만들고 보안 패치를 적용하는 일이 먼저다.

중간 수준의 성숙도에 도달해 보안 평가를 시작할 준비가 됐다고 가정하면, 다음 순서로 접근할 수 있다.

  • 먼저 신뢰할 수 있는 조언자를 둔다. 내부 인력이든 외부 인력이든 크게 중요하지 않지만, 질문에 빠르게 답하고 보안 전략을 세워 계획대로 진행하도록 도울 사람이 필요하다.
  • 가장 먼저 할 평가는 취약점 평가다. 성숙한 방어를 시험하기보다 보안 체계를 갖추기 위해 무엇을 고쳐야 하는지, 어떤 순서로 수정해야 하는지 우선순위 목록을 제공하기 때문이다. 성숙도가 가장 낮은 회사에 적합한 평가 방식이다.
  • 취약점 평가를 한 번 이상 진행하고 발견된 문제를 모두 수정한 뒤 침투 테스트로 넘어간다. 문제를 고치지 않으면 평가에 많은 비용을 쓰고도 낭비하는 셈이다. 이 단계에서는 신뢰할 수 있는 외부 업체나 내부 조직이 테스트를 맡을 수 있다. 다만 아직 내부 조직이 없다면 신뢰할 만한 외부 업체를 이용하는 편이 나을 수 있다. 이 시점에 발견될 문제는 심각하고 조직에 당혹스러울 수 있기 때문이다.
  • 취약점 평가와 침투 테스트를 여러 차례 진행한 뒤에도 발견되는 문제가 적다면 다음 단계를 검토할 수 있다. 더 많은 취약점을 찾고 싶고, 테스트 대상이 소스 코드 검토나 사설 네트워크, 핵심 자산처럼 지나치게 민감하지 않다면 버그 바운티를 고려할 수 있다. 규모와 운영 방식이 적절한 참여자 집단은 여러 사람의 시선으로만 발견할 수 있는 추가 취약점을 찾기도 한다. 다만 무엇을 대상으로 삼을지 신중하게 정하고 프로그램을 면밀히 관리해야 한다.
  • 침투 테스트를 시작한 뒤, 또는 침투 테스트와 병행해 레드팀 활동도 검토할 수 있다. 레드팀은 실제 공격자를 모방하는 지속적인 캠페인이다. 제대로 운영하려면 평가 대상 조직으로부터 상당한 독립성을 유지하고, 최신 지식과 숙련도를 갖추며, 효과를 유지하도록 도구와 기법을 계속 발전시켜야 한다. 레드팀의 목적은 블루팀을 개선하는 것이다. 이는 취약점 평가, 침투 테스트, 버그 바운티의 목표와 다르다.

선택할 때 고려할 점

신뢰할 수 있는 조언자나 조언 업체를 두고 조직의 성숙도에 따라 보안 평가를 안내받는 것이 좋다. 보통은 취약점 평가로 시작해 발견한 문제를 충분히 수정해야 한다. 환경에서 문제를 찾기 어려워질 때까지 다른 종류의 테스트를 시작하지 않는 편이 낫다. 그다음 신뢰할 수 있는 업체와 침투 테스트를 진행한다.

신뢰할 수 있는 업체의 침투 테스트에서 더 이상 문제가 거의 발견되지 않는다면, 여러 참여자의 시선을 활용하는 버그 바운티를 고려할 수 있다. 취약점 평가 단계가 끝나고 침투 테스트 단계로 넘어갈 때부터 레드팀 활동도 알아볼 수 있다. 적합한 레드팀을 조사하고 찾는 데 시간이 걸리기 때문이다. 레드팀은 ‘더 나은 침투 테스트’가 아니라 목표가 다른 별도의 평가 방식이다.

신뢰할 수 있는 조언자가 이 모든 과정을 이끌도록 해야 한다. 무엇을 언제 어떻게 할지에는 여러 변수가 있다. 이 안내는 시작을 돕기 위한 것이다.

경영진이 보안 문제를 인정하고 예산을 배정하도록 침투 테스트를 먼저 받아야 하는 경우도 있다. 하지만 보안 예산을 받으려면 큰 사고가 필요할 정도로 경영진의 이해가 부족하다면, 이후 과정에서도 훨씬 더 많은 갈등을 겪을 수 있다는 점을 알아둬야 한다.

효과적인 기업 레드팀에 관해서는 관련 글에서 다룬다. 글의 관점과 관련해, 글쓴이는 ‘신뢰할 수 있는 조언자’ 또는 ‘신뢰할 수 있는 침투 테스트 업체’ 범주에 해당하는 전문 침투 테스트 회사에서 일한다고 밝힌다.

가장 민감한 자산인 소스 코드, 사설 네트워크, 핵심 방어 영역을 여러 참여자에게 공개해 살펴보게 해서는 안 되는 상황만 있는 것은 아니다. 다만 여러 참여자가 취약점을 찾는 이점과 함께 신뢰 문제가 생길 수 있으므로, 적어도 현재 업계 상황에서는 이런 결정을 신중하게 내려야 한다.

침투 테스트는 취약점 평가보다 ‘더 나은’ 방식이 아니라 전혀 다른 평가다. 레드팀도 침투 테스트보다 ‘더 나은’ 방식이 아니라 목표가 다른 평가다.

버그 바운티는 가능한 한 많은 문제를 찾는다는 점에서 취약점 평가와 가장 비슷하다. 다만 성숙도가 낮아 결함을 쉽게 찾을 수 있는 환경에서 비용을 낭비하지 않는다는 점에서 더 높은 성숙도에 적합하다. 성숙도가 낮은 환경에 여러 참여자를 투입하면 신뢰 문제가 생길 수도 있다. 검증된 참여자만 초대하는 비공개 바운티를 활용할 수는 있지만, 초기 취약점 평가는 내부 인력이나 신뢰할 수 있는 자원으로 진행하고 성숙도가 높아져 추가 문제를 찾기 어려워진 뒤 바운티를 이용하는 편이 나을 수 있다.

신뢰할 수 있는 조언자 역할이 중요한 이유는 발견된 문제를 사업 목표에 맞춰 해석하고 활동의 우선순위를 정하는 데 도움을 주기 때문이다. 조언자 없이 평가를 진행하면 잘못된 문제에 많은 노력을 쓰면서도 위험을 충분히 줄이지 못할 수 있다. 보유 자원에 비해 고쳐야 할 문제는 늘 많으므로, 핵심은 어디에 집중할지 정하는 데 있다.