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

[ISMS] 보조기억매체 이용 및 관리 방법

ISMS 컨설팅을 위해 업체를 들어가게되면, 대부분의 업체가 CD 나 USB 와 같은 보조기억매체를 대상으로한 이용 및 관리 절차가 명확히 수립되지 않은 경우를 많이 보게 된다.

최근 CD, USB 메모리와 같은 보조기억매체를 통한 대량의 개인정보 및 회사 기밀정보가 외부로 유출되는 사고가 발생하고 있는데, 이것 역시 보조기억매체가 바이러스나 악성코드 침부를 위한 새로운 경로로 악용되는 사례도 나타나고 있어 보조기억매체의 안전한 이용 및 관리를 위한 대책마련이 요구되고 있다.

보조기억매체를 통한 정보유출 피해를 최소화하기 위한 대책으로 보조기억매체에 보안 솔루션을 적용하거나, 보안기능을 갖는 보안 보조기억매체를 이용하는 방법이 있지만, 이러한 보안 솔루션 및 보안 보조기억매체는 선택 및 이용, 관리 방법이 제품마다 어렵고 사용방법이 각기 달라 일반 사용자의 경우, 이를 활용하기가 쉽지 않다. 

이에 따라 본 포스팅에서는 일반 사용자들이 안전하게 보조기억매체를 이용할 수 있도록 이용 및 관리 절차에 대해 상세히 정리하였다.

1. 보조기억매체의 이용 / 관리 절차

• 일반 사용자가 보조기억매체를 이용해 정보를 안전하게 이용 / 관리하기 위한 절차와 방법에 대해 알아본다.
• 다만, 이러한 절차는 보조기억매체를 이용하는 환경 등에 따라 일부 달라질 수 있다.

1-1. 저장 정보의 보안등급 설정

: 보조기억매체에 저장 / 관리할 정보의 중요성, 정보유출 시 피해정도등을 고려하여 저장정보의 보안 등급을 설정한다.

[표] 정보의 접근허용 범위 및 유출시 예상 피해 정도에 따른 보안 등급 - 기업

[표 ] 정보 유출 시 예상 피해 정도에 따른 보안등급 - 일반 사용자

1-2. 이용환경에 적합한 보조기억매체 선택

: 저장할 정보의 보안등급에 적합한 보조기억매체를 선택한다

• [표 7] 보안등급에 따른 보조기억매체 선택

1-3. 보조기억매체의 자동실행 기능 해지 설정

: 바이러스, 악성코드 전파 경로로 악용되지 않도록 보조기억매체의 자동실행 기능을 해지해야 한다.

1-4. 초기 보안설정 변경

: 보안 보조기억매체 및 보안솔루션 이용 시, 사용자 ID/PW, 시리얼 번호, 디스크 저장 영역(보안/일반) 등에 대한 초기 보안설정을 사용자별 이용 환경에 따라 변경한다.

• 일반 보조기억매체는 별도의 초기 보안설정 변경절차 없이 사용가능하다. 다만, 정보를 안전하게 저장, 관리하기 위해서는 패스워드나 권한설정 등 운영체제 및 응용 프로그램에서 제공하는 보안기능을 적용 해야한다. 보안솔루션을 적용한 일반 보조기억매체나 보안 보조기억매체의 경우, 정보를 안전하게 저장 / 관리하기 위해서 사용자의 이용환경에 따른 초기 보안설정에 대한 변경이 필요하다. 초기 보안설정 필요 여부나 방법 등은 제품에 따라 다르지만 사용자 ID/PW 설정, 영역 구분, 바이러스 검색 및 치료 S/W 설정 등이 요구된다.
• 사용자 PW는 [패스워드 선택 및 이용 안내서(KISA)] 에 따라 안전한 PW로 설정하고, 필요에 따라 보안영역에는 접근제어 및 암/복호화기술 등 복수의 보안기능이 적용되어 있는지 확인해야 한다. 보안 보조기억매체의 이용 절차는 [붙임 1]을 참조한다.

1-5. 보안등급이 높은 저장 정보의 암호화 관리

