OWASP

OWASP TOP 10 요약

OWASP(Open Web Application Security Project)란 웹 보안 취약점을 연구하는 프로젝트이다.

2004년부터 3년마다 빈도가 가장 많이 발생하는 웹 애플리케이션의 취약점을 10가지를 선정하여 발표하고 있으며 신뢰할 수 있는 애플리케이션을 개발, 구입, 유지관리하는 데에 기여하는 개방 커뮤니티 역할을 한다.

 

2017년도에 발표한 OWASP TOP10 리스트는 인젝션, 취약한 인증, 민감한 데이터 노출, XML 외부 개체(XXE), 취약한 접근 통제, 잘못된 보안 구성, 크로스 사이트 스크립팅(XSS), 안전하지 않은

역직렬화, 알려진 취약점이 있는 구성요소 사용, 불충분한 로깅 및 모니터링이다.

취약점마다 각각 위험도 순으로 A1, A2, …, A10 나눠 요약되어 있다.

 

-A1. 인젝션

신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로 사용되어 인터프리터로 보내질 때 발생되어 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있다. 거의 모든 데이터의 소스가 인젝션 공격요인이 될 수 있기 때문에 공격 가능성이 쉽고

결과적으로 데이터의 손실, 파괴, 정보 노출, 호스트 탈취 ,서비스 거부 결과를 초래할 수 있다.

매우 일반적인 공격이며 특히 과거에 사용된 코드에서 나타나고 쿼리, 운영체제 명령어에서 자주 발견되는 만큼 코드를 검증하는 과정에서 스캐너와 퍼저를 사용해 인젝션 결함을 쉽게 발견

할 수 있다.

 

공격에 취약한 경우는 다음과 같다.

-사용자 제공 데이터가 유효하지 않거나 필터링 되어지지 않거나 애플리케이션에 의해 정제되지 않는 경우

-상황 인식 기반 필터링 없이 동적 쿼리나 매개 변수화 되지 않은 호출이 인터프리터에서 직접 사용 되는 경우

-악의적인 데이터가 객체 관계형 매핑 검색 매개 변수 내에서 사용되어 추가로 민감한 정보를

추출한다.

-악의적인 데이터가 직접적으로 동적 쿼리 안에 포함된 구조적 데이터와 악의적 데이터를 포함한 명령어, 일반 명령어, SQL, 저장 프로시저에 사용되거나 연결된다.

 

인젝션을 예방하기 위해서는 소스코드를 리뷰하면서 모든 파라미터, 헤더, URL, 쿠키, JSON, SOAP, XML 데이터 입력에 대한 철저한 자동화 테스트를 통한 검사가 필요하다.

인터프리터 사용을 피하거나 안전한 API를 사용하는 것과 ORMs 툴을 사용하도록 전환시키는 것을 권장하고 적극적으로 입력값 유효성을 검증하며 남은 동적 쿼리들을 위하며 필터링 구문을 사용해 인터프리터에 대한 특수 문자를 필터링 처리 해야한다.

 

 

-A2. 취약한 인증

 인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키,

세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을

위해 구현 상 결함을 악용하도록 허용한다.

자격 증명 자료, 관리 계정 목록, 자동화된 무차별 대입, 사전 공격 툴, 고급GPU 크래킹 툴을 통해서 수억개의 사용자ID와 암호 조합을 만들어 접근하거나 비밀번호 목록을 가진 툴과 사전 기반 공격으로 침투 할 수 있다.

이렇게 시스템을 손상 가능하게 하는 계정들이나 하나의 관리자 계정에만 접근만 하게 되면

사회 보장 사기, 신원 도용, 기밀 정보가 공개될 수 있다.

 

공격 침투 경로 예는 다음과 같다.

알려진 암호 목록을 사용해 계정 정보 삽입을 시켜 접근 권한이 없는 사용자가 인증을 받는 경우,

비밀번호 주기가 길고 복잡성이 낮은 경우, 다중 인증이 없는 경우

애플리케이션 세션에 대해 적절한 만료 시간이 정해지지 않는 경우 (로그아웃을 하지 않고 브라우저 탭을 닫을 경우 다른 사용자가 같은 브라우저를 사용할 시 여전히 인증되어 있음)

 

사용하는 애플리케이션이 다음과 같을 경우에는 취약점이 존재 할 수 있다.

