저널 온라인: 보안 정책을 작성하는 방법: 네트워크 보안 정책 매뉴얼

By Paul R. Meynen

ISACA Journal Online Volume 1, 2009

보안 정책을 작성하려는 보안 전문가에게는 그 일에 대한 어렵고 골치 아픈 성질을 이해하는 것이 중요하다. 무엇을 써야 하는가? 그것을 어떻게 써야 하는가? 누구 책임인가? 정보 보안 정책을 쓴다는 것은 일종의 예술 행위이다. 2~3일 안에 80 페이지 분량의 조직의 보안 매뉴얼을 작성해서 승인을 받으려는 사람은 다시 생각해야 한다.

이 글은 저자가 “최종적인” 네트워크 보안 정책 매뉴얼을 작성할 때 채택했던 접근방법을 설명한다. 어떤 정책 요건은 특정한 환경에서는 비용 억제적이거나 병참 업무 성격의 골치 아픈 일일 수 있는 반면, 그 아이디어는, 이것이 보안 환경을 위한 것이라는 것을 제외하면, 사람들이 갈망하는 모든 것을 (단순히) 목록으로 작성한 휴일 구매 리스트와 유사하다. 사람의 경험이 성숙되고, 위협이 변화하고 그리고 보안이 익숙해진 것처럼 이러한 정책도 발전하고 성숙될 것이다. 살아있는 문서와 같이 정책을 계속 숨쉬도록 하는 것이 중요하며, (그대로) 방치해서는 안 된다. 보안 무대는 급격히 변화하며 보안 정책도 (그 변화를) 따라가야만 한다.

현행 자원과 정책 진화

사람은 어떻게 아이디어 및 전략을 보안 정책으로 효과적으로 변환시키는가? 많은 보안 전문가들은 고위층 지원이 정보 보안 프로그램을 구현하고 유지하는데 필수적이라고 이해한다. 이러한 지원을 받고 유지하기 위해서는, 정책 범위가 명시적으로 정의되어야만 하고 그리고 보안 정책문들은 타당해야만 하며 그리고 모든 직원들에게 소통되어야만 한다.

현행 자원들은 다음을 포함하는 보안 정책 매뉴얼을 약술하는 프로세스를 분명히 한다:¹ 

• 취지(purpose)
• 구체적 목적(objective)
• 적용(Applicability)
• 배포(Distribution)
• 시행(Enforcement)
• 모니터링(Monitoring)

부수적으로, SANS (deriving from SysAdmin, Audit, Networking, and Security: 시스템관리, 감사, 네트워킹 그리고 보안의 머리글에서 따옴) 협회는 자신의 보안 정책 프로젝트에 대한 몇 가지 사례를 가지고 있다.²

어떤 글은 위험에 대처하는 정책을 쓰라고 이야기하기도 한다; 그것은 무엇을 의미하는가? 네트워크 보안에 대한 위험은 보안 표준을 검토함으로써 정의된다. 본 글에서는 앞서 나열한 항목들 속에 기록할 내용 그리고 비즈니스 및 IT 상황을 제공하면서 네트워크 보안 정책을 도입하기 위하여 표준을 효과적으로 이용하는 방법을 상세히 설명한다.

본 저자의 네트워크 보안 정책 매뉴얼(NSPM)³은 주로 정보보안포럼(Information Security Forum : ISF)의 우수 실무 표준⁴을, 다음으로는 국제표준기구(ISO)의 ISO 17799:2005⁵를 기반으로 한 것이다.⁶

NSPM은 ISF 표준의 네트워크 도메인에 초점을 맞추면서, 5가지 통제 목적 가운데 다음 4가지 요구사항을 다루고 있다.

• 네트워크 관리
• 통신량 관리
• 네트워크 운영
• 지역 보안 관리

