ISO 심사원의 뇌 구조

웹 서핑 중 재미있는 글을 발견했습니다.

ISO 심사원의 뇌 구조를 확인하고 각각에 따른 심사 응대 방식을 설명하는 글입니다.

인증 심사에서 무엇을 기대할 것인가?

"만약 심사위원이 무슨생각을 하는지 이해한다면, 스트레스를 조금더 받지 않을까?"

심사위원의 뇌는 아래와 같이 8가지로 구분할 수 있습니다.

• KNOWLEDGE
• QUEST
• ANNOYANCE
• HAPPYNESS
• EXPECTATIONS
• PROHIBITED
• AUTHORIZATION
• KNOWLEDGE

Knowlege - 심사원이 어떤 스탠다드에 능한가?

• Fact
• 심사위원은 오직 한개의 스탠다드로 심사를 할 것이다. (ex, ISO 27001)
• 대부분의 심사원들은 여러 ISO 기준에 대한 지식이 있을 것이다.(ISO 9001, ISO 14001,, ISO 20000, etc )
• Tip
• 큰 그림을 그리기 위해 심사위원의 지식과 경험을 활용하라. 각각의 스탠다드는 당신에게 적합할 것이다. 즉, 운영능력이 향상 될 것이다. 

Quest - 심사위원은 무엇을 바라는가?

• Fact
• 심사위원은 아래의 사항등을 평가할 것인다.
• 필수 문서를 모두 가지고 있는지
• 활동(activities)과 문서가 스탠다드에 부합하는지
• 수행되고 있는 활동이 문서(정책,지침, 등) 와 부합하는지
• Tip
• 조직내에서 필요하지 않는, 부합하지 않는 정책과 절차를 만들지 마십시오. 또한 개정된 문서는  모든 인원이 자세히 검토할 필요가 있습니다.

ANNOYANCE - 그들은 무엇에 짜증을 느끼는가?

• Fact
• 인증심사원들도 사람이다. 때문에 담당자들이 적극적으로 심사에 임하지 않고, 방어 자세를 취한다면 짜증을 느낄 것이다.
• Tip
• 심사위원의 질문을 회피하지 마세요. (어차피 무엇을 숨기고 있는지 바로 알아차릴 겁니다.)
• 거짓말을 하지마세요. (만약에 거짓말이 발각되면, 당신은 모든 신뢰를 잃게 될것 입니다.)
• 시간을 끌지 마세요. (심사위원을 일부로 이리저리 끌고 다니며 시간을 소모하지 마세요)

Authorization - 인증을 위해 심사위원이 무엇을 하는가?

• Fact
• 심사기간내에, 심사위원은 인증범위 내의 인원들에게 지적을 할 수 있습니다. 또한 어떤 문서도 볼 수 있으며, 조직내의 부지에도 갈 수 있습니다.
• Tip
• 인증범위 내의 모든 인원에게 심사 준비를 하라고 당부해 놓는다. 그리고 범위내 문서를 확실히 검토한다.

PROHIBITED - 심사위원이 못하는 것은 무엇인가?

• Fact
• 심사위원은 담당자들이 불평하지 않을 만한 명백한 증거가 없거나, 문서나 스탠다드의 요구사항에 부합하지 않는 것을 '부적합'으로 지정할 수 없다.
• Tip
• 만약 요구사항에 기재되어 있지 않거나, 애매한 사항을 발견하게 되면, 이 부분에 대해서는 심사위원에게 주장할 합당한 논거를 준비해야 한다. 

EXPECTATIONS - 심사위원은 무엇을 기대할 것인가

• Fact
• 인증심사는 초기심사가 끝이 아니다.
• TIP
• 성공적으로 심사를 마친 이후에도, 시스템과 문서를 지속적으로 관리해야 한다. - 심사위원은 다음에 왔을때 이 부분을 유념해서 확인 할 것이다. 

HAPPINESS - 심사위원이 어떨때 행복해 하는가?

