ISMS-P 인증심사원 인증 기준 풀이 편집하기

IT위키

경고: 로그인하지 않았습니다. 편집을 하면 IP 주소가 공개되게 됩니다. 로그인하거나 계정을 생성하면 편집자가 사용자 이름으로 기록되고, 다른 장점도 있습니다.

편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.

최신판 당신의 편집
1번째 줄: 1번째 줄:
*'''상위 문서: [[ISMS-P 인증심사원 교본]]'''
*'''상위 문서: [[ISMS-P 인증심사원 교본]]'''
결함을 찾는 문제가 헷갈리는 이유는 '''1. 일부 심사가준에 제목으로 유추하기 힘든 확인사항들이 포함된 경우''', '''2. 하나의 원인으로 인해 여러 심사기준상의 결함이 발생한 경우'''가 많기 때문이다. 1번의 경우엔 심사 기준을 정독함으로써 어느 정도 해결이 가능하나, 2번은 '''가장 근본 적인 원인(root cause)'''이 되는 결함을 찾는 매커니즘의 이해와 훈련이 필요하다. 모의고사 등을 통해 하나의 원인으로 여러 기준상의 결함이 발생하는 사례들을 확인하고, 해설지 등을 통해 root cause를  찾는 방법을 파악해야 한다. 이는 중복되는 기준들에 따라 판단 근거가 매번 달라지므로 일관된 규칙이나 공식은 없다. 심지어는 심사 현장에서 관례적으로 이루어지는 내용들도 있으므로 사례를 많이 접하고 익히는 것이 중요하다.  
결함을 찾는 문제가 헷갈리는 이유는 1. 일부 심사가준에 제목으로 유추하기 힘든 확인사항들이 포함된 경우, 2. 하나의 원인으로 인해 여러 심사기준상의 결함이 발생한 경우가 많기 때문이다. 1번의 경우엔 심사 기준을 정독함으로써 어느 정도 해결이 가능하나, 2번은 가장 근본 적인 원인(root cause)이 되는 결함을 찾는 매커니즘의 이해와 훈련이 필요하다. 모의고사 등을 통해 하나의 원인으로 여러 기준상의 결함이 발생하는 사례들을 확인하고, 해설지 등을 통해 root cause를  찾는 방법을 파악해야 한다. 이는 중복되는 기준들에 따라 판단 근거가 매번 달라지므로 일관된 규칙이나 공식은 없다. 심지어는 심사 현장에서 관례적으로 이루어지는 내용들도 있으므로 사례를 많이 접하고 익히는 것이 중요하다.  