유효한 사용자 이름과 비밀번호를 가진 상태에서 계정 정보 삽입과 같은 공격을 허용

password, admin, apple123 같은 약한 암호 또는 알려진 암호를 사용하는 경우,

안전하지 않은 지식 기반 답변을 사용하거나 효과가 없는 자격 증명 복구나 비밀번호 복구를 허용하는 경우, 평문, 암호화되거나 취약한 해쉬 비밀번호를 사용하는 경우

다중 인증이 없거나 비효율적인 경우, 세션ID가 URL에 노출되는 경우

로그아웃이나 비활성 기간 중에 사용자 세션 및 인증 토큰이 제대로 무효화 되지 않는 경우

 

이러한 공격을 막기위한 보안 대책이다.

다중 인증을 구현해 자동화된 계정 정보 삽입, 무차별 공격, 탈취된 계정정보를 재사용 하는 것을 예방한다.

admin 계정인 경우 기본 계정 정보를 사용하거나 제공하거나 배포하지 않는다.

비밀번호를 생성하거나 변경할 때 ‘최악의 Top 10000개 비밀번호’를 참조해 검사한다.

NIST 800-63 가이드라인에 따라 암호 길이, 복잡성 및 순환 정책 또는 다른 최신 정책, 근거 기반 암호 정책을 조정한다.

계정 열거 공격에 대한 대비로 모든 결과에 대해 동일한 메시지를 사용하여 등록, 계정 정보 복구, API 경로를 강화한다.

로그인 실패에 대한 제한이나 시간 연기를 하고 모든 실패에 대한 로그를 남기고 무차별 공격, 계정 정보 삽입 공격들이 탐지되면 관리자에게 알림을 보낸다.

로그인 이후에 예측 불허한 무작위 세션ID를 생성하는 서버 측의 안전한 내장 세션 관리자를 사용한다. 세션 ID는 URL에 없어야 하고 안전하게 보관되어야 한다.

로그아웃, 유휴 및 절대시간 초과 이후에는 무조건 무효화 되어야한다.

 

-A4. XML 외부 개체 (XXE)

XML 업로드가 가능하고 XML 문서에 취약한 코드, 의존성, 통합을 공격하는 내용을 포함할 수 있다면 취약한 XML 프로세스를 공격할 수 있어서 개발자에 대한 보안 교육이 필수적인 취약점이다

오래된 프로세서들은 XML처리 중에 참조되고 평가되는 URI에 대해 외부 개체의 지정을

허용 한다. 소스코드 분석 툴로 의존성 및 설정을 조사하고 취약점 분석툴을 통해 공격가능한지를 파악할 수 있어 XXE 취약점을 탐지하기가 쉽지만 이 취약점은 데이터 가져오기, 서버에서 원격 요청 실행, 내부 시스템 탐지, 서비스 거부 공격 수행 및 다른 공격들의 실행을 위해 사용될 수 있어 공격이 실행된다면 심각해진다.

애플리케이션이 직접 XML를 입력 받거나 신뢰할 수 없는 곳의 XML를 업로드, 신뢰할 수 없는 데이터를 입력할 경우에 XML 프로세서가 처리하는 경우

è  JSON과 같은 복잡하지 않은 데이터 형식을 사용하고 민감한 데이터를 지양한다.

è  애플리케이션이나 OS에서 사용중인 XML프로세서와 라이브러리를 패치하고 업그레이드하고 의존성 체커를 사용해야 한다.

è  서버에서 화이트리스트를 이용한 입력값 검증, 필터링, 검사를 구현해서 XML문서, 헤더, 노드에 있는 악의적인 데이터를 막습니다.

è  xml이나 xsl파일 업로드 기능이 xsd검증기 같은 것을 사용해 xml이 유효한 내용인지 확인

애플리케이션에 있는 XML 프로세서나 웹 기반의 SOAP에 DTD가 활성되어있는 경우

à모든 XML파서의 XML외부 개체와 DTD처리를 비활성화 시킨다.

애플리케이션이 페더레이션 보안이나 SSO 목적으로 확인 처리를 위해 SAML을 사용할 경우 취약하다. 애플리케이션이 SOAP 1.2이전의 버전을 사용하고 있다면 1.2나 그 이상으로 업그레이드 해야한다.

수동으로 소스코드 리뷰가 최선의 방법이지만 많은것들이 합쳐진 복잡한 애플리케이션에서는 소스코드분석툴을 이용해 xxe를 탐지하고 막는데 좋다. 이러한 방법들이 힘들다면