상기 리스트에 없는 5번째 통제 목적인 음성 네트워크는 이 정책 범위에 포함되지 않는다. 조직이 수용할 수 있는 수준에 맞춰 위험에 대한 정책문을 쓰는 한가지 손쉬운 방법은 표준의 문체를  (그대로) 정책문으로 변환하는 것이다. NPMS의 취지 (그리고 ISF 표준의 음성 네트워크 통제 목적의 범위)를 위해서, 음성 네트워크는 전체 네트워크에 대한 위험을 나타내지 않았으며, 따라서 그 영역을 배제시켰다.

추가로, NSPM은 ISF 표준에서 찾을 수 없는 구문들도 들어있다. NSPM은 ISF 표준 범위를 뛰어넘어 세부사항들을 통합하기 위해 네트워크 보안을 위한 통제를 포함하고 또한 방화벽 통제에 있어서 중요한 세부사항도 포함한다. 개별 표준은 (모든 것을) 망라하는 단일 솔루션이 아니다; 그렇지만, 그것은 네트워크 보안을 강화시키는 방법에 관한 생각과 아이디어를 발동시키기 위해서 이용되기도 한다.

늘어가는 고통

전반적인 NSPM의 쓰기 및 검토 과정에서, 끊임없는 발견 프로세스는 작은 변화들이 정책의 명료성을 높이는 것으로 나타났다. 이것에는 다음과 같은 것들이 포함된다:

• 표제들은 공통적인 정책문들을 그룹화하는데 사용되어야 한다.
• 수행책임에 대해서 어떠한 의구심도 들지 않도록 역할 및 책임이 정의되어야만 한다. 이것을 완성하기 위하여, 역할은, 가령 네트워크 보안 이사, 네트워크 보안 엔지니어, 네트워크 보안 설계자 등, 직무별로 그룹화되어야 한다. 초기의 초안들은 정책 전반에 걸쳐서 역할 및 책임이 중첩되지 않도록 정의되었다. 정책 초기에 역할 및 책임 정의는 네트워크 보안 프로그램을 관리하는 토대를 마련한다. 게다가, 역할 및 책임은 전사 차원의 정보 보안 프로그램의 우산 아래에서 수용 및 적용이 가능한 정책 안에서 정의되어야 하기 때문에, 이것은 각별한 주의를 기울일 필요가 있다. 네트워크 관리 통제 목적은 NSPM의 네트워크 보안에 관한 면밀한 초점을 갖고서 역할 및 책임을 다룬다.
• 정책 매뉴얼은 4개의 개별 정책들과는 대조적으로 개발되어야만 한다. 4개의 개별 정책을 이용하는 경우에는 연속성이 결여로 정책들간의 내용을 서로 연관시키기 어렵게 만들 수 있다. 앞서 열거한 4개의 통제 목적이 개별 정책인 반면, 여러 장으로 구성된 (정책) 매뉴얼을 작성하는 것은 정책들 전반에 걸쳐서 문맥 및 연속성을 제공한다. 더구나, 정책 도입 과정에서 메타데이터(예를 들어, 적용, 배포)를 정의하는 것은 관리를 보다 쉽도록 도와준다. 그로써 모든 후속 정책들이 단일 규칙 집합을 준수하도록 만든다.

정책 쓰기 사례 1

개요(서문)가 정책 및 그의 통제 목적에 앞에 나와야만 한다. 이것은 독자에게 전반적인 상황을 제시하고 이어지는 정책 문장들에 대한 요약 내용을 적는다. ISF 표준과 ISO 17799는 각 도메인과 통제 목적에 앞서 개요를 제공한다. 더구나, ISO 17799는 정책 문장을 작성할 때 그의 방향 제시를 위한 각각의 통제에 대한 도입부를 제공한다. 구현 가이드와 요약을 보강하는 것은 도메인과 이의 관련 통제 목적(들)을 도입하는 것을 보조할 것이다.