== 유사한 인증 기준 ==
== 유사한 인증 기준 ==
13번째 줄: 13번째 줄:
** 위험평가 결과에 맞는 보호대책을 선정하고 이행 계획을 승인 받는 과정이 미흡할 경우엔 1.2.4
** 위험평가 결과에 맞는 보호대책을 선정하고 이행 계획을 승인 받는 과정이 미흡할 경우엔 1.2.4
** 선정된 보호대책이 일부 이행되지 않았거나 미흡하게 이행된 경우 1.3.1
** 선정된 보호대책이 일부 이행되지 않았거나 미흡하게 이행된 경우 1.3.1
* [[ISMS-P 인증 기준 3.1.1.개인정보 수집 제한|'''3.1.1 개인정보 수집 제한''']] vs [[ISMS-P 인증 기준 3.1.2.개인정보의 수집 동의|'''3.1.2 개인정보 수집 동의''']]
* [[ISMS-P 인증 기준 1.4.2.관리체계 점검|'''1.4.2.관리체계 점검''']] vs [[ISMS-P 인증 기준 1.4.3.관리체계 개선|'''1.4.3.관리체계 개선''']]
* [[ISMS-P 인증 기준 1.4.2.관리체계 점검|'''1.4.2.관리체계 점검''']] vs [[ISMS-P 인증 기준 1.4.3.관리체계 개선|'''1.4.3.관리체계 개선''']]
** 관리체계 점검에 따른 문제점이 제대로 고쳐지지 않은 경우 1.4.3이라고 쉽게 생각할 수 있으나, 1.4.2 결합인 경우가 더 많다.
** 관리체계 점검에 따른 문제점이 제대로 고쳐지지 않은 경우 1.4.3이라고 쉽게 생각할 수 있으나, 1.4.2 결합인 경우가 더 많다.
** 1.4.2는 관리체계의 점검뿐만 아니라 기본적인 이행 및 조치 결과 보고까지의 범위를 아우른다.
** 1.4.2는 관리체계의 점검뿐만 아니라 기본적인 이행 및 조치 결과 보고까지의 범위를 아우른다.
** 1.4.3의 경우 반복적으로 발생하는 문제에 대해 근본적인 해결을 하는 것을 주안점으로 한다. 즉 단순히 점검 결과의 미이행은 1.4.2에 해당한다.
** 1.4.3의 경우 반복적으로 발생하는 문제에 대해 근본적인 해결을 하는 것을 주안점으로 한다. 즉 단순히 점검 결과의 미이행은 1.4.2에 해당한다.
* '''[[ISMS-P 인증 기준 2.3.1.외부자 현황 관리|2.3.1.외부자 현황 관리]]''' vs '''[[ISMS-P 인증 기준 2.3.3.외부자 보안 이행 관리|2.3.3.외부자 보안 이행 관리]]'''
** 외부자에 대한 보호 대책이 적용 되어 있는 상태에서 이행이 안 될 경우엔 2.3.3, 외부자에 대한 보안 대책이 마련되어 있지 않은 경우 2.3.1이다.
** '몰랐다.', '현실적으로 관리가 어렵다' 등의 내용이 나오면 2.3.3에 해당한다.
* [[ISMS-P 인증 기준 3.1.1.개인정보 수집 제한|'''3.1.1 개인정보 수집 제한''']] vs [[ISMS-P 인증 기준 3.1.2.개인정보의 수집 동의|'''3.1.2 개인정보 수집 동의''']]
* [[ISMS-P 인증 기준 2.8.1.보안 요구사항 정의|'''2.8.1.보안 요구사항 정의''']] vs [[ISMS-P 인증 기준 2.7.1.암호정책 적용|'''2.7.1.암호정책 적용''']] vs [[ISMS-P 인증 기준 1.4.1.법적 요구사항 준수 검토|'''1.4.1.법적 요구사항 준수 검토''']]
** 안전한 암호화 알고리즘 사용은 법적 요구사항이지만, 2.7.1 기준이 별도로 있기 때문에 취약한 암호화 알고리즘 사용은 2.7.1 결함이다.<ref>단, 오래전에 제정된 규정이, 개정되지 않아 취약해진 경우라면  [[ISMS-P 인증 기준 2.1.1.정책의 유지관리|2.1.1.정책의 유지관리]] 결함일수도 있다. (안전한 암호화 알고리즘의 기준 정립은 꽤 오래 전에 이루어졌으므로 그럴 가능성이 낮긴 함)</ref>
** 2.8.1에서 개발 보안 표준을 다루고 있으며, 개발 보안 표준에서 취약한 암호화 알고리즘이 명기되어 있다면 이는 2.8.1 결함이다. 마찬가지로 보안성 검토 기준이 법적 요구사항을 충족하지 못하는 경우에도 2.8.1 위반이 될 수 있다.<ref>코딩 표준의 암호화 알고리즘이 법적 요구사항을 충족하지 못하는 경우엔 2.8.1 결함이라고 안내서에 명확히 나와있다. 그 외에 보안성 검토  기준들이 법적 요구사항을 충족하지 못하는 경우엔 상황을 더 따져보아야 한다. (2.8.1에 따른 타당성 검토 및 인수 절차에 해당하는지, 유지관리의 문제는 아닌지 등)</ref>
* [[ISMS-P 인증 기준 2.8.3.시험과 운영 환경 분리|'''2.8.3.시험과 운영 환경 분리''']] vs [[ISMS-P 인증 기준 2.8.5.소스 프로그램 관리|'''2.8.5.소스 프로그램 관리''']] vs [[ISMS-P 인증 기준 2.8.6.운영환경 이관|'''2.8.6.운영환경 이관''']]
** 세가지 인증기준에 모두 운영계에 소스코드가 존재하거나 운영환경(운영계)에서 소스코드가 다루어지는 것에 대한 내용이 있다.
** 2.8.3의 경우 운영환경(운영계)에서 직접 개발을 하지 말라는 것이 주안점이며
** 2.8.5의 경우 운영환경(운영계)에서 소스코드를 보관 및 관리하지 말라는 것<ref>Java 등 응용 프로그램 개발 시엔 상황이 이해가 어려울 수 있으나, 웹 프로그램, 특히 컴파일이 없는 PHP 등의 개발 환경에서는 운영계에 소스코드가 존재할 수 밖에 없고, 가장 최신화된 소스가 운영계에 있는 소스이다. 소규모 조직의 경우 개발자 PC-운영계 소스코드만으로 소스코드 동기화, 관리 및 개발 반영이 이루어질 수 있는데, 이렇게 하지 말고 [[Git]]이든 [[SVN]]이든 별도 레파지토리를 운영하라는 것이다.</ref>이 주안점이고
** 2.8.6의 경우 운영환경(운영계)엔 운영에 필요한 파일 외에는 올리지 말라는 것이 주안점이다.


== 제목으로 유추가 어려운 인증 기준 ==
== 제목으로 유추가 어려운 인증 기준 ==
52번째 줄: 41번째 줄:


