다음은 다른 절에서 기술하기에는 적당하지 않을 것 같은 여러가지 기타 보안 지침들이다:
프로그램의 가정들을 사용하기 전에 적어도 (프로그램 시작부분에서) 프로그램이 이들의 일부를 검사하게 하라. 예를 들어 주어진 디렉토리에 설정된 "sticky" 비트에 의존한다면 이를 검사해라. 이러한 검사들은 거의 시간이 걸리지 않지만 심각한 문제를 예방할 수 있다. 각 호출에 대해 약간의 검사에 걸리는 시간이 우려된다면 적어도 설치시에 검사를 하거나 또는 더욱 좋은 것은 애플리케이션 시동시에 적어도 검사를 수행해라.
내장 스크립팅 언어를 갖고 있다면 이 언어가 스크립트를 호출하는 프로그램에 나쁜 영향을 미칠 수 있는 환경 변수를 설정하는 것이 가능할 수도 있다. 이에 대처해라.
복잡한 설정 언어가 필요하다면 이 언어가 주석 문자를 갖고 있고 주석처리된 많은 보안적인 예들을 포함하는 지 확인해라. 대개 '#'이 주석을 다는데 사용되는데 이 라인의 나머지가 주석이다.
가능하다면 setuid 또는 setgid 루트 프로그램을 작성하지 마라; 대신 루트로 사용자 로그인을 해라.
코드에 서명해라. 이렇게 함으로써 얻을 수 있는 것이 보내졌던 것인지를 살펴보기 위해 다른 사람들이 검사할 수 있다.
정적으로 링크되는 보안적인 프로그램을 고려해라. 이는 보안적인 프로그램이 동적 링크 라이브러를 사용하지 않음을 확인함으로써 이 메카니즘에 대한 공격에 대응한다. 그러나 이는 몇가지 단점이 있는데 동일한 루틴의 다중 복사때문에 디스크와 메모리 사용을 증가시킬 수 있으며 또한 더욱 바람직 하지 않은 것은 보안 취약성에 대한 라이브러리 갱신을 더욱 어렵게 만든다 - 대부분의 시스템에서 이들은 자동적으로 갱신되지 않을 것이며 개별적으로 찾아내 구현되어야 한다.
코드를 자세히 검토할 때 일치하지 않는 모든 경우를 고려해라. 예를 들어 switch 문이 있다면 cases 중 아무 것도 일치하지 않을 때 무엇이 발생할 것인가? "if" 문이 있다면 조건이 실패할 때 무엇이 발생할 것인가?
단지 파일을 ``removing" 한다고 해서 이 디스크로부터 파일 데이타를 제거하는 것은 아니다; 대부분의 시스템에서는 이 내용을 ``deleted" 로 표시하여 추후 재사용에 알맞게 만들며 대개 데이타는 적어도 다른 곳 (메모리, 스왑 파일 및 임시 파일) 에 일시적으로 저장된다. 정말로 단호한 공격에 대항하기 위해서는 데이타를 겹쳐쓰는 것으로는 충분하지 않다. 자성체 미디어를 지우는 문제에 대한 고전적인 논문은 Peter Gutman 의 논문 ``Secure Deletion of Data from Magnetic and Solid-State Memory''이다. 과감한 적은 컴퓨터에서 방출되는 전자기 모니터링 (군사 시스템들은 이를 극복하기 위해 TEMPEST 규칙을 따라야 한다) 및 키보드에 숨겨진 모니터와 같은 비밀 공격 등의 다른 방법을 사용할 수도 있다.
보안 취약성을 수정할 때 (현재 수정된) 취약성을 악용하려는 시도를 탐지해 기록하기 위해 ``경고" 를 추가하는 것을 고려해라. 이는 특히 공격자가 공격이 효과가 있을 것인지 미리 결정할 방법이 없다면 진행중인 공격을 노출시키기 때문에 공격 가능성을 감소시킬 것이다. 요약하면 취약성을 침입 탐지 시스템으로 변환시켜라. 이는 또한 인증전에 서버 프로그램의 버전을 드러내는 것은 보안에 대해 나쁜 개념이라고 제안한다. 왜냐하면 버전을 드러냄으로써 공격자가 효과가 있을 공격만을 사용하는 것을 쉽게 하기 때문이다. 몇몇 프로그램은 공격자가 ``잘못된 공격"을 사용해 탐지될 수 있도록 의도적으로 버전을 틀리게 말하는 것을 가능하게 한다. 또한 취약성이 네트워크를 통해 유발된다면 반드시 보안 스캐너가 취약성을 탐지할 수 있도록 하기바란다. 저자는 Nessus 를 사용하기를 추천하는데 반드시 오픈 소스 보안 스캐너가 문제점을 탐지할 수 있도록 해라. 이렇게 함으로써 갱신에 대해 소프트웨어를 검사하지 않는 사용자가 최소한 보안 취약성 스캔동안에 문제에 배울 것이다.
때때로 이 책과 같은 보안 지침을 검토해라. 최소한 11장 내의 결론을 다시 읽은 후 소개 (1장) 로 되돌아가 다시 읽어라.