Threat Stack은 이제 F5 Distributed Cloud App Infrastructure Protection(AIP)입니다. 지금 바로 팀과 함께 Distributed Cloud AIP를 사용해 보세요. 오늘.
PCI DSS 현재 버전은 2018년 5월에 발표된 3.2.1입니다. 요구 사항 6에서는 “안전한 시스템과 애플리케이션을 개발하고 유지 관리”해야 한다고 명시합니다. 물론 문제없죠. 정말 명확하고 간단한 일입니다. 적어도 안전한 시스템과 애플리케이션을 개발하고 유지 관리해 본 적이 없는 사람에게는 말이죠! 나머지 사람들에게는 결코 만만치 않은 요구 사항입니다.
하지만 이 문서에서는 대부분의 안전한 소프트웨어 개발 수명 주기에 이미 포함되어 있는 비교적 명확한 요구 사항들을 계속해서 나열합니다. 보안 취약점을 식별하는 프로세스를 수립하고, 알려진 취약점을 해결하며, 코딩 모범 사례를 적용하고, 개발 및 테스트 환경과 계정을 프로덕션 환경과 안전하게 분리해야 합니다. 또한 코드 검토를 수행하고, 변경 관리 프로세스를 마련하며, 개발자에게 안전한 코딩 기법을 교육하는 등의 조치도 필요합니다. 모두 상당히 합리적인 요구 사항입니다.
이 최상위 요구 사항을 좀 더 자세히 살펴보면, 요구 사항 6.5에는 애플리케이션이 보호되어야 할 여러 구체적인 취약점이 나열되어 있습니다. 이는 OWASP TOP 10, SANS CWE Top 25, CERT Secure Coding 등에서 꼽은 일종의 ‘주요 취약점 모음’으로, SQL 인젝션, 취약한 암호화, XSS, 버퍼 오버플로 등 예상할 수 있는 항목들입니다. 이 역시 합리적입니다. 공격자는 이러한 유형의 취약점을 초기 공격 지점으로 삼는 경우가 많습니다.
그리고 요구 사항 6.6에는 핵심적인 내용이 나옵니다. “외부에 공개된 웹 애플리케이션의 경우, 새로운 위협과 취약점에 지속적으로 대응하고 이러한 애플리케이션이 알려진 공격으로부터 보호되도록 해야 한다.” 어떤 공격을 말하는 걸까요? 이에 대해 “최소한 요구 사항 6.5에 명시된 모든 취약점”이라고 답합니다. 잠시 이 점을 생각해 보십시오. 문서 64페이지 깊숙이 묻혀 있는 이 단 하나의 요구 사항, 즉 6.6은 우리가 소프트웨어를 구축하고 운영하는 방식에 중대한 영향을 미칩니다! 이 요구 사항을 어떻게 충족하라고 제안할까요? 답은 두 부분으로 나뉩니다:
- “수동 또는 자동화된 취약점 보안 평가 도구나 방법”을 사용하여 매년 그리고 변경 사항이 있을 때마다 애플리케이션을 검토
- “웹 기반 공격을 탐지하고 방지하는 자동화된 기술 솔루션”을 사용하여
따라서 이는 웹 애플리케이션의 빌드 시간과 런타임 모두에 영향을 미치며, 실제로는 완전히 서로 다른 두 가지 활동을 포함합니다:
1. 애플리케이션을 검토하여 취약점이 있는지 선제적으로 파악하고, 발견된 취약점이 수정되도록 확인합니다.
– 그리고 –
2. 실시간으로 공격 탐지 및 차단
전혀 나쁜 요구 사항은 아닙니다. 지침에도 나와 있듯이, “외부에 공개된 웹 애플리케이션은 공격자의 주요 표적이며, 제대로 코딩되지 않은 웹 애플리케이션은 공격자가 민감한 데이터와 시스템에 손쉽게 접근할 수 있는 경로를 제공합니다.” 전적으로 동의합니다. 문제는 이 요구 사항을 실제로 구현하는 데 있습니다.
첫 번째 부분인 애플리케이션 검토를 어떻게 수행해야 하는지에 대해서는 구체적인 지침이 많지 않습니다. 애플리케이션은 “수동 또는 자동화된 취약점 보안 평가 도구나 방법을 사용하여” 검토해야 한다고 되어 있습니다. 상당히 포괄적인 표현입니다.
두 번째 부분에는 조금 더 구체적인 권고 사항이 있습니다. 공개 웹 애플리케이션 앞단에 “웹 기반 공격을 탐지하고 방지하는 자동화된 기술 솔루션(예: 웹 애플리케이션 방화벽)을 설치하여 모든 트래픽을 지속적으로 검사”해야 합니다. 이는 WAF 공급업체에 호재였습니다. 요구 사항 6.6을 충족하려는 팀들이 WAF를 갑자기 ‘체크리스트를 채우기 위한’ 구매 항목으로 여기게 되었기 때문입니다. 하지만 WAF는 요구 사항의 첫 번째 부분에는 도움이 되지 않습니다. WAF는 보안 평가 도구가 아닙니다. 애플리케이션이 무엇을 어떻게 수행하는지 전혀 알지 못합니다. WAF는 애플리케이션으로 전송되는 내용만 파악할 뿐, 애플리케이션이 해당 정보로 무엇을 할 수 있는지(또는 하지 않을지)는 알지 못합니다.
이 모든 요인으로 인해 많은 팀이 6.6 요구 사항 전체를 충족하는 데 어려움을 겪습니다. 이 짧은 요구 사항 하나에는 중요하면서도 상당히 다른 두 가지 필요 사항이 담겨 있습니다. 대부분은 WAF로 두 번째 부분을 충족하고, 첫 번째 부분을 해결하기 위해 여러 다른 기법(수동 코드 검토, 자동화된 소스 코드 분석 등)을 조합하려 할 것입니다.
하지만 단일 솔루션으로 요구 사항 6.6을 충족할 수 있는 대안이 있습니다. PCI 표준에서 WAF를 언급할 때 ‘예를 들어’라는 문구를 사용한다는 점에 주목할 필요가 있습니다. 이는 중요한 의미를 지닙니다(이전 버전의 표준에는 포함되지 않았던 문구입니다). 즉, ‘웹 기반 공격을 차단하거나 즉시 조사할 수 있도록 경고를 생성하도록 구성’되어 있다면 애플리케이션을 보호할 수 있는 다른 기술도 존재한다는 점을 인정한 것입니다. Threat Stack이 추가 비용 없이 Cloud Security Platform®에 추가한 통합 애플리케이션 보안 솔루션인 Application Security Monitoring은 요구 사항 6.6의 빌드 시점과 런타임 측면을 모두 해결합니다. 두 가지 큰 과제를 하나의 솔루션으로 해결할 수 있습니다.
빌드 시 다른 타사 코드 라이브러리와 마찬가지로 애플리케이션에 Threat Stack 마이크로에이전트를 추가합니다. 개발자 입장에서는 APM 솔루션을 사용해 애플리케이션을 계측하는 것과 매우 유사합니다. 마이크로에이전트를 추가하면 로컬 수동 테스트, 야간 빌드의 자동화 테스트, 사용자 인수 테스트 등 어떤 방식으로 실행하든 애플리케이션이 실행될 때마다 평가됩니다. PCI는 앱을 “최소 연 1회 및 변경 사항이 있을 때마다” 검토해야 한다고 규정합니다. Threat Stack은 여기서 한발 더 나아가 개발자가 별도의 작업을 하지 않아도 보안 취약점을 지속적으로 식별합니다. 작성해야 할 테스트도, 관리해야 할 서버도 없습니다.
취약점이 식별되면 요구 사항 6.6에 따라 해당 취약점을 해결해야 합니다. 즉, “모든 취약점이 수정되고 수정 후 애플리케이션이 재평가되도록” 해야 합니다. Threat Stack AppSec Monitoring은 탐지된 모든 위험에 대해 개발자가 즉시 조치할 수 있는 지침을 제공합니다. 여기에는 위험에 대한 설명, 수정 방법을 보여 주는 샘플 코드, 그리고 위험이 발견된 정확한 모듈 및 메서드 이름과 파일 위치 및 줄 번호가 포함됩니다. 개발자가 취약점을 수정한 후에는 ‘재평가’를 위해 별도의 작업을 수행할 필요가 없습니다. 다음번에 애플리케이션이 실행될 때 자동으로 평가됩니다.
런타임 시에는 알려진 공격으로부터 애플리케이션을 보호하기 위해 “모든 트래픽을 지속적으로 검사”해야 합니다. 동일한 Threat Stack 마이크로에이전트가 이 작업도 수행합니다. 애플리케이션이 개발 환경에서 프로덕션 환경으로 배포될 때 마이크로에이전트도 함께 배포됩니다(애플리케이션의 종속성으로 포함되어 있음). 이후 애플리케이션으로 전송되는 모든 웹 페이로드를 분석하여 공격 징후를 탐지합니다. 페이로드가 악성으로 판단되면 요청을 즉시 차단할 수 있습니다. 팀은 Threat Stack 포털이나 Slack 또는 기타 ChatOps 채널을 통해 공격에 대한 알림을 받습니다. 이는 “웹 기반 공격을 차단하거나 즉시 조사되는 경고를 생성”해야 한다는 PCI 요구 사항을 정확히 충족합니다.
PCI 6.6은 광범위한 요구 사항입니다. “새로운 위협과 취약점에 지속적으로 대응하고 이러한 애플리케이션을 알려진 공격으로부터 보호”하라는 규정은 소프트웨어 개발 수명 주기의 두 단계(개발 및 운영)에 걸쳐 있으며, 두 가지 별도의 작업(선제적 취약점 평가와 실시간 공격 탐지 및 방지)을 요구합니다. 두 작업 모두 복잡하며 일반적으로 서로 다른 팀이 담당합니다. 하지만 이를 해결하기 위해 별도의 도구 두 개를 사용할 필요는 없습니다. Threat Stack의 애플리케이션 보안 모니터링은 개발자의 작업 속도를 저하시키지 않는 단일 솔루션으로 두 요구 사항을 모두 충족합니다. 지금 바로 사용해 보세요!
자세히 알아보거나 애플리케이션 보안 모니터링을 직접 체험해 보고 싶다면 Threat Stack Cloud Security Platform 데모를 신청하세요. 규정 준수 및 보안 전문가가 고객의 구체적인 요구 사항에 대해 기꺼이 상담해 드립니다.
참고 자료
요구 사항 및 보안 평가 절차의 PCI DSS 요구 사항 6.6, 버전 3.2.1, 2018년 5월
6.6 공개 웹 애플리케이션의 경우, 새로운 위협과 취약성에 지속적으로 대응하고 다음 방법 중 하나를 통해 알려진 공격으로부터 해당 애플리케이션을 보호해야 합니다:
- 수동 또는 자동화된 애플리케이션 취약점 보안 평가 도구나 방법을 사용하여 외부에 공개된 웹 애플리케이션을 최소 연 1회 및 변경 사항이 발생할 때마다 검토
- 모든 트래픽을 지속적으로 검사할 수 있도록 외부에 공개된 웹 애플리케이션 앞단에 웹 기반 공격을 탐지하고 차단하는 자동화된 기술 솔루션(예: 웹 애플리케이션 방화벽)을 설치합니다.
Threat Stack은 이제 F5 Distributed Cloud App Infrastructure Protection(AIP)으로 변경되었습니다. 팀과 함께 Distributed Cloud AIP를 지금 바로 사용해 보세요.
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.