• Fact
• 원칙적으로 심사위원은 고객사 담당자와 상담(컨설팅) 할 수 없도록 되어 있다. - 즉 현재 직면한 문제의 해결방안에 대해 설명할 수 없다.
• Tip
• 인간관계를 긍정적으로 발전시켜라
• 명확하고 적절게 답변하라
• 문제를 숨기려하지말고 인정하라
• 심사위원의 의견을 물어보라
• 그렇게 한다면, 심사위원은 단순히 부적합 사항을 던져주지는 않을 것이다.  (대화도중, 몇몇 부적합 사항에 대한 가이던스를 제공해줄 것이다. 이것은 엄밀히 말하면 컨설팅은 아니다. 하지만 많은 시간을 절약할 수 있다.

Continue reading

No comments

[비 전산 부서를 위한] 관리적 취약점 분석 방법 가이드

지니온 노종현입니다. 본 포스팅은 '관리적 취약점 분석' 에 대해 내용을 기술하였습니다.

'관리적 취약점 분석' 이란, 조직이 수집한 전체 자산에 대해 기술적 방법이 아닌 '관리적인 방법으로 취약점을 분석' 하는 방법이며 , 최종적으로 1) '위험 정도' 와 2) '발생 가능성' 이 도출됩니다.

가능한 쉽게 설명하기 위해 5가지 단계로 분류하여 설명을 기재하였습니다.

STEP 1. 자산을 취합합니다.

아래 그림과 같이 '자산 분석' 하는 단계에 해당합니다. (해당 내용은 제공되는 방법론 가이드를 참조하시면 어려움 없이 진행될 것 같습니다.)

STEP 2. 그룹핑 기준 수립합니다. (위험 시나리오 문서 참고)

이는 전체 방법론 중에 '관리적 분석' 단계에 해당됩니다.

'관리적 분석' 을 위해서 우선 그룹핑이란 작업이 선행됩니다. 그룹핑이란 모든 자산에 대해 '위험 시나리오' 평가를 수행하게 되는 번거로움을 피하기 위해 자산을 형태 혹은 성격에 따라 그룹화하는 것을 의미합니다. 아래의 예를 보겠습니다.

위의 예시는 문서를 성격에 따라 그룹핑한 현황입니다. 저희가 1차적으로 그룹핑 기준을 수립하였으며, (위험 시나리오에서 그룹핑 예시 확인 가능) 만약 추가적인 그룹핑 구분이 필요하시면 추가하시면 됩니다. 이와 같은 방법으로 리스팅한 자산에 대해 그룹핑 기준을 수립하시면 됩니다.

- 주의 -
위의 기준은 자산의 종류에 따른 분류가 아니라 자산의 관리형태 혹은 성격에 따른 분류 기준입니다. 즉 [매뉴얼/기획문서/보고서/신청서] 와 같은 분류기준은 올바르지 않은 분류 기준입니다. 기준은 [전자문서-FTP 공유문서] 와 [전자문서-PC 내 저장문서] 와 같이 관리 형태의 기준으로 분류가 되어야 합니다. (이를 기준으로 각각의 [위험도] 와 [발생가능성]은 명확하게 차이가 나기 때문입니다.)

STEP 3. 각각 리스팅한 자산에 대해 위의 STEP 2 에서 정한 분류 기준을 명시해 주세요.

아래의 붉은 색으로 표기된 부분에 각 자산의 그룹핑 기준을 명시해 주세요

STEP 4. [위험정도] 와 [발생가능성]을 평가합니다.

이제 저희가 전달드린 [위험 시나리오] 문서에 각각 분류한 대상에 따라 [위험정도]와 [발생가능성]을 평가하여 값을 기재합니다.  (아래 이미지 참고)

( 각 자산에 대한 '위험도'와 해당 위험의 '발생가능성'은 자산 담당자가 가장 정확하게 판단할 수 있다는 전제하에 진행됩니다)

만약 '내가 분류한 문서 목록 리스트의 그룹핑은 [전자문서-PC 내 저장문서] 밖에 없어요" 라고 하시는 분들은 하나의 평가 테이블에만 평가값을 기재하면 됩니다. 

STEP 5. 나머지는 IT팀의 의 역할

위의 1-2 단계를 수행해주시면 나머지는 IT팀의 몫입니다. 

즉 위의 내용에 따라 업데이트된 1) 자산목록과 2) 위험시나리오 파일을 작성하여 IT팀에 전달해주시면,

위험평가를 통해 전체적인 RISK Value를 도출하게 됩니다. 

Continue reading

No comments

Risk Onwer 와 Asset Onwer 의 개념 이해

