Last Update: 28 Jun 2000

6 보안 정책

• 6.0 서론
• 6.1 회사 정책
• 6.2 정보 보안 정책
  • 6.2.1 개념
  • 6.2.2 정보의 분류
• 6.3 인사 보안 정책
  • 6.3.1 윤리
  • 6.3.2 패스워드 정책
  • 6.3.3 일반적인 소프트웨어 정책
  • 6.3.4 네트웍
  • 6.3.5 인터넷
  • 6.3.6 랩탑 및 이동형 컴퓨터
• 6.4 컴퓨터 & 네트웍 보안
  • 6.4.1 시스템 관리 정책
    • 6.4.1.1 물리적 보안
    • 6.4.1.2 접근 통제
    • 6.4.1.3 로그온 정책
    • 6.4.1.4 보증
    • 6.4.1.5 책임 추적성 및 감사
    • 6.4.1.6 서비스 신뢰성
  • 6.4.2 네트웍 정책
    • 6.4.2.1 네트웍/ 분산시스템 정책
    • 6.4.2.2 다이얼 인 접근
    • 6.4.2.3 다이얼 아웃 (PSTN/ ISDN)
    • 6.4.2.4 인터넷 방화벽
    • 6.4.2.5 다른 네트웍과의 인터페이스
    • 6.4.2.6 사고 대응 절차
  • 6.4.3 소프트웨어 개발 정책 (UC)
    • 6.4.3.1 일반적 지침
    • 6.4.3.2 프로덕션 지침
• 6.5 사업 연속성 계획 (UC)
• 6.6 정책 시행

각주
참고

서론

보안 정책은 보안에 관한 경영 전략 성명서이다. 정책문은 다음의 제목들로 묶여져 있다 :

1. 회사 정책
2. 정보 보안 정책
3. 인사 보안 정책
4. 물리적, 환경적 보안 정책
5. 컴퓨터 & 네트웍 보안
   • 시스템 관리
   • 네트웍 정책
   • 어플리케이션 개발 정책
6. 사업 연속성 계획

정책은 어떤 보안 주제에 대한 요점을 서술해야 한다, 그것이 왜 필요/중요한지, 그리고 어떤 것이 허용되고 어떤 것이 허용되지 않는지를 설명해야 한다. 너무 자주 변경이 일어나지 않도록 일반적이어야 하고, 시스템 의존적이거나 아키텍쳐가 아닌 일반적인 지시를 포함하고 있어야 한다. 정책에서는 또한 시행에 대한 문제를 풀어야 한다. 즉, 정책이 위반될 경우 어떠한 징계조치가 취해질 것인지가 명확해야 한다.
정책은 간결하고, 생산성과 보안의 적당한 균형을 이루며, 적절한 보안도구로 뒷받침되고, 이해하기 쉬워야 한다.

조직의 관리자들(line managers)은 정책이 지켜지고 이행되어지게 할 책임이 있다.
시스템 관리자들은 인사 정책에 대해 알아야 하고 개발자들은 인사 및 (시스템) 관리 정책에 대해 모두 알고 있어야 한다.
정책은 몇 개의 부분으로 나뉘어져 있으므로, 인사정책을 가능한 한 작고 '친숙하게' 만들어 직원들이 실제로 이것을 읽을 가능성이 최대화 되도록 한다.

결정적인 성공 요인
정보 보호의 성공적인 이행은 [bsi1] 다음에 달려있다:

1. 보안 목표와 활동은 사업의 목표 및 요구사항에 기반을 두어야 하고, 경영진에 의해 이끌어져야 한다.
2. 최고 경영자로부터 가시적인 지원과 약속이 있어야 한다.
3. 회사의 자산에 대한 보안 위험 (위협과 취약성) 및 조직내의 보안 수준에 대해 올바른 이해가 있어야 한다.
4. 보안은 모든 관리자와 직원들에게 효과적으로 팔려야한다.
5. 모든 직원과 계약직원에게 보안 정책 및 표준에 대한 포괄적인 지침이 배포되어야 한다.

이 장의 나머지 부분에서는 정책 개발에 필요한 사항들을 나열한다. 이후의 절들에서 쓰이는 기호 에서 까지는, 어떤 민감성 등급 이상의 데이타 보호가 필요한지를 나타낸다.

6.1 회사 정책

각 사업단위는 각자의 보안정책을 만들 책임이 있다. 이 정책은 업무 데이타의 보호와 관련위협/위험에 대응하는 프로세스, 그리고 그 자산들의 가치에 대한 원칙을 규정해야 한다.

모든 데이타는 (회사의) 민감성 등급에 따라 분류,표시되어야 한다.

6.2 정보 보안 정책

6.2.1 개념

• 모든 주요 정보 자산에는 소유주가 있어야 한다.
• 소유주는 법적 규제, 비용, 회사 정책 및 사업적 요구에 따라 민감성 등급(아래에 나열된) 중의 하나로 정보를 분류해야 한다., 소유주는 이 정보를 보호할 책임이 있다.
• 소유주는 이 데이타에 누가 접근할 수 있는지 선언해야 한다.
• 소유주는 이 데이타에 대해 책임이 있고 민감성에 따라 이를 직접 보호하거나 보호되도록 해야 한다.

6.2.2 정보의 분류

정보를 4등급으로 분류하는 분류시스템을 제안한다. 가장 낮은 이 가장 덜 민감하고, 가장 높은 이 제일 중요한 데이타/프로세스 이다. 각 등급은 이전 등급을 포함하는 집합이다. 예를 들어, 시스템이 등급 으로 분류되었을 경우 그 시스템은 등급 과 , 그리고 등급 의 지시를따라야 한다. 시스템이 하나 이상의 민감성 등급을 가지는 데이타를 포함한다면, 그 시스템은 가장 기밀한 데이타의 등급으로 분류되어야 한다.

등급 : 공개/ 미분류 정보
설명: 이 시스템들에 있는 데이타는 회사와 아무 관계없이 공개될 수 있다. (즉 기밀 데이타가 아니다.) 데이타 무결성이 치명적이지 않다. 악의적인 공격에 의한 서비스 손실은 감수할 수 있을만한 것이다. 예: 기밀 데이타가 없는 테스트 시스템, 일부 공개 정보 서비스
보관에 대한 지침: 없음
전송에 대한 지침: 없음
파기에 대한 지침: 없음

등급 : 내부 정보
설명: 이 데이타에 대한 외부 접근은 금지되지만, 이 데이타가 공개되더라도 그 결과가 치명적이지는 않다. (e.g. 회사가 공개적으로 창피를 당할 수 있다.) 내부 접근은 선택적이다. 데이타 무결성은 중요하지만 치명적이지는 않다. 예) 개발그룹 (현재의 살아있는 데이타를 가지고 있지 않은)의 데이타, 일부 공개 서비스, 일부 고객 데이타, "일상적인" 작업 문서 및 프로젝트/회의 의정서, 사내 전화번호부.

보관에 대한 지침:

1. 정보는 분류 표시(label) 되어야 한다. 즉, 분류 레벨이 문서, 매체(테이프,디스켓,디스크,CD 등), 전자메시지 및 파일 등에 씌어져 있어야 한다.
2. 바이러스에 감염되기 쉬운 IT 시스템들에 대해 주기적으로 바이러스 검사가 수행되어야 한다. 시스템의 무결성이 주기적으로 감시되어야 한다.

전송에 대한 지침:

1. 외부 파트너와의 협력을 수반하는 프로젝트에 대해, 어떤 정보를 외부 파트너와 공유해도 좋은지를 프로젝트 정책 문서에 (계약조항으로) 명기해야 한다.
2. 이 정보는 회사 내에 머물러 있어야 하고, 꼭 공개 매체(인터넷 같은)를 통해 전송해야 한다면, 암호화 되어야 한다.
3. 내부 데이타는 1번과 2번의 경우를 제외하고는 회사 밖으로 옮겨져서는 안된다.

파기에 대한 지침: 없음

등급 : 기밀 정보
설명: 이 등급의 정보는 회사 내부 정보로 외부 접근으로부터 보호된다. 이러한 데이타가 인가되지 않은 사람에 의해 접근되었을 경우, 회사의 운영상 효율성에 영향을 줄 수 있고, 중대한 재정적 손실을 야기할 수 있으며, 경쟁사에게 상당한 이익을 주거나 고객 신뢰도가 상당히 저하될 수 있다. 데이타 무결성은 필수적이다. 예) 급여, 인사 데이타, 회계 데이타, 패스워드, 회사 보안 취약점에 대한 정보, 매우 비밀스러운 고객 데이타 및 비밀 계약서 등. 데이타 센터는 보통 이 수준의 보안을 유지한다.