API보안 게이트웨이, 웹 어플리케이션방화벽 사용을 고려하는것도 좋다.

 

악의적인 xml파일을 업로드해 공격하는 시나리오 예이다.

-<!ENTITY xxe SYSTEM “file:///etc/passwd”>]>를 이용해 서버에서 데이터를 가져오려고 시도한다.

-ENTITY라인을 변경하여 서버의 사설망을 찾는다.

<!ENTITY xxe SYSTEM “https://192.168.1.1/private”>]>

-무한 파일을 포함하여 서비스 거부 공격을 시도하는 경우

<!ENTITY xxe SYSTEM “file:///dev/random”>]>

 

 

 

 

 

 

 

 

-A.5 취약한 접근 통제

접근통제를 무력화 시키는 것은 공격에 있어 기본이다. 접근통제에 실패할 경우 일반적으로

인가되지 않은 정보 노출, 데이터 조작이나 파괴 (공격자는 사용자, 관리자, 권한 부여가 가능한 사용자, 모든 데이터에 생성/접근/수정/삭제 권한을 가진 사용자를 가장하여 행동할 수 있게 됨), 사용자에게 허용된 범위를 벗어난 사업적 기능 수행 등을 초래하게 된다. 사업적 관점에서

영향도는 애플리케이션 데이터의 보호 필요성에 따라 달라 질 수 있다.

소스코드 분석 툴과 취약점 스캔 툴은 접근통제의 절차 존재 여부만 탐지 할 수 있고 작동여부에 대해서는 탐지 하지 못한다. 그래서 취약점을 확인하기 위해 수동 작업으로 탐지를 해야하며, 특정 프레임워크 상의 접근통제 절차 누락은 자동화 툴을 사용해서도 탐지가 가능하다.

자동화된 탐지 기법과 개발자를 통한 기능 점검에는 한계가 있기 때문에 수동 점검으로

하는 것이 가장 좋은 방법이라 접근통제 절차가 취약한 경우가 흔하게 발생된다.

아래의 경우 취약한 접근 통제가 있는 경우이다.

URL, 내부 애플리케이션 상태, HTML 페이지 조작, 맞춤형 API 공격툴을 통해 접근통제 절차를

우회할 수 있는 경우, 기본 키가 다른 사용자의 레코드로 변경되도록 허용하고 다른 계정의

정보를 열람하거나 편집할 수 있도록 허용되어 있는 경우, 일반 사용자로 로그인하여 관리자

처럼 활동하는 사용자가 있는 경우(권한 상승이 가능),

JSON 웹 토큰의 접근 통제 토큰 재전송이나 변경, 권한 상승 목적으로 쿠키나 감춰진 필드 조작 같은 메타 데이터 조작 행위가 허용되는 경우, 인증 절차를 거치지 않은 사용자가 인증이 필요한 페이지를 볼 수 있는 경우, (POST, GET, DELETE)메소드에 대한 접근통제를 적용하지 않은 API를 사용하는 경우가 있다.

위 같은 경우를 막기 위한 방법들이다.

불특정 다수에게 공개된 자원을 제외하고는 디폴트 정책은 차단으로 운영한다.

모든 사용자가 아닌 레코드 소유자만 생성/열람/수정/삭제 권한을 갖게 끔 강제해야 한다.

애플리케이션 비즈니스의 제한 요구 사항들은 도메인 모델에 의해 적용되어야 한다.

웹 서버상의 디렉토리 리스팅 기능을 비활성화하고 git과 같은 메타데이터와 백업파일들이 웹

루트에 존재하지 않게 해야한다.

접근 통제가 실패할 경우 로그기록에 남아야 하고 반복적으로 실패할 경우에는 관리자에게 경고 메시지가 전송되어야 한다.

자동화 공격 툴로 인한 피해를 최소화 하기 위해 API와 컨트롤러에 대한 접근 임계치를

제한 해야하고 JSON 웹 토큰은 로그아웃 이후 무효화되어야 한다.

위 취약점이 들어날경우 공격 시나리오 예이다.

request.getParameter(“acct”); 이값이 sql문에서 사용된다고 할 때 입력값을 검증 절차 없이 접근하게 된다면 acct 파라미터 값을 원하는 다른값으로 변경시켜 공격이 가능하다.