: 보안등급이 높은 저장 정보는 복수의 보안기능을 적용하고 반드시 암호화하여 관리한다.

• 보안등급이 높은 저장 정보는 추가적인 보안기능을 복수로 적용하여 보호하고, 반드시 파일이나 디스크 상태로 암호화하여 보관하여야 한다. 특히, 보조기억매체 전용 보안 솔루션이나 보안 보조기억매체를 이용할 경우, 보안영역에 보관하여 일정 수준의 보안성을 보장받도록 한다. 제품에 따라 보안영역이 제공하는 보안기능이 상이할 수 있지만 대부분의 보안영역은 항상 자동적으로 암호화 되어 저장된다.
• 또한, 보조기억매체의 저장 정보는 매체의 분실이나 오류 등에 대비하여 다른 저장매체에 백업파일을 보관해야한다. 다만, 보안등급이 높은 저장 정보는 백업파일도 암호화하여 보관하고, 필요한 경우 복수의 보안기능을 적용/관리하도록 한다.

1-6. 보안등급이 높은 저장 정보의 완전삭제

: 보안등급이 높은 저장 정보 삭제 시, 디스크 포맷 및 완전 삭제S/W를 이용해 추후 정보복구가 불가능하도록 삭제한다.

• 보안등급이 높은 저장 정보를 삭제할 경우, 디스크 포맷 기능이나 완전 삭제 S/W 등을 이용하여 복구가 불가능하도록 한다. 복구 불가능한 정보의 완전한 삭제는 다음과 같이 이루어지며, 완전 삭제 S/W는 자동적으로 정보의 완전한 삭제 과정을 반복 수행하는 것이다.
• 1. 임의의 문자로 데이터를 덮어씀
  2. 첫번째 문자의 보수로 덮어씀
  3. 다시 임의의 문자로 데이터를 덮어씀
  4. 이 과정을 7번 반복

[표] 완전 삭제 기능을 제공하는 무료 솔루션

1-7. 이용하지 않는 보조기억매체 폐기

: 이용빈도가 높지 않은 보조기억매체는 포맷 등을 통해 저장 정보를 완전히 삭제하고 필요한 경우 물리적으로 폐기한다.

<Reference> 

• 보조매체 이용 안내서, 2010.1, KISA 

Continue reading

No comments

각종 법률 및 제도에서 규정하는 정보보호교육

“개인정보보호 교육을 몇번 받아야 하는지 잘 모르겠어요"

기업을 대표하는 정보보호 담당자들 조차 자사 임직원을 대상으로 정보보호교육을 몇 회 시행해야 하는지 정확히 알지 못하는 경우가 많습니다.

이번 포스팅에서는 각 조직의 특성에 따라 1) 정보보호교육을 몇 회 시행해야 하는지, 2) 어떻게 시행해야하는지 3) 누가 교육을 받아야하는지에 대하여 자세히 알아보도록 하겠습니다.

일반적으로 교육에 대해 규정한 법령 및 제도는 아래와 같습니다

1. 개인정보보호법
2. 정보통신망법
3. 정보보호 관리체계 (ISMS)
4. ISO27001

하나씩 자세히 알아보도록 하겠습니다.

1. 개인정보보호법
개인정보보호법에서는 아래와 같이 규정하고 있습니다.

개인정보보호법 - 제28조(개인정보취급자에 대한 감독)

개인정보보호법에서는 개인정보취급자에게 정기적으로 '필요한 교육' 을 실시해야 한다고 명시되어 있습니다. 그러나 교육 횟수 및 내용 등을 명확히 규정하고 있지 않습니다.

2. 정보통신망법 

정보통신망법 - "개인정보의 기술적 관리적 보호조치 기준" 고시

정보통신망법에서는 아래와 같이 개인정보관리책임자 및 개인정보취급자를 대상으로 매년 2회 이상 교육을 실시하여야 한다고 명시되어 있습니다.

교육 내용에는 해당 업무를 수행하기 위한 분야별 전문기술 교육뿐만 아니라 개인정보보호 관련 법률 및 제도, 사내 규정 등 필히 알고 있어야 하는 기본적인 내용을 포함하여 교육을 실시하도록 하고 있습니다.