* 소스코드를 운영 환경에 두지 않기<ref>소스코드 뿐만 아니라 운영서버에 서비스 실행에 불필요한 파일(배포모듈, 백업본, 개발 관련 문서, 매뉴얼 등) 모두 해당</ref>
* 소스코드를 운영 환경에 두지 않기<ref>소스코드 뿐만 아니라 운영서버에 서비스 실행에 불필요한 파일(배포모듈, 백업본, 개발 관련 문서, 매뉴얼 등) 모두 해당</ref>
■ [[ISMS-P 인증 기준 2.10.1.보안시스템 운영|'''2.10.1.보안시스템 운영''']]
* VPN 등 보안시스템에 해당되는 시스템의 계정 관리 미흡


■ [[ISMS-P 인증 기준 2.10.8.패치관리|'''2.10.8.패치관리''']]
■ [[ISMS-P 인증 기준 2.10.8.패치관리|'''2.10.8.패치관리''']]
86번째 줄: 72번째 줄:
** 개인정보처리시스템의 관리·운영·개발·보안 등을 목적으로 원격으로 직접 접속하는 단말기(관리용 단말기)에 대하여 보호조치를 적용
** 개인정보처리시스템의 관리·운영·개발·보안 등을 목적으로 원격으로 직접 접속하는 단말기(관리용 단말기)에 대하여 보호조치를 적용
* [[ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험|'''ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험''']]
* [[ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험|'''ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험''']]
** 공공기관 개인정보 영향평가 대상인데 수행하지 못한 경우
** 공공기관 개인정보 영향평가
** 이런 다른 법률 준수 여부, 예를 들어 '''[[개인정보 손해배상 책임보험|개인정보 배상책임 보험]]'''이나 [[정보보호 공시 제도|'''정보보호 공시''']] 대상인데 이를 이행하지 않은 경우엔 [[ISMS-P 인증 기준 1.4.1.법적 요구사항 준수 검토|'''1.4.1.법적 요구사항 준수 검토''']] 결함이나, 개인정보 영향평가는 법적 요구사항인 동시에 보안 요구사항 검토와 직결된 문제이므로 1.4.1이 아닌 2.8.2라는 점을 기억해야 함
** 또한 2.8.2는 대부분 [[ISMS-P 인증 기준 2.8.1.보안 요구사항 정의|'''2.8.1.보안 요구사항 정의''']]에서 정의된 보안 요구사항을 제대로 검토하고 시험하지 못한 경우에 대한 결함을 다루나, 개인정보 영향평가는 따로 정의할 필요가 없는 법적 요구사항이라 '개인정보 영향평가를 해야한다'라는 사실조차 누락한 경우라도 2.8.1이 아닌 2.8.2 결함임


== 빈출 결함 사례 ==
== 빈출 결함 사례 ==
113번째 줄: 97번째 줄:
**[[ISMS-P 정책의 유지관리|정책의 유지관리]]나 [[ISMS-P 백업 및 복구관리|백업 및 복구관리]] 결함이 아님을 주의
**[[ISMS-P 정책의 유지관리|정책의 유지관리]]나 [[ISMS-P 백업 및 복구관리|백업 및 복구관리]] 결함이 아님을 주의
*'''새롭게 도입한 장비, 시스템에 대한 보안성 검토가 이루어지지 않았다.'''
*'''새롭게 도입한 장비, 시스템에 대한 보안성 검토가 이루어지지 않았다.'''
**'''▶ [[ISMS-P 인증 기준 2.8.1.보안 요구사항 정의|2.8.1.보안 요구사항 정의]]''' 결함
**▶ [[ISMS-P 인증 기준 2.8.1.보안 요구사항 정의|2.8.1.보안 요구사항 정의]] 결함
**검토가 이루어지지 않았다고 해서 [[ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험|2.8.2.보안 요구사항 검토 및 시험]] 결함이 아님을 주의
**검토가 이루어지지 않았다고 해서 [[ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험|2.8.2.보안 요구사항 검토 및 시험]] 결함이 아님을 주의
*'''정보 자산들에게 잘못된 보안등급이 부여되어 있거나 보안등급이 최신화되지 않음'''
*'''정보 자산들에게 잘못된 보안등급이 부여되어 있거나 보안등급이 최신화되지 않음'''
**'''▶ [[ISMS-P 인증 기준 1.2.1.정보자산 식별|1.2.1.정보자산 식별]]''' 결함
**▶ [[ISMS-P 인증 기준 1.2.1.정보자산 식별|1.2.1.정보자산 식별]] 결함
**[[ISMS-P 인증 기준 1.2.3.위험 평가|1.2.3.위험 평가]] 결함이 아님을 주의
**[[ISMS-P 인증 기준 1.2.3.위험 평가|1.2.3.위험 평가]] 결함이 아님을 주의
*'''운영 환경에서 소스코드가 존재'''
*'''운영 환경에서 소스코드가 존재'''
**'''▶ [[ISMS-P 인증 기준 2.8.6.운영환경 이관|2.8.6.운영환경 이관]]''' 결함
**▶ [[ISMS-P 인증 기준 2.8.6.운영환경 이관|2.8.6.운영환경 이관]] 결함
**[[ISMS-P 인증 기준 2.8.5.소스 프로그램 관리|2.8.5.소스 프로그램 관리]] 결함이 아님을 주의<ref>해당 항목에도 운영 환경에 소스코드를 두지 말라는 내용이 있으나, 원칙만 제시되어 있으며, 2.8.6에선 주요 확인사항과 결함 사례에서 모두 해당 요구사항 확인 가능</ref>
**[[ISMS-P 인증 기준 2.8.5.소스 프로그램 관리|2.8.5.소스 프로그램 관리]] 결함이 아님을 주의<ref>해당 항목에도 운영 환경에 소스코드를 두지 말라는 내용이 있으나, 원칙만 제시되어 있으며, 2.8.6에선 주요 확인사항과 결함 사례에서 모두 해당 요구사항 확인 가능</ref>
*'''회원가입, 로그인, 개인정보 수정 화면 등이 https가 아닌 http로 되어 있다.'''
**'''▶ [[ISMS-P 인증 기준 2.7.1.암호정책 적용|2.7.1.암호정책 적용]]''' 결함


