ISMS-P 결함사례 고찰 #2.8. 정보시스템 도입 및 개발 보안

2.8.1 보안 요구사항 정의

인증기준: 정보시스템의 도입·개발·변경 시 정보보호 및 개인정보보호 관련 법적 요구사항, 최신 보안취약점, 안전한 코딩방법 등 보안 요구사항을 정의하고 적용하여야 한다.

 

결함사례#1

정보시스템 인수 전 보안성 검증 기준 및 절차가 마련되어 있지 않은 경우가 있다. 정보시스템에 대한 보안성 기준과 절차를 마련하는 것은 언제나 필수적인 일이다. 이것에 따라 타당성을 검토하여 인수할 준비를 할 수 있기 때문이다. 부동산을 살 때 그 부동산에 대한 정보, 입지, 미래에 가격이 오를만한 가능성 등을 전부 검토하지 않는가. 그거와 다를 바가 없다. 도입하기 전에는 도입 계획이 필요한 법이고, 그에 따라 검토는 필수적으로 이뤄져야 한다.

 

결함사례#2

신규 시스템 도입 시 기존 운영환경에 대한 영향 및 보안성을 검토하도록 내부 규정을 마련하고 있으나, 최근 도입한 일부 정보시스템에 대하여 인수 시 보안요건에 대해 세부 기준 및 계획이 수립되지 않았으며, 이에 따라 인수 시 보안성검토가 수행되지 않은 경우가 있다. #1의 연장선으로 보이며, 실제로 이미 도입하기로 회사 내부적으로 결정이 났다고 하더라도, 이에 대한 검토는 필수적으로 진행해야 한다. 이용률, 사용량, 능력한계 등을 분석하여 이미 조직이 잘못된 결정을 내렸다 하더라도 그 위험성에 대해 따질 필요는 당연히 있기 때문이다.

 

결함사례#3

개발 관련 내부 지침에 개발과 관련된 주요 보안 요구사항(인증 및 암호화, 보안로그 등)이 정의되어 있지 않은 경우가 있다. 이런 요구사항은 KISA에서 이미 가이드의 일부로 소개하고 있으며, 이것이 정의되어 있지 않다면 이미 첫 단추부터 잘못 끼운 것이 아닐까 싶다. 어떻게 방법론을 적용해야 하는지 이미 명시되어 있으니 이를 참고하여 업무를 진행하면 될 것이다.

 

결함사례#4

'개발표준정의서'에 사용자 패스워드를 안전하지 않은 암호화 알고리즘(MD5, SHA1)으로 사용하도록 되어 있어 관련 법적 요구사항을 적절히 반영하지 않는 경우가 있다. MD5, SHA1은 안전하지 않은 것의 대명사로, 법에는 어느 알고리즘 이상을 사용해야 하는지 분명하게 명시되어 있다. 법에 친절하게 명시가 되어있음에도 불구하고 반영하지 않았다는 것은 법을 전혀 고려하지 않았다는 말이 될 것이다. 이런 결함사례를 겪은 조직은 성문법에 따라 조치를 즉각 취해야 할 것이다.

 

2.8.2 보안 요구사항 검토 및 시험

인증기준: 사전 정의된 보안 요구사항에 따라 정보시스템이 도입 또는 구현되었는지를 검토하기 위하여 법적 요구사항 준수, 최신 보안취약점 점검, 안전한 코딩 구현, 개인정보 영향평가 등의 검토 기준과 절차를 수립·이행하고, 발견된 문제점에 대한 개선조치를 수행하여야 한다.

 

결함사례#1

정보시스템 구현 이후 개발 관련 내부 지침 및 문서에 정의된 보안 요구사항을 시험하지 않고 있는 경우가 있다. 보통은 당연하게도 보안 요구사항을 시험해서 체크리스트, 시험 결과서 등에 이를 반영할 것이다. 제대로 요구사항이 적용이 되었는지 하나하나 따지지 않고서 어떻게 그것을 바로 적용할 수 있겠는가. 이런 사례가 있다는 것은 정말 보안에 신경을 쓰지 않을 때 가능한 일이지 않을까.. 싶다.

 