* 자주 묻는 질문

Q : 개인정보관리자 및 취급자를 대상으로 매년 2회 이상 교육실시는 개인정보를 다루는 모든 사람에게 개별적으로 적용되는 것인가요?

> 조직 내에 개인정보를 다루는 개인정보관리자 및 취급자는 모두 회사에서 수립한 교육 계획에 따라 최소2회 이상의 교육을 받아야 합니다. 만약 회사에서 연 2회 이상의 교육 기회를 제공하였으나 개인정보관리자 및 취급자가 개별적인 사정으로 교육을 실시하지 않았다면 별도로 교육을 받을 수 있는 기회를 제공해야 합니다.

Q : 정보보호 교육의 일부분으로 개인정보보호 교육이 포함되었다면 교육으로 인정되는 것인가요?

> 정보보호 교육이라 하더라도 회사 내부의 개인정보보호 교육 계획에 의해 실시되었다면 개인정보보호 교육으로 인정될 수 있습니다. 다만, 이때에는 개인정보보호 교육 목적과 대상, 일정 및 방법이 개인정보보호 교육 계획과 부합되어야 하며 교육 실시에 대한 자료는 문서화하여 보관할 수 있습니다.

3. 정보보호 관리체계 (ISMS)

ISMS 에서는 다음과 같은 항목을 통해 교육 횟수를 규정하고 있습니다. 교육 계획 수립, 추가 교육, 효과성 측정 관련한 내용은 생략하도록 하겠습니다.

2-1. 통제항목 : 5.2.1 교육 시행 및 평가

2-2. 통제목적 : 정보보호 관리체계 범위 내 임직원 및 외부자를 대상으로 연 1회 이상 교육을 시행하고 정보보호 정책 및 절차의 중대한 변경, 조직 내/외부 보안사고 발생, 관련 법규 변경 등의 사유가 발생할 경우 추가 교육을 수행하여야 한다. 또한 교육 시행에 대한 기록을 남기고 평가하여야 한다.

2-3. 점검항목 : 정보보호 관리체계 범위 내 임직원 및 외부자를 대상으로 연 1회 이상 기본 정보보호 교육을 수행하고 있는가?

• 경영진(최고경영진)의 승인을 받은 정보보호 교육 계획에 따라 정규직 임직원, 임시직원, 외주용역, 외부자 등을 대상으로 연 1회 이상 기본 정보보호 교육을 시행하여야 한다.

• IT 및 정보보호 직무자는 기본 정보보호 교육 이외에 직무별 정보보호 교육을 별도로 연 1회 이상 이수하여야 한다.

• 개인정보관리책임자 및 개인정보취급자는 연 2회 이상 개인정보보호 교육을 이수하여야 한다. (기본 정보보호 교육에 개인정보보호 내용을 포함할 수 있다.)

• ※ 참고 ※ - 정보통신망 이용촉진 및 정보보호 등에 관한 법률 '개인정보의 기술적 ∙ 관리적 보호조치 기준(고시)' 제3조(내부관리계획의 수립 ∙ 시행) 2항

* 자주 묻는 질문

Q. 인턴도 교육을 받아야 하나요?

> 물론입니다. ISMS 규정에서는 아래와 같이 명시하고 있습니다.

- 정보보호 교육 대상에는 정보보호 관리체계 범위 내 정보자산에 직/간접적으로 접근하는 정규직 임직원, 임시직원, 외주용역업체 직원 등 모든 인력을 포함 한다.
- 정보자산이 위치한 장소에 접근할 수 있는 청소원, 경비원 등에게도 기본적인 정보보호 인식교육을 수행하여야 한다.
- 교육 대상이 하도급에 의해 파견된 직원인 경우 해당 용역업체 담당자가 정보보호 교육을 수행할 수 있도록 관련 자료를 제공하고 지원하여야 한다.

Q. 장기 휴가자도 교육을 받아야 하나요?

> 물론입니다. ISMS 규정에서는 아래와 같이 규정하고 있습니다.

