금융보안원에서 발간한 금융분야 침투테스트(모의해킹) 수행 가이드라인에 명시되어 있는 점검과 관련한 용어들을 정리해보며 침투테스트에 대한 제 생각을 정리했습니다.
용어 정리
취약점 분석평가, 모의해킹, 침투테스트, 레드티밍와 관련하여 유사한 개념이 혼용되고 있어 용어를 정리했습니다.
| 구분 | 취약점 분석평가 (Vulnerability Assessment) | 침투테스트 (Penetration Testing) | 레드티밍 (Red Teaming) |
|---|---|---|---|
| 수행 목적 | 취약점 목록 도출, 기준 준수 확인 | 실제 침투 가능성 입증 | 위협 행위자 기반 사이버 복원력 검증 |
| 점검 목표 | 전자금융기반시설 | 핵심·중요 서비스 및 자산 | 핵심·중요 서비스 및 자산 |
| 공격 허용 범위 | 전자금융기반시설 | IT 인프라 전체 | IT 인프라 외 인력·시설 등 기업의 모든 유·무형 자산 |
| 블루팀 인지 | 전체 공지 | 일부 공지 또는 비공지 가능 | 원칙적 비공지 |
| 수행 기간 | 수일~수주 | 평균 1~2개월 이상 | 3개월 이상 |
| 수행 방식 | 체크리스트 항목별 점검 | 공격 단계 구성 후 시나리오 수행 | 위협 정보 기반 시나리오 수행 |
| 결과물 | 항목별 양호·취약 목록 | 침투 경로 중심 보고서, 영향도 분석 | 위협 시나리오별 방어력 평가 보고서 |
취약점 분석 평가
흔히 아는 체크리스트 기반으로 취약/양호 판단하는 것으로 보안 기준 준수를 확인하는데 효과적이며 금융회사가 전자금융감독규정으로 필수로 해야하는 업무입니다.
여러 취약점을 이용하여 실제 자산에 침투하거나, 정보를 탈취하는 가능성을 입증하는 것은 모의해킹(침투테스트) 영역입니다.
침투테스트(모의해킹,모의침투)
IT인프라에 대한 침투 가능성을 입증하는 목표지향적 점검 방식입니다.
단순 취약점 도출 뿐만 아니라 초기침투 -> 내부 확산 -> 핵심 자산 접근과 같이 공격 흐름을 재현하는 것이 핵심입니다.
현재 제가 하고 있는 업무로 자체적인 침투테스트를 하거나, 오펜시브 회사(금융보안원)를 통해 수행하고 있습니다.
레드티밍
실제 위협 행위자(APT 그룹 등) 전술,기법,절차(TTP)를 기반으로 고도화된 공격시나리오를 장기간에 걸쳐 수행하는 방식입니다.
실제 공격자의 행위를 최대한 재현하며, 레드티밍은 사이버 복원력 검증을 목적으로 하며, 침투테스트 보다 기간과 비용이 상당히 높습니다.
다만 현재 국내 금융권에서는 침투테스트 내실화과 우선 과제입니다.
Conclusion
현재 침투테스트(모의해킹) 업무를 하면서 느끼는 생각은 몇년이 지나도 침투테스트/레드티밍은 국내 금융권에서는 활발하게 작동하기는 어려울꺼 같습니다. ( 제 주관적인 생각입니다.. )
핵심 중요서비스 및 자산에 침투를 해야하는데 담당자들이 가장 먼저 불안해하는게 바로 가용성 문제입니다.
가용성을 최대한 지키면서 점검을 하려면 연속성 확보가 제일 중요합니다.
연속성 확보란 침투테스트 수행팀에게 제한적인 정보 또는 접근 권한을 예외적으로 제공하는 조치를 말합니다.
ex) 탐지/차단으로 거점 소실, 시간 제약 또는 운영 안정성 사유로 다음 공격 단계 검증이 곤란한 경우 활용할 수 있음
예시로 이미 서버를 장악하여 계정 확보 했을때 해당 계정으로 이어서 점검이 진행되어야 하나, 만일 운영상 안정성 이슈가 있을 경우 동일한 권한의 테스트 계정을 전달 받아 진행해야 합니다.
그러나 테스트 계정을 발급하고 관리하는 주체는 인프라/IT/현업/보안등 각기 다른 부서에서 담당하고 있습니다. 부서에서는 자기들이 관리하는 서버에 문제가 있다는 사실을 충분히 이해하지 않으려고 하고, 해당 과정에서 각 부서와 긴밀한 협조가 되어야하나 금융업계 특성 상 굉장히 수직적인 구조이기 때문에 굉장히 어렵습니다.
블랙박스 점검이라면서 테스트 제공이 어려우니 직접 뚫으셔라, 운영상 테스트 계정 발급 못해드리지만 가용성 문제가 있을 수도 있으니 점검 멈춰라, 장애나면 책임질꺼냐, 이미 뚫었는데 왜 추가로 뭐할려고 하시냐, 왜 몰래하냐 공지어딨냐, 점검 기간 내 갑자기 잠수함 패치 등등 별의별 소리를 듣습니다.
침투테스트 업무를 하면서 최대한 가용성을 훼손하지 않으려고 하지만 같은 회사 사람들에게 불만과 항의가 들어오면 마음이 좋지 않습니다.
저도 다른 회사보다 안전한 회사를 만들겠다고 나름대로 노력하지만 돌아오는 반응과 업무 스트레스를 생각하면 그냥 안뚫렸다고 보고하는게 더 낫겠다라는 생각이 많이 듭니다.
물론 장애가 발생하면 금감원에 보고하도록 되어있고 뉴스 기사로 도배가 될텐데 담당자 또한 책임에서 자유롭지는 못할테니 그분들의 입장도 이해가됩니다. ( AI 보안위협과 관련하여 면피 조항이 있긴 하지만 이런걸로 면피가 될까?………. )
취약점을 찾는 과정도 문제지만 취약점을 조치하는 과정이 더 어렵습니다.
내부 확산 단계에서 아마도 문제가 되는 부분이 나온다면 이는 조치가 사실상 불가능할 것으로 생각합니다.
왜냐하면 망분리가 있기 때문에 초기침투 시발점이 되는 DMZ 서버와 연결된 WAS 쪽만 고치면 되는거 아니야? 라는 생각이 퍼져있습니다.
또한 고치기 위해 영향도 파악, 예산, 인력등 많은 리소스가 필요하지만 회사에서는 실제로 일어나지도 않은 행위에 대해서 적극적인 지원이 기대하긴 어렵습니다. (아마 동종업계가 사고나면 지원해줄지도?)
이제는 상시평가에서도 침투테스트를 하게끔 신설되었고, ISMS-P 기술심사에서도 모의침투 시험이 도입되어 앞으로 많이 감독기관, 인증기관등에서 지속적으로 자료를 요구할텐데 벌써부터 머리가 어지럽습니다. ( 이런 고칠 수 없는 여러 이유들을 과연 이해해줄까?? 만일 위험수용을 한다면 L카드사 징계 건을 보고도 정보보안에서 이를 위험수용 할 수 있을까? )