ISMS 인증 교육

정책 - 규정  - 지침 - 절차서 간의 일관성이 필요하다. 따라서 정책에서 규정을 가리키도록, 규정에서 지침을 가리키도록, 지침에서 절차서를 가리키도록 하는 방안이 좋다. 정책은 회사를 움직이는 것이기에 정보보안팀에서 TOP DOWN으로 가는 것이 아니라, 인사팀, 총무팀, 법무팀 등 유관부서와 꾸준한 소통을 통해서 만들어야 한다. 개인정보 관련은 이미 정해진 게 많아서 회사 자체적으로 유연하게 바꾸기는 어려우나, 정보보호는 기업에 맞게 보안 수준을 고려해서 만들 수 있는 부분이 많다. 이를테면, '주기적으로'라는 용어를 조직마다 다르게 해석할 수 있는 것이다. 따라서 무조건 강하게 가는 게 아니라, 조직의 실정에 맞게 완화할 수 있는 것은 완화하는 방향으로 설정해야 한다. 절차서를 제외한 정책, 규정, 지침은 제정 및 개정 시 CEO의 승인을 받아야 한다. 따라서 매번 CEO의 승인을 받기는 상당히 불편하고 번거로우니, 자세한 내용은 절차서로 빼서 자주 변경하는 것이 편할 것이다. 

ISMS-P가 아니라, ISMS만 한다고 하더라도 개인정보 서비스 흐름도는 있어야 한다. 정보 서비스 흐름도만 해서 될 것은 아니고, 그렇게 할 경우 결함을 받을 가능성이 크다. 개인정보 서비스는 부서별로 처리하는 곳도 있고, 단순하게 온라인만 있는 것도 아니거니와 오프라인이 있는 것도 있다. 그런 것들을 모두 하나하나 작성해야 녹여야 할 것이고, 심사원들이 제공과 파기를 특히나 유심히 보기 때문에 이 부분을 주의해야 할 것이다. 흐름도를 그리기 이전 개인정보 흐름표는 각 서비스에 넘기고, 물론 암호화 등 그분들이 작성하지 못할 자료가 있겠으나 가능한, 특히 파기 부분은 상세하게 작성하도록 요청해야 한다. 

취약점 진단은 매년 같은 월을 정하는 것이 좋고, 취약점 점검 계획 > 취약점 보고 > 취약점 조치 결과 보고의 3단계에서 공식적 보고가 반드시 필요하다. 신규 서비스, 정보시스템, 보안장비의 경우 보안성 검토는 반드시 필요하다. 그 외에도 보안성 검토는 수시로 해야 할 것이다. 이후 위험평가에서는 N/A에서 별도 사유를 아주 상세하게 적을 필요가 있다. 왜 N/A인지 꼼꼼하게 따지는 심사원들이 있기 때문이다. 위험관리에서는 위험수용을 하는 경우도 있는데, 정보보호팀에서 판단해서 하는 게 아니라, CISO와 크게는 CEO의 승인까지 받아서 수용을 결정해야 한다. 위험을 감수한다는 것이기에 그저 정보보호위원회에서 승인했다고 되는 내용은 아니고, 정말 수용할 만한 내용인지도 확인한다. 수용은 '위험의 영향이 크지 않다고 판단될 때' 행하는 것이기 때문이다.

관리체계 운영명세서는 각각의 기준 항목에 대한 운영현황을 현 상황과 100% 일치하도록 자세하게 작성하여야 하고, 증적자료와 함께 폴더별로 정리해야 한다. 마찬가지로 N/A는 그 사유를 상세하게 작성해야 한다. 기술적, 물리적 환경을 근거로 명시해야 하고, 매년 심사받기 전, 문서에 갱신 혹은 변경되어야 할 내용이 있는지 확인해야 한다.

심사 인터뷰를 대응할 때는 현업 직원들에게 애매한 답변을 주어서는 안된다고 사전 교육을 수행해야 할 것이다. 인터뷰 대상 직원 대상으로 실제로 교육을 수행할 필요가 있다. 사전에 예상 질문지를 던져줄 수 있다면 아주 좋다. 그리고 소관부서와 답변이 엇갈리는 경우가 있기 때문에 그 싱크를 맞출 수 있도록 고려할 필요가 있다.

