PCI DSS 요구 사항 6.6을 해결하는 방법 - Threat Stack의 2대 1 솔루션

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. 실시간으로 공격 탐지 및 차단

전혀 나쁜 요구 사항은 아닙니다. 지침에 명시된 대로, "공개 웹 애플리케이션은 공격자의 주요 타겟이며, 코딩이 형편없는 웹 애플리케이션은 공격자가 민감한 데이터와 시스템에 쉽게 접근할 수 있는 경로를 제공합니다." 저는 전적으로 동의합니다. 문제는 요구사항을 실제로 구현하는 데 있습니다. 

첫 번째 부분인 앱 검토를 수행하는 방법에 대한 지침은 많지 않습니다. 앱은 "수동 또는 자동 취약성 보안 평가 도구나 방법을 사용하여" 검토해야 합니다. 꽤 광범위하죠. 

두 번째 부분에는 좀 더 구체적인 권장 사항이 담겨 있습니다. "공개 웹 애플리케이션 앞에 웹 기반 공격(예: 웹 애플리케이션 방화벽)을 탐지하고 방지하는 자동화된 기술 솔루션을 설치하여 모든 트래픽을 지속적으로 확인해야 합니다." 이는 요구 사항 6.6을 충족하고자 하는 팀에 "체크박스" 구매가 갑자기 필요하게 된 WAF 공급업체에게 큰 도움이 되었습니다. 하지만 WAF는 요구 사항의 첫 번째 부분에는 도움이 되지 않습니다. WAF는 보안 평가 도구가 아닙니다. 어떤 응용프로그램이 무슨 기능을 하는지, 어떻게 작동하는지 전혀 모릅니다. 애플리케이션에 전송되는 내용만 이해할 뿐, 애플리케이션이 해당 정보로 무엇을 할 수 있는지(또는 할 수 없는지)는 이해하지 못합니다.

이 모든 사항으로 인해 많은 팀이 6.6의 모든 요구 사항을 충족하는 데 어려움을 겪고 있습니다. 이 하나의 작은 요구 사항 안에는 중요하면서도 상당히 다른 두 가지 요구 사항이 있습니다. 대부분은 WAF로 두 번째 부분을 충족시키려 하고, 첫 번째 부분을 해결하기 위해 여러 가지 다른 기술(수동 코드 검토, 자동화된 소스 코드 분석 등)을 조합합니다. 

하지만 단일 솔루션으로 요구 사항 6.6을 충족할 수 있는 대안이 있습니다. PCI 표준에는 WAF를 언급할 때 "예를 들어"라는 문구가 포함되어 있다는 점이 눈에 띄실 겁니다. 이는 중요한 사항입니다(이전 버전의 표준에는 포함되지 않았습니다). 웹 기반 공격을 차단하거나 즉시 조사되는 경고를 생성하도록 구성된 경우 애플리케이션을 보호할 수 있는 다른 기술이 존재한다는 것을 인정합니다.  Threat Stack이 추가 비용 없이 Cloud Security Platform®에 추가한 통합 애플리케이션 보안 솔루션인 애플리케이션 보안 모니터링은 요구 사항 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 데모에 등록하세요. 당사의 규정 준수 및 보안 전문가가 귀하의 구체적인 요구 사항에 대해 기꺼이 상담해 드리겠습니다.