ISO27001 인증을 받은 기업의 담당자들도, Risk owner 와 Asset owner 의 개념을 명확히 이해하지 못하는 경우가 많습니다.

따라서 본 포스팅에서는 ISO27001에서의  필수로 요구하는 개념인 Risk Owner, Asset Owner 에 대해 정리하도록 하겠습니다. 

1. Asset owner

Asset Owner 라는 개념은 기존의 ISO27001:2005 버전에도 있었으며, 이 제정된 2013 버전에도 존재하고 있습니다. 간단히 정의하면 이는 '자산 담당자' 입니다. (영어로는 'who is responsible for each asset' 로 정의 될 수 있음) 여기서 자산은 단순히 서버나 네트워크 등의 전산자산에만 국한되는 것이 아니라 서비스, 사람, 시설, 조직, 문서도 포함하고 있습니다.

어떤 자산에 대한 책임자가 아무도 없다면 자산관리가 제대로 될까요? 쉽게 비유하면 '무정부상태' 가 될 것입니다.

2. Risk owner

ISO27001:2013 버전 에서는 “Risk owner” 란 새로운 개념이 도입되었습니다.

정의는 다음과 같습니다. "Person or entity with the accountability and authority to manage a risk"

Risk Owner 는 기존의 Asset Owner 가 가지고 있는 권한만으로는 잠재적위험을 해결 하기어렵다는 사실로 인해 도입된 것으로 보입니다.

Risk owner 의 적임자는 아래와 같은 자격을 갖춰야 합니다.

• Risk owner 는 리스크를 식별하는 운영과, 프로세스에 밀접하게 관련있는 사람
• 해당 자산에 위험이 “실현화” 되었을 경우, 본인 스스로가 피해 또는 문책을 받을 수 있는 위치의 사람
• 위험관리와 관련한 업무를 위해, 결정권자에게 어떠한 요구를 하거나, 주장을 할 수 있는 위치의 사람

즉, Risk Owner는 기본적으로 Risk를 해결하는데 관심이 있고, 조직내에서 충분히 높은 지위에 있어야 합니다. 

3. 결론

ISO27001: 2013 을 준비하는 기업은 각 자산에 대해 Risk owner와 Asset owner를 반드시 지정해야 합니다.

일반적으로 A라는 서버의 Asset Owner는 IT관리자가 될 수 있으며, Risk Owner는 IT팀장이 될 수 있습니다. 이에 따라 IT 관리자는 각각의 서버를 지속적으로 관리할 것이며, IT 부서장은 IT관리자를 대상으로 직무훈련을 제공하거나, 해당자산의 보안 향상을 위해 경영진들에게 금전적 지원을 요청할 수 있습니다. 

Continue reading

No comments

인증을 쉽게 받을 수 있는 방법이 있나요?

“인증을 쉽게 받을 수 있는 방법이 있나요?"

ISO27001 인증을 준비하는 기업 담당자과 이야기를 나누면 위와 말을 종종 듣게됩니다. 우선 결론부터 말씀드리면 (불행하게도…) 그런 방법은 없습니다. 하지만 각각의 업무를 좀 더 쉽게 할 수는 있습니다. 인증 준비에 어려움을 겪고 있는 담당자를 위해, 16가지 팁을 의역하여 정리하였습니다. 

< 원활한 ISO27001 이행을 위한 16가지 체크리스트 >

1. 경영진의 지원을 득하라

경영진의 지원을 받아야하는 하는 것은 당연해 보이지만, 보통은 심각하게 고려되지 않습니다. 즉 경영진과 별개로 전산팀이 개별적으로 진행하면 되지 않나 라는 생각을 하는 조직이 많습니다. 그러나 경험상으로 이것은 ISO27001 프로젝트가 실패하는 주 이유입니다. 프로젝트를 수행하기 위해 필요한 예산 및 인력등을 원할히 제공받기 위해서는 경영진의 지원이 반드시 필요합니다. (참고)

2. 하나의 프로젝트로 인식하라

ISO27001는 다양한 업무, 많은 사람들으로부터 복잡하게 수행되는 복잡한 이슈입니다. 즉 이것은 하나의 프로젝트입니다. 무엇을 해야하는지, 누가 업무를 해야하는지 언제까지 해야하는지에 관련한 명확한 계획 및 규정이 없다면, 성공적으로 ISO27001을 마무리 할 수 없을것입니다.