인증심사 준비할 때는 증적 정리 체크리스트를 통해 수행할 수 있을 텐데, 매일매일 수행하지 않아서 개학 직전 일기 몰아쓰듯 하면 들킬 수밖에 없다. 따라서 데일리로 해야 할 일, 위클리/먼슬리로 해야 할 일들을 분명히 구분해서 정리할 필요가 있을 것이다.

인증 기준 및 주요 요구사항은 회사마다 정말 천차만별이기에 단순 ISMS 인증제도 기준서를 보고 그대로 할 것이 아니라, 그것을 조직의 특성에 맞게 반영할 필요가 있다. 1.1.1 경영진 참여는 정보보호위원회 회의록이 정말 중요하다 할 것이다. 만약에 이전에 정보보호 안건이 없었다면, 지금부터라도 그 안에 정보보호 안건도 1개라도 녹여서 회의록으로 인정받도록 해야 할 것이다. 만일 모두 바빠서 모이기 힘들다 하면 서면회의라도 진행하여 증적을 반드시 남겨야 한다. 

최근 강화인증군 대상으로 5일 동안 취약점 진단을 수행한다는 것은 전체 자산을 대상으로 하는 것은 불가할 것이기에, 개인정보처리시스템을 대상으로 수행할 가능성이 높다. 또한 신기술에 해당하는 자산(k9s, AI 관련 등)에 대해서 취약점 진단을 '추가로' 수행할 때는 보통 현업 부서를 설득하는 게 쉽지 않은데, 그럴 때는 ISMS 인증 범위에 해당하느냐 해당하지 않느냐로 명분을 삼는 것이 가장 좋다. ISMS에 들어간 이상 취약점 진단은 필수이기 때문이다. 그리고 민간은 보통 주정통을 기반으로 취약점 진단을 수행할 텐데, 신기술이라 주정통으로 불가할 경우에는... 애당초 외주를 맡길 때 취약점 진단까지 수행하도록 하는 것이 좋다. 기준까지 너희가 마련해서 진단까지 수행해!라고 하는 것이다. 1.1.2 최고책임자의 지정은 자격 요건과 직무의 독립성이 심사의 핵심이라 할 것이다. 최근 망법, 개보법 개정으로 CISO와 CPO에 대한 요건이 바뀌었으므로, 이를 만족할 필요가 있다. 보수적인 인사팀에서는 CISO나 CPO의 인사발령을 해주지 않는 경우도 있는데, 그렇다 하면 게시한 내역이라도 무언가 근거를 찾아야 한다. 결함 사례 중에서는 CISO 지정 및 신고 의무 대상자임에도 정보보호 지정 및 신고하지 않은 경우가 꽤나 흔하다. 그런데 이제는 CPO도 개보위에 신고한 여부를 확인하는 경우가 많을 것으로 보이기에 이 부분도 신경 써야 할 것이다. 1.1.3 조직 구성에서는 정보보호 및 개인정보보호 위원회 규정 및 회의록 정도는 기본적으로 보기 때문에 이 정도는 보유하고 있는지 확인해야 할 것이다. 1.1.4 범위 설정은 핵심 자산을 포함하도록 관리체계 범위를 설정해야 하는데, 인증심사 진행하다 보면 결함이 나오기도 한다. 보통 이럴 경우 중결함으로 되기 때문에 인증범위를 제대로 식별할 필요가 있다. 특히나 클라우드 서비스를 별도로 식별하고 문서화 관리할 필요가 있다. 그리고 간혹 외주 직원들이 상주할 경우, 외주 직원들의 PC를 범위에 제외하는 경우가 있는데, 이것을 놓치지 않도록 주의해야 할 것이다. 결함은 주로 대외 서비스와 관련된 내부 관리 시스템이 포함되지 않아서 맞는 경우가 많다. 이를 테면, 외부에 공개된 임직원용 복지몰 같은 곳 말이다. 그리고 개발과 관련된 것이라면, 모든 것을 다 포함시켜야 할 것이다. 1.1.5 정책 수립은 정책이 수립이 되는 것까지는 모두 하겠지만, 회사의 환경에 맞는 내용인지, 모든 직원의 볼 수 있게 공개가 되어있는지까지 안 되어있는 경우가 꽤 있다. CISO 승인으로 끝나서 결함을 받는 경우도 있다. 1.1.6 자원 할당은 보통 ISMS 때문에라도 전문가를 뽑는 경우가 많아서 전문성이 없는 경우가 드물다. 그리고 전년도 말쯤에 다음 해의 연간 정보보호 활동 계획을 미리 작성하여 경영진과 협의해 예산, 인력 등을 조율하는 과정이 필요하다. 1.2.1 정보자산 부분에서 인프라 부서에서 놓치는 경우가 많다. 따라서 신규 시스템은 반드시 CISO 승인을 받도록 한다면 정보보호팀에 반드시 공유가 될 수밖에 없다. 그러면 보안성 검토도 수행하고, 정보자산도 놓칠 수가 없기 때문에 그런 식으로 프로세스를 수립하는 것이 좋다. 그리고 쇼단, DNS로도 많이 찾을 수 있을 텐데, 우리와 관련 있는데 몰랐던 사이트가 많이 나올 수 있다. 대부분 와일드카드로 되어있을 텐데, 그러면 하나하나 확인해서 많은 숨겨진 자산을 찾아낼 수 있을 것이다. 오프라인 부분은 못 찾을 수도 있는데, 어차피 오프라인은 정보통신망에 해당하지 않으니 엄청 매달릴 필요는 없다. 1.2.2 현황 및 흐름분석은 정보서비스 흐름도와 관련된 것으로, 전 과정을 가시화하여 파악하고 있는지 평가한다. 1.2.3 위험평가는 연 1회 이상 한다는 것은 모두가 알고 있을 것이다. 여기서 보통 문제가 생기는 것들은 DoA를 경영진의 의사결정에 의해 결정했는지를 보는 것이다. 보통 최초심사 때 많이 나오는 것으로, 위험평가서에서 조치결과서까지 모두 보고해야 한다. 위험 발생 가능성과 영향도를 최하점으로 기재하는 경우가 가끔 있다. 당장 도저히 해결하기 어려울 것 같아 미루는 것인데, 이렇게 하면 바로 결함을 맞을 수 있으니 유의해야 한다. 위험관리가 정말 잘되고 있다면 결함을 주지 않기 때문에 위험은 위험이라고 분명히 말할 수 있어야 한다. 보통 결함이 나오면 우리가 드러내지 못한 걸 심사원이 밝혀 결함을 주는 것이다. 1.3.1 보호대책 구현은 보통 사후심사에서 결함이 많이 나오는데, 이행 연기에 대한 증적이 없으면 결함이 된다. 항상 사유서를 CISO에게 재승인받는 것이 필요하며, 정보보호 운영명세서를 수시 혹은 주기적으로 내용 검토해야 한다. 그래서 결함 사례를 보면 보고하지 않아서, 운영명세서와 실제 현황이 일치하지 않아서인 경우가 많다. 1.3.3 운영현황 관리는 결함은 잘 나오지는 않고, 작년에 나왔던 결함이 조치가 잘 되었는지 정도를 확인하곤 한다. 따라서 작년의 결함이 올해 조치가 잘 되어 운영되고 있는지 확인할 필요가 있다. 적어도 본 심사 3개월 전에 체크하는 것이 좋을 것이다. 1.4.1 법적 요구사항 준수 검토 항목은 결함이 정말 많이 나오는 항목이다. 정말 온라인이건 오프라인이건 한 땀 한 땀 구체적으로 보기 때문에 여기서 결함이 안 나오기가 쉽지 않다. 특히 법령은 수시로 개정되기 때문에 한번 확인한 것으로 끝내지 않고 지속적으로 팔로우 업해야 한다. 우리 회사가 어떤 법의 영향을 받는지 구체적으로 확인하고 수시로, 주기적으로 점검해야 할 것이다. 1.4.2 관리체계 점검에서는 감사 수행을 위해 독립성 및 전문성이 확보된 인력으로 구성하는데, 정말 조직의 보안성을 제고하고 싶다면 같은 인력을 줄곧 쓰는 것은 피해야 할 것이다. 