ISF 같은 표준은 일관되게 “should 하여야 한다”라는 단어를 사용한다. 정책에서 “should 하여야 한다”의 사용은 충분하지 않을 것이다. 그러한 단어는 해석(판단)해야 하는 가능성이 있으며 또한 보안 사고 후에 정책을 실시하는데 어려움을 초래한다. 정책은 규칙들(rules)의 집합이다; 그러므로, 정책을 강제로 시행하기 위해서 “머스트(must 하여야만 한다)” 혹은 “윌(will 반드시 ~ 한다)”이 사용된다.

그림 1—정책문 개발 사례 1

예: 장애 관리 통제를 위한 원리 및 목적(NW3.3)   원칙: 어떤 형태이든지 모든 네트워크 장애는 장애 관리 프로세스에 따라서 기록되고, 검토되고 그리고 해결되어야 한다. (should)   목적: 네트워크 장애를 효과적으로 확인하고 해결하기 위하여, 유사한 장애의 재발 위험을 감소시키고 업무 영향은 최소화시켜야 한다.(should)   정책문: 네트워크 상에서 발생하는 모든 장애는 수립된 장애 관리 프로세스에 따라서 기록되고, 검토되고 그리고 해결되어야만 한다(must). 장애 관리는 업무 영향과 유사 장애에 대한 미래 위험을 완화시키기 위하여 신속한 응답과 효율적인 해결방안을 고려한다.

정책 쓰기 사례 2

ISF 표준은 네트워크 자원의 오작동을 줄이기 위해서 회사는 네트워크 구성요소들이 복구되도록 보장할 것을(should) 제시한다. NSPM은 핵심 시스템이 먼저 복구되어야만 하고 그러한 시스템을 복구하기 위한 역량을 갖춰야만 하는 점을 확인시킨다(그림 2). 게다가, NSPM은 “핵심 시간기준critical timescales”을 능가하는 값이 명확하게 명시된 사업 연속성 계획으로부터 복구 목표 시간을 구체화한다.

그림 2—정책서 개발 사례 2

예: 네트워크 회복 통제(NW1.3.3) (ISF로부터)   주요 네트워크 구성요소들이 핵심 시간기준 이내에 교체될 수 있도록 보증함으로써 핵심 통신 장비, 소프트웨어, 회선 그리고 서비스의 오작동 위험은 감소되어야 한다.   정책문: 오작동 위험 및 영향을 완화하기 위하여, 주요 네트워크 구성요소들이 지정된 복구 목표 시간 내에 교체될 수 있도록 보증함으로써 핵심 시스템 세그먼트들(segments)에 우선순위가 부여되고 적절한 용량이 그러한 세그먼트들에 할당되어야만 한다.

정책 쓰기 사례 3

사람은 제약 조건을 만듦으로써 제품 또는 기술을 정의하는 것은 피해야만 한다. 예를 들면:

외부 접근은 커버로스(Kerberos) 인증 서버를 이용하여 제공되어야 하는데, 커버로스 인증 서버는 외부 연결을 위한 신뢰할 수 있고 완전한 인증을 제공하여야 한다.

이러한 명시적인 정의는 문제를 야기할 것이다. 인증 기술이 또 다른 솔루션으로 변경되면, 정책 매뉴얼은 검토되고 수정되어야만 한다. 대신에, 다음과 같은 정책 문장이 사용되어야만 한다:

전용 원격 접속 서버가 모든 외부 접근을 위해 사용될 것이다(will); 그것은 신뢰할 수 있고 허용된 접근 통제(예를 들면, Kerberos, TACACS+, Radius)를 이용하여 외부 접속을 인증하여야만 한다.

“e.g. 예를 들면” 이라는 용어는 “예를 들면 for example”을 의미와 더불어 “포함하는 including”이라는 표현과 유사한 것으로써 매우 유용한 표현이다. 바꿔 말하면, “예를 들면”은 기술에 대한 실질 사례의 언급이며, 가능한 솔루션을 모두 명시하고자 하는 의도는 아니다(즉 나열된 것만으로 제한하는 것이 아니다).