또한 공격자가 브라우저를 통해 원하는 대상의 URL을 직접 입력할 경우 접근 대상이 관리자 페이지라면 공격이 가능하다.

http://example.com/app/admin_getappInfo

그래서 인가되지 않은 사용자가 요청한 페이지에 접근할 수 있는 경우 취약하다

 

 

-A.6 잘못된 보안 구성

인가되지 않은 영역으로 접근할 수 있는 권한이나 시스템 정보를 얻기 위해 패치 되지 않은 취약점을 공격하거나 디폴트 계정, 미사용 페이지, 보호받지 못하는 파일이나 디렉토리에 접근을 시도해 시스템이나 기능에 접근할 수 있는 기회를 얻게 될 수도 있으며 이를 통해 시스템 상의 권한을 완전히 장악하게 되는 경우가 발생한다.

네트워크 서비스, 플랫폼, 웹 서버, 애플리케이션 서버, DB, 프레임워크, 사용자 정의코드, 설치된 가상머신, 컨테이너, 스토리지 등 애플리케이션 스택의 모든 영역에서 발생할 수 있으며 자동화된

취약점 스캐너는 설정 오류, 디폴트 계정 정보, 활성화된 불필요한 서비스, 변경이 필요한 과거 옵션 값과 같은 미흡한 설정 상태들을 찾아내는데 유용하게 사용된다. ================

 

적절한 보안 강화 절차가 누락되거나 클라우드 서비스 상에 권한이 부적절하게 설정되어 있고

애플리케이션 서버, 프레임워크 라이브러리, 데이터베이스 상에 보안 설정이 되어 있지 않고

구 버전이나 취약한 버전의 소프트웨어를 사용하고 있다면 공격자가 서버를 공격하는데 악용될 수 있고 게다가 디폴트 계정과 비밀번호가 활성화되어 있거나 해당 정보들을 변경없이 사용중이라면 디폴트 패스워드를 사용해 관리 서비스에 접속을 성공해 권한을 획득 할 수 있다.

(업그레이드된 시스템 상에 최신 보안 기능들이 비활성화 되어 있거나 안전하게 설정되지 않은 경우도 포함이다.)

불필요한 기능(포트, 서비스, 페이지, 계정, 권한)이 활성화 되어있거나 설치되어 있는 경우

예를 들어 서버 내 디렉토리 리스팅이 비활성화되지 않았다면 디렉토리 목록이 노출됨을 발견 후

자바 클래스 파일을 다운로드하여 디컴파일과 리버싱을 통해 애플리케이션 상에 존재하는 심각한 접근 통제 취약점을 찾아 낼 수 있다. 또한 디폴트 권한을 이용해 클라우드 스토리지에 저장되어 있는 민감한 데이터에 대한 접근이 허용되기도 한다.

에러 처리 과정에서 스택 추적 정보나 공격에 도움이 될만한 정보들을 노출하고 있는 경우

구성 요소 버전 정보와 같은 공격에 도움을 줄 수 있는 민감한 정보나 내부적인 결함들이 잠재적으로 노출될 수 있다.

이러한 공격들을 막기 위해 적절하고 빠르게 차단이 이뤄지고 쉽게 다른 환경으로 전환할 수 있는 반복적인 보안 강화 절차를 적용해야 한다. 이렇게 새로운 보안 환경을 구축하는데 소모되는 리소스를 최소화 하기 위해 절차를 자동화시켜야 한다.

불필요한 기능, 구성 요소, 문서, 샘플 애플리케이션 없이 최소한으로 플랫폼을 유지, 불필요한

기능과 라이브러리는 삭제하거나 설치하지 않는다.

보안 정보, 업데이트, 패치를 대상으로 설정들을 모두 검토하고 갱신하는 절차가 필요하고

보안 헤더와 같은 보안 강화 수단을 사용자에게 전송해야 한다.

그리고 모든 영역의 보안 설정이 적절히 반영되어 있는지 검증할 수 있는 자동화된 절차가 있어야 한다.

 

 

 

 

 

-A.7 크로스 사이트 스크립팅(XSS)

자동화된 도구는 세 가지 유형의 모든 XSS의 취약점을 탐지하거나 악용할 수 있어(자유롭게

활용이 가능한 공격 프레임워크가 존재) 공격이 쉬운편에 속한다.