2.1.1 정책의 유지관리도 결함이 종종 발생하는 항목인데, 정책이 최신 규제를 반영하지 못할 때 결함이 발생한다. 결국 법이나 최신 동향을 팔로우 업하지 않아서 문제가 생긴다는 것이다. 그렇기에 조직이 영향을 받는 법이 개정되면, 개정사항 중에 우리 회사의 정책에 반영할 것이 없는지 확인해야 한다. 앞서 말했듯, 정책은 회사 전체에 영향을 주는 문서기 때문에 정보보호팀에서만 수행해서는 아니 될 것이고, 이해관계자와 해당 내용을 충분히 협의 및 검토해야 한다. 그밖에, 정책서에는 A라고 되어있는데, 지침에는 B로 되어있어 기준이 서로 충돌하는 경우가 은근 빈번하다. 따라서 앞서 기술했듯, 문서의 체계를 관리해서 하나만 수정해도 되도록 수행할 필요가 있다. 2.1.2 조직의 유지관리는 직무기술서, 업무분장표가 보통 있으니 문제가 없다고 생각할 수 있는데, 정보보호 활동을 주기적으로 평가할 수 있는 KPI와 관련하여 결함을 맞는 경우가 있다. 따라서 이 부분이 없다면 인사팀과 긴밀하게 협의할 필요가 있을 것이다. 2.1.3 정보자산 관리를 두고 1.2.1 정보자산 식별과 상당히 헷갈릴 수 있는데, 1.2.1 정보자산 식별은 자산 목록화 및 중요도를 산정하는 것이고, 2.1.3은 그렇다면 그 등급에 맞춰 어떻게 관리하고 책임자를 지정할 것인지를 다루는 영역이다. 퇴사자 반영이 되지 않아 정보자산의 담당자 및 책임자 현행화가 되지 않아 결함이 되는 사례가 있으며, 따라서 적어도 1년에 2번은 확인해야 할 것이다. 2.2.1 주요 직무자 지정 및 관리에서 주요 데이터에 접근할 수 있는 자는 반드시 목록에 포함해야 하는데, 개인정보에 접근할 수 있는 자, 회계담당자, 인사담당자는 반드시 포함해야 할 것이다. 개인정보취급자 목록은 인사시스템과 연동하는 것이 좋을 것이고, 수기로 하면 분명 문제가 생길 것이다. 난이도가 어렵지 않기 때문에 시스템과 연동하는 게 베스트다. 

