프로그램 시동, 세션 시동 및 수상한 행동에 대한 감사 기록을 작성해라. 가치있는 가능한 정보로는 날짜, 시간, uid, euid, gid, egid, 단말기 정보, 프로세스 id 와 커맨드 라인 값들이 있는데 syslog(3) 함수가 감사 로그를 구현하는데 있어 도움이 될 수 있다. 한가지 조심해야할 문제는 모든 로깅 시스템이 많은 정보 (이 정보가 매우 도움이 될 것이기 때문에) 를 기록할 수 있어야 하지만 이 정보가 주의깊게 다뤄지지 않는다면 정보 자체가 공격하는데 사용될 수 있다는 것이다. 결국 공격자는 프로그램에 보내지는 입력의 일부를 제어하는데 있을 수 있는 공격자에 의해 보내진 데이타를 기록할 때는 로그가 손상되지 않도록 ``예상된" 문자들의 목록을 확인하고 모든 ``예기치 않은" 문자들을 이스케이프해라. 이렇게 하지 않으면 실제 문제가 될 수 있다; 사용자가 실제 문제를 일으킬 수 있는 제어 문자들 (특히 NIL 또는 라인 끝) 과 같은 문자를 포함할 수도 있다. 예를 들어 공격자가 개행 문자를 끼워넣는다면 개행 문자뒤에 원하는 로그 엔트리를 놓음으로써 그 엔트리를 변조할 수 있다. 불행히 이러한 문자들을 이스케이핑하는 것에 대한 표준 관례가 있을 것 같지는 않다. 저자는 URL 이스케이핑 메카니즘 (%hh, hh 는 이스케이프되는 바이트의 16진수) 을 특히 좋아하지만 C 관례 (8진수에 대해 \ooo, \X, X 는 특별 심볼로 예, 개행 문자에 대해 \n) 를 포함해 다른 것들도 있다. 또한 캐럿 (caret) 시스템 (^I 는 control-I) 도 있지만 이 시스템은 127 위의 바이트 값을 다루지는 못한다.
시스템이 감사 레코드를 저장하기 위한 자원을 다써버릴 때까지 감사 레코드를 기록되게 하는 매우 많은 수의 이벤트를 수행함으로써 사용자가 서비스 부인 공격 (또는 적어도 감사 중지) 을 만들 수 있는 위험이 있다. 이 위협에 대처하기 위한 한가지 접근 방법은 감사 기록 레코딩의 정도를 제한 (rate limit) 하는 것이다; 너무 많은 감사 레코드들이 기록되고 있다면 의도적으로 응답 속도를 감소시켜라. 또한 의심스러운 공격자에게만 응답 속도를 줄이려고 할 수도 있지만 많은 경우 단독 공격자가 잠재적으로 많은 사용자들로 가장할 수 있다.
물론 무엇이 ``수상한 행동"인가를 선택하는 것은 프로그램이 하는 일과 이의 예상된 사용에 의존하는데 초기에 논의한 필터링 검사에서 걸러지지 않는 모든 입력이 아마도 후보이다 (예, NIL 을 포함하여). 정상 사용으로부터 생길수 없는 입력은 될 수 있는한 기록되어야 하는데 특정 요구 필드가 수상한 방식으로 사라지는 CGI 스크립트가 그 예이다. /etc/passwd 또는 /etc/shadow 또는 비슷한 문장을 갖고 있는 모든 입력은 많은 경우 매우 의심스럽다. 비슷하게 윈도우의 "registry" 파일 또는 .pwl 파일에 접근하려는 것은 매우 의심스럽다.
감사 레코드에 패스워드를 기록하지 마라. 종종 사람들은 여러 시스템에 대해 패스워드를 우연히 입력하는데 따라서 패스워드를 기록하는 것은 시스템 관리자가 관리 영역 외부의 다른 컴퓨터에 침입할 수 있도록 한다.