ISMS-P 인증심사원 인증 기준 풀이 편집하기 (부분)

== 중첩된 인증 기준 판단 사례 ==
아래 내용들은 실제 심사 사례나 모의고사 등을 통해 헷갈리는 사례들을 모아 놓은 것이니 참고할 것. 다만, 사적인 경험이나 문제집에서 도출된 것이며 KISA의 공식 확인이 있었던 것은 아니라 실제 KISA의 인증심사원 문제의 해석 방향과 일치하지 않을 수 도 있으니 주의할 것. 의구심이 있는 내용이 있으면 서로 편집하거나 토론을 통해 해결할 수 있다.

하나의 문제가 두 가지 이상의 인증 기준에 따른 결함으로 중첩되어 해당하는 경우, 가장 기본적인 판단 기준은 아래와 같다.

* '''두 인증 기준에 따른 결함이 서로 인과관계가 있을 경우''', 더 근본적인 원인(root cause)에 해당하는 인증 기준이 정답이 된다.
** 시기적으로나 업무 절차적으로 더 선순위에 해당하거나, 더 큰 범위의 포괄적인 문제를 관장하는 경우가 더 근본적이라고 판단할 수 있다.
* '''두 인증 기준에 중첩되어 해당되지만 인과간계를 갖지 않는 경우''', 더 정확하게 맞아 떨어지는(best fit) 인증 기준이 정답이 된다.
** B에 대한 문제인데, 1번 인증기준은 A, B, C에 모두 해당될 수 있는 경우이고 2번 인증 기준은 B에만 해당될 수 있다면 2번 인증 기준이 정답이 된다.