보관에 대한 지침:

1. 정보는 분류 표시(label) 되어야 한다. 즉, 분류 레벨이 문서, 매체(테이프,디스켓,디스크,CD 등), 전자메시지 및 파일 등에 씌어져 있어야 한다.
2. 바이러스에 감염되기 쉬운 IT 시스템들에 대해 주기적으로 바이러스 검사가 수행되어야 한다. 시스템의 무결성이 주기적으로 감시되어야 한다. IT 시스템들은 데이타 및 프로그램에 대한 비인가 변경에 대해 보호되도록 구성되어져야 한다.
3. 정보는 잠금장치가 되어 있는 곳에 보관되어야 한다. (e.g. 문서는 잠겨진 캐비넷 안에, 컴퓨터는 잠겨진 방 안에).

전송에 대한 지침:

1. 패스워드는 평문(clear-text)으로 전송되어서는 안된다 (전자적으로든 종이로든)
2. 이 정보는 회사 내에 머물러 있어야 하고, 꼭 공중 매체(인터넷 같은)를 통해 전송해야 한다면, 암호화 되어야 한다. 암호화 알고리즘은 강력한 것을 사용해야 한다.[3]

파기에 대한 지침:

1. 정보가 더이상 필요하지 않을때는 안전하게 처리되어야 한다. (e.g. 문서는 분쇄기로, 오래된 디스크 및 디스켓은 파기 등)

등급 : 극비 정보
설명: 이 데이타에 대한 인가되지 않은 외부 또는 내부 접근은 회사에 치명적일 수 있다. 데이타 무결성은 필수적이다. 이 데이타에 접근할 수 있는 사람은 매우 적어야 한다. 이 데이타의 사용에 관해서는 매우 엄격한 규칙이 지켜져야 한다. 예) 군사 데이타, 현안의 주요 계약/재조직/재무 집행

보관에 대한 지침:

1. 정보는 분류 표시(label) 되어야 한다. 즉, 분류 레벨이 문서, 매체(테이프,디스켓,디스크,CD 등), 전자메시지 및 파일 등에 씌어져 있어야 한다.
2. 바이러스에 감염되기 쉬운 IT 시스템들에 대해 주기적으로 바이러스 검사가 수행되어야 한다. 시스템의 무결성이 주기적으로 감시되어야 한다. IT 시스템들은 데이타 및 프로그램에 대한 비인가 변경에 대해 보호되도록 구성되어져야 하고 매년 감사를 받아야 한다.
3. 정보는 잠금장치가 되어 있는 곳에 보관되어야 한다. (e.g. 문서는 잠겨진 캐비넷 안에, 컴퓨터는 잠겨진 방 안에).
4. 정보는 암호화된 형태로 보관되거나 물리적으로 안전하게 보호되는 분리가능한 디스크에 보관되어야 한다.

전송에 대한 지침:

1. 이 정보는 안전한 지역 밖으로 전송되는 동안 암호화 되어야 한다. 암호화 알고리즘은 강력한 것을 사용해야 한다.[4]

파괴에 대한 지침:

1. 정보가 더이상 필요하지 않을 때는 안전하게 처리되어야 한다. (e.g. 문서는 분쇄기로, 오래된 디스크 및 디스켓은 파기 등)

회사 및 법적 요구사항에 충실
지역,국가,국제적 법률 (e.g. 데이타 프라이버시, 음란물 유포) 및 다음 사항을 준수해야 한다:

인터넷 음란물: 인터넷은 이제 가벼운 음란물에서터 아동 성도착, 나치 선전까지 불법 자료의 주요 운송매체로 보여지고 있다.
* 이러한 자료가 회사 인터넷 게이트웨이를 지나가는 것이 발견되면 전송이 차단되어야 한다.
* 직원은 회사 컴퓨터나 기반구조를 이용하여 그러한 자료에 접근해서는 안된다. 이 지시를 위반하는 사용자들은 징계될 수도 있다.

프라이버시 규정: 인사 데이타는 보관 또는 처리되는 곳의 데이타 프라이버시 관련 국가법규에 따라 보호되어야 한다.

6.3 직원 보안 정책

Part1의 "보안 메카니즘/인증" 장도 참고한다.

6.3.1 윤리

사용자들은 다음과 같은 일을 해서는 안된다: 계정이나 패스워드를 친구나 친척과 공유, 시스템 패스워드 파일에 대해 패스워드 체커 사용, 네트웍 스니퍼 사용, 서비스 두절, 시스템 자원 오남용, 이메일 악용, 다른 사용자의 파일을 파일 소유주의 요청 없이 검사, PC 바이너리 파일 다운로드, 라이센스 받지 않은 소프트웨어의 복사 또는 복사허용

6.3.2 패스워드 정책

패스워드 관리에 대한 상세한 논의에 대해서는 "Green Book" [green]을 참고한다.
사용자이름과 패스워드 조합에 의해 시스템에서 사용자가 식별된다. 좋은 개인 패스워드 정책을 채용하는 것이 현재 시스템들에의 비인가 접근에 대한 가장 중요한 방어책이다.

내용
* 숫자,대문자,소문자,구두점의 혼합사용
* 기억하기 쉬운 것(적어놓을 필요가 없도록)
* 빨리 타이핑할 수 있는 것 (다른사람이 관찰하기 어렵도록).

예
* 시나 노래의 한두개 라인을 골라 첫글자만 따온다.
* 작은 단어 두개를 이상한 문자를 써서 조합한다.
* 두문자어(acronym)를 만든다.

나쁜 예
* 배우자,부모,동료,친구,애완동물,동네,달,요일 이름.
* 자동차/오토바이 등록번호, 전화번호.
* 일반적인 사전 단어 (불어,독어,영어,이태리어,...).
* 동일한 숫자/문자의 연속
* 뻔한 키보드 연속 순서
* 위 항목들을 거꾸로 하거나, 앞 또는 뒤에 숫자를 붙인것.

지침
* 적어놓거나 이메일로 드러내지 않는다.
* 디폴트 패스워드는 사용하면 안된다.
* 다른사람에게 패스워드를 알려주지 않는다.
* 어떤 시스템상에서 패스워드들이 노출되었을때는 즉시 시스템의 모든 패스워드들을 변경한다.
* 관리자 (또는 루트) 패스워드를 공유하지 않는다. 대신 사용자 그룹이나 su 유틸리티 같은 것을 사용한다.
* 가능하다면 플랫폼들간에 사용자 패스워드를 동기화 하도록 노력한다. 사용자가 하나의 패스워드만을 기억해도 된다면 더 좋은 패스워드를 선택하려 할 것이다. Single Sign-On에 대한 논의는 "보안 메카니즘" 장을 참고한다.
* 크래킹의 위험/성공결과에 대해 사용자들에게 자세히 알려준다. 교육이 잘된 사용자를 만드는 것이 좋은 패스워드의 선택을 보장하기 위한 가장 좋은 방법이다.
* 벤더에 의해 정의된 디폴트 패스워드는 시스템을 사용하기 전에 변경해야 한다.
* 패스워드는 암호화된 형태로 저장되어야 한다. 암호화는 강력해야 하고, 성능좋은 워크스테이션에서 일주일간의 brute force 복호화를 견딜 수 있어야 한다.
* 패스워드는 입력되는 동안 화면에 나타나서는 안되고, 각 문자에 대해 "*"가 나타나서도 안된다.
* 사용자가 다른 사용자들의 (암호화된) 패스워드를 (패스워드파일에서) 읽을 수 있으면 안된다.
* 소프트웨어에 평문(clear-text) 패스워드를 넣어 두는 것은 어떤 일이 있어도 피해야 한다. 암호화된 패스워드를 묻는 것도 가능한한 피해야 한다.
* 패스워드의 최소기간, 최대기간, 최소길이 및 이력목록 등을 규정해야 한다. E.g.

최소 사용기간 = 2 일, 최대 사용기간 = 6 개월, 최소 길이 = 6 문자.
최소 사용기간 = 2 일, 최대 사용기간 = 30일, 최소 길이 = 6 문자.
패스워드 이력: 최근 사용된 5개의 패스워드는 금지되어야 한다.

