답변

질문 배경:
최근 몇 년 동안 정보 시스템에 대한 공격이 증가하고 있으며 데이터 보호에 대한 요구 사항이 법에 의해 강화되고 있습니다. 기업은 제품 생애 주기의 모든 단계에서 보안 문제에 대한 포괄적이고 지속적인 접근이 필요하다고 요구합니다.

문제:
비기능적인 보안 요구 사항은 종종 명확하지 않게 표현되거나 표준에서 수정 없이 복사됩니다. 이는 IT 팀에게 높은 위험 및 반복 또는 수행할 수 없는 작업으로 이어질 수 있습니다.

해결책:
분석가는 다음을 수행해야 합니다:

1. 규제 환경(GDPR, FZ-152, ISO/IEC 27001 등)을 이해하고 프로젝트의 필요에 맞게 조정합니다.
2. 정보 보안 전문가와의 인터뷰를 통해 구체적인 위협 및 요구 사항(암호화, 감사, 접근 제어)을 기록합니다.
3. 매개변수를 아키텍트와 개발자가 편리하게 사용할 수 있는 형식으로 분해합니다(명확한 보안 기준, 비밀번호 정책, 로깅 및 보고 요구 사항).
4. 기술적 조치를 팀과 조율하여 프로세스가 차단되지 않도록 합니다.

주요 특징:

• 보안 전문가와의 필수적인 협력
• 규제 요구 사항을 기술적으로 실행 가능한 작업으로 변환
• 문서화의 최신 상태 유지

함정 질문.

요구 사항 형성 시 정보 보안 체크리스트를 완전히 신뢰할 수 있습니까?

체크리스트는 시작점으로 유용하지만 모든 비즈니스 특성을 포괄하지는 않습니다. 보안 요구 사항은 각 프로젝트에 대해 개별적으로 논의되어야 합니다.

시스템의 모든 부분에 대한 보안 감사가 필수입니까?

일부 모듈은 민감한 데이터를 처리하지 않거나 내부용일 수 있습니다. 그러나 위험 분석은 전체 솔루션에 대해 필수적입니다. 최소한의 필요 접근 원칙이 시행됩니다.

보안 요구 사항을 100% 구현하려고 해야 합니까?

일반적으로 데이터 분류 및 위협 수준에 따라 가장 중요한 조치가 수행됩니다. "완전한 보안"은 신화이며 타협은 불가피하므로 위험 관리가 중요합니다.

일반적인 오류와 안티 패턴

• 특성을 고려하지 않고 요구 사항을 형식적으로 복사함
• 충분한 세부 설명 부족(예: "암호화를 사용"이라는 표현에는 기준이 정의되지 않음)
• 시스템 변경 시 보안에 대한 정기적인 재검토 부족

사례

부정적인 사례: 정보 보안 요구 사항을 "ISO 표준 준수"의 지점으로 축소하고 데이터 전송 채널의 암호화 설정을 잊어버렸습니다. 결과: 사고, 벌금. 장점: 문서가 빠르게 작성됨. 단점: 실제 취약점 및 감사 시 문제 발생.

긍정적인 사례: 분석가가 정보 보안 전문의를 초빙하여 위협 분석 세션을 진행하고 요구 사항을 수용 기준으로 문서화했습니다. 모든 조치가 조정되고 실행 가능합니다. 장점: 보안이 구현되었으며 감사에 성공적으로 통과함. 단점: 조정에 더 많은 시간과 노력이 필요하였습니다.