'''위 두 가지 기준으로 판단된 실제 사례들은 아래를 통해 확인할 수 있다.'''<blockquote>'''사용자 계정 발급 절차 없이 하나의 계정을 여러 명이 쓰거나 한 명이 여러 개의 계정을 만들어 사용하여 계정별 사용자에 대한 식별이 불가한 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.5.1.사용자 계정 관리|2.5.1.사용자 계정 관리]]
**[[ISMS-P 인증 기준 2.5.2.사용자 식별|2.5.2.사용자 식별]]
*'''(정답 및 판단근거)''' 
**더 근본적인 원인을 찾는 대표적인 사례라고 할 수 있다. 일단 지금 사례만 보았을 때는 2.5.1과 2.5.2의 결함 사례에 모두 해당이 된다. 하지만 여기서 계정의 사용자가 식별이 되지 않는 문제는 명백하게 사용자 계정 발급 절차가 없음에 기인한다고 볼 수 있다.
**만약 계정 발급 절차가 있는데도 불구하고 계정이 무분별하게 생성되고 사용자 식별이 안되는 경우라면 2.5.2 결함일 수 있다. 하지만 이 두 가지 모두에서 결함이 확인된다면 2.5.1을 해결하면 두가지 문제가 모두 해결될 수도 있다고 판단하고 우선 2.5.1을 결함으로 잡게 된다.
**'''답) [[ISMS-P 인증 기준 2.5.1.사용자 계정 관리|2.5.1.사용자 계정 관리]]'''

<br /><blockquote>'''잘못 구성된(사원, 대리급으로만 구성) 정보보호위원회의 의결로 정보보호 정책이 수립되어 경영진 보고 없이 정책이 배포된 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**잘못된 정보보호위원회 구성 = [[ISMS-P 인증 기준 1.1.3.조직 구성|1.1.3.조직 구성]]
**잘못된 정보보호 정책 수립 = [[ISMS-P 인증 기준 1.1.5.정책 수립|1.1.5.정책 수립]]
**경영진 보고 누락 = [[ISMS-P 인증 기준 1.1.1.경영진의 참여|1.1.1.경영진의 참여]]
**잘못된 보호대책 공유 = [[ISMS-P 인증 기준 1.3.2.보호대책 공유|1.3.2.보호대책 공유]]
*'''(정답 및 판단근거)''' 
**인과 관계상 명백히 잘못 구성된 정보보호위원회(조직)의 결정에 따라 발생한 문제이므로, 현 사안에선 가장 근본적인(root cause) 조직 구성 결함 사례로 봄
**'''답) [[ISMS-P 인증 기준 1.1.3.조직 구성]]'''
<blockquote>'''PMS(패치 관리 시스템)에 접근통제가 제대로 되지 않아 외주 직원이 상시 접근 가능한 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.6.1.네트워크 접근|2.6.1.네트워크 접근]]
**[[ISMS-P 인증 기준 2.6.2.정보시스템 접근|2.6.2.정보시스템 접근]]
**[[ISMS-P 인증 기준 2.6.3.응용프로그램 접근|2.6.3.응용프로그램 접근]]
**[[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.1.보안시스템 운영]]
**[[ISMS-P 인증 기준 2.10.8.패치관리|2.10.8.패치관리]]
*'''(정답 및 판단근거)''' 
**경우에 따라 다를 수 있으나, 2.10.8 패치관리 인증 기준에 PMS에 대한 접근통제 요구사항이 있다는 점을 주의해야 한다.
**네트워크 망 구성의 전반적인 통제 미흡으로 PMS에 접근 통제가 미흡해진 상황이라면 2.6.1 네트워크 접근이 root cause로 판단되어 정합일수도 있지만, 대상이 PMS라면  굳이 상황판단이 애매한 문제는 출제하지 않을 가능성이 높다. 2.6.2 정보시스템은 서버 등 운영체제에 직접 접근하는 경우가 대상이라 해당사항이 없다.
**2.6.3 응용 프로그램 접근도 큰 의미에서는 현재 상황을 포함한다고 볼 수 있으며, 2.10.1에서도 PMS를 다루고 있다. 하지만 이들이 PMS에 대한 접근 통제에 대한 root cause라고 보긴 어렵다. Best fit 관점에선 2.6.3이 더 넓은 범위를 포함하고, 2.10.1이 좀 더 좁은 범위로 특정되어 있지만, 2.10.8은 PMS에 대해서만 직접적으로 다루고 있는 인증 기준이므로 가장 best fit에 해당한다고 할 수 있다.
**'''답) [[ISMS-P 인증 기준 2.10.8.패치관리|2.10.8.패치관리]]'''

<br /><blockquote>'''잘못된 배포과정을 통해 업데이트된 시스템이 운영에 배포되어 장애가 발생한 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**잘못된 배포 과정 = [[ISMS-P 인증 기준 2.9.1.변경관리|2.9.1.변경관리]]
**잘못된 운영 반영 = [[ISMS-P 인증 기준 2.8.6.운영환경 이관|2.8.6.운영환경 이관]]
*'''(정답 및 판단근거)''' 
**운영환경 이관은 절차적인 계획 수립 및 기본적인 이행 여부의 관점이며, 변경관리는 실무적인 검토 실패에 관한 관점이 강하다.
**운영환경 배포에 대한 절차가 마련되지 않은 경우라면 2.8.6 결함이지만, 배포 과정에서 실무적으로 과실이 있었던 경우 대부분 변경관리 결함 사례로 처리된다.
**'''답) [[ISMS-P 인증 기준 2.9.1.변경관리]]'''

<br /><blockquote>'''업무용 단말에 보안 프로그램들이 설치되어 있으나, 잘못된 예외처리로 보안 결함이 발생한 경우,'''</blockquote>

*'''(참고)''' 관련 인증 기준
**잘못된 단말 보안 = [[ISMS-P 인증 기준 2.10.6.업무용 단말기기 보안|2.10.6.업무용 단말기기 보안]]
**잘못된 예외처리 운영 = [[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.1.보안시스템 운영]]
*'''(정답 및 판단근거)''' 
**업무용 단말기에 필요한 보안 프로그램들이 설치되어 있는 지에 관한 것은 2.10.6의 관점이나,설치되어 있는 프로그램들에 대한 잘못된 운용은 2.10.1에 해당함
**'''답) [[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.1.보안시스템 운영]]'''

<br /><blockquote>'''불가피한 사유로 운영 데이터를 시험 데이터로 임시 사용했으나 프로젝트 종료 후 파기하지 않은 경우.'''</blockquote>