계정 · 권한 · 접근통제는 반드시 시스템화가 필요하다. 특히 특수계정은 누가 언제 무엇을 했는지 로그를 저장할 필요가 있고, 공용계정에 대해서도 어쩔 수 없이 공용계정을 사용해야 하는 경우가 많을 것이다. 그때 이 공용계정에 대한 책임추적 방안이 없으면 취약점이라 할 것이다. 2.6.3 응용프로그램 접근에서 증적자료는 모두 실사점검을 하기 때문에 미리 소통이 필요하다. 2.6.4 데이터베이스 접근은 DB 접근을 차단하고 특정 쿼리를 날렸을 때 잘 통제하는지 보는 것인데, 심사할 때 매우 까다롭게 본다. 보통 개발자나 DBA 대상으로 인터뷰를 하기 때문에 잘 안내할 필요가 있다. DB 접근 내역에 대한 주기적 검토는 월간 정보보호 보고에 녹이면 좋고, DB 접근제어솔루션은 사실상 선택이 아닌 필수다. 이게 있어야 심사를 받을 수 있다 할 것이고, 이게 있으면 접근제어, 권한제어, SQL 감사/로깅, 분석 및 보고서 생성이 모두 가능할 것이고, DB가 수가 많은 점을 고려한다면 반드시 필수라 할 것이다. 2.6.5 무선 네트워크 접근은 무선 네트워크 장비 목록 관리, 정보 송수신 시 암호화 기능 설정(WPA2 이상), SSID 숨김 기능 설정(브로드캐스팅 중지), 접속 단말 인증 방안(IP, MAC 인증) > NAC를 이용한 IP, MAC 인증도 가능의 4가지를 모두 설정한다면야 충분히 대응할 수 있을 것이다. 그밖에 테더링, 비인가 AP 차단 등은 일반적으로 통제하기 어려우므로 WIPS를 도입하여 통제하도록 해야 할 것이다. 이게 실질적으로 정말 쉽지 않아서 임직원 대상 교육이 꾸준히 필요하다. 2.7.1 암호정책 적용 부분은 전수조사를 해야만 한다. 상당히 결함이 많이 발생하는 영역으로, 위험도 분석이니, 저장 위치니 등등 구분하지 말고 그냥 다 암호화하는 게 편하다.

 