* 허용되는 패스워드 내용을 규정해야 한다. 시스템은 패스워드를 수용하기 전에 이 규칙에 따라 패스워드 내용을 검사해야 한다. E.g. 위 나쁜 예 절을 참고.
* 사용자는 다른 사용자의 패스워드를 변경할 수 없어야 한다. 그러나, 계정 운영자는 사용자 패스워드를 변경할 수 있다.
* 특별한 어플리케이션 계정의 경우 (e.g. 유닉스에서의 오라클), 패스워드를 봉쇄하여 Interactive 로그온을 막아야 한다.
* 가능하면 처음 로그인할 때 강제적으로 패스워드를 변경하도록 한다.
* 보다 강력한 인증을 고려한다. (e.g. 스마트 토큰, 칩 카드, 생체인증 등).
* 가능하다면 자동 패스워드 생성 기능을 제공한다 (사용자를 돕기위해).
* 패스워드 체커가 주기적으로 취약한 패스워드를 검사해야 한다.(주 1회)

6.3.3 일반적인 소프트웨어 정책

• 공개 소프트웨어는 등급 및 의 TCB를 가지는 시스템에서 (즉 도스/윈도우가 아닌), 설치 책임이 있는 시스템 관리자가 저자/소스의 무결성에 대해 확신하는 경우에 한해 사용할 수 있다.
• 등급 의 시스템에서는 공개 소프트웨어의 사용을 피해야 한다. 그렇지만, 필요할 경우, 소스코드 검토 후, 또는 (소스코드가 너무 크다면) 소프트웨어가 다른 많은 회사(잘 알려져 있고 믿을 수 있는)들의 비슷한 시스템들에서 최소한 1년이상 일반적으로 사용되고, 보호되는 환경에서 소프트웨어가 엄격히 테스트된 후에만 사용할 수 있다.
• 라이센스 받지 않은 소프트웨어를 사용해서는 안된다.
• 게임이 자원 (디스크/메모리/CPU) 의 5% (예를들어) 이상을 사용하지 않으며 악용되지 않는다는 것을 시스템 관리자가 보장할 수 있을 경우, 시스템상에 설치가 허용된다.
• 유닉스: set-user-id (SUID) 및 set-group-id (SGID) 스크립트들은 시스템 상에 허용되지 않는다. 대신 펄이나 컴파일된 프로그램을 사용한다.

6.3.4 네트웍

1. 기밀정보
   • 공중 네트웍을 거쳐 전송되는 기밀 데이타는 암호화 되어야 한다.
2. 네트웍에의 연결:
   • 사용자는 컴퓨터 및 장비를 사내 LAN을 제외한 어떤 네트웍에도 연결할 수 없다.
   • 외부 (공중&사설) 네트웍에의 접근은 방화벽을 거쳐 일어나야 한다.모든 방화벽은 회사 보안에 따라 설치 및 유지되어야 한다.
3. 모뎀:
   • 사용자들은 컴퓨터 및 장비에 모뎀을 가질 수 없다.
   • 사내 LAN으로의 다이얼-인 접속은 일정한 사용자들에게는 허용된다. 모든 다이얼-인 접속은 일회용 패스워드 메카니즘을 가지는 안전한 서버상에서 일어나야 한다.
4. 이메일
   • 사용자들은 보통의 이메일 시스템들이 프라이버시나 송수신 증명을 보장하지 않는다는 것을 알고있어야 한다. 많은 시스템들에서 시스템 관리자가 모든 이메일을 읽을 수 있다.
   • 등급 의 데이타는 사내에서 암호화 없이 내부적으로 전송될 수 있다. 등급 은 암호화되어야 한다. 등급 의 데이타는 이메일로 전송되어서는 안된다.
   • 등급 의 데이타 및 외부와의 프로젝트를 위해 명확하게 허용된 정보만이 이메일을 통해 회사밖으로 전송될 수 있다.
   • 사용자들은 이메일로 전송된 매크로, PS파일, 설치프로그램을 여는 위험에 대해 알고 있어야 한다.

6.3.5 인터넷

인터넷 연결은 현재의 업무 환경에서, 특히 연구부서에서는 거의 불가피하다. 구조 및 통제의 부족으로 인해 인터넷은 다음과 같은 여러가지 위험을 가져온다:

• 기밀정보의 노출.
• 회사 네트웍이 인터넷 해커에 의해 침투될 수 있다.
• 정보가 변경 또는 삭제될 수 있다.
• 시스템 과부하로 인해 시스템으로의 접근이 거부될 수 있다.

인터넷 접근이 허용되려면, 사용자들은 내포된 위험 및 인터넷 사용 관련 회사정책에 대해 알고 있어야 한다. => 명확한 인터넷 정책이 존재해야 하고, 잘 알려지고 시행되어야 한다.

• 인터넷으로 나가는 모든 접근은, 회사 보안 정책을 준수하는 것으로 인증되고 승인된 회사 게이트웨이를 통해 나가야 한다.
• 표준 (WWW) 인터넷 접근이 허용된 사람은 누구인가? (e.g. 운영관리자, 연구부서)
• 인터넷 이메일 접근이 허용된 사람은 누구인가? (e.g. 모두!)
• 언제 접근이 허용되지 않는가? (e.g. 등급 서버로부터는 안됨).
• 어떤 인터넷 클라이언트 소프트웨어가 허용되는가? (e.g. 회사 표준)
• 인터넷 클라이언트를 사용할 수 없는 경우 및 대상은? (e.g. 음란물, 위험하거나 라이센스 없는 소프트웨어의 다운로드, 과도한 개인적 사용 등)
• 누가 인터넷 서비스를 제공 할 수 있는가? 어떤 조건에서? (e.g. 승인된 방화벽 정책, 공개로 분류된 정보만 게시)

6.3.6 랩탑 및 휴대용 컴퓨터

휴대용 컴퓨터는 직원들이 "이동하는 동안" 생산성을 높일 수 있도록 해주고, 정보에 접근할 수 있는 장소에 있어 유연성을 제공해 준다. 보안의 관점에서 볼 때 이들은 정보 노출, 절도 등의 위험을 유발할 수 있고, 회사 네트웍에 비인가 접속지점을 제공할 수도 있다. 이동 컴퓨팅 인구가 증가하고 있으므로, 특별한 정책이 필요하다.

몇몇 이슈들을 보면:

• 랩탑사용의 위험성에 대해 사용자들을 교육시킨다.
• 윈워드같은 사무용 프로그램에서 패스워드에 의한 보호는 견문있는 공격자에게는 무용지물이다.
• 분리형 하드디스크를 쓰면 가장 중요한 정보 구성원을 주머니에 넣어 쉽게 보호할 수 있다. 그런데 한편으로는 정보를 훔치기 쉽게 하기도 한다.

가능한 정책들은:

• 전문 IT 요원이 랩탑을 준비하고 설치하게 한다. 랩탑 모델 선택에 대해 적절한 조언을 해줄 수 있는 지식을 가진 직원을 둔다.
• 가능하다면 강력한 암호화를[5] 제공하고, 사용하기 쉬운 파일 암호화 프로그램을 설치한다. 디스크 암호화 프로그램도 대안이지만, 관리부담이 더 클 수 있고 성능 및 호환성에 영향을 줄 수도 있다.
• 일반 사용자가 시스템 전체에 접근할 수 없는 운영체제를 고려한다. (유닉스나 NT 같은)
• 사용자들은 회사 건물 밖에서 랩탑에 대한 책임을 진다.
• 가능하면 자동 화면 보호 메카니즘과 부트 패스워드를 사용해야 한다. 부트 패스워드는 호기심 많지만 지식은 없는 공격자로부터 보호해준다.
• 능동적인 바이러스 스캐너를 설치해야 한다. (모든 회사 사용자들에게 무료로 제공한다)
• 대중 운송수단에서는 랩탑을 손에 들고 다닌다.
• 등급 의 데이타는 암호화 되지 않은 상태로 랩탑으로 운송해서는 안된다.
• 사용하지 않을 때는 컴퓨터를 끈다.
• 회사 네트웍 시스템에 접근할 수 있는 패스워드를 절대 랩탑에 저장하지 않는다.
• 통신:
  • 등급 의 데이타를 암호화되지 않은 상태로 안전하지 못한 네트웍(인터넷, Mobile-GSM, 적외선 등)을 통해 전송하지 않는다.
  • 회사 네트웍으로의 전화접속에 대해 네트웍 접근 정책에 명시되어야 한다.
  • 사용하지 않을때는 모뎀을 꺼둔다.