결함사례#2

응용프로그램 테스트 시나리오 및 기술적 취약점 점검항목에 입력값 유효성 체크 등의 중요 점검항목 일부가 누락된 경우가 있다. 개인적으로 무언가 테스트나 점검을 하기에 앞서 체크리스트를 따져서 누락되는 항목이 없는지 확인하는 것을 선호한다. 꼼꼼한 사람이 있는 게 아니라, 꼼꼼하게 업무를 하는 사람이 있는 것이라고 믿기 때문이다. 아마 이 사례도 꼼꼼하게 업무를 진행하지 않았기에 발생한 경우이지 않을까 싶다. 보안 업무를 하다 보면, 무언가가 누락이 되는 사례가 참 많다. 그래서 개인적으로 지침과 체크리스트를 기반으로 하는 것을 선호하는 것이다.

 

결함사례#3

구현 또는 시험 과정에서 알려진 기술적 취약점이 존재하는지 여부를 점검하지 않거나, 타당한 사유 또는 승인 없이 확인된 취약점에 대한 개선조치를 이행하지 않은 경우가 있다. 보통은 여기서의 타당한 사유는 존재하지 않는 편이라고 봐야 하겠다. 법에서 관습적으로 '타당한 사유'라고 성문화하는 게 보편적이기야 하다만, 이를 실제로 충족하는 경우가 드물기 때문이다. 취약점이 존재하는지 여부를 점검하는 것은 구현 과정은 물론이거니와 주기적으로 진행해야 하는 업무다. 이를 이행하지 않았다는 것은 뭐.. 업무 스케줄이 급박했을 수도 있고, 귀찮았을 수도 있고.. 그랬을 터이다. 그런데 어쩌겠는가. 취약점 평가를 하지 않았다면 ISMS-P에서 당연히 떨어질 수밖에 없다.

 

결함사례#4

공공기관이 5만 명 이상 정보주체의 고유식별정보를 처리하는 등 영향평가 의무 대상 개인정보 파일 및 개인정보처리시스템을 신규로 구축하면서 영향평가를 실시하지 않은 경우가 있다. 사실 이 경우도 법으로 전부 명시가 되어있다. 그래서 내가 속한 조직이 영향평가 의무대상에 속하는지 확인하는 일은 결코 어렵지 않다. 특히나 법률에 관해서는 계속해서 개정이 어떻게 되는지 주목할 필요가 있을 것이다. 이 규모와 규모에 따른 적용에 대해서는 내용이 가끔 바뀌곤 하기 때문이다.

 

결함사례#5

공공기관이 영향평가를 수행한 후 영향평가기관으로부터 영향평가서를 받은 지 2개월이 지났음에도 불구하고 영향평가서를 개인정보 보호위원회에 제출하지 않은 경우가 있다. 2개월이라는 시간도 분명하게 명시되어 있으며, 보통은 타당한 사유가 역시나 없을 것이기 때문에 반드시 그 기간 안에 제출해야 한다. 봐주고 말고 할 게 없다. 명시가 되어 있으니 개인정보 보호위원회는 그것에 따라야 하기 때문이다. 조율이 사실상 불가능에 가까운 것이기 때문에 반드시 그 기간 안에 제출을 완료해야 할 것이다.

 

결함사례#6

신규 시스템 도입 시 기존 운영환경에 대한 영향 및 보안성을 검토(취약점 점검 등)하도록 내부 지침을 마련하고 있으나, 최근 도입한 일부 정보시스템에 대하여 인수 시 취약점 점검 등 보안성검토가 수행되지 않은 경우가 있다. 무엇이든 변동이 있을 경우에는 정기적 검토를 제외하고서도 최초 검토를 실시해야 한다. 이것도 하나의 프레임워크를 만들어서 누락되는 일이 없도록 해야 할 것이다.

 

2.8.3 시험과 운영 환경 분리

인증기준: 개발 및 시험 시스템은 운영시스템에 대한 비인가 접근 및 변경의 위험을 감소시키기 위하여 원칙적으로 분리하여야 한다.

 

결함사례#1

