ISO 27001 인증 준비 9일차.

이제 조금씩 방향이 잡히기 시작했다.

그동안은 회사의 조직과 업무를 살펴보고,

개인정보가 어디에서 어떻게 처리되는지 확인하고,

방화벽과 서버, 홈페이지의 보안상태를 점검하고,

각종 문제점과 부족한 증적을 찾아내는 일을 해왔다.

그렇게 하나씩 들여다보다 보니 어느 순간 이런 생각이 들었다.

“그런데 이 모든 것을 정말 다 인증 대상으로 만들어야 하는 걸까?”

우리 회사의 서비스는 생각보다 훨씬 방대했다.

서비스도 많고,

시스템도 많고,

모든 서비스를 인증 대상에 넣을 필요는 없었다

ISO 27001은 모든 회사와 조직에 동일한 범위를 강제로 적용하는 방식이 아니다.

ISO 역시 ISO 27001을 조직의 규모와 필요에 맞게 정보보호 관리체계를 수립하고, 위험관리 프로세스를 조직의 상황에 맞게 적용할 수 있는 표준으로 설명하고 있다. 또한 실제 인증을 받는 경우 조직이 적용할 관리체계의 범위를 정의하는 것이 중요하다.

그래서 우리 회사처럼 서비스가 방대한 경우에는 인증이 필요한 서비스와 시스템을 중심으로 범위를 정하는 것이 현실적인 접근이 될 수 있었다.

우리 회사는 ISO나 ISMS의 의무 인증 대상에 해당하지 않았기 때문에, 인증을 준비하는 과정에서도 어떤 서비스와 조직을 범위에 넣을 것인지 보다 현실적으로 검토할 수 있었다.

다만 여기에서 한 가지는 구분할 필요가 있다.

“의무대상이 아니기 때문에 ISO 27001은 일부만 인증할 수 있다”는 의미는 아니다.

ISO 27001 자체가 원래 조직의 상황에 맞춰 범위를 정의할 수 있는 관리체계이고, ISMS 역시 인증 신청 시 인증범위를 정해 진행한다.

즉 우리에게 중요한 것은

“얼마나 많이 포함할 것인가?”

보다

“어떤 범위를 실제로 관리하고 인증할 것인가?”

였다.

인증범위를 정하는 일이 생각보다 어려웠다

처음에는 단순하게 생각했다.

“서비스 하나 선택하면 되는 것 아닌가?”

그런데 실제로는 그렇게 간단하지 않았다.

하나의 서비스가 있으면 그 서비스와 연결된 서버가 있고,

네트워크가 있고,

데이터베이스가 있고,

개발자가 있고,

운영자가 있고,

개인정보를 처리하는 부서가 있을 수 있다.

외부업체가 유지보수를 할 수도 있고,

가족사와 연결되어 있을 수도 있다.

결국 서비스 하나를 인증범위에 넣는 순간 주변의 수많은 요소가 함께 따라온다.

그래서 범위를 정한다는 것은 단순히 서비스 이름 하나를 선택하는 작업이 아니었다.

그 서비스를 운영하기 위해 필요한

조직 + 사람 + 시스템 + 데이터 + 인프라 + 프로세스

전체를 어디까지 포함할 것인지 정하는 작업이었다.

이걸 보고 나니 왜 지금까지 그렇게 많은 미팅을 했는지 조금 더 이해가 됐다.

처음에는 그냥 회사 전체를 알아가는 줄 알았다.

그런데 사실은 인증범위를 결정하기 위한 준비 과정이었던 셈이다.

정보보호 정책도 한 번에 전사 적용하는 것이 아니었다

9일차에는 정보보호 정책을 어떻게 회사에 적용할 것인지에 대한 이야기도 나왔다.

여기에서 컨설팅사에서 설명해준 방식이 재미있었다.

처음부터 모든 조직에 모든 정책을 한꺼번에 적용하는 것이 아니라 단계적으로 확산시키는 방식이었다.

이번 컨설팅에서 이야기된 방식은 크게 세 단계였다.

1단계 — 적용 가능한 조직부터 시작

먼저 위원회를 구성하고 기본적인 정보보호 체계를 정리한다.

그리고 현재 준비가 가능한 조직부터 정책을 적용한다.

2단계 — 적용 범위 확대

1단계에서 실제 운영하면서 발견된 문제점을 수정하고,