6.4 컴퓨터 및 네트웍 정책

6.4.1 시스템 관리 정책

관리자는, 필요할 때 시스템이 사용 가능하고 기밀 정보는 접근이 허가된 사람들에게만 사용가능하며 정보가 불법 변경의 대상이 되지 않도록 보호해야 한다.
다음 사항들을 정의한다:

• 누가/어디서 관리 정책을 갱신하는가?
• 접근을 허용하고 사용을 승인할 권한은 누구에게 있는가? 누가 시스템 관리자 권한을 가질 수 있는가? [6]
• 관리자의 권리와 책임은 무엇인가?
• 사용자들은 자기 워크스테이션에 대해 루트/관리자 접근이 허용될 것인가?
• 관리자 권한을 가지는 사용자의 검색경로(PATH)에는 절대로 현재 디렉토리가 들어있으면 안된다. (트로이목마 예방)

6.4.1.1 물리적 보안

재난(홍수, 화재, 지진, 폭발, 정전 등), 절도, 접근통제, 금고, 컴퓨터실 및 배선 캐비넷 등과 관련하여 건물을 보호하기 위해 취할 조치에 대해 상세하게 정의한 물리적 보안 정책 문서가 있어야 한다. ("물리적보안" 장도 참고).

• 구역을 정의해야 한다. 예를 들어:

구역 1: 일반에게 열려진 영역.
구역 2: 일반에게는 열려있지 않고 회사 직원에게만 열려진 영역.
구역 3: 보호영역. 신분확인에 의해서만 접근 가능, 접근이 엄격히 통제됨.

• 손상된 기밀 디스크와 테이프를 파기할 책임은 누구에게 있는가?
• 낡은 서버/디스크/테이프를 파기할 책임은 누구에게 있는가? 이들을 수리해도 괜찮은가?
• 서버실 (구역3) 에 대한 지령을 정의한다:
  • 모든 컴퓨팅 장비는 깨끗하게 설치되고 레이블 되어야 한다.
  • 배선은 깔끔해야 하고 레이블되어야 하며, 뜻하지않게 어지럽혀지거나 절단되는 일이 없도록 해야 한다.
  • 어떤 서버가 어디에 설치되어 있는지에 대한 도표가 있어야 하고, 연락처 (contact person)도 같이 있어야 한다.
• 전자매체의 운반에 대한 지시사항들을 정의한다. (테이프, 백업, 디스크...)

6.4.1.2 접근 통제

• 모든 사용자는 인가되어야 한다.
• 사용자들은 자기 환경에서 자기에게 속하는 객체들의 권한을 설정할 수 있어야 한다.
• 사용자들이 공유 디렉토리에서 다른 사용자의 파일을 삭제하지 못하도록 방지되어야 한다.[7].
• 루트 로그인을 콘솔에서만 허용하는 것을 고려한다.
• 공인된 정책에 따라 시스템 상의 모든 객체(파일,프린터,장비,데이타베이스, 명령어, 어플리케이션 등)에 대한 사용자 접근을 통제할 수 있어야 한다.
• 사용자들이 다른 사용자들에게 부여된 접근 통제를 검사할 수 있어서는 안된다.
• 분류등급 에서 까지로 데이타를 표시(레이블)할 수 있어야 한다.
• 강제적 접근통제가 제공되어야 한다.

6.4.1.3 로그온 정책

기본 원칙: 사용자에게 작업에 필요한 최소한의 시간동안 최소한의 권한을 준다.

• 계정은 인가된 사람에 대해서만 존재해야 한다.
• 각 사용자는 이름이나 번호로 식별되어야 하고 그룹에 속해 있어야 한다.
• 사용자이름과 그룹이름의 구조는 가능한한 전사적으로 표준화되어야 한다. (문자의 개수, 배합) .
• 사용자와 그룹은 사용자 자신이 아니라 관리자 (또는 그에 상당하는 자) 에 의해 관리되어야 한다.
• 그룹 (공동)계정은 피해야 한다. (등급 에서 금지).
• 각 사용자는 시스템상에 하나의 계정만 가지고 있어야 한다.
• 게스트 계정이 사용되는 경우, 이들의 환경은 매우 제한적이어야 한다.
• 게스트 계정은 허용되지 않는다.
• 사용자이름과 패스워드는 같은 (한번의) 통신으로 배포되어서는 안된다.
• 사용자가 옮기거나 퇴직하면, 그 계정은 즉시 봉쇄 또는 삭제해야 한다. 인사관리자가 시스템관리자에게 자동적으로 통보하는 절차가 있어야 한다.
• 휴지기간 15분후에는 패스워드 있는 화면보호기가 작동되어야 한다.
• 사용자의 검색경로에 현재 디렉토리가 포함되어서는 안된다.
• 사용자 어플리케이션 및 시스템 구성은 그 사용자만 쓸 수 있어야 하고 모두가 읽을 수 있게 되어 있으면 안된다.[8].
• 사용자들의 파일 생성 마스크는 (유닉스에서 "umask" ), 새로 생성된 파일을 누구나 읽거나 쓸 수 있도록 주어서는 안된다.
• 사용자들은 보안을 위반하는 행위들에 대해 알고 있어야 한다. 마찬가지로 보안 위반이 의심되면 보안 관리자에게 통보해야 한다.

• 어떤 계정이 단시간에 연속적으로 로그인 실패하는 경우 ( e.g. 1시간동안 20번 시도), 계정을 봉쇄하고 사용자에게 알린다. 관리 계정에 대해서는 이렇게 하지 않는다! (서비스 거부 공격 취약점을 여는 것임)
• 사용자가 로그온 하면 다음 내용이 표시되어야 한다:
  1. 시스템 오남용과 관련한 법적 경고
  2. 마지막으로 성공 또는 실패한 로그인 시간 및 장비. (맞는지 사용자가 확인해야 함)
• 로그온은 필요할 때만 가능해야 한다. (e.g. 월요일에서 금요일까지 06:00 부터 22:00 사이)
• 슈퍼유저로 직접 로그온 허용을 피한다. 특히 한 시스템을 한 명 이상이 관리할 때에는 더욱 피해야 한다.
• 다이얼업 시스템에서:
  1. 3번의(예를들면) 로그인 시도 실패가 있었을 경우 전화선을 단절한다.
  2. 하루 중 어느 시간에 어떤 포트를 사용할 수 있는 지 규정할 수 있어야 한다.
• 사용자가 로그인 이름이나 패스워드를 잘못 입력했을 경우, 두 경우의 에러 메시지가 모두 같아야 한다. 공격자일 수도 있는데 사용자 계정이 유효하다는 것을 알려주어서는 안된다. 사용자 계정과 패스워드의 조합이 틀렸다는 것만 알려주는 것이 좋다.[9]
• 잘못된 사용자 이름/패스워드 조합이 입력되었을 경우, 1초를 기다린 후 로그인 프롬프트를 다시 띄워준다. 조합이 또 틀렸을 경우 2초를 기다리고, 다음 번엔 3초를 기다리는 식으로 한다. 이로써 공격자 및 특히 자동 로그온 공격 프로그램을 느려지게 (또한 짜증나게) 한다. [10]
• 관리자(administrator) 그룹의 멤버들은 관리자(management)의 인가를 받아야 한다.
• 한 사용자가 얼마나 많은 동시 세션을 가질 수 있는지 규정할 수 있어야 한다.
• 사용자 계정에 대해 만료일을 설정할 수 있어야 한다.

6.4.1.4 보증

• 시스템에 대한 감사가 정기적으로 실행되어야 한다. ( 일년에 한번, 3개월에 한번).
• 새로운 서버들은 담당 시스템 관리자가 설치 및 준비한다. 그리고 나서 보안 직원이 감사를 수행하고 민감성 레벨중의 하나로 인증한다. 어떤 시스템에 대해 모든 지령이 이행될 수 없다면 (예를들어 OS 한계때문에), 이러한 예외들은 인증시 명확히 문서화 되어야 한다.
• 현 운영체제의 ITSEC/TCSEC 요구사항 준수에 대해서는 "운영체제 개론" 장에서 논의한다.

6.4.1.5 책임추적성과 감사