- 출장, 휴가 등으로 인해 정기 정보보호 교육에 불참한 인력에 대해 전달교육, 추가교육, 온라인 교육 등의 방법으로 정보보호 교육을 시행하여야 한다

4. ISO 27001

ISO 27001 에서는 아래와 같이 교육에 대해 규정하고 있습니다

3-1. 통제항목 : A.7.2 고용 중 - A.7.2.2 정보보안 인식, 교육 및 훈련

3-2. 통제사항 : 조직의 모든 임직원, 관련 하청업자에 대해서, 해당 직무 기능과 관련된 조직 내 정책과 절차를 적절하게 인식할 수 있도록 관련 교육과 훈련 및 정규 업데이트를 실시한다.

<A.7.2.2 Information security awareness education and training>

5. 요약

지금까지 4개 법령 및 제도에서 교육에 대해 규정항목을 살펴보았습니다.

위의 내용을 종합적으로 정리하면 아래의 4가지 분류에 따라 교육방법이 분류 될 수 있습니다.

본인이 속한 기업이 

• 개인정보보호법 적용 기업인 경우 :
• 정보통신서비스 제공자인 경우 (ISMS 인증 의무 대상 아님) :
• 정보통신서비스 제공자이자 ISMS 인증 의무대상 기업인 경우 :
• 개인정보보호법 적용 대상인 경우 :

하나씩 살펴 보도록 하겠습니다.

1) 개인정보보호법 적용 기업인 경우

교육 횟수, 내용 등에 대한 정확한 규정이 없으므로, 개인정보취급자를 대상으로 필요한 교육을 1회 이상 수행하면 됩니다.

2) 정보통신서비스 제공자인 경우 (ISMS 인증 의무 대상 아님)

단순 정보통신서비스 제공자인 경우, 개인정보취급자를 대상으로 매년 2회 이상 교육을 실시하여야 합니다.

3) 정보통신서비스 제공자이자 ISMS 인증 의무대상 기업인 경우

정규직 임직원, 임시직원, 외주용역, 외부자 등을 대상으로 연 1회 이상 기본 정보보호교육을 시행하여야 합니다.

개인정보관리책임자 및 개인정보취급자는 연 2회 이상 개인정보보호 교육을 이수 하여야 합니다. 

(단, 기본 정보보호 교육에 개인정보보호 내용을 포함하여 1회를 갈음할 수 있습니다.)

또한 IT 및 정보보호 직무자는 기본 정보보호 교육 이외에 직무별 정보보호 교육을 별도로 연 1회 이상 이수하여야 합니다.

4) ISO27001 적용 대상인 경우

이 역시 교육 횟수, 및 교육 내용등에 대한 정확하게 명시하고 있지 않습니다.

따라서 임직원 및 외부직원을 대상으로한 개인정보보호교육 및 직무 교육에 대한 규정을 정책/지침에 명시하고 정기적으로 교육훈련을 시행하면 됩니다. 

Continue reading

No comments

[정보통신망법] 보안서버의 정의 및 관련 규정

이번 포스팅에서는 보안서버의 정의 및 종류와 보안서버를 강제하는 법률 조항에 대해 정리해 보도록 하겠습니다.

1. 보안서버란?

보안서버란 인터넷상에서 사용자 PC와 웹 서버 사이에 송/수신되는 개인정보를 암호화하여 전송하는 서버를 의미합니다. 

인터넷에서 송/수신되는 개인정보의 대표적인 예로는 로그인시 ID/패스워드, 회원가입시 이름/전화번호, 인터넷 뱅킹 이용시 계좌 번호/계좌 비밀번호 등이 해당됩니다.

아래의 예시에서, 정보통신망법에서 정의하는 유형별 개인정보를 확인할 수 있습니다.

* [정보통신망법]에서 정의하는 개인정보의 예시

<참고 - 정보통신서비스 제공자를 위한 개인정보 법령 해설서, 방송통신위원회 / 한국인터넷진흥원, 2012>

2. 보안 서버의 필요성

