보안시험의 실패와 테스트 프로세스 정의 수립

보안시험 접근의 실패 분석

실패의 정도가 있다는 것을 이해할 필요가 있다. 보안 취약성이 탐지되고 해결되지 않는다고 해서 반드시 보안 테스트 접근이 실패하는 것은 아니다. 보안 취약성이 너무 많아서 매일 새로운 보안 취약성이 발견된다. 그러나 보안 테스트 접근법이 보안 위험을 효과적으로 식별하기에 부적절했던 다른 사례가 있으며, 이로 인해 민감한 데이터 및 기타 디지털 자산이 손상되었습니다.

 

근본 원인 분석은 보안 테스트 접근 방식이 실패한 이유를 확인하는 데 도움이 될 수 있습니다. 가능한 원인 포함 :

 

• 보안 테스트를 수립하는 데 있어 행정 리더십 부족
• 보안 테스트 전략(자금 부족, 시간 부족, 자원 부족 등)을 구현하는 데 필요한 자원의 실행 부족
• 보안 테스트 접근법의 효과적인 구현 부족(필요한 작업을 수행하기 위해 필요한 기술 부족 등)
• 보안 테스트 접근방식에 대한 조직 이해 부족 및 지원
• 보안 테스트 접근방식에 대한 이해 및 지원 부족
• 보안 리스크에 대한 이해 부족
• 테스트 접근 방식과 조직의 보안 정책 간의 정렬 부족
• 테스트 접근 방식과 조직의 보안 테스트 정책 및 전략 간의 정렬 부족
• 시스템의 목적에 대한 이해 부족
• 시스템에 대한 기술 정보 부족(잘못된 가정을 유발)
• 보안 테스트를 위한 효과적인 도구 부족
• 보안 테스트 기술 부족

 

이해관계자 식별

보안 테스트 노력이 효과적이려면 경영진에게 비즈니스 사례가 이루어져야 합니다.이 비즈니스 사례는 보안 오류의 위험과 특정 프로젝트에 대한 효과적인 보안 테스트 접근법을 갖는 이점을 명확하게 정의해야 합니다.

 

서로 다른 이해 관계자가 보안 테스트 접근법의 다른 이점을 보게 됩니다.

 

• 경영진은 비즈니스 보호를 혜택으로 볼 것이다.
• 고위 경영진은 실사를 볼 수 있다.
• 비즈니스 고객은 사기로부터 보호받을 수 있습니다
• 준수 담당자(내부 기업 보안 정책의 경우)는 조직이 법적 의무 측면에서 준수한다는 확신을 가질 수 있다.
• 규제 담당자(외부 보안법의 경우)는 보안 규정이 준수되고 있는 이점을 볼 수 있다.
• 개인정보보호담당자들은 개인정보가 안전하게 유지되고 디지털 자산 보호에 실사가 드러나는 이점을 볼 수 있다.

 

보안 시험 관행 개선

보안 테스트 관행을 개선하기 위해서는 먼저 기존 관행에 대한 평가가 필요하다. 보안 테스트 관행을 평가하는 객관적인 방법이 있어야 합니다. 이들은 보안 테스트 목표를 위한 주요 메트릭에 기반을 두고 있으며, 핵심 전략 요소의 성공 정도를 식별할 수 있습니다.

 

이러한 관행은 다음과 같이 평가되어야 합니다.

 

• 단기적, 장기적 관점에서
• 과정과 조직을 고려한다
• 사람, 도구, 시스템 및 기술을 고려하면 주요 지표에는 다음이 포함되지만 이에 국한되지는 않는다.

 

테스트에 의한 보안 위험의 범위 수준

테스트에 의한 보안 정책 및 관행의 적용 범위 수준 테스트에 의한 보안 요구 사항 적용 범위 수준

보안 취약성이 확인된 시기와 장소를 기준으로 과거 보안 테스트 노력의 유효성 수준. 여기에는 릴리스 전 및 릴리스 후 보안 취약성이 모두 포함됩니다.

 

보안 테스트 프로세스 정의

보안 테스트 프로세스를 특정 응용 프로그램 라이프사이클모델에 정렬

다음 유형의 라이프사이클 프로세스는 각각 보안 테스트에 대한 우려를 가지고 있다. 보안 테스트를 생명 주기에 맞게 정렬하는 것이 중요합니다.

 

이 프로젝트에서 보안 테스터는 다음을 알아야 합니다.

 

• 보안 요구 사항과 위험은 프로젝트 초기에 정의되며 소프트웨어 요구 사항 사양에 문서화되어야 합니다.
• 프로젝트 중에 보안 요구가 변경될 수 있지만 업데이트된 소프트웨어 요구 사항에 반영되지 않을 수 있습니다. 보안 테스트는 매우 구체적이고 완료된 것으로 보일 수 있지만, 프로젝트가 늦어짐에 따라 불완전하거나 현재 상태가 아닐 수 있다.
• 보안 테스트는 언제든지 수행할 수 있지만 프로젝트에서 이러한 테스트가 수행되는 것은 일반적입니다. 순차적인 라이프 사이클 프로젝트가 끝날 때 보안 테스트 결과를 처리하기가 어려울 수 있습니다.

 

반복/증가적 수명주기

점진적인 프로젝트는 애플리케이션의 작고 빈번한 릴리스를 제공한다. 민첩한 방법은 이 접근법의 예시이다. 이 프로젝트에서 보안 테스터는 다음을 알아야 합니다.

 

보안 요구와 위험은 프로젝트 전체에 걸쳐 나타나며(일반적으로 반복기 스프린트의 맥락에서) 요구 사양, 사용자 스토리, 모델, 수용 기준 및/또는 프로토타입으로 정의할 수 있다.

보안 요구와 위험은 프로젝트 중에 바뀔 수 있으며, 보안 요구와 위험이 식별되는 반복에서 해결될 수 있다.