3. 범위를 정하라

규모가 큰 조직인 경우, 특정 부서만 국한하여 ISO27001 인증을 받을 수도 있습니다. 그로인해 프로젝트 수행히 발생할 수 있는 비용적 인력적 측면의 리스크를 줄일 수 있습니다. (참조)

4. ISMS 정책서을 작성하라

ISMS 정책서은 ISMS 에서 가장 높은 레벨의 문서입니다. 이것은 아주 디테일하지 않아도 되지만 정보보안을 위한 기본적 이슈들은 명시가 되어야 합니다. 그러면… 정책서가 아주 디테일하지 않아도 된다면, 대체 정책서는 목적은 무엇을까요? 정책서의 목적은 경영진이 무엇을 성취할지, 어떻게 그것을 통제할 것인지를 수립하는 것입니다.

5.  위험평가 방법론을 정의하라

위험평가는 ISO27001 수행 업무 중 가장 복잡한 업무 중 하나입니다. 핵심은, 1) 자산, 취약점, 위협을 식별하고 2) 이러한 위험(RISK)의 영향도, 발생가능성을 확인하며, 3) 조직내에서 수용할 수 있는 위험의 수준을 정하는 것입니다. 만약 이러한 방법론이 정확하지 않으면, 완전 엉터리 결과가 나올 수도 있습니다. (참조)

6. 위험 평가(Risk assessment) 및 위험 조치(Risk treatment)를 수행하라

수립한 위험평가 방법론을 기준으로 위험평가, 위험조치를 수행합니다. 큰 기업일 경우 몇 달이 걸릴 수도 있는 복잡한 작업이기 때문에 여러 인원이 상호협력하여 업무를 수행하여야 합니다. 핵심사항은 조직전체의 위험에 대한 큰 그림(comprehensive picture)을 이해하는 것입니다.

위험 평가 프로세스의 기본적인 목적은 수용할 수 없는 위험을 감소시키는 것입니다. 보통 Annex A 의 통제항목을 적용하여 계획을 세웁니다.

이번 단계에서는 ‘위험평가’, ‘위험조치 프로세스’와 관련된 모든 내용이 포함된 ‘위험평가보고서'가 산출되어야 합니다. 또한 도출된 잔여 위험(residual risk)에 대해서는 반드시 승인을 받아야 합니다. 승인은 별도의 공문 형태이든, 자체 문서든 상관없습니다.

7. SOA(Statement of Application) 를 작성하라

위험 조치 프로세스가 끝나면, Annex 중에 어떤 통제항목이 적용되어야 하는지 정확히 알아야 합니다. (전체 114개 통제항목이지만, 모두 해당되지 않을 수도 있습니다.) 흔히 SOA 라고 불리는 이 문서의 목적은 아래와 같습니다.

• ISO27001에서 요구하는 전체 통제항목을 나열하고
• 어떤 항목이 우리 조직에 적용되어야 하는지를 정하며, 제외한 항목의 경우 사유를 기재합니다.
• 그리고 통제목적에 근거하여 실제 조직이 어떻게 해당 항목을 준수하고 있는지 기술하는 것입니다. 

또한 SoA는 ISO27001 인증과 관련하여 경영진보고 및 승인을 위한 가장 알맞은 문서입니다.

8. 위험 조치 계획을 작성하라

여기서 끝이 아닙니다. 위험과 관련해서 마지막으로 ‘위험 조치계획’을 작성해야 합니다.

위험 조치 계획의 목표는 SoA의 컨트롤을 어떻게(누가 진행할지, 언제까지 진행할지, 필요 예산은 얼마인지) 이행할지 정하는 것입니다.(다르게 말하면 도출된 위험을 어떻게 조치할지에 대해서도 필요합니다)

9. 컨트롤의 유효성을 측정하는 방안을 정의하라

실제로 많은 담당자들이 해당 항목의 중요성을 간과하곤 합니다. 요점은, ISMS 와 관련하여 수행한 것 업무들을 측정하지 않으면, 기존 목적을 달성했는지 확인할 수 없다는 것이다. 그러므로, 전체 ISMS  와 SoA에서의 각각의 통제항목 적용성에 대해 정하고 목적의 이행을 측정하기 위한 방법을 수립하라

전체 ISMS와 SoA 통제항목에 의 목적을 수립하고, 이를 평가할 수 있는 정확한 측정방법을 수립하여야 한다.