인터넷상의 암호화되지 않은 개인정보는 가로채기 등의 해킹을 통해 해커에게 쉽게 유출될 수 있습니다. 반면 암호화된 개인정보는 해킹을 당해도 보호받을 수 있습니다.

• 정보유출 방지 (sniffing 방지)
• 위조사이트 방지 (phising 방지)
• 기업의 신뢰도 향상

<그림 - 보안서버 구축의 필요성>

3. 보안서버의 방식

보안서버는 구축방식에 따라 SSL방식과 응용프로그램 방식 2가지 방식으로 구분됩니다. 

1) SSL 방식

• 사용자 컴퓨터에 별도 보안 프로그램을 설치할 필요가 없으며, 웹 서버에 설치된 [SSL 인증서]를 통해 개인정보를 암호화하여 전송하는 방식입니다.
• 보안서버 구축에 소요되는 비용이 상대적으로 저렴하지만 주기적으로 인증서 갱신을 위한 비용이 소요됩니다. 
• 로그인 페이지 등 보안이 필요한 웹페이지에 접속한 상태에서 브라우저 하단 상태 표시줄에 자물쇠 마크로 확인할 수 있으나, 웹사이트의 구성 방법에 따라 자물쇠 모양의 마크가 보이지 않을 수도 있습니다.

2) 응용프로그램 방식

• 암호화 응용 프로그램을 이용한 보안서버는 웹 서버에 접속하면 사용자 컴퓨터에 자동으로 보안 프로그램이 설치되고 이를 통해 개인정보를 암호화하여 전송합니다.
• 해당 웹사이트에 접속하게 되면 윈도우 오른쪽 하단 작업표시줄 알림영역에 아래 그림과 같은 아이콘을 통해 암호화 실행여부를 확인할 수 있습니다. (응용프로그램에 따라 아이콘이 다를 수 있습니다.)

* 세부 구축 방법 및 자세한 설명은 [보안서버 구축가이드,KISA] 를 참고하세요. 

4. 보안서버 관련 규정

4-1. 정보통신망법
보안서버와 관련된 규정은 [정보통신망법] 에 명확히 명시되어 있습니다.
해당 규정은 보안서버의 기능과 일맥상통합니다. 즉 정보통신망을 통해 이용자의 개인정보 및 인증정보를 송/수신 할때는 보안서버 구축 조치를 통해 이를 암호화 해야합니다.  

4-2. 정보보호관리체계 (ISMS)

ISMS 통제항목에서는 아래와 같이 보안서버 구축을 규정하고 있습니다.

통제항목 : 8.1 분석 및 설계 보안관리 - 8.1.2 인증 및 암호화 기능
통제내용 : 정보시스템 설계 시 사용자 인증에 관한 보안요구사항을 반드시 고려하여야 하며 중요정보의 입/출력 및 송수신 과정에서 무결성, 기밀성이 요구될 경우 법적 요구사항을 고려하여야 한다.

점검항목 : 개인정보 및 인증정보 등의 중요한 정보 전송 시 SSL보안서버 구축 등을 통하여 암호화하고 있는가?

설명 : 정보통신망을 통해 중요정보를 송/수신하는 경우, 법적 요구사항을 고려하여 보안서버 구축 등의 조치를 통한 암호화 통신이 이루어져야 한다. 

5. 요약

내용이 아주 많지만, 간단히 정리하면 1) 정보통신망법에 적용되는 대상 그리고 2) 정보보호관리체계(ISMS)은 반드시 보안서버를 구축해야 합니다.

Continue reading

No comments

취약점 점검에 대해 규정하는 법률 및 국내/외 제도

안녕하세요. 본 포스팅에서는 '취약점 점검’에 대해 규정하는 법률 및 국내/외 제도를 정리 해보도록 하겠습니다.

본 포스팅의 목적은 독자가 속해있는 기업이 1) 취약점 점검을 수행해야 하는지, 혹은 2) 어떤 법/제도에 의해 취약점 점검을 수행해야 하는지, 3) 취약점 점검을 강제하는 규정이 어떤것이 있는지에 대한 궁금증을 해소하는데에 있습니다. 