그 경험을 바탕으로 더 많은 조직으로 정책 적용 범위를 넓혀간다.

3단계 — 전사 확산

마지막으로 회사 전체 조직에 정책과 프로세스를 적용하고,

전사적으로 정보보호 관리체계가 운영되도록 만드는 것이다.

여기서 중요한 것은 이 1→2→3단계 자체가 ISO 27001에서 정한 공식 의무 순서라는 의미는 아니라는 것이다.

ISO 27001은 조직의 상황에 맞는 정보보호 관리체계를 구축하고 지속적으로 개선하는 것을 요구하는 표준이다.

따라서 우리 컨설팅에서 제시한 이 단계는 현실적으로 정책을 도입하고 정착시키기 위한 실행 로드맵이라고 이해하는 편이 적절했다.

그런데 개인적으로는 이 방식이 이해하기 쉬웠다.

회사 전체에 갑자기 새로운 규정을 쏟아붓는다면 반발도 생길 수 있고,

실무자들도 무엇을 어떻게 해야 하는지 혼란스러울 수 있다.

반면 가능한 조직부터 시작하면 실제 업무에서 문제가 무엇인지 확인하면서 조금씩 확장할 수 있다.

이제는 ‘훈련’까지 실제로 해야 했다

그동안은 정책과 시스템, 문서 같은 부분에 집중했다.

그런데 이제는 실제로 훈련을 해서 움직여야 한다는 이야기도 다시 나왔다.

대표적인 것이 침해사고 모의훈련이었다.

실제 침해사고가 발생했다고 가정하고,

누가 최초로 발견하고,

누가 보고하고,

누가 대응하며,

어떤 절차로 조치할 것인지 확인하는 것이다.

그리고 여기에 DR(Disaster Recovery) 모의훈련도 포함됐다.

서비스에 문제가 생겼을 때 실제로 복구가 가능한지,

백업된 데이터로 정상적인 서비스를 복구할 수 있는지,

복구 과정에서 문제가 발생하지는 않는지 등을 확인하는 것이다.

여기에서도 역시 빠지지 않는 것이 있었다.

기록이다.

훈련을 했다는 사실,

참여한 사람이 누구였는지,

어떤 상황을 가정했는지,

어떤 문제가 발견됐는지,

어떻게 개선했는지.

이런 내용이 남아 있어야 한다.

이쯤 되니 정말 모든 활동에 증적이 따라온다는 생각이 들었다.

임대장비 하나를 반납하는 데도 기록이 필요했다

이날 또 하나 알게 된 것은 임대장비 관리였다.

회사에서 장비를 임대해서 사용하는 경우가 있을 수 있다.

노트북이든 서버든 저장장치든,

계약이 종료되면 장비를 다시 반납하게 된다.

그런데 단순히

“장비를 업체에 돌려줬습니다.”

로 끝내면 안 된다는 것이다.

특히 저장매체에 회사의 데이터가 남아 있다면,

반출 전에 적절한 방법으로 데이터를 삭제하거나 매체를 초기화하고,

그 사실을 확인할 수 있는 증빙을 남기는 것이 중요하다.

이 역시 결국 같은 이야기였다.

“삭제했다.”

가 아니라

“삭제했고, 그 사실을 이렇게 확인할 수 있다.”

여야 한다.

임대장비 하나가 나가는 순간에도 정보보호의 마지막 단계가 필요했던 것이다.

비인가 소프트웨어도 관리해야 했다

그리고 비인가 소프트웨어 설치 통제에 대한 이야기도 나왔다.

사실 개발자나 IT 담당자 입장에서는 필요한 프로그램 하나 설치하는 것이 별것 아닌 일처럼 느껴질 수 있다.

하지만 회사의 시스템에 어떤 소프트웨어가 설치되어 있는지 관리되지 않는다면 여러 가지 문제가 발생할 수 있다.

어떤 프로그램인지,

누가 설치했는지,

업무상 필요한 것인지,

공식적으로 승인된 것인지,

현재도 사용하고 있는지.

이런 부분을 확인할 필요가 있다.

특히 서버나 중요 정보자산에 대해서는 더욱 그렇다.

그래서 여기에서도

설치 요청 → 검토 → 승인 → 설치 → 기록

과 같은 관리 프로세스가 필요하다는 이야기가 나왔다.

