질문 배경:
정보 보안 요구 사항은 최초의 보안 감사 표준(예: ISO 27001 또는 러시아의 법률 FZ-152)이 등장한 이후로 대규모 IT 프로젝트의 중요한 요소입니다. 요구 사항의 명확한 분석과 형식화 없이는 시스템의 보안이 선언적이고 실제로 적용될 수 없는 위험이 있습니다.
문제:
보안 요구 사항은 종종 모호하게 정의됩니다("모든 것이 보호되어야 한다") 경영 프로세스와 아키텍처를 고려하지 않으며, 조직적, 기술적, 사용자적 수준에서 해독되지 않습니다. 또한, 의뢰인과 개발자 간에 동일한 요구 사항에 대한 해석 차이가 발생할 수 있으며, 이로 인해 구현 가능성과 규범 간의 불일치가 발생합니다.
해결책:
시스템 분석가는 기업, 정부 및 산업 표준(예: GOST, GDPR, PCI DSS, ISO 27001)을 연구하는 것부터 시작합니다. 그런 다음 그는 아키텍트 및 보안 전문가와 함께 비즈니스적으로 중요한 프로세스, 데이터 저장 및 전송 지점, 잠재적 위협을 파악하고 관련 위험 목록을 정의합니다. 이를 바탕으로 분석가는 접근, 저장, 로깅, 암호화에 대한 자세한 요구 사항 매트릭스를 준비하고 사고 시나리오를 작성합니다. 합의 후, 그들은 문서화됩니다. 요구 사항이 테스트 또는 감사 중에 검증할 수 있도록?
주요 특징:
정보 보안(안티바이러스, 방화벽, SIEM)에 대한 기술적 수단만 신뢰할 수 없는 이유는 무엇인가요?
정보 보안은 프로세스이며 단순히 시스템의 집합이 아니기 때문입니다. 조직적 절차, 인간 요소, 정기적인 검사 및 사용자 교육이 중요한 역할을 합니다.
시스템이 내부 테스트만 통과했다면 요구 사항을 충족한 것으로 간주할 수 있나요?
아니요. 종종 규범을 충족하기 위해서는 외부 감사, 인증 및 때때로 규제 기관의 통제 하에 스트레스 테스트가 필요합니다.
"시스템은 152-FZ에 따라 보호되어야 한다"는 요구 사항을 기술 사양서에 전달하는 것만으로 충분한가요?
충분하지 않습니다. 구체적인 조치(접근 제어, 이벤트 로그 보관, 데이터 암호화), 구현 장소 및 검증 기준을 명시해야 합니다.
부정적인 사례: 인터넷 뱅킹 프로젝트에서 분석가는 기술 사양서에 "152-FZ의 요구 사항을 준수해야 한다"는 일반적인 문구만 전달했습니다. 계약자는 표준 인증 및 SSL 인증서만 구현했으며 외부 감사 단계에서 데이터 저장 관리 부족 및 인증 로그가 보호되지 않았음이 밝혀졌습니다.
장점:
단점:
긍정적인 사례:
프로젝트 시작 시 시스템 분석가는 보안 전문가 및 의뢰인과 함께 위협 목록을 합의하고 각 시나리오에 대해 암호화 및 감사에 대한 구체적인 요구 사항을 개발하고 책임자를 지정했습니다. 결과적으로 시스템은 지적 없이 감사를 통과했습니다.
장점:
단점: