Building a Security Policy Framework

BuildingaSecurityPolicyFramework.pdf

원재 : Building a Security Policy Framework for a Large, Multi-national Company, January 20, 2005
출처 : SANS Institute

회사의 정보보안 정책 및 지침, 가이드라인의 재개정을 위해 자료를 수집하던 중, 과거 한번 본 자료이나 스치고 지나가버린 Document를 다시 발견해서 Keep을 해두고 간단한 요약을 해둡니다.
영어에 울렁증이 있는 관계로 해석을 잘못한 경우도 있을지 모릅니다. 그러니 되도록 영어가 되시는 분들은 원문을 보시길 바라겠습니다.


해당 자료는 저자가 회의 정책을 개발하고 이를 유지하는 일렬의 실제 과정을 정리한 문건으로 실제 사내에서 정보보안 정책의 개발시에 참고가 될만한 내용인 듯 싶습니다.

본 문서에서 저자는 보안 정책을 개발하고 이를 공표한 이후 정책의 준수에 대한 모니터링을 포함하는 전반의 Process를 다음의 단계에 따라 수행했다고 합니다.

• Developing the framework
• Defining policy
• Determining a review process
• Writing the documents and having them reviewed
• Generating end user awareness about the updated policies and general security topics
  

많은 회사들이 그렇듯이 저자의 회사의 경우에도 외부 컨설턴트를 고용하여 정보보안 컨설팅을 받아본 결과 부적절한 정책과 부족한 정책의 홍보 및 인식화, 프로세스가 아닌 기술적 보안에 치우진 결과를 도출하게 되었다고 합니다.

이에 보안인식 프로그램(Security Awareness Program)을 만들게 되었다고 합니다.

“A Security Awareness Program involves defining your baseline (the policies), communicating them (awareness), and evaluating your success (compliance monitoring and vulnerability assessments).”

즉, 정책을 제개정하고 이를 홍보하고 준수할 수 있도록 모니터링하는 체계를 만든다는 의미로 보입니다.

Our three year plan defined that we would focus on policy development in year one, pick up the
awareness campaign in year two, and pick up compliance monitoring in year three.

호.. 이 과정을 3년간이나 수행했다고 하네요.ㅋ
그럴만한 것이 회사가 Global Business를 수행하는 다양한 Business가 존재하고 5만개가 넘는 시스템을 보유하고 있었다고 합니다.

Framework의 정의
먼저 CISSP Model이나 ISO 17799 Model등의 Global Standard Model을 참조하였다고 하네요.

CISSP 10 Domains :

1. Access Control Systems and Methodology
2. Applications and Systems Development Security
3. Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP)
4. Cryptography
5. Law, Investigation and Ethics
6. Operations Security
7. Physical Security
8. Security Architecture and Models
9. Security Management Practices
10. Telecommunications and Network Security

ISO 17799:2000(E) Standard :

1. Security Policy
2. Organizational Security
3. Asset Classification and Control
4. Personnel Security
5. Physical and Environmental Security
6. Communications and Operations Management
7. Access Control
8. Systems Development and Maintenance
9. Business Continuity Management
10. Compliance
    

이러한 Standard Domans를 검토하여 해당 조직에 적용하기 알맞다고 판단는 모델을 선정하였다고 합니다.
저자의 경우 Bindview/Meta Security Group Policy Operations Center solution을 채택했다고 합니다.

Bindview/Meta Security Group Policy Operations Center :

1. Asset Identification and Classification
2. Asset Protection
3. Asset Management
4. Acceptable Use
5. Vulnerability Assessment and Management
6. Threat Assessment and Monitoring
7. Security Awareness

본 모델을 선택한 이유는 저자의 회사에 적용이 좀더 쉽다는 점과 비지니스 관리자가 이해하기 쉽다는 이유였다고 합니다.

[Security Ploicy Framework]

이를 통해 최종 적으로 도출된 Framework가 그림과 같습니다.
※ 그림이 잘 안보이시면 클릭해서 보세요.

Framework가 간결하네요. 뭔가 있어보이는 그림은 아닙니다. 제가 생각하는 바로는 정책에 하부 구조까지 포함시킬 필요가 있을 듯 싶습니다.
즉, 정책 - 지침 - 가이드라인(절차서)의 연계구조를 Framework에 포함시키고 또한 정책의 생성, 공표, 교육, 검토, 개정의 라이프사이클도 역시 포함될 필요가 있지 않나 싶습니다.

