[웹 방어 레시피] 1부, 전투 공간 준비

"우리의 웹 사이트는 안전한가?" 라는 질문에 대해 몇 가지 응답 예시를 열거하고 각각의 문제점을 강조한다.

 

Q1. 지불 카드 산업 데이터 보안 표준(PCI DSS, Payment Card industry Data Security Standard)을 준수하므로 우리의 웹 어플리케이션은 안전하다.

 

A1. PCI DSS는 다른 대부분의 규정과 같이 준수해야 할 최소한의 규정이다. 이 말은 규정을 준수하는 것이 우리의 웹 사이트를 해킹의 위험에서 벗어나게 해준다는 의미가 아니다. PCI DSS는 위험 완화보다 위험전가(신용카드 회사로부터 상인)에 대한 내용이다.

 

 

Q2. PCI를 통과했기 때문에 안전하다고 말하기는 어렵지만, 안전하다면 PCI 검사를 통과하기가 훨씬 쉽다.

 

A2. 더욱 일반적인 의미로 규정은 제어-준수 철학으로 고통받는 편이다. 입력 값 중심이며 실제 작업의 효용성을 분석하거나 모니터링하지 않는다. 모든 준비와 상관없이 우리의 웹 보안이 성공하거나 또는 충돌하고 불타는 것은 실제 프로덕션 네트워크에서 벌어진다.

 

 

Q3. 상용 웹 보안 제품을 배포했기 때문에 우리의 웹 어플리케이션은 안전하다.

 

A3. 이와 같은 응담은 보안에 대한 잘못된 믿음이 초래한 불행한 결과이다. 보안 제품은 그들이 보호하는 애플리케이션과 마찬가지로 잘못 사용될 경우 결함을 가지게 된다. 또한 공격자가 탐지를 회피하거나 조작할 수 있도록 허용하는 설정 또는 배포를 잘못할 잠재적 문제의 가능성도 있다.

 

 

Q4. 우리는 SSL을 사용하므로 우리의 웹 어플리케이션은 안전하다.

 

A4. 많은 전자 상거래 웹 사이트는 눈에 띄도록 SSL 이미지 배너를 표시한다. 이는 웹 사이트가 신뢰할 수 있는 인증 기관(CA)에서 구입한 SSL(Secure Socker Layer) 인증서를 사용하기 때문에 웹 사이트가 안전하다는 것을 나타낸다. 

서명된 SSL 인증서를 사용하는 것은 네트워크 스니핑과 웹 사이트 스푸핑 공격을 방지하는 데 도움이 된다.

SSL은 이와 같은 두 가지 문제를 완화하는 데 도움이 되지만 눈에 띄는 한 가지 약점이 있다. SSL의 사용이 악의적인 사용자가 직접 웹 애플리케이션 자체를 공격하는 것을 방지하는 데 아무런 도움이 되지 않는다는 점이다. 

 

 

Q5. 웹 공격 차단을 보여줄 수 있는 경고들이 있으므로 우리의 웹 애플리케이션은 안전하다.

 

A5. 웹 공격 시도의 증거를 확보하는 것은 좋지만 충분하지는 않다. 차단된 공격에 대한 증거를 제공하는 것은 유용한 측정의 기준이지만, 관리자가 실제로 알고 싶은 것은 어떠한 성공적인 공격이라도 일어났는지 여부이다.

 

프로덕션 네트워크와 웹 어플리케이션의 보안 매커니즘이 어떻게 작동하고 있는지 측정하는 데 중요하다고 생각하는 웹 보안 수치이다.

