보안 테스트 보고서 - 더미 작성 방법

비디오: (해킹, 보안) 모의해킹 보고서 쓸 때 지키면 좋은 것 2024

보안 테스트 취약점 정보를 관리 용 또는 클라이언트 용 정식 문서로 구성해야 할 수 있습니다. 이것은 항상 그런 것은 아니지만 종종 전문적인 일이며 진지하게 자신의 업무를 수행한다는 것을 보여줍니다. 비판적인 결과를 공개하고 다른 당사자가 이해할 수 있도록 문서화하십시오.

그래프와 차트는 장점입니다. 특히 데이터를 파일로 저장하기 어려운 경우 결과를 화면 캡처하여 보고서에 멋진 느낌을 추가하고 문제가 있음을 보여주는 확실한 증거를 보여줍니다.

취약점을 간결하고 기술적이지 않은 방식으로 문서화하십시오. 모든 보고서에는 다음 정보가 포함되어야합니다.

테스트가 수행 된 날짜
수행 된 테스트
발견 된 취약점 요약
해결해야 할 취약점의 우선 순위가있는 목록
권장 사항 발견 된 보안 구멍을 연결하는 방법에 대한 특정 단계

IT / 보안 프로세스의 운영 평가를 수행 할 수 있다면 항상 가치를 더합니다. 취약한 비즈니스 프로세스, IT 및 보안에 대한 경영진의 지원 등에 대한 일반적인 관찰 목록을 추가하고 각 문제를 해결하기위한 권장 사항을 추가하십시오. 이것을 근본 원인 분석의 일종으로 볼 수 있습니다.

대부분의 사람들은 최종 보고서에 모든 결과가 아닌 요약본 을 포함하기를 원합니다. 대부분의 사람들이 원하는 마지막 일은 기술적 전문 용어가 포함 된 600 페이지의 PDF 파일을 살펴 보는 것입니다. 많은 컨설팅 회사가 이러한 유형의 보고서에 대해 메가 박스를 청구하는 것으로 알려져 있습니다. 그리고 그들은 그것으로 도망칩니다. 그러나 그것이 옳은 것은 아닙니다.

관리자와 개발자는 보안 도구의 원시 데이터 보고서가 필요합니다. 그렇게하면 나중에 특정 HTTP 요청 / 응답, 누락 된 패치에 대한 세부 정보 등을 볼 때 데이터를 참조 할 수 있습니다.

최종 보고서의 일부로 보안 테스트를 수행 할 때 관찰 한 행동을 문서로 작성하고자 할 수 있습니다. 예를 들어, 명백한 사회 공학 공격을 수행 할 때 직원들은 완전히 무시하거나 심지어 호전적입니까? IT 부서 또는 보안 담당자가 테스트 중 네트워크 성능 저하 또는 시스템 로그 파일에 나타나는 다양한 공격과 같은 기술적 인 문제를 완전히 놓치고 있습니까?

IT 직원 또는 관리 서비스 공급자가 테스트에 응답하는 속도 또는 응답 여부와 같이 관찰 한 다른 보안 문제를 문서화 할 수도 있습니다. 근본 원인 분석 방법에 따라 누락, 불완전 또는 따르지 않은 절차를 문서화해야합니다.

최종 보고서를 보지 못하게 된 사람들로부터 보호되도록 최종 보고서를 지키십시오. 보안 평가 보고서와 관련 데이터 및 지원 파일을 경쟁 업체, 해커 또는 악의적 인 내부자가 처리 할 경우 조직에 문제가 발생할 수 있습니다. 이 문제를 방지 할 수있는 방법은 다음과 같습니다.