정책 구조의 정의
저자는 일단 본 Framework를 만들고 나서 정책의 구조를 정의했습니다.
즉, 상위 레벨의 문서로서 정책과 그 하부의 좀더 자세한 "Procedure"를 두는 것으로 했습니다. 단, Procedure는 운영 프로세스 문서와는 구별된다고 하네요.
또한 세부적인 가이드라인과 체크리스트가 각각의 정책이나 Procedure의 하부에 포함되는 형식을 두도록 했다고 합니다.

검토 프로세스의 정의
많은 회사들이 정책은 한번의 컨설팅을 통해 그럴싸하게 만들어 놓지만 리뷰를 통한 현행화가 부진한 경우가 많습니다. 이는 정책의 유지보수를 위한 정형화된 프로세스가 존재하지 않아서 초래되는 경우가 많은데, 저자의 경우처럼 처음 정책을 만드는 단계에서 이를 리뷰하고 제개정을 하는 프로세스의 정의가 우선되어야 한다고 봅니다.

저자의 경우 다음과 같은 프로세스를 정의했다고 합니다.

1. Identify policy or supporting procedure to be written
2. Research best practices on the topic
1. Industry experts (Security Focus, CSI, SANS, ISO 17779, CIS, etc)
2. Current company practices
3. Start with a template
4. Apply technical writing techniques
5. Incorporate current policy or procedure
6. Review the document and make updates with the:
1. IT Security Team
2. Content Experts (some times they were on our IT Security Team)
3. Security Advisory Team (SAT)
7. Once a policy was approved by the SAT, it was submitted to the Chief Information Officer (CIO) for final approval. The SAT and Security Manager had final approval authority for procedures.
8. Review each policy and associated procedures at least every two years for currency and relevance.
   

관리자의 검토
정책을 개발하였으면 승인을 받아야 정책으로서의 실효성이 존재합니다. 따라서 저자의 경우 CIO에게 이를 보고하였으며 IT 조직외에도 관련된 부서(감사, 법무, 인사부서 등) 검토 및 승인을 거쳤다고 합니다.

작성
정책의 작성시에는 1. 되도록 일상적 용어를 사용(use more personal pronouns)하고 2. 실행적 동사(?)를 사용(write in an active tense) 3. 간결한 문장을 사용(use shorter sentences) 4. 긴 문단보다는 목록으로 표시(use bulleted lists, not long paragraphs) 하도록 하였다고 합니다.
쉽지 않죠.

문서의 내용은 다음과 같은 목차 구조를 가져가도록 했다고 합니다.

• Purpose
• Scope
• Who is Affected
• Requirements
• Responsibilities
• Enforcement and Exception Handling
  

공표
새로운 정책은 조직 구성원에게 홍보하고 이를 인지할 수 있도록 해야 합니다. 저자는 다음과 같은 방법으로 정책을 홍보하고 인식하는 방법을 보여줍니다.

• Email all end users
• Article in on-line internal newsletter
• Tri-fold brochures available in break areas
• Posters
• Lunch time seminars
• Policy on-line

국내 기업사정에 맞추어 제가 생각하는 공표의 방법은 다음과 같은 방식이 있을 것으로 생각됩니다.

• 보안 포털이나 그룹웨어 등에 정책을 개제
• 사내 직원이 모두 열람가능한 온라인 게시판에 개정 내용을 공지
• 사내 직원에게 전체 메일로 개정 내용을 안내 메일 발송
• 사내 방송, 사보 등에 홍보
  
• 포스터 및 스티커 홍보물 제작 및 배포
• 책자 제작 및 배포

기타 가능한 홍보수단을 최대한 활용해서 모든 사내 구성원이 제개정된 정책의 내용을 인지할 수 있도록 해야 할 것입니다.

결론
글 중간에도 언급하였듯이 정책을 만드는 것은 사실 그리 어렵지 않습니다. 일반적으로 정보보안 관련 컨설팅을 받으면서 컨설팅업체에게서 받은 템플릿을 일부 회사 사정에 맞추어 개정을 해서 사규화 해버린 경우도 많습니다.
문제는 대부분이 기술적 보안에 치우치고 있으며 정책의 현행화가 미흡하고 또한 전혀 현실에 맞지 않은 정책을 재정하고 있어서 정책에 따라 실제 업무가 실행되고 있지 않다는 점입니다.
처음 저자가 언급했듯이 "정보보호는 단지 기술에만 한정되지 않다. 이것은 프로세스이고 정책이며 문화이다."를 인지하고 정책의 수립과 이를 배포하고 실행을 모니터링하는 구체적인 프로세스를 수립하고 이것이 정례화하도록 노력할 필요가 있을 것입니다.