두 번째로 많이 발생하는 문제이며 그만큼 응용 프로그램에서 자주 발견된다. 또 자주 발견되는 만큼 자동화 도구로 취약점들을 찾을 수 있다.

이 취약점을 이용해 원격 코드 실행, 인증 혹은 세션정보를 훔치거나 악성코드를 전달하게 된다.

(XSS 공격은 세션 도용, 계정 탈취, 다중 요소 인증 우회, 악성코드 배포, 키로깅, 다른 클라이언트 공격 등을 포함)

XSS는 세 가지 형태로 존재 하게 된다.

reflected XSS : HTML출력의 일부로써 유효성이 확인되지 않고, 특수문자가 필터링되지 않은

사용자 입력이 애플리케이션 또는 API에 포함되어 공격이 실행되면서 피해자의 브라우저에서

 임의의 HTML과 자바스크립트를 실행할 수 있다. 대표적으로 광고 사이트와 웹사이트에서

워터링 홀 공격을 수행한다.

stored XSS : 정제되지 않은 사용자 입력값이 저장되어 나중에 사용자 또는 관리자가 보게 되면 공격이 수행된다.

DOM 기반 XSS : 페이지에 공격자가 제어 가능한 데이터를 동적으로 포함할 수 있는

자바스크립트 프레임워크에 취약하다.

 

필터링 없이 신뢰할 수 없는 데이터를 사용할 경우 특정 파라미터를 브라우저 내에서 조작해

사용자의 쿠키를 전송 하는 악성 스크립트로 바꿔 전송시키면 피해자의 세션ID가 공격자의 웹 사이트로 전송되어 사용자의 현재 세션을 가로채기가 가능하다.

XSS를 방지하기 위해서는 XSS를 자동으로 필터링처리하는 최신 프레임워크를 사용하고

각 프레임워크의 XSS보호의 한계를 알아보고 다루지 않은 사용 사례들을 적절히 처리해야 한다.

HTML 출력 내 컨텍스트 기반으로 신뢰할 수 없는 HTTP 요청 데이터를 필터링하면 reflected xss, store xss 취약점이 해결된다.

클라이언트 측에서 브라우저 문서를 수정할 때 상황에 맞게 인코딩을 적용하면 dom 기반 xss 공격에 대해 대응할 수 있고 브라우저 API에 유사한 문맥 감지 필터링 기술을 적용시킬 수 있다.

컨텐츠 보안 정책을 활성화시켜 xss에 대한 심층적인 방어를 통제 할 수가 있다.

 

 

 

 

 

 

 

 

 

 

 

-A.9 알려진 취약점이 있는 구성 요소 사용

 

많이 알려진 취약점에 대해 이미 작성된 공격 코드들이 있어 공격이 쉽게 이뤄진다.

보통 애플리케이션이나 API에서 사용하는 구성 요소들을 이해하지 못해 최신 상태로 유지하지 못한 상황에서 발생한다.

클라이언트와 서버에서 사용하는 모든 구성 요소의 버전을 알지 못한다면 취약할 가능성이 있다.

(직접 사용하는 구성 요소와 중첩된 종속성 포함)

소프트웨어가 취약하거나, 지원이 없거나, 오래된 버전인 경우,.

(OS, 웹/애플리케이션 서버, DBMS, 애플리케이션, API, 모든 구성요소 런타임 환경과 라이브러리)

정기적으로 취약점을 스캔하지 않거나, 사용 중인 컴포넌트와 관련된 보안 취약점 공지 서비스에 등록하지 않은 경우와 플랫폼, 프레임워크와 종속성을 수정하거나 업그레이드하지 않은 경우,

개발자가 직접 업데이트된, 업그레이드된 라이브러리의 호환성을 테스트 하지 않은 경우

취약할 가능성이 있다.

 

일반적인 구성요소는 애플리케이션 자체와 동일한 권한으로 실행되므로 구성요소의 결함으로

인해 심각한 영향을 받을 수 있다. 결함은 실수(코딩 오류)와 고의적(백도어)일 수 있다.

예를 들어 사물인터넷 같은 경우 패치하기가 어려워 나중에 취약점이 발견되면 문제가 생기므로 패치를 적용하는 것이 중요하다.

 

-보안 대책

사용하지 않는 종속성, 불필요한 기능, 구성 요소, 파일과 문서 등을 제거해야 한다.

dependencyCheck, retire.js와 같은 도구를 사용하여 클라이언트 및 서버 측의 구성 요소