타당한 사유 또는 승인 없이 별도의 개발환경을 구성하지 않고 운영환경에서 직접 소스코드 변경을 수행하고 있는 경우가 있다. 이게 업무적으로 훨씬 편하니까 이렇게 하는 건데, 원칙적으로 개발 영역과 운영 영역은 분리되어야 한다. 항상 외치는 망분리와 유사한 개념으로 봐야 한다. 분리는 언제나 이뤄져야 한다는 것을 명심하고 구축에 임해야 할 것이다.

 

결함사례#2

불가피하게 개발시스템과 운영시스템을 분리하지 않고 운영 중에 있으나, 이에 대한 상호 검토 내역, 모니터링 내역 등이 누락되어 있는 경우가 있다. 물론, 불가피한 경우가 존재하기는 할 것이다. 그런데 불가피해서 분리하지 않았다면, 최소한의 모니터링과 상시 검토, 책임추적성 확보는 필수적이다. 분리를 하지 않은 일종의 책임이라고 볼 수 있다. 분리도 안 하고, 분리를 하지 않은 것에 대한 조치도 취하지 않는다면, 정말 문제가 많은 시스템이라 볼 수 있을 것이다.

 

결함사례#3

개발시스템이 별도로 구성되어 있으나, 개발환경으로부터 운영환경으로의 접근이 통제되지 않아 개발자들이 개발시스템을 경유하여 불필요하게 운영시스템 접근이 가능한 경우가 있다. 기껏 분리를 했는데 접근을 통제하지 않는다면 말짱 도루묵일 것이다. 이에 대한 조치는 즉각적으로 이뤄져야 할 것이다.

 

2.8.4 시험 데이터 보안

인증기준: 시스템 시험 과정에서 운영데이터의 유출을 예방하기 위하여 시험 데이터의 생성과 이용 및 관리, 파기, 기술적 보호조치에 관한 절차를 수립·이행하여야 한다.

 

결함사례#1

개발 서버에서 사용할 시험 데이터 생성에 대한 구체적 기준 및 절차가 수립되어 있지 않은 경우가 있다. 이에 대한 구체적 기준과 절차를 수립하지 않으면, 실제 데이터가 유출되는 경우도 있을 것이고, 제대로 가공이나 변환되지 않는 경우도 발생할 것이다. 언제나 프레임워크나 지침을 두고 그에 따라 업무를 수행하는 것을 습관적으로 이행해야 할 것이다.

 

결함사례#2

타당한 사유 및 책임자 승인 없이 실 운영데이터를 가공하지 않고 시험 데이터로 사용하고 있는 경우가 있다. 실 운영데이터를 가공이나 변환하지 않는다면 개인정보가 유출될 염려가 있다. 가공하지 않고 사용할 경우에는 그에 대한 접근 제어를 철저히 하고, 모니터링 등의 대책을 마련해야 한다. 이게 유출이 되면 대참사가 일어나는 것이기 때문이다.

 

결함사례#3

불가피한 사유로 사전 승인을 받아 실 운영데이터를 시험 용도로 사용하면서, 테스트 데이터베이스에 대하여 운영 데이터베이스와 동일한 수준의 접근통제를 적용하고 있지 않은 경우가 있다. 시험 용도로 사용한다고 해도, 어찌되었건 사용을 하는 건 동일하다. 이 경우에도 실제와 마찬가지로 접근통제를 적용할 필요가 있다. 공격자가 테스트 DB라고 봐주는 경우는 없으니 말이다.

 

결함사례#4

실 운영데이터를 테스트 용도로 사용한 후 테스트가 완료되었음에도 실 운영데이터를 테스트 데이터베이스에서 삭제하지 않은 경우가 있다. 실 운영데이터는 언제나 파기 원칙에 따른 절차를 밟아야 한다. 법으로 명시되어 있는 만큼 해당 절차를 지키는 것은 그다지 어렵지 않을 것이다.

 

2.8.5 소스 프로그램 관리

인증기준: 소스 프로그램은 인가된 사용자만이 접근할 수 있도록 관리하고, 운영환경에 보관하지 않는 것을 원칙으로 하여야 한다.

 

결함사례#1

