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

From CS Wiki
Revision as of 23:51, 9 July 2022 by 심사보 (talk | contribs)

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

유사한 인증 기준

제목으로 유추가 어려운 인증 기준

아래 내용들은 암기가 필요하다. 세션 타임아웃에 관한 내용이 문제로 나왔을 경우, 상식적으로 "응용프로그램 접근"이나 "정보시스템 접근"과 같은 "접근 통제"와 관련되어 보이는 제목의 인증 기준이 답일 것이라고 유추하기 힘들다. 인증 기준들을 꼼꼼히 읽어보았거나, 역으로 깊게 생각해보면 시스템에 오랫동안 로그인이 유지되어 있으면 자리를 비운 사이 누군가가 접근을 할 수 있게 되는 등의 접근 통제와 관련되었다고 볼 수 있지만, 훈련이 되어 있지 않다면 실전에선 다른 항목에서 결함을 찾으려고 할 가능성도 매우 높기 때문이다.

ISMS-P 인증 기준 2.6.3.응용프로그램 접근

  • 중요정보의 필요최소한의 노출 구현
  • 세션 타임아웃 설정

ISMS-P 인증 기준 2.6.2.정보시스템 접근

  • 세션 타임아웃 설정
  • 불필요한 포트 식별
  • 주요 서비스 독립 서버 운영

ISMS-P 인증 기준 2.6.4.데이터베이스 접근

  • 테이블 목록 등 정보 식별

ISMS-P 인증 기준 1.1.3.조직 구성

  • 조직이 구성되어 있으나 조직이 구성만 되어 있고 운영되지 않는 경우도 포함됨

빈출 결함 사례

중첩된 인증 기준 판단 사례

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

사용자 계정 발급 절차 없이 하나의 계정을 여러명이 쓰거나 한명이 여러개의 계정을 만들어 사용하여 계정별 사용자에 대한 식별이 불가한 경우

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


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


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


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


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


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


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


내부 지침에선 적절한 비밀번호 정책을 제시하고 있으나 실제 운영시스템의 비밀번호 설정 규칙은 취약하게 들어가 있는 경우

  • ex) 지침에선 영문+숫자 10자 이상으로 설정토록 하였으나, OOO 시스템의 비밀번호 설정 규칙을 검증하는 로직에는 영문+숫자로 8자리 이상으로 설정토록 하고 있는 경우
  • (참고) 관련 인증 기준
  • (정답 및 해설)
    • 논란이 있을 수 있다. 실제로 지침과 다른 비밀번호를 사용하고 있는 것이 확인되는 경우 2.5.4. 비밀번호 관리 결함(비밀번호 관리 규칙 수립·이행에서 '이행')으로 볼 수도 있다.
    • 하지만 실제 비밀번호가 아니라 비밀번호 설정 규칙의 불일치라면 이는 2.8.2에 걸릴 가능성이 더 높다. 특히 비밀번호 뿐만 아니라 여러가지 실무적인 사항들이 지침과 다르게 적용된 것들이 무더기로 보인다면 이는 답이 2.8.2일 확률이 매우 높다.
    • 참고로 지침에 비밀번호 정책이 적절하게 있다는 것을 보여주지 않고, 단순히 패스워드 규칙만이 증적으로 제시된 상황이라면 2.5.4가 답이다.
    • 답) ISMS-P 인증 기준 2.8.2.보안 요구사항 검토 및 시험


시스템 유지보수 등 부수적인 업무를 담당하는 계열사 직원들의 계정이, 직원이 퇴사한 이후에도 삭제되지 않고 그대로 존재하고 있는 경우

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


시스템 시간이 UTC로 되어 있어서 시간을 잘못 파악하여 보안 사고나 컴플라이언스 위반이 나타난 경우

같이 보기

각주

Retrieved from "https://cswiki.net/index.php?title=ISMS-P_인증심사원_인증_기준_풀이&oldid=34026"
Creative Commons Attribution-NonCommercial-ShareAlike
Powered by MediaWiki