• 감사 추적 로그 및 프로그램/유틸리티들은 보호되어야 한다. 보안 인력만이 이에 접근할 수 있어야 한다.
• 로그에는 패스워드가 포함되지 않아야 한다.
• 시스템 관리자의 행위 (특히 유닉스에서 su 사용)는 로그에 기록되어야 한다.
• 실패한 로그인 시도들은 로그에 기록되어야 한다. (또한 될 수 있는대로 통지되어야 한다).
• 중요한 이벤트들은 자동적으로 알람을 울려야 한다. (고순위 메시지)
• 주체에 대한, 그리고 객체에 대한 감사를 지정할 수 있어야 한다.
• 감사로그에서 각 엔트리는 최소한 다음을 포함해야 한다: 사용자이름 또는 UID, 날짜 및 시간, 단말 id, 에러 레벨 (성공 또는 실패) 및 이벤트 설명.
• 로그는 가능한 한 읽기전용 매체에 보관되어야 한다. (종이, WORM (write once, read many)). 로그는 또 각 시스템에 두는 것 보다, 가능하다면 특별히 안전한 시스템으로 전송되어야 한다. 공유 파일시스템 상의 로그 저장을 피한다.
• 모든 시스템은 클락을 동기화 하여, 감사로그에 찍힌 시간의 유효성을 보장한다.

6.4.1.6 서비스의 신뢰도

백업 및 복원 정책

• 백업은 정기적으로 이루어져야 하고, 어떤 백업 매체는 정기적으로 오프 사이트에 보관되어야 한다.
• 등급 백업은 잠겨진 금고안에 보관해야 한다. 모든 매체를 고려한다. ?은 테이프는 파괴되어야 하며, 그냥 버려져서는 안된다.
• 각 시스템이나 시스템 그룹에 대해 다음을 포함하는 백업 정책이 있어야 (문서화 되어야) 한다:
  • 언제 어떻게 (전체 혹은 증량적) 백업할 것인가, 매체는 어디에 얼마동안 보관할 것인가?
  • 백업은 얼마나 자주할 것이며, 올바로 운영되는지는 누가 확인할 것인가?
  • 색인은 얼마동안 보관하고, 어디에 보관하며, 압축된 매체에서 어떻게 추출될 수 있는가?
• 다음을 포함하는 복원정책도 있어야 한다:
  • 올바르게 운영되고 있는지를 누가 확인하는가?
  • 모든 어플리케이션에 대해 어떤 유틸리티를 사용하여 어떤 방법으로 데이타를 복원하는지에 대한 자세한 설명 (e.g. OS, 데이타베이스 복원 메카니즘).
  • 특히, 심각한 디스크 또는 다른 하드웨어 장애 후 운영체제를 복원하는 방법에 대한 자세한 설명이 필요하다. 내장된 EPROM 명령어의 사용, 단일사용자 또는 진단모드(사용가능한 경우)의 사용법 등을 문서화 해야 한다.
  • 다양한 재난 시나리오에 대한 예상 복원 시간도 문서화해야 한다.
• 복원정책을 정기적으로 테스트한다. ( 해마다)

변경 관리 (sw/hw 설치 또는 갱신)

• 시스템 관리자들만이 서버에 소프트웨어를 설치 또는 갱신할 수 있다. 사용자들은등급 의 워크스테이션에 소프트웨어를 설치할 수 없다.
• 시스템들은 벤더 지시에 따라 정확하게 설치되어야 한다.
• 모든 서버에서는 시스템의 모든 변경사항에 대한 상세한 변경로그가 보존되어야 한다. 최소한 다음을 포함하는 간단한 텍스트 파일이라도 생성할 것을 제안한다 (e.g. /etc/mods) : 날짜, 시스템관리자 이름, 변경된 파일 및 이유/코멘트.
• OS 설치에서는 모든 권장 패치를 포함해야 한다.
• 모든 시스템의 설치시 다음 정보를 포함하는 레이블이 부착되어야 한다: 호스트이름, 제조업체/모델, IP 주소, MAC 주소, 케이블링 노드 ID (네트웍 토폴로지에서 허용한다면), 보증만료기간 및 보안/헬프데스크 전화번호
• 서버에는 또 다음사항도 포함되어야 한다: 모든 주변기기에 서버이름 표기, 디스크종류/보증기간/수퍼블록/구성, 정지/재시동을 위한 콘솔 명령어 (e.g. 특별한 키 순서)
• SW의 원 제조업체로부터 나온 패치만 적용해야 한다. 인터넷 같은 공중망에서 내려받은 패치는 강력한 해쉬 메카니즘(MD5 같은)을 이용하여 무결성을 검사해야 한다. 패치는 테스트 환경에서 먼저 테스트한 후(가능하다면 적어도 몇 주 전에) 실제 시스템에 적용해야 한다.

6.4.2 네트웍 정책

컴퓨터들간의 정보 전송은 보안에 심각한 위협을 불러올 수 있다.

6.4.2.1 네트웍/분산 시스템 정책

1. 보증: 네트웍 구성은 문서화 되어야 한다.
2. 식별 및 인증:
   • 회사 네트웍 상의 모든 주체를 식별하고 인증할 수 있어야 한다.
   • 가능하다면, 단일 메카니즘으로 여러 어플리케이션들과 시스템들에 걸친 사용자 로그온이 가능하도록 하여, 여러개의 사용자이름과 패스워드가 존재하는 것을 피한다.
3. 책임과 감사
   • 사용자들은 자신들의 행동에 대해 책임을 진다. 이들은 "네트웍 사용자 정책"을 준수해야만 한다.
   • 중요한 네트웍 노드들은 activity를 로그해야 한다. 이 로그들을 정기적으로 분석하여 보안침해 흔적을 찾는다.
   • 중요한 필터들의 접근통제 리스트(ACL:Access Control Lists)에 대해 6개월마다 감사를 수행해야 한다.
4. 접근통제
   • 민감한 네트웍 노드의 구성: 불필요한 네트웍 서비스는 사용할 수 없어야 한다. 네트웍 서비스는 엄격하게 구성해야 하고, 모든 보안 bug fix (패치)를 설치해야 한다.
   • 사용가능한 네트웍은 무제한 접근, 제한된 접근 또는 매우 제한된 접근으로 분류 표시되어, 사용자/데이타 소유주들이 제공되는 보호에 대해 알고 있도록 해야 한다. 예를들어 어떤 LAN 이 무제한 접근으로 레이블 되어 있고 기밀 데이타가 이 LAN을 통해 전송되어야 한다면, LAN상의 보안 결핍을 보상하기 위해 어플리케이션 수준 암호화 같은 부가적인 조치가 필요할 것이다. 토큰 링과 FDDI는 제한된 접근의 예이다 (올바르게 관리된다면).
   • 제한된 접근의 네트웍이 필요한 경우, 배선은 공중 구역을 지나가서는 안되고, 전선관으로 보호되어야 하며, 접속점은 인가된 사람만 사용할 수 있어야 한다. 외부인이 배선을 담당했을 경우, 이를 점검한다.