별도의 소스 프로그램 백업 및 형상관리시스템이 구축되어 있지 않으며, 이전 버전의 소스 코드를 운영 서버 또는 개발자 PC에 승인 및 이력관리 없이 보관하고 있는 경우가 있다. 소스 프로그램에 대한 변경이력을 관리하는 것은 필수로 여겨야 한다. 그런데 여기서도 절차를 수립하고, 그것을 따라서 해야 할 것이다.

 

결함사례#2

형상관리시스템을 구축하여 운영하고 있으나 형상관리시스템 또는 형상관리시스템에 저장된 소스코드에 대한 접근제한, 접근 및 변경이력이 적절히 관리되지 않고 있는 경우가 있다. 이것도 #1처럼 지침과 절차를 수립하지 않아서 생기는 문제가 아닐까 싶다. 변경 이력과 변경통제 수행내역에 대해 정기적인 검토를 수행해야 할 것이다.

 

결함사례#3

내부 규정에는 형상관리시스템을 통하여 소스 프로그램 버전관리를 하도록 되어 있으나, 최신 버전의 소스 프로그램은 개발자 PC에만 보관되어 있고 이에 대한 별도의 백업이 수행되고 있지 않은 경우가 있다. 별도의 백업은 언제나 필수로 여겨야 한다. 이 사례에 대한 소고를 쓰면서 '필수'라는 말을 자주 말하게 되는데, 그만큼이나 기본으로 여겨지는 것들이 지켜지지 않아 결함사례로 뽑히는 경우가 많기 때문이다. 백업은 반드시 수행해야 하고, 백업본에 대한 비인가자의 접근 통제도 확실히 진행해야 할 겅시다. 백업본의 위치도 분명 분리를 해야 하는 것은 물론이고 말이다.

 

2.8.6 운영환경 이관

인증기준: 신규 도입·개발 또는 변경된 시스템을 운영환경으로 이관할 때는 통제된 절차를 따라야 하고, 실행코드는 시험 및 사용자 인수 절차에 따라 실행되어야 한다.

 

결함사례#1

개발·변경이 완료된 소스 프로그램을 운영환경으로 이관 시 검토·승인하는 절차가 마련되어 있지 않은 경우가 있다. 소스 프로그램을 운영환경으로 이관할 때도 안전하게 하기 위한 절차가 수립 및 이행되어야 한다. 그래서 이관 전략에 대해서도 기획을 해야 하고, 문제 발생 시의 대응 방안 등 고려해야 할 사항이 꽤나 될 것이다.

 

결함사례#2

운영서버에 서비스 실행에 불필요한 파일(소스코드 또는 배포모듈, 백업본, 개발 관련 문서, 매뉴얼 등)이 존재하는 경우가 있다. 운영 환경에는 서비스 실행에 필요한 것만을 두고, 설치해야 한다. 승인되지 않은 개발도구 같은 것들이 있다면 운영 환경과 개발 환경이 100% 분리되었다고 말할 수 없을 것이다.

 

결함사례#3

내부 지침에 운영환경 이관 시 안전한 이관·복구를 위하여 변경작업 요청서 및 결과서를 작성하도록 정하고 있으나, 관련 문서가 확인되지 않은 경우가 있다. 안전한 이관과 복구를 위한 계획은 필수적이며, 당연히 이에 대한 문서화 작업은 그에 따른 수순으로 이행되는 일이다. 이 문서를 토대로 누락되는 것 없이 안전하게 업무를 진행해야 하기 때문이다.

 

결함사례#4

내부 지침에는 모바일 앱을 앱마켓에 배포하는 경우 내부 검토 및 승인을 받도록 하고 있으나, 개발자가 해당 절차를 거치지 않고 임의로 앱마켓에 배포하고 있는 경우가 있다. 내부적으로 검토가 이뤄져야 문제가 없는지 파악할 수 있다. 개발자가 아무리 스스로 완성도를 자랑한다 한들, 중이 제 머리 못 깎는다는 말이 있는 법이다. 괜히 스스로 덤탱이 쓰는 일 없이, 지침에 따라 절차를 거쳐 안전하게 배포하도록 해야 할 것이다.