*'''(참고)''' 관련 인증 기준
**시험 데이터 변환, 실 데이터 사용 시 사용 후 파기 = [[ISMS-P 인증 기준 2.8.4.시험 데이터 보안|2.8.4.시험 데이터 보안]]
**개인정보 처리목적 달성 시 파기 = [[ISMS-P 인증 기준 3.4.1.개인정보의 파기|3.4.1.개인정보의 파기]]
*'''(정답 및 판단근거)'''  
**불가피한 경우 운영 데이터를 시험 데이터로 사용할 수는 있으나 시험 후 데이터 삭제를 철저히 하여야 한다.
**다른 인증 기준에 따른 파기와, 포괄적인 3.4.1.개인정보 파기가 경합한다면 대부분 다른 인증 기준에 따른 파기가 정답인 경우가 많다. 인증 기준이 중첩되면 root cause나 best fit을 찾아야 하는데, 다른 기준에 따른 파기와 관련하여 일반적인 내용의 3.4.1 개인정보의 파기가 시기적으로나 업무 절차적으로나 root cause가 되긴 어렵기 때문
**답) [[ISMS-P 인증 기준 2.8.4.시험 데이터 보안|'''2.8.4.시험 데이터 보안''']]

<br /><blockquote>'''재해복구 과정에서 개인정보가 포함된 임시 테이블이 생성되었으나 작업 후 삭제되지 않은 채 방치된 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 3.4.1.개인정보의 파기|3.4.1.개인정보의 파기]]
**[[ISMS-P 인증 기준 2.6.4.데이터베이스 접근|2.6.4.데이터베이스 접근]]
*'''(정답 및 판단근거)''' 
**결과적으로 파기되어야 하는 개인정보가 파기되지 않은 문제가 발생하였을 수도 있으나, 근본적으로 재해복구 등의 과정에서 생성된 테이블 목록이 현행화되어 관리되지 못한 문제로, 테이블 목록 관리에 관한 2.6.4.데이터베이스 접근 결함이다.
**'''답) [[ISMS-P 인증 기준 2.6.4.데이터베이스 접근|2.6.4.데이터베이스 접근]]'''

<br /><blockquote>'''망분리 대상 내부망 PC에서 인터넷으로 접근할 수 있는 방화벽 정책이 들어가 있으나 실제 다른 네트워크 장비에 의해 차단되고 있는 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.6.1.네트워크 접근|2.6.1.네트워크 접근]]
**[[ISMS-P 인증 기준 2.6.7.인터넷 접속 통제|2.6.7.인터넷 접속 통제]]
**[[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.1.보안시스템 운영]]
*'''(정답 및 판단근거)'''
**방화벽이 잘못 들어가 있는 것을 보고 2.6.1 네트워크 접근이나 2.6.7 인터넷 접속 통제 를 의심할 수도 있으나 실제로 인터넷에 접속되지 않고 있기 때문에 해당 항목에 대해선 결함이 아니다.
**다만 불필요한 방화벽 정책이 삭제되지 않고 남아 있으므로 2.10.1. 보안시스템 운영 결함으로 볼 수 있다.
**'''답) [[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.1.보안시스템 운영]]'''
<blockquote>'''시스템 유지보수 등 부수적인 업무를 담당하는 계열사 직원들의 계정이, 직원이 퇴사한 이후에도 삭제되지 않고 그대로 존재하고 있는 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.5.1.사용자 계정 관리|2.5.1.사용자 계정 관리]]
**[[ISMS-P 인증 기준 2.5.5.특수 계정 및 권한 관리|2.5.5.특수 계정 및 권한 관리]]
*'''(정답 및 판단근거)'''
**논란이 있을 수 있다. 계열사 직원이 내부에서 상시적으로 업무를 수행하는 파견직 등이라면 2.5.1의 "전보, 퇴직 등 인사이동 발생 시 지체 없이 접근권한 변경 또는 말소"라는 기준에 대한 결함일 수 있다.
**다만 계열사 직원이 외부인이고, 상시적으로 접근을 하지 않으며, 다소 특수한 업무를 하는 경우엔 2.5.5에 대한 결함으로 판단될 가능성이 높다. 특히 "<u>정보시스템 유지보수 등 외부자에게 부여하는 특수권한은 필요시에만 생성, 업무 종료 후에는 즉시 삭제 또는 정지하는 절차를 적용</u>"이라는 내용이 명시적으로 들어가 있으므로 '시스템 유지보수'와 관련된 외부 직원일 경우 대부분 2.5.5에 대한 결함으로 볼 수 있다.
**'''답) [[ISMS-P 인증 기준 2.5.5.특수 계정 및 권한 관리]]'''
<blockquote>'''사내에 들어와서 일하는 위탁업체 직원들이 BYOD로 가져온 업무용 노트북에 백신 설치가 되어 있지 않은 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.10.6.업무용 단말기기 보안|2.10.6.업무용 단말기기 보안]]
**[[ISMS-P 인증 기준 2.3.3.외부자 보안 이행 관리|2.3.3.외부자 보안 이행 관리]]
*'''(정답 및 판단근거)'''
**논란이 있을 수 있다. 다만, 외부자 보안 이행 관리는 위탁 계약서, 내부정책 등에 보안조치 미이행에 대한 인증 기준이므로 계약서나 내부정책의 내용이 있어어야 확실하다.
**내규에 따라서 위탁직원들이 사내 업무용 단말기를 사용하도록 되어 있으면 2.10.6 결함으로 판단될 수도 있다.
**하지만 노트북을 외부에서 가져와서 사용하는 경우엔 2.3.3 결함으로 판단될 가능성이 높다.
**'''답) [[ISMS-P 인증 기준 2.3.3.외부자 보안 이행 관리|2.3.3.외부자 보안 이행 관리]]'''
<blockquote>'''시스템 시간이 UTC로 되어 있어서 시간을 잘못 파악하여 보안 사고나 컴플라이언스 위반이 나타난 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.9.6.시간 동기화|2.9.6.시간 동기화]]
**[[ISMS-P 인증 기준 2.11.1.사고 예방 및 대응체계 구축|2.11.1.사고 예방 및 대응체계 구축]]
*'''(정답 및 판단근거)'''
**시스템 시간의 기준이 한국 표준시간과 맞지 않는다는 것이 항상 시간 동기화 결함은 아니다. 클라우드 서비스나 글로벌 서비스를 운영하는 경우라면 표준시가 불가피하게 다르게 운영될 수도 있다.
**이를 제대로 인지하지 못하여 사고로 이어지는 경우엔 2.9.6은 결함으로 잡을 수 없기에 2.11.1 결함이 된다.
**그러나 논란의 소지가 있을 수 있는데, 한국 표준시로 설정하는데 문제가 전혀 없는데도 불구하고 외국 시간으로 잘못 설정되어 있었다면 해당 문제를 유발한 2.9.6가 root cause 관점에서  결함이 될 수도 있다.
**'''답) [[ISMS-P 인증 기준 2.11.1.사고 예방 및 대응체계 구축|2.11.1.사고 예방 및 대응체계 구축]]'''
<blockquote>'''백업 대상과 방법을 정의한 지침에서 백업 주기는 주1회로 되어 있는 시스템이, 재해 복구계획에선 RPO가 3일로 설정된 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.1.1.정책의 유지관리|2.1.1.정책의 유지관리]]
**[[ISMS-P 인증 기준 2.9.3.백업 및 복구관리|2.9.3.백업 및 복구관리]]
**[[ISMS-P 인증 기준 2.12.1.재해, 재난 대비 안전조치|2.12.1.재해, 재난 대비 안전조치]]
*'''(정답 및 판단근거)'''
**논란이 있을 순 있으나, 정책의 유지관리 결함이라고 하기엔 시스템별 백업 주기나 RPO는 실무적인 수치로, 정책이나 지침의 레벨이라고 보기 어렵다.
**백업 및 복구관리 결함이라고 하기엔 백업 및 복구 자체만을 기준으로 보기엔 결함의 근거가 없다. 또한 재해 복구 계획이 백업 및 복구관리 기준보다 더 상위 정책·지침이라고 볼 수 없으므로 주1회 백업이 잘못되었다고 판단할 수 없다.
**'''답) [[ISMS-P 인증 기준 2.12.1.재해, 재난 대비 안전조치|2.12.1.재해, 재난 대비 안전조치]]'''
<br /><blockquote>'''내부 지침에선 적절한 비밀번호 정책을 제시하고 있으나 실제 운영시스템의 비밀번호 설정 규칙은 취약하게 들어가 있는 경우'''

