무료 온라인 액세스 ISC.SSCP.v2024-09-04.q565 모의 시험 (Page 46)

SSCP 문제 221

모뎀과 전화 접속 원격 액세스 시스템의 기본 언어는 다음과 같습니다.

A. 비동기 통신.

B. 동기 통신.

C. 비동기 상호작용.

D. 동기식 상호 작용.

SSCP 문제 222

다음 중 조직의 IT 시스템에 대한 사이버 공격을 구체적으로 다루는 것은 무엇입니까?

A. 지원 계획의 연속성

B. 비즈니스 연속성 계획

C. 사고 대응 계획

D. 운영 계획의 연속성

SSCP 문제 223

소프트웨어 개발 수명 주기의 다음 단계 중 일반적으로 보안 사양을 통합하고, 액세스 제어를 결정하고, 암호화 옵션을 평가하는 단계는 무엇입니까?

A. 상세 설계

B. 구현

C. 제품 디자인

D. 소프트웨어 계획 및 요구 사항

정답: C

설명/참조:
제품 설계 단계에서는 보안 사양 통합, 테스트 계획 및 데이터 조정, 액세스 제어 결정, 설계 문서화, 암호화 옵션 평가 및 검증을 다룹니다.
보안 소프트웨어 설치, 시스템 실행, 승인 테스트, 보안 소프트웨어 테스트, 전체 문서 인증 및 승인(필요한 경우)을 다루기 때문에 구현이 올바르지 않습니다.
세부 설계는 정보 보안 정책, 표준, 법적 문제 및 개념의 조기 검증을 다루기 때문에 정확하지 않습니다.
소프트웨어 계획 및 요구 사항은 위협, 취약점, 보안 요구 사항, 합리적인 관리, 실사, 법적 책임, 비용/이익 분석, 원하는 보호 수준, 테스트 계획을 다루기 때문에 정확하지 않습니다.
출처:
KRUTZ, Ronald L. & VINES, Russel D., CISSP 준비 가이드: 컴퓨터 보안의 10가지 도메인 마스터하기, John Wiley & Sons, 2001, 7장: 애플리케이션 및 시스템 개발(252페이지).
KRUTZ, Ronald & VINES, Russel, CISSP 준비 가이드: Gold Edition, Wiley Publishing Inc., 2003, 7장: 보안 수명 주기 구성 요소, 그림 7.5(346페이지).
145
시스템 개발 수명주기의 기본 단계 중 보안 요구사항이 공식화되는 단계는 무엇입니까?
A. 폐기
B. 시스템 설계 사양
C. 개발 및 구현
D. 기능적 요구사항 정의
답변D
기능 요구 사항 정의 과정에서 프로젝트 관리 및 시스템 개발 팀은 현재 및 가능한 미래 기능 요구 사항에 대한 포괄적인 분석을 수행하여 새 시스템이 최종 사용자 요구 사항을 충족하는지 확인합니다. 또한 팀은 프로젝트 시작 단계부터 문서를 검토하고 필요에 따라 수정하거나 업데이트합니다. 소규모 프로젝트의 경우 이 단계는 프로젝트 개시 단계에 포함되는 경우가 많습니다. 이 시점에서 보안 요구사항을 공식화해야 합니다.
개발 수명주기는 일반적으로 SDLC(시스템 개발 수명주기)라고 하는 소프트웨어 개발 프로젝트를 계획, 실행 및 제어하는 데 사용할 수 있는 프로젝트 관리 도구입니다.
SDLC는 프로젝트 설계 및 개발에 시스템 분석가, 소프트웨어 엔지니어, 프로그래머 및 최종 사용자가 포함되는 프로세스입니다. 업계 전반에 걸친 SDLC가 없기 때문에 조직에서는 SDLC 방법 중 하나를 사용하거나 SDLC 방법을 조합하여 사용할 수 있습니다.
SDLC는 기능 요구 사항 정의부터 구현까지 소프트웨어 개발 프로젝트 단계에 대한 프레임워크를 제공합니다. 사용된 방법에 관계없이 SDLC는 함께 표시되거나 별도의 요소로 표시될 수 있는 필수 단계의 개요를 설명합니다. 선택한 모델은 프로젝트를 기반으로 해야 합니다.
예를 들어 일부 모델은 장기적이고 복잡한 프로젝트에 더 잘 작동하는 반면 다른 모델은 단기 프로젝트에 더 적합합니다. 핵심 요소는 공식화된 SDLC가 활용된다는 것입니다.
단계 수는 세 가지 기본 단계(개념, 설계 및 구현)부터 다양합니다.
SDLC의 기본 단계는 다음과 같습니다.
프로젝트 시작 및 계획
기능적 요구사항 정의
시스템 설계 사양
개발 및 구현
문서화 및 공통 프로그램 제어
시험 및 평가 관리(인증 및 인정)
생산으로의 전환(구현)
SLC(시스템 수명 주기)는 SDLC를 넘어 두 가지 추가 단계를 포함하도록 확장됩니다.
운영 및 유지보수 지원(설치 후)
개정 및 시스템 교체
시스템 설계 사양
이 단계에는 시스템 및 소프트웨어 설계와 관련된 모든 활동이 포함됩니다. 이 단계에서는 시스템 아키텍처, 시스템 출력 및 시스템 인터페이스가 설계됩니다. 일반적으로 회사의 전반적인 보안 아키텍처를 기반으로 데이터 입력, 데이터 흐름 및 출력 요구 사항이 설정되고 보안 기능이 설계됩니다.
개발 및 구현
이 단계에서는 소스 코드가 생성되고, 테스트 시나리오 및 테스트 사례가 개발되고, 단위 및 통합 테스트가 수행되고, 유지 관리와 승인 테스트 및 생산으로의 전환을 위해 프로그램과 시스템이 문서화됩니다. 소프트웨어 품질, 신뢰성 및 운영 일관성에 대한 일반적인 주의뿐만 아니라 보안 악용 및 기타 위험으로 이어질 수 있는 일반적인 취약점을 제거하기 위해 코드를 분석하도록 특별한 주의를 기울여야 합니다.
문서화 및 공통 프로그램 제어
이는 프로그램 내에서 데이터를 편집할 때 사용되는 컨트롤, 프로그램에서 수행해야 하는 로깅 유형 및 프로그램 버전을 저장하는 방법입니다. 이러한 컨트롤이 많이 필요할 수 있습니다. 컨트롤의 전체 목록은 아래 참조를 참조하세요.
수락
승인 단계에서는 독립적인 그룹이 테스트 데이터를 개발하고 코드를 테스트하여 조직 환경 내에서 작동하고 모든 기능 및 보안 요구 사항을 충족하는지 확인하는 것이 좋습니다. 업무 분리 문제를 방지하려면 적용 가능한 모든 개발 단계에서 독립적인 그룹이 코드를 테스트하는 것이 중요합니다. 보안 테스트의 목표는 애플리케이션이 보안 요구 사항 및 사양을 충족하는지 확인하는 것입니다. 보안 테스트에서는 사용자가 소프트웨어 보안 정책 및 요구 사항을 위반할 수 있는 모든 설계 및 구현 결함을 밝혀야 합니다. 테스트 유효성을 보장하려면 프로덕션 환경을 시뮬레이션하는 환경에서 애플리케이션을 테스트해야 합니다. 여기에는 보안 인증 패키지와 사용자 문서가 포함되어야 합니다.
인증 및 인정(보안인증)
인증은 미리 결정된 보안 표준 또는 정책 세트에 대해 소프트웨어 또는 시스템의 보안 상태를 평가하는 프로세스입니다. 인증은 또한 시스템이 의도한 기능 요구 사항을 얼마나 잘 수행하는지 검사합니다. 인증 또는 평가 문서에는 기술적, 비기술적 보안 기능 및 대응책에 대한 분석과 소프트웨어 또는 시스템이 임무 및 운영 환경에 대한 보안 요구 사항을 충족하는 정도가 포함되어야 합니다.
프로덕션으로의 전환(구현)
이 단계에서는 새 시스템이 수용 단계에서 실제 프로덕션 환경으로 전환됩니다. 이 단계의 활동에는 보안 인증 획득이 포함됩니다. 구현 및 교육 일정에 따라 신규 사용자를 교육합니다. 설치 및 데이터 변환을 포함한 시스템 구현 필요한 경우 병렬 작업을 수행합니다.
개정 및 시스템 교체
시스템이 프로덕션 모드에 있으므로 하드웨어 및 소프트웨어 기준은 정기적인 평가 및 감사를 받아야 합니다. 경우에 따라 응용 프로그램의 문제는 결함이나 결함이 아니라 현재 응용 프로그램에서 개발되지 않은 추가 기능일 수 있습니다. 애플리케이션에 대한 모든 변경 사항은 동일한 SDLC를 따라야 하며 변경 관리 시스템에 기록되어야 합니다. 개정 검토에는 향후 문제를 방지하기 위한 보안 계획 및 절차가 포함되어야 합니다. 정기적인 애플리케이션 감사를 수행해야 하며 문제가 발생할 경우 보안 사고를 문서화하는 것이 포함되어야 합니다. 시스템 오류를 문서화하는 것은 향후 시스템 개선을 정당화하는 데 유용한 리소스입니다.
아래에는 800-63 개정 2 문서에서 NIST가 사용하는 단계가 있습니다. 위에서 언급한 것처럼 단계는 문서마다 다릅니다. 시험 목적을 위해 위에 간략하게 제시된 공식 ISC2 학습서에 제공된 목록을 사용하십시오. SDLC의 각 단계에서의 활동에 대한 자세한 설명은 책을 참조하십시오.
그러나 모든 참조에는 매우 유사한 단계가 사용됩니다. 공식 책에서 언급했듯이 가장 기본적인 버전(개념, 설계 및 구현)에서는 3단계만큼 간단할 수도 있고 SDLC의 보다 세부적인 버전에서는 훨씬 더 많은 단계일 수도 있습니다.
중요한 것은 SDLC를 활용하는 것입니다.