일별 웹 트랜잭션	숫자(#)로 표시돼야 한다. 웹 트래픽의 기준을 설정하고 다른 수치에 대한 몇 가지 관점을 제공한다.
탐지된 공격(True positive)	숫자(#) 또는 일별 총 웹 트랜잭션에 대한 백분율(%)로 표시돼야 한다. 악의적인 웹 트래픽과 보안 탐지 정확도 모두를 위한 일반적인 지표이다.
미탐 공격(False negative)	숫자(#) 또는 일별 총 웹 트랜잭션에 대한 백분율(%)로 표시돼야 한다. 보안 탐지 정확도의 효과에 대한 일반적인 지표며, 게임의 최종 점수를 제공하려고 할 때 놓친 중요한 수치이다.
차단된 트래픽(False positive)	숫자(#) 또는 일별 총 웹 트랜잭션에 대한 백분율(%)로 표시돼야 한다. 이 또한 보안 탐지 정확도의 효과에 대한 일반적인 지표다. 정상적인 고객의 데이터를 차단하는 것은 수익을 놓친 것을 의미하므로 많은 조직에서 주요한 데이터다. 조직은 웹 트랜잭션에 지장을 주는 행위인 오탐 경고를 추적하는 방법을 가지고 있어야 한다.
공격 탐지 실패율	백분율(%)로 표현돼야 한다. 이는 미탐된 공격 수와 오탐 수를 더한 후 탐지된 공격 수로 나눠서 구할 수 있다. 이 백분율은 우리의 웹 애플리케이션 보안 탐지 정확도에 대한 전반적인 효율성을 제공한다.

 

Q6. 어떤 비정상적인 행위도 식별되지 않았으므로 우리의 웹 애플리케이션은 안전하다.

 

A6. 이 응답의 주요 결점은 비정상적인 애플리케이션의 행위를 식별하기 위해 사용된 데이터를 이용해야 한다는 것이다. 대부분의 조직은 충분한 양의 로깅 세부 정보를 생성하기 위해 웹 애플리케이션을 적절하게 수정하지 않는다. 대부분의 웹 사이트들은 공동 로그 포맷과 같은 웹 서버의 로깅 매커니즘을 기본적으로 사용한다.

 

109.70.36.102 - - [15/Fed/2012:09:08:16 -0500] "POST /wordpress/ /xmlrpc.php HTTP/1.1" 500 163 "-" "Wordpress Hash Grabber v2. 01ibwww-per1/6.02" 109.70.36.102 - - [15/Fed/2012:09:08:17 -0500] "POST /wordpress/ /xmlrpc.php HTTP/1.1" 200 613 "-" "Wordpress Hash Grabber v2 01ibwww-perl/6.02"

첫 번째로, User-Agent 항목이 알려진 워드프레스 악성 프ㅜ로그램인 워드프레스 해시 그래버의 값을 보여주는 것이다. 두 번째로, 반환된 HTTP 상태 코드 토큰이다. 첫 번째 항목은 500 내부 서버 오류 상태 코드를 반환했고, 두 번째 항목은 200 OK 상태 코드를 리턴했다.

첫 번째 항목의 어떤 데이터가 웹 애플리케이션이 오류 조건을 생성하게 만들었는가? POST 요청은 데이터를 웹 서버의 CFL 로그에 기록이 남는 QUERY_STRING 값이 아니라 요청 본문 안에 넣어 전달하기 때문에 어떤 매개변수 데이터가 전달됐는지 우리는 알 수 없다.

이 트랜잭션의 응답 본문 내에는 어떠한 데이터가 반환됐는가? 이는 대답해야 할 중요한 질문이지만 CLF 로그는 전체 트랜잭션 데이터의 오직 일부분만 포함한다. 예를 들어 쿠키, POST 요청 본문, 아웃바운드된 데이터와 요청 헤더를 포함하지 않는다. 아웃바운드 HTTP 응답 데이터에 대해 적절하게 로그를 남기지 않는 경우 심각한 사고 대응 질문에 적절히 대답하지 못하는 결과를 초래한다.

공격자가 어떤 데이터를 훔쳤는가? 강력한 HTTP 감사 로그의 부재는 웹 관련된 사고에 대해 적절한 침해 사고 대응 단계를 수행할 수 없는 주요한 원인 중의 하나다.

 

 

Q7. 어떤 비정상적인 행위도 식별되지 않았고 악성적인 행위의 징후를 발견하기 위해 전체 HTTP 감사 로그를 수집 및 분석하므로 우리의 웹 애플리케이션은 안전하다.

 

A7. 우리는 다른 악성 행위의 징후를 분석할 수 있도록 반드시 전체 HTTP 감사 로그를 가지고 있어야 한다. 사고 대응 과정에서 관리자는 종종 '이 사람이 다른 무엇을 했는지'에 대해 묻는다. 이 질문에 정확하게 대답하기 위해서는 단순히 악성이라고 구별괸 하나의 트랜잭션뿐 아니라 해단 사용자의 전체 웹 세션에 대한 감사 로그를 가지고 있어야 한다.

 

 

Q8. 어떤 비정상적인 행위도 식별되지 않았고 악성적인 행위의 징후를 발견하기 위해 전체 HTTP 감사 로그를 수집 및 분석하므로 우리의 웹 애플리케이션은 안전하다. 또한 우리는 취약점의 존재를 대비해 정기적으로 애플리케이션을 테스트한다.

 

A. 웹 애플리케이션 공격 시도를 식별하고 차단하는 것은 중요하다. 하지만 우리의 애플리케이션 내에서 알려진 취약점의 존재와 이러한 공격의 목표를 연관시키는 것이 가장 중요하다. 어떤 애플리케이션이 배포돼 있는지 확인하는 것과 특정 취약점이 있는지 확인하는 것은 보안 이벤트의 우선순위를 적절하게 나누는데 중요하다.

 

 

Q9. 어떤 비정상적인 행위도 식별되지 않았고 악성적인 행위의 징후를 발견하기 위해 전체 HTTP 감사 로그를 수집 및 분석하므로 우리의 웹 애플리케이션은 안전하다. 또한, 우리는 취약점의 존재를 대비하고 탐지 및 사고 대응 능력을 향상시키기 위해 정기적으로 애플리케이션을 테스트한다.

 

A9. 우리의 웹 애플리케이션 취약점이 어디에 있는지 알고 있더라도 여전히 효율성을 확보하기 위해 실시간 시뮬레이션을 통해 보안 운영 방어를 적극적으로 테스트해야 한다.

 

 

 

 

---

출처: ModSecurity를 활용한 웹 애플리케이션 방어 레시피, 라이언 바넷 지음