정책 쓰기 사례 4

끝으로, NSPM은 네트워크 보안에 초점을 맞춘 것을 기억하라. ISF와 ISO 17799 표준에는 전사 보안 프로그램 안에 있어야 하는 추가 영역이 있다. NSPM은 전사적 프로그램 상황들을 망라하고자 노력하지만 범위를 벗어난 규칙들은 정의하지 않는다. 예를 들면, NSPM에 있는 무선 접근 통제는 다음처럼 기술하고 있다:

무선 접속에 대한 문서가 유지관리 되어야만 한다. 그것은 최소 길이의 점대점 하드웨어 암호화를 유지관리하기 위한 무선 하드웨어 구성도를 반드시 포함한다.

예를 들어, 128 비트 암호 표준을 정의하는 것은 NSPM의 범위를 벗어나는 것이다. 이 정책문은 수용가능한 암호화 정책에 속할 수도 있다.

결론

보안 정책을 쓰는 것은 흥미로운 것이다. 그것은 회사 전체적으로 자원들의 일치와 직원들의 협력을 필요로 한다. 그렇더라도, 정책 쓰기는 없어서는 안될 스킬이며, 따라서 정책이 수립되면, 검토를 받아야만 하고 수정되어야만 한다(적어도 년간 단위로). 보안 정책의 유지관리는 일상적인 비즈니스 활동과 내외 악의적인 위협에 대한 방어책에 대한 유지관리처럼 똑같이 중요하다. 개인 데이터와 고객의 신상 정보에 대한 보안은 비즈니스에 있어서 매우 중요하다. 예를 들면, 신용카드 정보, 의료 정보 그리고 (미국에서의) 사회 보장 번호는 NSPM의 토대이다. 그것은 전사 정보 보안 프로그램의 심장이다.

Endnotes

¹ Simon, Mark; “An Enterprise Security Policy Management Framework Part 1 & 2,” ISSA Journal, February 2008, www.issa.org/Members/Journals-Archive/2008.html. SANS Institute, “Building a Security Policy Framework for a Large, Multi-national Company,” January 2005, www.giac.org/certified_professionals/practicals/gsec/4276.php. Gartenberg, Marc; “How to Develop an Enterprise Security Policy,” ComputerWorld, January 2005, www.computerworld.com/securitytopics/security/story/0,10801,98896,00.html. Ungerman, Mark; “Creating and Enforcing an Effective Information Security Policy,” Information Systems Control Journal, ISACA, vol. 6, 2005
² SANS Institute, Security Policy Project, www.sans.org/resources/policies
³ The Network Security Policy Manual is an original, copyrighted creation of the author (Paul Meynen). To obtain a copy of the NSPM, please e-mail MeynenP@gmail.com.
⁴ Information Security Forum, The Standard of Good Practice, https://www.isfsecuritystandard.com/SOGP07/index.htm
⁵ International Organization for Standardization, ISO 17799:2005, Information Technology—Security Techniques—Code of Practice for Information Security Management, 2005, www.iso.org
⁶ A copy of ISO 17799:2005 was not obtained by the author until the end of the course in which he developed the NSPM. Consequently, there was not sufficient time to incorporate all the additional policy statements recommended in ISO 17799:2005. However, ISO 17799:2005 presents an incredible level of detail and is a robust standard to implement a security program. As the NSPM evolves, the implementation guidance (explained later) in the ISO standard will be leveraged to incorporate new statements into the NSPM.

Author’s Note

The author would like to thank James Krev for his patience and guidance in support of this research at DePaul University, as well as Jacob Furst and Linda Allen for their meticulous editing of the work.

Paul R. Meynen
is an information security consultant in Chicago, Illinois, USA. He completed the Network Security Policy Manual as part of an independent study course at DePaul University, administered by James Krev. Meynen may be reached at MeynenP@gmail.com.