*ex) 지침에선 영문+숫자 10자 이상으로 설정토록 하였으나, OOO 시스템의 비밀번호 설정 규칙을 검증하는 로직에는 영문+숫자로 8자리 이상으로 설정토록 하고 있는 경우
</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 2.5.4.비밀번호 관리|2.5.4.비밀번호 관리]]
**[[ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험|2.8.2.보안 요구사항 검토 및 시험]]
*'''(정답 및 판단근거)'''
**논란이 있을 수 있다. 실제로 지침과 다른 비밀번호를 사용하고 있는 것이 확인되는 경우 2.5.4. 비밀번호 관리 결함(비밀번호 관리 규칙 수립·이행에서 '이행')으로 볼 수도 있다.
**하지만 실제 비밀번호가 아니라 비밀번호 설정 규칙의 불일치라면 이는 2.8.2에 걸릴 가능성이 더 높다. 특히 비밀번호 뿐만 아니라 여러가지 실무적인 사항들이 지침과 다르게 적용된 것들이 무더기로 보인다면 이는 답이 2.8.2일 확률이 매우 높다.
**참고로 지침에 비밀번호 정책이 적절하게 있다는 것을 보여주지 않고, 단순히 패스워드 규칙만이 증적으로 제시된 상황이라면 2.5.4가 답이다.
**'''답) [[ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험|2.8.2.보안 요구사항 검토 및 시험]]'''
<blockquote>'''법적으로 잘못된 내용이 사고 대응지침에 들어가 있는 경우'''</blockquote>