10. 통제항목 및 필수 절차를 수행하라

4가지 필수 절차와 Annex A의 통제항목을 이행하는 단계입니다. (참고) 이는 신규 기술 (혹은 장비) 관점에서 통제하는 사항 뿐만아니라, 조직내 신규부서, 신규 프로세스에도 적용이 되어야 합니다. 필요시 정책 및 절차가 제/개정 되기도 해야하며, 몇몇 인원은 이러한 신규정책을 모르거나 이행하지 않을 수도 있습니다. (그렇기 다음 단계(훈련과 인식 프로그램)가 반드시 수행되어야 합니다. )

11.훈련과 인식(awareness) 프로그램

임직원들이 신규 정책이나 지침을 모두 이행하게 하기 위해서는 가장 먼저 이것이 왜 필요한 지 명확히 설명을 하고, 필요하다면 각 정책지침에서 요구하는 내용에 대해 교육을 실시하는 것이 필요합니다. 해당 항목은 ISO 27001프로젝트가 실패하는 주요 원인중 하나 입니다.

12. ISMS 운영하라

조직내 인원에게 ISO27001가 루틴화하여 적용되도록 하는 과정입니다. 여기서 핵심 단어는 ‘증적(records)’ 입니다. 심사위원은 증적을 정말 좋아합니다. 증적이 없으면, 인증을 받아 보신 분이라면, 해당 활동이 정말 수행되었는지 증명하기가 매우 어렵다는 것을 알 수 있을 것입니다. 또한 예전에 무슨 이슈가 있었는지 모니터링 하고 싶을때 증적을 사용할 수도 있습니다. 그리고 마지막으로 특정 직원 혹은 파트너가 ISMS 에서 요구하는 대로 형식을 준수하는지 확인할 수도 있습니다.

13. ISMS 모니터링 

통제 목적이 있고 이를 측정할 수 있는 방법론이 필요합니다. 특정 결과가 초기 목적과 맞는 결과인지 아닌지 확인해야 합니다. 만약 그렇지 않다면, 이는 잘못 수행된 것이며, 이를 보완하고 예방하기 위한 2차 조치가 계획될 것입니다. 

14. 내부 감사

일반 임직원들인 보안을 잘 모르기 때문에, 보안에 위배된 행위를 하면서도 그 상황자체를 모르고 있는 경우가 많습니다. (반면, 보안에 위배된 행위인지 알고있지만, (아무도 터치하지 않아서) 모른체하고 하고 있는 경우도 있습니다. 그러나 이러한 문제들을 지속적으로 방치하면 조직측면에서 어떤 사고가 발생할지 모르는 일입니다. 

이 항목의 요점은 이러한 감사를 통해 단순히 징계를 주는것에서 그치는게 아니라,  지속적인 내부감사를 통해 보완결점을 발견하면 이를 보완하고 예방하기 위한 다음 액션조치가 이루어져야 한다는 것입니다.(참고)

15. 경영 검토

경영진이 방화벽 설정을 해야하는 아니지만, ISMS 와 관련하여 무슨일이 발생하는지는 알아야 합니다. 경영검토회의를 통해 ISMS 와 관련한 담당자들이 그들의 책임을 완수했는지, ISMS의 결과가 요구했던대로 만족스럽게 도출되었는지 검토해야하며, 일반직원이 할 수 없는 중대한 사안에 대해 결정을 해줘야 합니다. 

16. 보완(Corrective) 및 예방 조치

경영 시스템(manaement system)의 목적은 조직내 수행된 업무 중 잘못된 것 (혹은 부적합) 또는 교정된것, 예방해야할 것에 대한 모든것을 확인하는 것입니다. 그러므로 ISO 27001은 체계적인 보완 및 예방 활동을 요구합니다. 이는 부적합을 유발하는 근원은 반드시 확인되어야 하며, 그리고 이를 제거하고, 재확인하는 것을 말합니다.

Reference

• http://www.iso27001standard.com/blog/2010/09/28/iso-27001-implementation-checklist/?utm_source=infusionsoft&utm_medium=follow-up-sequence&utm_campaign=documents&inf_contact_key=4d1024b0e92ef7a4951076ccec410b7e506dc8c77a98b13c131aa84e453e6222

Continue reading

No comments