5. 정확성: 중요한 네트웍 노드들은 자기 데이타에 대한 무결성을 정기적으로 검사해야 한다.
6. 데이타 교환:
   • 기밀 정보는 승인된 수송 메카니즘에 의해서만 전송되어야 한다. (e.g. 기밀 데이타에 사용되는 이메일 시스템들은 보안 관리책임자(management)의 승인을 받아야 한다.
   • 로그인 세션 정보(e.g. 사용자 이름, 패스워드)는 읽을 수 있는 형태로 네트웍을 통해 보내져서는 안된다.
   • 호스트간 네트웍 서비스들은 서로 상대방을 인증해야 한다.
   • 네트웍은 정보 도청으로부터 보호되어야 한다 => 사용자들이 snoop,etherfind, tcpdump, iptrace 등과 같은 네트웍 스니퍼 들을 사용할 수 없어야 한다. 네트웍은 서브넷으로 분리하고, 능동적 브릿지와 허브를 사용하며, 사용하지 않는 네트웍 접속점은 불능상태로 만들어야 한다.
     • 등급 데이타에 대해, 내부 네트웍 전송전 암호화를 고려한다. 공중망을 통해 전송되는 등급 데이타는 반드시 암호화 되어야 한다.
     • 가능하다면 네트웍은 전자기적 도청으로부터 보호되어야 한다.
   • 정보가 전송될 때 (송신 또는 수신), 송신자나 수신자의 신원이 정보에 첨부되어야 하고 전송에 대한 책임이 있는 여러 요소들에 의해 확인되어야 한다.
   • 등급 의 데이타는 더 낮은 등급의 비인가 사용자나 시스템으로 보내질 수 없다
   • 어떤 어플리케이션에서는(e.g. 등급 이메일), 송/수신자가 실제로 송/수신 했다는 것을 증명할 수 있는 메카니즘이 존재해야 한다. (송/수신자 증명)
7. 서비스의 신뢰성 / 가용성
   • 네트웍은 24시간, 일주일 내내 가동되어야 한다. 유지보수 시간은 수요일 18:00-22:00이다. 업무시간 동안의 최대 중단시간은 1시간이며, 최대 빈도는 2개월에 한번이다.
   • 네트웍 장애 및 성능문제에 대해 감시해야 한다. 심각한 네트웍 붕괴가 발생하기 전에, 가능한 곳에는 예방 조치가 취해져야 한다.
   • 변경관리: 갱신 및 구성 변경은 품질 프로세스에 따라 수행되고 로그되어야 한다.
   • 모든 시스템의 설치시 다음 정보를 포함하는 레이블이 부착되어야 한다: 호스트이름, 제조업체/모델, IP 주소, MAC 주소, 케이블링 노드 ID (네트웍 토폴로지에서 허용한다면), 보증만료기간 및 보안/헬프데스크 전화번호
   • 서버는 또 다음사항도 포함해야 한다: 모든 주변기기에 서버이름 표기, 디스크종류/보증기간/수퍼블록/구성, 정지/재시동을 위한 콘솔 명령어 (e.g. 특별한 키 순서)
   • SW의 원 제조업체로부터 나온 패치만 적용해야 한다. 인터넷 같은 공중망에서 내려받은 패치는 강력한 해쉬 메카니즘(MD5 같은)을 이용하여 무결성을 검사해야 한다. 패치는 테스트 환경에서 먼저 테스트한 후(가능하다면 적어도 몇 주 전에) 실제 시스템에 적용해야 한다.

원격 접근 정책: 외부 네트웍 인터페이스
네트웍들의 (X.25, 전화접속,인터넷, 벤더 네트웍, 고객 네트웍 등등) 연결이 보안 정책을 위반하는 결과를 가져올 경우, 서로 연결되어서는 안된다. 외부 네트웍에의 접속은 방화벽을 거쳐서만 일어나야 한다. 방화벽은 보안정책을 가지고 있어야 하고 정기적으로 감시 및 감사되어야 한다.

6.4.2.2 Dial-In 접속

들어오는 모든 전화연결은 (PSTN 또는 ISDN을 통해) 강력한 일회용 패스워드 인증 시스템(SecurID같은)을 사용해야 한다.

회사 네트웍으로의 전화접속은 필요한 경우에만 허용하되, 다음 조건들을 만족하는 경우라야 한다:

1. 보증
   • 전화접속 서버 구성이 정확하게 문서화 되어 있어야 한다.
   • 매년 감사를 받아야 한다.
2. 신원확인 및 인증
   • 들어오는 모든 전화연결은 (PSTN 또는 ISDN을 통해) 강력한 인증 시스템을 사용해야 한다: 일회용 패스워드, challenge-response 등등.
   • 관리자 로그인시 패스워드가 평문으로 보내져서는 안된다.
   • 또한, 가능한 경우에는 콜백이나 폐쇄 사용자 그룹(CUG) 기능들이 사용되어야 한다.
3. 책임추적성과 감사
   • 사용자들이 자신의 행동에 책임을 질 수 있도록 되어야 한다.
   • 전화접속 서버는 연결에 대해 상세 로그와 감사를 제공해야 한다.
   • 로그는 자동적으로 분석되고, 심각한 에러발생시 알람을 생성해야 한다.
   • 로그는 적어도 1년간 보관되어야 한다.
   • 의미있는 로그항목들은 매일 검사해야 한다.
   • 사용량에 대한 통계를 얻을 수 있어야 한다.
   • 서버는 (매주) 정기적인 모니터링과 매년 감사를 받아야 한다.
4. 접근 통제
   • 전화접속 서버들은 파일이나 프린터를 다른 내부 시스템과 공유할 수 없다. 즉, 파일이나 프린터 서버가 될 수 없다.
   • 관리직원들에게만 시스템상에 로그온이 허용된다.
   • 사용자들은 이 시스템들에 직접 로그온할 수 없다 (내부에서).
   • 전화접속 서버들은 물리적으로 안전한 (잠겨진) 방안에 설치되어야 한다.
   • 모뎀을 가지고 있는 사용자 목록을 유지해야 한다. 가능하다면 전화망을 주기적으로 스캔하여 비인가된 모뎀을 찾아낸다.
   • 밤에 필요하지 않을 경우에는 모뎀을 꺼둔다 (5달러짜리 타이머를 사서 할 수도 있다).
5. 정확성: 요구사항 없음.
6. 데이타교환
   • 가능하면, 특히 원격 관리업무 수행을 위한 접근시에는 암호화된 패스워드 통신을 사용한다 (e.g. 암호화된 텔넷, SSH).
   • 송수신 부인방지는 필요하지 않다.
7. 서비스의 신뢰성
   1. 전화접속 서버는 필요없는 모든 서비스를 중지시켜야 한다.
   2. 전화접속 서버는 견고한 다중작업 시스템이어야 한다. (e.g. UNIX, VAX 또는 NT).
   3. 전화접속 서버는 다음과 같은 가용성을 제공해야 한다: => 7x24h, 최대 중단시간 4시간 (업무시간동안), 최대빈도 한달에 두번. 유지보수 시간: 수요일 업무시간 후.
   4. 변경관리: 갱신 및 구성 변경은 품질 프로세스에 따라 수행되고 로그되어야 한다.
   5. 중요한 프로세스가 무너졌을 때 경고가 발생되어야 한다.
   6. 필요한 경우 정기적인 백업이 이루어져야 한다.

6.4.2.3 Dial-out (PSTN/ ISDN)

Dial-out 네트웍 연결은 회사 네트웍을 확장시켜, 네트웍으로의 통제되지 않는 접속점을 만들어낼 수 있다.

1. 사용자들은 시스템의 dial-out 기능 (모뎀)을 사용할 수 없다.
2. 그러한 기능이 필요하다면, 다음 조건을 만족해야 한다:
   • 관련된 부서 관리자와 사내 보안부서의 인가를 받아야 하고 인가는 매년 재발행 되어야 한다.
   • 중앙화된 "dial-out" 서버를 통해 사용해야 하고 서버는 사내 보안부서에 의해 매년 감사를 받아야 한다.
   • 모뎀을 가지고 있는 사용자 목록에 기록되어야 한다.
   • 가능하다면, 전화망에 비인가 모뎀이 있는지 정기적으로 조사해야 한다.

6.4.2.4 인터넷 방화벽

인터넷은 종종, 특히 연구부서에서는, 정보를 공유하고 검색하는데 중요한 도구가 된다. 회사 네트웍으로부터의 인터넷 접근은 반드시 방화벽을 거쳐 일어나야 한다.

1. 보증
   • 방화벽 정책 및 구성은 정확하게 문서화 한다.
   • 방화벽 시스템은 정기적으로 감시되고 매년 감사를 받아야 한다.
2. 신원확인 및 인증
   • 인터넷으로부터 들어오는 사용자 연결은 강력한 인증시스템을 사용한다: 일회용 패스워드, challenge-response, 등등.
   • 관리자 계정 또한 일회용 패스워드나 암호화된 로그인 세션을 사용한다.
3. 책임추적성과 감사
   • 방화벽과 프락시 시스템은 안전하게 설치되어야 한다. 운영체제에서 모든 불필요한 서비스들을 중단한다.
   • 상세한 방화벽 로그를 보존한다 (가능하다면 wirte-once 매체를 가지는 전용서버에).
   • 모든 보안감사 로그를 보존한다.
   • 로그는 자동적으로 분석되고, 심각한 에러는 경보를 발생하도록 한다.
   • 로그는 적어도 일년동안 보관한다.
   • 의미있는 로그항목은 매주 검사되어야 한다.
   • 사용량에 대한 통계를 얻을 수 있도록 한다.
4. 접근 통제
   • 회사 네트웍으로부터의 모든 인터넷 접근은 방화벽 안에 위치한 프락시를 통해 발생해야 한다.
   • 디폴트 구성: 명시되지 않은 한, 서비스들은 금지된다.
   • 모든 사용자들은 인터넷을 통해 이메일을 교환할 수 있다.
   • R&D 부서 사용자들은 WWW 와 ftp를 사용할 수 있다 (프락시를 통해). 다른 사용자들은 인가를 받아야 한다.
   • 사용자들은 인터넷에 서비스를 제공할 수 없다.
   • 실험용 서비스를 위해 완전한 인터넷 접속을 필요로하는 연구부서들은 이러한 서비스들을 회사 네트웍에 설치할 수 없고, 방화벽 외부의 분리된 네트웍에 설치해야 한다.
   • 사용자들은 방화벽 시스템에 직접 로그온할 수 없다.
   • 불법자료에의 인터넷 접근은 가능한 한 금지되어야 한다.
5. 정확성: 방화벽 시스템의 파일 무결성을 정기적으로 (매달) 검사하도록 한다.
6. 데이타 교환
   • 방화벽시스템으로의 모든 로그인 세션은 암호화된 로그인이나 일회용 패스워드를 사용한다.
   • 라우팅, DNS 및 이메일과 같은 네트웍 서비스의 전복(subversion)이나 스푸핑(spoofing)을 막아야 한다.
7. 서비스의 신뢰성
   • 방화벽은 다음과 같은 가용성을 제공한다: => 7x24h, 최대 중단시간 4시간(업무시간중), 최대빈도 한달에 두번. 유지보수시간: 수요일 18:00 이후.
   • 변경관리: 갱신 및 구성 변경은 품질관리 프로세스에 따라 수행되고 로그되어야 한다.
   • 중요한 서비스/프로세스 붕괴시 경고를 발생한다.
   • 중요한 서비스(WWW 프락시 같은)는 고가용성으로 구성한다.
   • 필요한 곳에 정기적 백업이 이루어져야 한다. (e.g. 구성파일, WWW와 같이 변하는 데이타).

6.4.2.5 다른 네트웍과의 인터페이스

다른 네트웍과의 인터페이스에도 (SNA, Decnet, X.25, ATM etc.) 마찬가지로 명확한 정책이 필요하다.

고객/벤더 네트웍과의 인터페이스
고객이나 벤더 사이트로부터의 회사 네트웍 접근은 점점 더 보편화되어가고 있다.

• 각 인터페이스에 대해, 어떤 정보가 어떻게 전송되고, 이것이 회사 보안 정책과 어떻게 관련되는지 설명하는 정책문서가 있어야 한다.
• 이러한 인터페이스들은 방화벽에 의해 보호되고 정기적으로 감시 및 감사를 받아야 한다. (위 내용 참조)
• 인터페이스가 네트웍 정책을 준수한다는 것을 보장하는 서비스 레벨 협약 (Service level agreement)이 있어야 한다.
• 인터페이스의 세부항목이나 인터페이스를 통해 접근 가능한 데이타의 제3자로의 유출 방지를 보장하는 유출 금지 협약에 고객/벤더의 서명을 받는다.

전화 네트웍
전화, 팩스 및 음성메일 시스템 및 네트웍은 공격자들의 빈번한 침투지점이다. 이 시스템들이 외부에서 접근할 수 있는 기능을 가지고 있다면, 악용을 막기 위한 정책이 필요하다.

6.4.2.6 사고 대응 절차

범위
이 절차에는 방화벽 상에 보안 사고가 발생했을 때 어떤 조치를 취해야 하는지를 상세하게 서술한다. 방화벽은 회사네트웍을 비인가된 인터넷 접근으로부터 보호 하도록 설계된 것이다. 방화벽은 보안 침해에 대해 정기적으로 감시된다. 침해가 탐지 되었을 때, 어떻게 대응 해야 할 지 알아야 한다. 그것이 이 절차의 목적이다. 사고에 대한 대응은 컴퓨터와 서비스, 정보의 정상적인 운영상태를 보호하고 복원하는 것을 목표로 한다.

• 법적인 측면은 여기서 다루지 않기로 한다. 이후 버전에서 다루어질 것이다.

목적
견고한 보안정책, 교육받은 사용자와 견고한 시스템 관리가 있다 하더라도 비상 대응팀은 유용하다. 재난 대비 계획을 세운다!

• "비상호출(Firecall)"을 받을 사람은 누구인가, 이들은 심각한 보안 침해에 대해 어떻게 대처해야 하는가?
• 내부 인력이 충분히 전문적이지 못하다면, 특화된 회사에 "비상대기" 용역을 계약할 수도 있다.
• 보안 사고 발생시 누가 담당할 것인지를 사전에 결정한다. 명령 체계를 결정한다 (프로세스와 책임을 정의한다).

사고 대응팀
주된 역할은 아래 이탤릭체로 표시되어 있다. 각 역할에 대해 백업 담당자가 있어야 한다.

관리(Management) 책임 A.Boss, (Tel. xxxx)
(전반적인 조정/책임) 백업: B. OtherBoss (Tel. xxxx)
책임: 이 문서가 존재하고 시행되도록 확실히 한다. 사업연속성에 대한 주요 위협을 인식. 행동의 우선순위를 정하고, 사고중 핵심 결정을 내리고 조정한다. 이 절차에 대한예외를 승인한다.

방화벽 기술적 책임 A. Techie (Tel. xxxx),
백업 B. OtherTechie (Tel. Xxx)
책임: 문제의 시스템들을 기술적으로 관리하는 방법을 안다. 사고를 탐지할 수 있고 손실을 제한하기 위해 기술적 조치를 취할 수 있다. 시스템에 대한 확실한 기술적 이해는 필수적이다.

언론 책임 A. Prman (tel. Xxx)
백업: A. OtherPrMan (Tel. Xxx)
책임: 매체 인터페이스, 공공성명, 언론 조정.
추가지원:
법적 조언 ?
First Response Team, 부록 참조.

절차
비상시에는 다음사항들을 각각 고려하고 시행해야 한다. 관련된 주요 조치들은:

1. 준비: 팀은 이 장을 읽고 그 내용을 알고 있어야 한다.
2. 사고 탐지: 기민한 평가
3. 즉각적인 조치: 손실을 한정
4. 홍보/언론관계
5. 상세한 상황 분석
6. 복구: 데이타/서비스/시스템의 복원
7. Follow-up

2. 사고탐지: 기민한 평가
무슨일이 일어났는가? :

• 위협의 원천: e.g. 우발적인 관리자 손상/실수, 우발적인 내부 또는 기밀 문서의 누출, 인터넷으로부터의 공격, 전화망으로부터의 공격, 회사 네트웍 내부로부터의 공격 또는 hoax(장난,가짜).
• 위협의 결과: 무결성, 기밀성 또는 시스템/서비스/데이타 가용성이 영향을 받을 수 있음.

공격이 발생했을 경우:

• 공격자가 시스템 침투헤 성공했다고 하자. 그는 다시 마음대로 들어올 수 있는가? 어디에서 침입자들이 탐지되었는가? 손실의 범위는 어느정도인가? 제기되는 주요 위험은 무엇인가? e.g. 가용성, 정보의 비밀성, 정보의 무결성, 불리한 홍보
• 하나의 위협원으로부터의 "명백한" 공격들은 사실 다른 위협원으로부터의 훨씬 더 많은 교묘한 공격들을 숨기고 있을 수도 있다는 것을 주의해야 한다.

3. 즉각적인 조치:손실을 한정:
심각한 공격이나 재난이 발생하면, 관리책임자 와 기술책임자는 위협을 제거하거나 손실을 제한하기 위해 필요한 즉각적인 조처를 결정해야 한다. (상황의 중대성과 사용자의 필요성에 따라)
=> 문제의 사고에 대한 처리를 누가 담당할 것인지가 명확해야 한다. 누가 전반적인 책임/조정자인지 정의한다. 명령체계를 확실히 이해하고 있도록 한다.
=> 이벤트 로그를 시작한다: 취해지는 각각의 조치,이벤트,발견된 증거에 대해 일일히 문서화한다. (시간과 날짜도 함께).

가능한 즉각적 조치들은:

• 정보의 복원,
• 관련 시스템을 네트웍으로부터 분리 또는 종료,
• 회사 네트웍을 인터넷으로부터 분리,
• 하나 또는 그이상의 원격접속서버(RAS)를 네트웍으로부터 제거, 종료, 전원 끔.
• 네트웍이나 컴퓨터를 끄지는 않지만, 사용자 서비스에 영향을 주지 않고 손실을 최소화하기 위한 시도 (위험한 접근법일 수 있음)
• 모든 로그/데이타를 즉시 테이프나 다른 오프라인 저장소로 복사

4. 홍보 / 언론

• 오직 언론책임자 만이 언론/기자들과 접촉하거나 진술할 수 있다.
• 공격의 세부사항이 이메일을 통해 누구와라도 논의되어야 한다면, 암호화 및 서명된 이메일을 사용한다 (e.g. via PGP).
• 필요하다고 생각되고 언론책임자의 인가를 받은 경우, FIRST/CERT 및/또는 영향받은 다른 사이트에 사고를 보고한다.
• 즉각적인 조치로 인해 서비스가 영향을 받을 경우, 사용자들에게 뭐라고 전해줘야 하는지 헬프데스크에게 알려준다.

5. 상세 상황 분석:

• 우선순위를 정하고, 무엇을 할 지 결정한다.
• 손실의 범위를 측정한다. E.g.
  • 시스템 분석: 변경된 파일은? 추가 또는 변경된 프로그램/계정은? 변경이 발견되면 비슷한 시스템들에서도 이런 변경을 확인한다.
  • 정확하게 무슨 일이 일어났는지를 입증하도록 노력한다.
• 필요에 따라 관리자 (administrators), 관리/경영자(management) 및 법률 시행당국에 통보한다.

6. 복구: 데이타/서비스/시스템 복원:

• 사고에 따라 다음 일들이 필요할 수 있다:
• 시스템을 지우고 데이타/프로그램/서비스를 복원.
• 시스템에서 발견된 취약점 해결.
• 손상된 시스템 상의 프로그램을 믿지 않는다. 안전한 사본과 비교한다.(e.g. CDROM 상의 OS).

7. Follow-up

• 모든 서비스들이 복원되었는가?
• 공격자가 이용한 취약점은 바로잡았는가? 원인은 다루어졌는가?
• 보험이나 법적 청구/절차를 제기해야 하는가?
• 이 사고 대응 절차를 변경할 필요가 있는가?
• 방화벽의 변경이 필요하다면, 방화벽 변경 절차를 활성화한다.

=> 절차 끝.

일반적인 지침:

• 연락처 이름, 전화번호, 이메일주소를 오프라인에 보관한다. 비상시에 온라인 주소록을 사용할 수 있을 것으로 가정하지 않는다.
• 침입자가 아주 영리해서 중단시키기 어려울 것 같으면, 전문가를 불러 도움을 청해볼 만 하다.
• 최근 몇개월 간의, 신뢰할 수 있고 간격이 짧은 백업들이 매우 중요하다.
• 유닉스 시스템들에 대해서는 [unix1]을 한 부 구해서 손쉬운 곳에 둘 것을 강력히 권고한다. 여기에는 탐지,감시, 제거 및 침입 이후의 청소에 대한 자세한 정보들이 들어있다. 방화벽 서비스에 대한 상세한 기술적 논의도 있다. 또한 [unix3]  [sans3]그리고
• NT 시스템들의 경우에는, NT 문제 예방에 대해 [sans2]를 참고하고, 공격에 대한 일반적 논의에 대해 [unix1] 도 참고한다.
• 이 사고대응 절차는, 될 수 있는대로 매년, 테스트 되어야 한다.
• 사용자들에 대한 두절을 최소화하고, 사용자들과 연락한다. 중요 서버를 일주일간 중단하고 외부 공격 소스를 추적하려 하는 것은 사용자들에게 그동안의 시간적, 경제적 손실만큼의 가치가 없을 것이다.
• 모든 사고 대응팀 구성원은 [sans1]을 필독한다.
• 위에 넣지 않은 CERT의 새로운 지침도 참고한다.
  대응: www.cert.org/security-improvement/modules/m06.html , www.cert.org/security-improvement/practices/p046.html
  정책: www.cert.org/security-improvement/practices/p044.html
• 이 책의 기술 관련 장들도 잊지 말 것!
• SANS Institute 에서는 쓸만한 소책자들을 많이 만든다. 예를들어 [sans1, [sans2], [sans3], 또 다른 보안 관련 책자들을 사이트에서 확인해 볼 것을 권한다. www.sans.org

6.4.3 소프트웨어 개발 정책

보안은 새로운 시스템의 필수적 부분이어야 한다. 기능적 요구사항들이 설계될 때, 시스템이 다룰 데이타의 민감성과 가용성에 대응하는 보안 요구사항을 명확히 나타낸다.

6.4.3.1 일반적 지침

• 개발과 프로덕션 환경/데이타를 분리한다.
• 보안을 어플리케이션 개발의 필수 부분으로 간주한다.
• 테스트 데이타는 기밀 정보를 포함하고 있어서는 안된다.
• 안전한 언어의 사용을 고려한다 (e.g. C 보다는 Java, Perl 보다는 Tainted Perl).
• 중요한 새 시스템들에 대해 ITSEC 승인 받을 것을 고려한다.

6.4.3.2 프로덕션 지침

어플리케이션과 함께 어떤 문서가 산출될 것인가? E.g.운영, 설치, 관리, 보안, 사용자 매뉴얼.

6.5 사업 연속성 계획

재난 계획과 정보 분류를 통해 중요한 업무 프로세스의 연속성이 보장되어야 한다.

전산화된 정보의 가용성
사업 연속성에 영향을 줄 수 있는 업무프로세스에는 고가용성이 요구된다. 이 프로세스들의 소유주는, 요구되는 가용성을 명시하고 IT 직원들이 이를 구현하도록 확실히 해야 한다.[11]

시스템 중복성
등급 또는 그이상의 시스템들은 어떤 형태로든 하드웨어, 서비스 또는 시스템 중복성 (Redundancy) 을 필요로 할 것이다. 가용성 등급에 대한 시스템 요구사항 (5장) 및 메카니즘 장(7장)을 참고한다.

보안 위기/재난
심각한 공격이나 재난이 발생하면:

• 비상호출(Firecall) 팀이 책임을 맡는다.
• 관련 시스템은 네트웍으로부터 분리한다.
• 취해지는 각각의 조치,이벤트,발견된 증거에 대해 일일이 문서화한다. (시간과 날짜도 함께).
• 시스템을 분석한다: 변경된 파일은? 추가 또는 변경된 프로그램/계정은? 변경이 발견되면 비슷한 시스템들에서도 이런 변경을 확인한다.
• 필요에 따라 시스템/네트웍 관리자 (administrators), 조직의 관리자(management) 및 법률시행당국에 통보한다
• 공격의 세부사항에 대해 이메일을 통해 누구와라도 논의 한다면, 암호화 및 서명된 이메일을 사용한다 (e.g. via PGP)
• 필요하다면 사고를 CERT/FIRST 에 보고한다.

6.6 시행

이 정책을 지키지 않는 사용자는 경고를 받게 되고, 해당 관리자에게 보고된다. 계속 경고를 무시하는 사용자는 직무에서 해임될 수 있다.

각주:
[3]  [4] i.e. XOR 같은 단순한 메카니즘이 아닌 RCA 1024-bit, IDEA, 3DES 등등. 일반 DES는 더이상 강력한 것으로 간주되지 않는다.
[5] E.g. 군사용의 강력한 암호화 및 안전한 파일삭제를 제공하는 F-Secure Desktop 또는 PGP desktop
[6] 루트 접근이 허가된 사람은? 유닉스 시스템에서, sudo (예를들어) 등을 사용하여 루트 권한을 제한하는 것이 좋다. NT 시스템에서는, 사용자그룹을 이용하여 관리적 접근을 제한한다.
[7] UNIX: 모두 쓰기 가능한 디렉토리에는 sticky bit 이 설정되어야 한다.
[8] 유닉스에서, 이것은 .cshrc, .mailrc, .login, .profile, .netscape 등등을 의미한다.
[9] 유닉스 시스템에서는 이것이 표준이지만, NT에서는 (아직) 아니다.
[10] 유닉스상에서는 5번의 로그인 실패 시도마다 몇 초 동안 프롬프트가 지연된다.
[11] 가용성 개선을 위해서는, 예방적 조치는 중단 가능성을 줄이고 복구조치는 사고 후 중단 시간을 줄인다.

정책 참고:
   SANS 보안정책 모델: www.sans.org/newlook/resources/policies/policies.htm
   EFF 정책 견본: www.eff.org/pub/CAF/policies/
   사이트 보안 핸드북 The Site Security Handbook ds.internic.net/rfc/rfc2196.txt
   NIST csrc.ncsl.nist.gov/secplcy
   Georgia Institute of Technology 컴퓨터와 네트웍 사용 정책 COMPUTER AND NETWORK USAGE POLICY

           IT Security Cookbook,   Last Update: 28 Jul 2000