*'''(참고)''' 관련 인증 기준
**[[ISMS-P 인증 기준 1.4.1.법적 요구사항 준수 검토|1.4.1.법적 요구사항 준수 검토]]
**[[ISMS-P 인증 기준 2.1.1.정책의 유지관리|2.1.1.정책의 유지관리]]
**[[ISMS-P 인증 기준 2.11.1.사고 예방 및 대응체계 구축|2.11.1.사고 예방 및 대응체계 구축]]
*'''(판단근거)'''
**논란이 있을 수 있다. 모두가 답이 될 수 있으며, 실제로 위 관련 인증기준들이 모두 보기로 나오려면 이에 대한 인과관계나 처리 과정들이 기술된 증적이 있어야 한다. 제정될 때 부터 잘못되었는지, 법이 개정되었는데 업데이트가 안 된건지, 아니면 시고 대응지침만 날림으로 작성된 것인지 봐야 한다.
**하지만 문제에서 그러한 히스토리를 찾을 수 없고 문제에 저 셋 중 하나가 나온다면 그걸 답으로 선택할 수 있다. 이렇게 답이 여러 개가 될 수 있는 문제들은 대부분 논란의 소지가 될 수 있는 다른 보기를 없앤다. 그렇기 때문에 "법적으로 위배된 내용이 있네? 이거 저번에 개정된 내용인데" 라는 배경지식만으로 1.4.1이나 2.1.1일 것이라고 단정짓고 답안지에 2.11.1이 있어도 무시하는 일은 없어야 한다. 셋중에 하나는 분명히 결함이라고 인지할 수 있어야 하며, 셋중에 하나만 보기에서 제시가 되었다면 답으로 선택하면 된다.
**그러한 히스토리가 나오지 않는데 위의 보기가 여러 개가 나온다면 출제오류라고 주장할 수 있다.<ref>하지만 이의제기를 받아주지 않는 것이 현실</ref>
설명	입력하는 내용	문서에 나오는 결과
기울임꼴	''기울인 글씨''	기울인 글씨
굵게	'''굵은 글씨'''	굵은 글씨
굵고 기울인 글씨	'''''굵고 기울인 글씨'''''	*굵고 기울인 글씨*