SDLC 단계
이 질문에 사용된 참고 자료:
NIST SP 800-64 개정 2(http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf)
그리고
슈나이터, 앤드루 (2013-04-15). CISSP CBK 공식 (ISC)2 가이드, 제3판: 소프트웨어 개발 보안((ISC)2 Press) (Kindle Locations 134-157). 아우어바흐 출판물. 킨들 에디션.

SSCP 문제 224

다음 중 컴퓨터 조사 문제에 관한 문제로 가장 거리가 먼 것은 무엇입니까?

A. 정보는 유형입니다.

B. 증거를 수집하기 쉽습니다.

C. 컴퓨터 생성 기록은 2차 증거로만 간주되므로 최선의 증거만큼 신뢰할 수 없습니다.

D. 대부분의 경우 전문가 또는 전문가가 필요하지 않습니다.

정답: C

설명/참조:
컴퓨터 생성 기록은 정확하고 신뢰할 수 있음을 입증할 수 없기 때문에 일반적으로 전문 증거 범주에 속하므로 이것이 문제가 될 수 있습니다.
미국 연방 증거 규칙에 따르면 전문 증거는 일반적으로 법정에서 채택되지 않습니다. 이러한 허용 불가능성은 전문법칙으로 알려져 있지만, 데이터가 수집된 방법, 시기, 주체 및 상황에 대한 몇 가지 예외가 있습니다.
출처: KRUTZ, Ronald L. & VINES, Russel D., CISSP 준비 가이드: 컴퓨터 보안의 10가지 도메인 마스터하기, John Wiley & Sons, 2001, 9장: 법률, 조사 및 윤리(310페이지).
중요 사항:
시험 목적을 위해서는 전문법칙에 대한 사업 기록 면제를 기억하는 것이 매우 중요합니다. 예를 들어, 로그 파일을 생성하고 비즈니스 프로세스의 일부로 정기적으로 검토하는 경우 해당 파일은 법정에서 허용될 수 있으며 정규 비즈니스 과정에서 생성되었으며 일부이기 때문에 소문으로 간주되지 않습니다. 그러한 기록을 생성하기 위한 정규 업무 과정의
다음은 HISM 책의 또 다른 인용문입니다.
전문법칙에 대한 사업 기록 면제
연방 증거 규칙 803(6)은 정기적으로 수행되는 비즈니스 활동 중에 보관된 경우, 지식을 가진 사람이 전송한 정보에 의해 또는 그와 가까운 시점에 작성된 보고서 또는 기타 비즈니스 문서를 법원이 인정할 수 있도록 허용합니다. 하기 위한 사업 활동의 정기적인 관행이었습니다.
[보고서 또는 문서] 정보의 출처나 준비 방법 또는 상황이 신뢰성이 부족함을 나타내는 경우를 제외하고 모두 관리인 또는 기타 자격을 갖춘 증인의 증언을 통해 입증된 것이어야 합니다.
규칙 803(6)을 충족하려면 증인은 다음을 수행해야 합니다.
* 해당 기록을 정기적으로 보관합니다.
* 정규 업무 과정에서 이러한 기록을 활용하십시오.
* 정규 업무 과정에서 준비되었음을 알아두세요.
감사 추적은 정상적인 비즈니스 과정에서 생성된 경우 기준을 충족합니다. 결과물을 생산하는 프로세스는 신뢰성이 입증되어야 합니다. 컴퓨터로 생성된 증거가 사용되고 인정 가능한 경우, 법원은 인쇄물을 생성하는 시스템과 관련된 컴퓨터, 로그 및 유지 관리 기록의 세부 사항을 공개하도록 명령할 수 있으며, 그런 다음 피고인은 해당 자료를 사용하여 문서의 신뢰성을 공격할 수 있습니다. 증거. 감사 추적이 정규 업무 과정에서 사용되거나 검토되지 않는 경우(적어도 예외(예: 로그온 시도 실패))는 허용 기준을 충족하지 않습니다.
연방 증거 규칙 1001(3)은 전문법칙에 대한 또 다른 예외를 제공합니다. 이 규칙에 따르면 메모리나 디스크 덤프가 정규 업무 과정에서 발생하지 않더라도 증거로 인정될 수 있습니다. 이 덤프는 단지 사실을 진술하는 역할만 합니다. 시스템 덤프(2진수 또는 16진수)는 내용의 진실성을 증명하기 위해 제공되는 것이 아니라 컴퓨터 상태만을 증명하기 위해 제공되기 때문에 소문이 아닙니다.
영업기록법의 예:
사업 기록법은 1931년에 제정되었습니다(PA No. 56). 법령에 따라 문서가 인정되기 위해서는 제안자는 다음을 입증해야 합니다. (1) 해당 문서는 정규 업무 과정에서 작성되었습니다. (2) 기록을 작성하는 것이 일반적인 업무 과정이었습니다. (3) 해당 행위, 거래 또는 사건이 발생했을 때 또는 그 직후에 기록이 작성되었습니다(State v. Vennard, 159 Conn. 385, 397(1970); Mucci v. LeMonte,
157 코네티컷 566, 570(1969). 이러한 필수 요소 중 하나라도 확립하지 못하면 해당 문서는 법령에 따라 허용되지 않습니다(McCahill v. Town and Country Associates, Ltd., 185 Conn. 37(1981); State v. Peary, 176 Conn. 170(1978); Welles v. Fish Transport Co., , 123 Conn. 49(1937).
법령은 사업체 진입을 한 사람이 증인으로 출석할 수 없을 필요는 없으며 제안자는 기록을 작성한 사람을 증인으로 부르거나 그 사람이 출석할 수 없음을 보여줄 필요가 없다고 명시적으로 규정합니다(State v. Jeustiniano) , 172 코네티컷 275(1977).
사업 기록을 증거로 제시하는 사람은 해당 기록의 신뢰성을 독립적으로 입증할 필요가 없습니다. 그러나 기록이 정확하다는 추정은 없습니다. 기록의 정확성과 무게는 사실 판단자에게 문제가 됩니다(State v. Waterman, 7 Conn. App. 326 (1986); Handbook of Connecticut Evidence, Second Edition, § 11. 14. 3).
참조: http://search.cga.state.ct.us/dtsearch_lpa.asp?cmd=getdoc&DocId=16833&Index=I%3A%
5Czindex%5C1995&HitCount=0&hits=&hc=0&req=&Item=712

SSCP 문제 225

기업 보안 정책의 주요 목적은 무엇입니까?

A. 정보 보안에 대한 책임을 조직의 모든 사용자에게 이전합니다.

B. 정보 보안과 관련하여 경영진의 의도를 전달합니다.

C. 특정 작업을 수행하기 위한 자세한 단계를 제공합니다.

D. 모든 개발 활동을 위한 공통 프레임워크를 제공합니다.

정답: B

섹션: 보안 운영 관리
설명/참조:
기업 보안 정책은 조직 내 정보 보안과 관련하여 경영진의 의도를 나타내는 높은 수준의 문서입니다. 이는 높은 수준의 목적이므로 사용되는 특정 제품, 특정 단계 등에 대한 세부 정보를 제공하지 않습니다.
액세스 제어에 대한 조직의 요구 사항은 보안 정책에 정의되고 문서화되어야 합니다.
각 사용자 또는 사용자 그룹에 대한 액세스 규칙 및 권한은 액세스 정책 설명에 명확하게 명시되어야 합니다.
액세스 제어 정책은 최소한 다음을 고려해야 합니다.
일반 보안 원칙 및 조직에 대한 적용 가능성에 대한 설명 개별 기업 애플리케이션, 시스템 및 서비스의 보안 요구 사항 다양한 시스템 및 네트워크의 액세스 제어와 정보 분류 정책 간의 일관성 자산 보호에 관한 계약상의 의무 또는 규정 준수 사용자 액세스 프로필을 정의하는 표준 조직 역할에 대한 액세스 제어 시스템 관리에 관한 세부 정보 CISSP(공인 정보 시스템 보안 전문가)로서 귀하는 보안 정책, 표준 및 지원 지침, 절차 및 기준의 초안 작성 및 조정에 직접 참여하게 됩니다.
기술적 보안 문제와 새로운 위협에 대해 CISSP에서 제공하는 지침은 새로운 정책 채택을 위해 고려됩니다. CISSP에서는 정부 규제 및 업계 동향에 대한 해석, 보안 아키텍처에 포함할 벤더 솔루션 분석 등의 활동도 수행합니다.
다음은 오답입니다.
정보 보안에 대한 책임을 조직의 모든 사용자에게 전가하는 것은 사기입니다. 책임을 이전할 수 없으며 권한만 이전할 수 있습니다. 책임은 고위 경영진에게도 있습니다. 키워크 ALL 및 USERS도 잘못된 선택임을 나타냅니다.
특정 작업을 수행하기 위한 세부 단계를 제공하는 것도 가짜 비방입니다. 단계별 문서를 절차라고 합니다. 특정 작업을 수행하는 방법을 자세히 설명합니다.
모든 개발 활동에 공통 프레임워크를 제공하는 것도 잘못된 선택입니다. 보안 정책은 개발 활동에만 국한되지 않습니다.
이 질문에 사용된 참조:
에르난데스 CISSP, 스티븐(2012-12-21). CISSP CBK에 대한 공식 (ISC)2 가이드, 제3판((ISC)2 Press)(Kindle 위치 1551-1565). 아우어바흐 출판물. 킨들 에디션.
그리고
에르난데스 CISSP, 스티븐(2012-12-21). CISSP CBK에 대한 공식 (ISC)2 가이드, 제3판((ISC)2 Press)(Kindle 위치 9109-9112). 아우어바흐 출판물. 킨들 에디션.