== 중첩된 인증 기준 판단 사례 ==
== 중첩된 인증 기준 판단 사례 ==
134번째 줄: 116번째 줄:
** B에 대한 문제인데, 1번 인증기준은 A, B, C에 모두 해당될 수 있는 경우이고 2번 인증 기준은 B에만 해당될 수 있다면 2번 인증 기준이 정답이 된다.
** B에 대한 문제인데, 1번 인증기준은 A, B, C에 모두 해당될 수 있는 경우이고 2번 인증 기준은 B에만 해당될 수 있다면 2번 인증 기준이 정답이 된다.


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


*'''(참고)''' 관련 인증 기준
*'''(참고)''' 관련 인증 기준
216번째 줄: 198번째 줄:
**다만 불필요한 방화벽 정책이 삭제되지 않고 남아 있으므로 2.10.1. 보안시스템 운영 결함으로 볼 수 있다.
**다만 불필요한 방화벽 정책이 삭제되지 않고 남아 있으므로 2.10.1. 보안시스템 운영 결함으로 볼 수 있다.
**'''답) [[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.1.보안시스템 운영]]'''
**'''답) [[ISMS-P 인증 기준 2.10.1.보안시스템 운영|2.10.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>
<blockquote>'''시스템 유지보수 등 부수적인 업무를 담당하는 계열사 직원들의 계정이, 직원이 퇴사한 이후에도 삭제되지 않고 그대로 존재하고 있는 경우'''</blockquote>


255번째 줄: 251번째 줄:
**백업 및 복구관리 결함이라고 하기엔 백업 및 복구 자체만을 기준으로 보기엔 결함의 근거가 없다. 또한 재해 복구 계획이 백업 및 복구관리 기준보다 더 상위 정책·지침이라고 볼 수 없으므로 주1회 백업이 잘못되었다고 판단할 수 없다.
**백업 및 복구관리 결함이라고 하기엔 백업 및 복구 자체만을 기준으로 보기엔 결함의 근거가 없다. 또한 재해 복구 계획이 백업 및 복구관리 기준보다 더 상위 정책·지침이라고 볼 수 없으므로 주1회 백업이 잘못되었다고 판단할 수 없다.
**'''답) [[ISMS-P 인증 기준 2.12.1.재해, 재난 대비 안전조치|2.12.1.재해, 재난 대비 안전조치]]'''
**'''답) [[ISMS-P 인증 기준 2.12.1.재해, 재난 대비 안전조치|2.12.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>'''내부 지침에선 적절한 비밀번호 정책을 제시하고 있으나 실제 운영시스템의 비밀번호 설정 규칙은 취약하게 들어가 있는 경우'''
*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>
== 같이 보기 ==
== 같이 보기 ==


IT위키에서의 모든 기여는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 라이선스로 배포된다는 점을 유의해 주세요(자세한 내용에 대해서는 IT위키:저작권 문서를 읽어주세요). 만약 여기에 동의하지 않는다면 문서를 저장하지 말아 주세요.
또한, 직접 작성했거나 퍼블릭 도메인과 같은 자유 문서에서 가져왔다는 것을 보증해야 합니다. 저작권이 있는 내용을 허가 없이 저장하지 마세요!
취소 편집 도움말 (새 창에서 열림)