최근 이슈된 ISMS 인증 강화방안에 대해서는 취약점 점검원 부분이 추가되었는데, 개인정보처리시스템 등 주요시스템을 대상으로 진단을 할 가능성이 높다. 이 부분에 대해서 대비를 미리 해두면 좋을 것이고, 강화인증으로는 특히 기술적인 요소를 많이 따질 것으로 예상된다. 암호화 알고리즘의 경우 인증기준 안내서에 있는 것을 따르는 것이 좋다. 그렇기에 BASE64 같은 것보다는 명시된 것을 사용해야 할 것이다. 2.8.4 시험과 데이터 보안은 실데이터를 개발 서버에 사용하지 말라는 게 아니라, 사용할 거면 CISO 승인을 받고 개발서버에서 실데이터를 사용하라는 것이다. 당연히 이 경우에는 주구장창 쓰는 게 아니라 기간을 정해서 쓰도록 해야 할 것이다. 그런데 실데이터가 필요한 게 아니라 데이터 형식이 필요한데도 실데이터를 요구하는 경우가 있을 수 있는데, 이때는 개발 서버로 이관 시에 마스킹하여 이관하면 될 것이다. 그러면 별도의 승인 없이 쓸 수 있다. 2.9.4 로그 및 접속기 관리에 대해서는 윈도우 이벤트 뷰어 용량 확보 관련해서는 최대 로그 크기를 가능한 큰 숫자로 설정해야 할 것이다. 2.9.6 시간 동기화는 NTP 서버를 동기화한다고 끝나는 게 아니라, 모든 정보시스템 및 정보보안 솔루션 등이 하나의 NTP 서버를 바라보게끔 해야 한다. 2.9.7 정보산의 재사용 및 폐기 관련해서는 불용 처리된 HDD/SDD를 전산실 혹은 사무실에 아무런 보안 조치 없이 장기간 쌓아두면 결함을 맞게 되므로 주의해야 한다. 2.10.1 보안시스템 운영은 정말 결함 빈도가 높은 항목인데, 가장 많이 나오는 결함이 방화벽에 쓸데없는 정책이 있을 때다. 방화벽 카운트를 보여달라는 경우가 많고, 주로 퍼밋(올퍼밋, 올포트, 올아이피) 정책 위주로 검토한다. 카운트가 0인데 정책이 남아있어? 그럼 결함인 것이다. 그밖에 EOS 제품이거나 시그니처 업데이트 중단된 경우 결함을 맞게 된다. 2.10.2 클라우드 보안은 권한 부분에 대한 검토가 면밀히 필요하다. 사스건 파스건, 권한이 있는 부분까지는 보기 때문이다. 그리고 그것이 SLA에 녹아있어야 할 것이다. 또한, 자체적으로 보안서비스를 받는 것이 좋으며, 특히 IAM 및 Access Key는 철저하게 관리해야 한다. 클라우드 IAM 계정에 필요 이상의 권한이 과도하게 부여될 경우에는 결함을 맞게 될 것이다. 2.11.1에서 서버 백신을 설치하면 참 좋지만 쉽지는 않을 것이다. 선택이 아닌 필수이기에 우선은 주요시스템이라도 먼저 도입해야 할 것이고, 그 이후부터 대응체계 구축은 사실 난이도는 쉽다. 문서로만 작성하면 되기 때문이다. 여기서 비상 연락망은 주기적으로 최신화해야 할 것이고, 침해하고 대응 매뉴얼은 필수로 만들고 현행화를 관리해야 한다. 2.11.3 이상행위 분석 및 모니터링은 관제팀이 있으면 모르겠으나, 그게 없으면 쉽지가 않다. 자체적으로 보안관제가 안 된다면, SIEM, SOAR 솔루션을 도입하도록 해야 할 것이다. 플레이북을 디테일하게 잘 만드는 방안이 있으나, 이것도 사실 쉽지는 않다. 어디까지나 관제를 할 수 없을 때의 아쉬운 대체방안이라 할 것이다. 심사에는 문제없지만 말이다. 

 

이 모든 인증 준비를 위해 연간 업무 스케줄을 미리 짜는 것이 좋을 것이다. 주기를 미리 다 지정하고, 이에 따라 언제 수행할지 정해놓으면 놓칠 게 없을 것이다. 그리고 업무별로 담당자가 지정되어있어 이 부분에 대해 업무를 상기시키고 진행하면 되는 것이다. 정보보호 월간 점검 보고에도 엑셀 파일로 제작하여 각 시트별로 보고 항목을 정리하면 편하다. 그러면 하나로 모든 게 정리되는 것이다.