6일차에 방화벽 정책을 볼 때와 상당히 비슷했다.

결국 무엇인가를 추가하거나 변경하는 행위에는 그에 따른 관리절차가 필요했다.

개발자에게는 시큐어 코딩이 필요했다

개발과 관련해서는 시큐어 코딩(Secure Coding) 이야기도 이어졌다.

개발자가 기능을 정상적으로 구현하는 것만으로 끝나는 것이 아니라,

애플리케이션 자체에 보안 취약점이 발생하지 않도록 개발 단계에서부터 보안을 고려해야 한다는 것이다.

생각해보면 당연한 이야기다.

개발이 끝난 뒤 보안 취약점을 찾아내고 수정하는 방법도 있지만,

가능하면 애초에 개발 과정에서부터 보안을 고려하는 것이 좋다.

그러려면 개발자에게 교육을 해야 하고,

회사가 어떤 기준으로 시큐어 코딩을 적용할지 정해야 한다.

예를 들어 어떤 취약점을 중요하게 보는지,

코드 리뷰는 어떤 방식으로 진행할지,

개발 완료 후 어떤 보안검토를 할지 등을 기준으로 만들어야 한다.

결국 개발자 개인의 “주의”만으로 해결할 문제가 아니라

회사의 개발 프로세스 안에 보안을 포함시키는 것이 필요했다.

이 이야기를 들으면서 2일차에 이야기했던 개발·테스트·운영 분리와도 자연스럽게 연결됐다.

개발부터 배포까지의 과정 전체에 보안이 들어가기 시작하는 것이다.

할 일이 줄어들기는커녕 계속 늘어난다

9일차가 끝나면서 솔직히 조금 지쳤다.

처음에는 ISO 27001 인증 준비라고 하면

정책 만들고,

문서 정리하고,

심사받으면 되는 줄 알았다.

그런데 실제로 해보니 그렇지 않았다.

인증범위를 정해야 하고,

정보보호 정책을 만들어야 하고,

조직에 적용해야 하고,

모의훈련도 해야 하고,

DR도 확인해야 하고,

임대장비도 관리해야 하고,

소프트웨어 설치도 통제해야 하고,

개발자 교육과 시큐어 코딩도 해야 한다.

그리고 하나하나 실행했다면 또 기록이 필요하다.

정말 끝이 없는 것처럼 느껴졌다.

그런데 한편으로 생각해보면 조금 다른 의미도 있었다.

처음에는 해야 할 일이 계속 생긴다고만 생각했는데,

이제는 그 많은 일이 하나의 방향을 향하고 있다는 것이 보이기 시작했다.

결국 인증범위가 가장 중요할 수도 있겠다는 생각

9일차에 가장 크게 느낀 것은 역시 인증범위의 중요성이었다.

우리 회사의 서비스 전체를 모두 범위에 넣는다면 관리해야 하는 정보자산도 많아지고,

9일차를 마치며

9일차는 지금까지의 컨설팅 내용이 하나씩 정리되기 시작한 날이었다.

처음에는 회사 전체가 너무 커서 어디서부터 봐야 할지 막막했다.

하지만 이제는 적어도

무엇을 인증할 것인지

를 정하기 시작했다.

그리고 그 안에서 필요한 정책과 프로세스를 단계적으로 도입하고,

모의훈련을 진행하고,

장비 반납부터 소프트웨어 설치, 개발 과정까지 관리 범위를 넓혀가야 했다.

처음에는 ISO 27001이 “보안을 잘하는 회사라는 것을 인증받는 것”이라고만 생각했다.

그런데 9일째가 되니 조금 다른 의미로 보인다.

회사가 중요하게 생각하는 정보와 서비스를 정하고, 그 범위 안에서 실제로 보안을 관리할 수 있는 체계를 만드는 과정.

그게 지금 우리가 하고 있는 일이었다.

그리고 이상하게도 범위가 확정되어 갈수록 마음은 조금 편해졌다.

해야 할 일이 많다는 사실은 변하지 않았다.

오히려 더 명확해졌다.

그런데 적어도 이제는

“우리가 무엇을 어디까지 해야 하는가?”

라는 질문에 조금씩 답할 수 있게 됐기 때문이다.

물론 그 답을 얻었다고 해서 일이 끝난 것은 아니었다.

오히려 이제부터가 진짜 시작이었다.