침투 테스트
침투 테스트(간단히 말해 침투 테스트)는 적보다 먼저 취약점을 찾기 위해 조직의 시스템에 대한 공격을 승인받은 시뮬레이션입니다. 이 분야는 네트워크에 침입하는 영리한 개인에서 방법론 프레임워크, 인증 및 규제 인식을 갖춘 구조화된 산업으로 성숙해졌습니다. 실제 펜 테스트가 어떤 모습인지 이해하면 그 가치와 한계가 명확해집니다.
전체 기사 본문은 아래에 영어로 제공됩니다.
침투 테스트는 보안 약점을 식별하기 위해 조직의 시스템을 손상시키려는 인증된 관행입니다. 침투 테스터는 허용되는 범위, 제한되지 않는 범위, 보고 유형에 따른 서면 계약에 따라 운영됩니다. 좋은 의도가 있더라도 무단 테스트는 대부분의 관할권에서 컴퓨터 사기 형태의 범죄 활동입니다.
펜 테스트 단계
- Scoping. 범위 내에 있는 것(특정 네트워크, 애플리케이션, 기간), 그렇지 않은 것(생산에 중요한 시스템, 타사 데이터), 허용되는 기술(사회 공학 예/아니요, DoS 예/아니요)을 정의합니다. 서면으로 문서화되었습니다.
- Reconnaissance. 정보 수집. OSINT, 네트워크 매핑, 포트 검색, 서비스 식별.
- 취약점 식별. 알려진 취약점 검색, 사용자 지정 애플리케이션 논리 검사, 잘못된 구성 식별.
- Exploitation. 취약점이 악용될 수 있음을 입증하려고 시도합니다. "이것은 나쁠 수 있습니다"뿐만 아니라 "이것이 바로 공격자가 수행하는 작업입니다."
- Post-exploitation. 초기 액세스 권한을 얻은 후 공격자가 할 수 있는 작업(측면 이동, 데이터 액세스, 권한 상승)을 탐색합니다. 테스트 목표가 충족되면 중지됩니다.
- Reporting. 재현 단계, 심각도 등급, 수정 권장 사항이 포함된 자세한 결과.
- Re-test. 조직이 결과를 처리할 시간을 가진 후 작업을 수정하는 검증.
Common 테스트 카테고리
- 외부 침투 테스트. 공용 인터넷에서 조직을 공격합니다. 외부인이 무엇을 보고, 스캔하고, 악용할 수 있습니까?
- 내부 침투 테스트. 초기 기반을 확보합니다(보안 침해된 직원 노트북, 악의적인 내부자). 공격자는 여기에서 무엇에 도달할 수 있습니까?
- 웹 애플리케이션 테스트. 특정 앱에 집중 — SQL 주입, XSS, 비즈니스 로직 결함, 인증 약점.
- 모바일 애플리케이션 테스트. 리버스 엔지니어링 APK/IPA, 런타임 조작, API 악용.
- API 침투 테스트. API 계층에 초점 — 인증 결함, 데이터 노출, 속도 제한 우회.
- Cloud 구성 평가. AWS/Azure/GCP 관련 잘못된 구성 — 노출된 S3 버킷, 과도한 허용 IAM, 공개 Lambda.
- 무선 평가. Wi-Fi 보안 테스트.
- 물리적 침투 테스트. 물리적 접근 시도 - 뒤쫓기, 자물쇠 따기, 리셉션에서 사회 공학.
- 사회 공학 평가. 피싱 캠페인, 비싱, 직원 조작 시도.
블랙 박스 vs 회색 상자 vs 흰색 box
- 블랙박스. 테스터는 외부 공격자가 무엇을 할 것인지만 알고 있습니다. 현실적이지만 느림.
- 회색 상자. 제한된 정보 제공(계정 자격 증명, 네트워크 다이어그램). 실제로 가장 일반적입니다.
- 흰색 상자. 소스 코드, 아키텍처 문서, 관리자 자격 증명을 포함한 전체 액세스입니다. 가장 철저한; 자동화된 도구 및 외부 테스트에서 놓칠 수 있는 문제를 찾아냅니다.
방법론 프레임워크
- OWASP 웹 보안 테스트 가이드. 웹 애플리케이션 테스트를 위한 종합 프레임워크.
- NIST SP 800-115. 미국 정부 보안 기술 가이드 테스트.
- OSSTMM. 오픈 소스 보안 테스트 방법론 매뉴얼.
- PTES. 침투 테스트 실행 표준.
- MITRE ATT&CK. 그 자체로는 방법론이 아니라 레드팀 운영에 많이 사용되는 전술-기술-절차 프레임워크입니다.
거래 도구
- Reconnaissance: nmap, Masscan, Shodan, theHarvester, Recon-ng
- 웹 테스트: Burp Suite(산업 표준), OWASP ZAP, sqlmap
- Exploitation 프레임워크: Metasploit, Cobalt Strike(레드팀 표준), Empire, Sliver
- 무선: Aircrack-ng, Wifite, hcxdumptool
- Password 공격: Hashcat, John the Ripper
- 운영 체제: Kali Linux 많은 도구를 번들로 제공하는 표준 배포판입니다.
Pen 테스트와 취약점 검색
종종 혼란스럽습니다. 중요한 차이점:
- Vulnerability scan — 알려진 문제를 나열하는 자동화된 도구입니다. 저렴하고 빠르며 매주 실행할 수 있습니다. 비즈니스 로직 결함, 연결된 취약점, 소셜 엔지니어링 벡터를 놓칩니다.
- 침투 테스트 — 창의적인 방법을 사용하는 인간 테스터입니다. 비용이 많이 들고 시간이 많이 소요되며 스캐너가 놓친 문제를 찾아냅니다. 일반적으로 연간 또는 반년마다 실행됩니다.
성숙한 보안 프로그램은 지속적인 적용 범위를 위한 자동 스캔과 심도에 대한 주기적인 펜 테스트를 모두 사용합니다.
인증
- OSCP(공격적 보안 인증 전문가) — 실용적인 표준입니다. 취약한 랩에 대한 24시간 실습 시험.
- OSCE3 — 고급 웹 앱, 익스플로잇 개발, Offensive Security의 무선 인증.
- GPEN, GWAPT, GXPN — SANS GIAC 인증.
- CEH (Certified Ethical Hacker) — OSCP보다 더 이론적인 입문용 자격 증명.
- PNPT (Practical Network Penetration Tester) — TCM Security의 실습 시험.
OSCP는 유명 펜 테스트에서 가장 일반적으로 요구되는 자격 증명입니다.
법적 및 윤리적 계층
서면 승인 없이 펜 테스트를 하는 것은 미국 CFAA, 영국 컴퓨터 오용법, 기타 유사한 법률 등 대부분의 관할권에서 범죄입니다. 승인을 받은 경우에도 범위 확장으로 인해 법적 문제가 발생할 수 있습니다. 서면 승인("탈옥 편지"라고도 함)은 테스터의 법적 보호입니다.
평판이 좋은 펜 테스트 회사는 사고에 대비한 보험을 유지하고, 민감한 데이터에 대해 엄격한 데이터 처리 정책을 따르며, 실제로 진행 중인 침입이나 중요한 개인 데이터가 발생할 경우 명확한 에스컬레이션 경로를 제공합니다.
조직에서 일반적으로 기대하는 것
A 펜 테스트 보고서 포함:
- 비기술적 리더십에 대한 요약
- CVSS 점수를 사용한 심각도 순위 결과
- 각 결과에 대한 자세한 재현 단계
- 스크린샷 및 개념 증명 증거
- 특정 교정 권장 사항
- 보안 상태에 대한 총체적인 관찰
발견 사항은 실행 가능해야 합니다. "취약성 X는 구성요소 Y에 존재합니다. 이것이 악용된 방법은 다음과 같습니다. 해결 방법은 다음과 같습니다." — "보안이 취약합니다."가 아닙니다.
자주 묻는 질문
- 얼마나 자주 펜 테스트를 받아야 합니까?
- 공통 주기: 일반적인 상태에 대해 매년, 주요 변경(새 애플리케이션, 아키텍처 점검) 후 및 규정 준수에 따라 요구됩니다(PCI-DSS는 카드 소지자 환경에 대해 연간 침투 테스트를 요구합니다).
- 펜 테스트와 레드팀 — 차이점은 무엇인가요?
- 펜 테스트의 범위는 정의된 대상에서 가능한 한 많은 취약점을 찾아내는 것입니다. 레드팀 참여는 특정 실제 공격을 엔드투엔드(초기 액세스, 측면 이동, 유출)로 시뮬레이션하여 탐지 및 대응 기능을 테스트합니다. 레드 팀은 더 넓고, 더 길며, 더 은밀한 경우가 많습니다. <a href="/learning/red-team-blue-team">red 팀 기사</a>를 참조하세요.
- 소규모 회사가 펜 테스트를 수행할 가치가 있나요?
- 무엇이 위험에 처해 있는지에 따라 다릅니다. 고객 데이터를 처리하거나, 결제를 수락하거나, 규제 대상 산업에서 운영하는 중소기업에 도움이 됩니다. 사용자 데이터가 없는 순수한 브로셔 사이트는 가치가 떨어집니다. 비용은 좁은 범위의 경우 수천에서 포괄적인 경우 수만까지 다양합니다.
- 펜 테스트를 통해 모든 취약점을 찾을 수 있나요?
- 아니요. 그들은 인간이 사용하는 도구를 사용하여 할당된 시간 속에서 발견 가능한 것을 찾습니다. 시간 제한이 있는 테스트에서는 누락된 사항이 있습니다. 충분히 철저한 테스트는 자주 실행하기에는 비용이 너무 많이 듭니다. 계층화된 적용 범위를 위해 지속적인 검색 및 버그 현상금을 결합합니다.
- 펜 테스터는 문제를 해결해야 합니까?
- 때때로. 영향을 입증하려면 실제 활용이 필요한 경우가 많습니다. 평판이 좋은 테스터는 파괴적인 작업을 수행하기 전에 의사소통하고 가능하면 스테이징을 사용하며 모든 것을 문서화합니다. 범위 문서에서는 파괴적 조치 제한을 미리 지정해야 합니다.