(라이브러리, 프레임워크)와 해당 종속성의 버전을 지속적으로 관리한다.

à 패치 관리 프로세스가 있어야 함

CVE와 NVD로부터 구성요소 내 취약점을 지속적으로 모니터링 해야하고. 소프트웨어 구성 분석

도구를 사용하여 프로세스를 자동화 해야한다. 또한 사용하는 구성요소와 관련된 보안 취약점에 대한 알림을 구독해 매번 확인한다.

조작되거나 악의적인 구성 요소가 포함될 가능성을 줄이기 위해 안전한 링크를 통해 공식적인

출처로부터 구성 요소를 획득해야만 하고 서명된 패키지를 사용해야 한다.

유지 관리되지 않거나 이전 버전의 보안 패치를 만들지 않는 라이브러리 및 구성 요소를 모니터링하고 패치가 불가능한 경우 발견된 문제를 모니터링, 탐지 혹은 보호하기 위해 가상패치를 배포하는 것을 고려해봐야 한다.

 

 

 

 

 

 

 

-A.10 불충분한 로깅 및 모니터링

 

불충분한 로깅 및 모니터링에 대한 공격은 거의 모든 중요한 보안사고의 기반이 된다.

공격자는 탐지되지 않고 부족한 모니터링과 부적절한 대응에 의존해 공격을 시작하는데 취약성 탐색을 계속하다 보면 공격 성공율이 매우 높아져 피해를 충분히 입힐 수 있다.

불충분한 로깅 및 모니터링이 진행중인지를 확인하려면 다음과 같다.

로그인, 로그인 실패, 높은 가치를 가진 트랜잭션들과 같은 감사해야 할 이벤트들이 기록되지 않는 경우, 경고 및 오류에 대해 로그 메시지가 없거나, 불충분하거나 불명확한 경우

의심스러운 활동에 대해 애플리케이션과 API의 로그를 모니터링하지 않는 경우

로그를 저장하더라도 로컬에만 저장하는 경우, 경고 입계값과 응답 에스컬레이션 프로세스가 적절하지 않거나 효과적이지 않는 경우, 실시간으로 유효한 공격을 탐지, 에스컬레이션 또는 경고를 못하는 경우, 사용자나 공격자에게 로깅이나 경고 이벤트가 보여져 정보 유출문제가 있는 경우

 

이러한 취약점을 통한 공격 시나리오 예이다.

-오픈소스 포럼 소프트웨어에 결함이 악용되어 해킹당했다. 공격자는 다음 버전과 내부 소스코드 저장소를 삭제했다. 소스코드를 복구할 수 있었지만 이렇게 모니터링, 로깅 혹은 경고의 부재 때문에 훨씬 더 큰 불이익을 초래하게된다.

-공격자는 공통암호를 사용하는 사용자를 찾기 위해 스캔을 한다. 다른 모든 사용자의 경우

이 스캔은 단지 하나의 잘못된 로그인 기록만을 남게되고 며칠후 다른 비밀번호로 작업을 반복 수행해 원하는 결과를 얻게 될 수 있다.

-특정 기업이 내부 악성코드 분석 샌드박스를 갖고 있었다. 샌드박스 소프트웨어는 잠재적으로

원치않는 소프트웨어를 탐지했지만, 이 탐지에 아무도 대응하지 않았고 나중가서야 보안사고가 탐지되서야 알게된다.

 

이러한 취약점을 해결하기 위해 충분한 모니터링을 하고 충분한 로그가 기록되어야 한다.

-모든 로그인, 접근 통제 실패, 서버 측면의 입력값 검증 실패 등이 의심스럽거나 악의적인 계정을 식별할 수 있는 충분한 사용자 문맥으로 기록될 수 있는지 확실시 해야한다.

그리고 포렌식 분석을 허용할 수 있는 충분한 시간이 확보되어야 한다.

-중앙 집중적 로그 관리 솔루션에 의해 쉽게 사용될 수 있는 형식으로 로그가 생성되는지 확실시 해야 한다.

-부가 가치가 높은 거래에는 단지 추가만 가능한 데이터베이스 테이블과 같은 변조나 삭제를 방지하기 위한 무결성 통제 기능을 갖춘 감사 추적 기능을 확실시 해야 한다.

-의심스러운 활동이 적시에 탐지되고 대응될 수 있도록 효과적인 모니터링 및 경고를 설정해야 한다.