우선 취약점 점검을 강제하는 법률 및 국내/외 제도는 아래와 같이 5가지로 분류됩니다.

1) 정보통신기반보호법

2) 정보통신망법 이용촉진 및 정보보호 등에 관한 법률

3) 전자금융감독규정
4) ISMS (Information Security Management System)
5) ISO 27001:2013

하나씩 자세히 알아보겠습니다. 

1. 정보통신기반보호법

1-1. 세부 규정

<제9조 (취약점의 분석/평가) - 출처. 법제처 공식 홈페이지>

1-2 상세 내용

위 법령에서 정의한 [취약점 분석/평가]는 453개의 관리적/물리적/기술적 점검 항목에 대한 취약여부를 점검하고 모의해킹, 침투테스트 등을 수행하는 종합적인 위험진단입니다.
  

해당 [취약점 분석/평가] 중 기술적 점검은, 시스템에 대한 실제 보안값 설정에 관한 것으로 각 시스템에 대한 명령어 코드(Command),  메뉴 구성(UI)과 같은 기술적인 사항을 알아야만 가능하기에, 주요정보통신기반시설 담당자들이 어려움을 느낄 수 있습니다. 이에 안행부는 전체 313개 기술적 점검항목에 대한 점검방법 및 조치방법 및 상세 매뉴얼을 개발하였습니다.
[참고 - 주요정보통신기반시설 기술적 취약점 분석평가 방법 상세 가이드]

1-3 [취약점 분석 / 평가 ] 수행 주체 및 주기

• 수행 주체
• • 주요정보통신기반시설의 관리기관이 직접 수행할 경우 자체 전담반을 구성하여 운영
  • 관리기관이 외부기관에게 위탁할 경우, 지식정보보안 컨설팅전문업체 등 전문기관에 위탁 수행

• 수행 주기
• • 1) 주요정보통신기반시설로 지정된 첫 회는 지정 후 6개월 이내에 취약점 분석 / 평가를 실시
  • • 6개월 이내 취약점 분석.평가를 수행치 못할 경우 관할 중앙행정 기관의 장의 승인을 얻어 3개월 연장가능(총9개월)
    • 주요정보통신기반시설로 최초 지정일로 부터 6개월 이전 취약점 분석.평가를 하였을 경우 수행한 것으로 간주
  • 2) 매년 정기적으로 취약점 분석 / 평가 실시

취약점 분석.평가 수행시, 가용자원과 대상시설 식별, 자산 중요도 산정 및 해당 시스템 대한 정밀분석을 실시해야 하며, 만약 취약점 분석.평가 대상시설에 중대한 변화가 있거나, 관리기관의 장이 필요하다고 판단하는 경우에는 1년이 되지않아도 취약점 분석·평가를 실시할 수 있습니다. 

2. 정보통신망법 이용촉진 및 정보보호 등에 관한 법률 (정보통신망법)

<제47조(이용자의 정보보호) - 출처. 법제처 공식 홈페이지>

3. 전자금융감독규정

전자금융감독규정 제15조(해킹 등 방지대책) 및 제17조(홈페이지 등 공개용 웹서버 방지대책), '금융IT부문 보호업무 모범규준' 에 의거 금융회사 등은 주기적으로 취약점 분석 / 평가를 실시하도록 하고 있습니다.

<제15조 (해킹 등 방지 대책) - 출처. 법제처 공식 홈페이지>

<제17조 (홈페이지 등 공개용 웹서버 관리대책) - 출처. 법제처 공식 홈페이지>

또한 취약점 분석/평가 범위가 확대되어, 금융회사등은 전자금융감독규정 제37조의2의 규정에 따라 전자금융기반시설에 대한 취약점 분석/평가를 실시할 때 전자금융기반시설에 포함되지 않는 ‘비 금융 전산시스템’에 대한 침해사고가 전자금융기반시설로 전파될 가능성이 있는 경우, 해당 비 금융전산시스템을 취약점 분석/대상에 포함되도록 하고 있습니다. 

즉, 금융회사등은 非금융 전산시스템에 대한 침해사고가 전자금융기반 시설로 전파되는 것을 사전에 예방하기 위해 非금융 전산시스템에 대해 주기적으로 취약점 점검을 시행하도록 노력하여야 합니다. 

[참고 - 금융회사 정보기술(IT) 부문 보호업무 이행지침]

4. 정보보호관리체계 (이하 ISMS)

ISMS는 조직의 자산에 대한 안전성 및 신뢰성을 향상시키기 위한 절차와 과정을 체계적으로 수립, 문서화하고 지속적인 관리/운영을 통하여 정보보호 목표인 정보의 기밀성, 무결성, 가용성을 실현하기 위한 일련의 과정 및 활동을 말합니다.

ISMS에서는 아래와 같은 항목에서 취약점 점검을 요구하고 있습니다.
(전체 104개 통제항목 중 4개 통제항목)

4-1. [관리과정 - 3. 위험관리 - 3.2 위험 식별 및 평가]

• 통제내용 : 위험관리 방법 및 계획에 따라 정보보호 전 영역에 대한 위험 식별 및 평가를 연 1회 이상 수행하고 그 결과에 따라 조직에서 수용 가능한 위험수준을 설정하여 관리하여야 한다
• 점검항목 : 정보보호 관리체계 인증범위 내의 정보시스템 자산에 대해 취약점 점검을 통한 기술적 위험을 식별하고 있는가?
• 설명 : 기술적 위험은 정보보호 관리체계 범위 내의 정보시스템(서버, 네트워크 장비, 응용 프로그램 등), 정보보호시스템 등에 대한 취약점 점검(점검툴 사용, 체크리스트 사용, 침투시험 등)을 수행하여 발견된 취약점을 위험으로 식별하여야 한다.

4-2. [8. 시스템 개발 보안 -  8.2  구현 및 이관 보안 - 8.2.1 구현 및 시험]

• 통제내용 : 기술적 위험은 정보보호 관리체계 범위 내의 정보시스템(서버, 네트워크 장비, 응용 프로그램 등), 정보보호시스템 등에 대한 취약점 점검(점검툴 사용, 체크리스트 사용, 침투시험 등)을 수행하여 발견된 취약점을 위험으로 식별하여야 한다.
• 설명 : 코딩 완료 후 안전한 코딩 표준 및 규약 준수 여부를 점검하고 기술적 보안 취약점이 존재하는 지 확인하여 취약점 발견 시 재코딩을 하여야 한다.
• 시스템이 안전한 코딩표준에 따라 구현하는 지 소스코드 검증 (소스코드 검증도구 활용 등)
• 코딩이 완료된 프로그램은 운영환경과 동일한 환경에서 취약점 점검도구 또는 모의진단을 통한 취약점 노출 여부를 점검

4-3. [11.2  시스템 및 서비스 운영 보안 11.2.8  공개서버 보안]

• 통제내용 : 웹사이트 등에 정보를 공개하는 경우 정보 수집, 저장, 공개에 따른 허가 및 게시절차를 수립하고 공개서버에 대한 물리적, 기술적 보호대책을 수립하여야 한다.
• 점검항목 (1/2) : 공개서버의 취약점 점검을 주기적으로 수행하고 발견된 취약점을 조치하고 있는가?
• 설명 : 웹서버의 경우 최소한 OWASP TOP 10 웹취약점은 기본적으로 점검하여 취약점이 발견된 경우 신속하게 조치를 하여야 한다. (인증기준 11.2.10 취약점 점검 참고)
• 참고 : 전자금융거래법 '전자금융감독규정(고시)' 제17조(홈페이지 등 공개용 웹서버 관리대책) /웹서버구축 보안점검 안내서 (KISA)

• 점검항목 (2/2) : 웹서버 등 공개 서버를 운영하는 경우 이에 대한 보호대책을 마련하고 있는가?
• 설명 : 공개서버(웹서버, 메일서버 등)를 운영하는 경우 다음과 같은 보호대책을 마련하여야 한다.
• • 공개서버 전용서버로 운영
  • 웹서버를 통한 개인정보 송 ∙ 수신 시 SSL(Secure Socket Layer)/TLS(Transport Layer Security) 인증서 설치 등 보안서버 구축
  • 접근권한 설정
  • 백신설치 및 OS 최신 패치
  • 불필요한 서비스 제거 및 포트 차단
  • 불필요한 소프트웨어 ∙ 스크립트 ∙ 실행파일 등 설치 금지 등
  • 불필요한 페이지(테스트 페이지) 및 에러처리 미흡에 따른 시스템 정보 노출 방지
  • 주기적인 취약점 점검 등

4-4 [11.2 시스템 및 서비스 운영 보안 - 11.2.10 취약점 점검]

• 통제내용 : 정보시스템이 알려진 취약점에 노출되어 있는 지 여부를 확인하기 위하여 정기적으로 기술적 취약점 점검을 수행하고 발견된 취약점들은 조치하여야 한다.
• 점검항목 : 정보시스템 취약점 점검 절차를 수립하여 정기적으로 점검을 수행하고 있는가?
• 설명
• • 정보시스템 취약점 점검 정책과 절차를 다음과 같은 내용을 포함하여 수립하여야 한다.
  • • 취약점 점검 대상 (예 : 서버, 네트워크 장비 등)
    • 취약점 점검 주기
    • 취약점 점검 담당자 및 책임자 지정
    • 취약점 점검 절차 및 방법 등

• • 정보시스템 중요도에 따라 주기적으로 다음과 같은 내용을 포함하여 취약점 점검을 실시하여야 한다.
  • • 라우터, 스위치 등 네트워크 장비 구성, 설정 취약점
    • 서버 OS, 보안 설정 취약점
    • 방화벽 등 정보보호시스템 취약점
    • 어플리케이션 취약점
    • 웹서비스 취약점
    • 스마트기기 및 모바일 서비스(모바일 앱 등) 취약점

• • 취약점 점검 시 회사의 규모 및 보유하고 있는 정보의 중요도에 따라 모의침투테스트를 수행하는 것을 고려하여야 한다.
  • 취약점 점검 시 이력관리가 될 수 있도록 '점검일시', '점검대상', '점검방법', '점검내용 및 결과', '발견사항', ' 조치사항' 등이 포함된 보고서를 작성하여야 한다.

• 점검항목  : 발견된 취약점에 대한 조치를 수행하고 그 결과를 책임자에게 보고하고 있는가?
• 취약점 점검 결과 발견된 취약점별로 대응방안 및 조치결과를 문서화하여야 하며 조치결과서를 작성하여 책임자에게 보고하여야 한다.
• 불가피하게 조치를 할 수 없는 취약점의 경우 그 사유를 명확하게 확인하고 책임자에게 보고하여야 한다.

자세히 기재하니 내용이 복잡해 보이네요. 

간단히 요약하면 ISMS 적용 대상자는 정보보호관리체계 범위 내의 정보시스템을 대상으로 1) 정기적으로 취약점 점검을 수행하고, 2) 웹사이트에 대한 취약점 점검을 수행하고, 3) 발견된 취약점에 대한 조치를 수행하고, 그 결과를 책임자에게 보고해야 합니다. 

5. ISO27001

ISMS는 국내에서 수행 및 적용하는 인증 제도이고, ISO27001은 국제 정보보호인증제도 입니다.

ISO27001에 대한 상세한 설명은 본 포스팅의 목적에 벗어나는 내용이므로 생략하도록 하겠습니다.

ISO 27001에서는 아래의 항목에서 취약점 점검을 요구하고 있습니다.

• 통제항목 : A.12.6 기술적 취약성 관리 - A.12.6.1 기술적 취약성 관리 
• 통제 : 조직내에서 사용하고 있는 정보시스템의 기술적 취약점 정보를 정확하고 신속하게 확보하고, 조직은 이러한 취약점에 노출된 사례에 대해 적절하게 평가하고 관련 위험을 해결하기 위한 적절한 조치를 취해야 합니다.

<ISO27001 : 2013 통제항목 - 12.6.1 Management of technical vulnerabilities >

Continue reading

No comments