보안 검토, 강화, 통제된 테스트 선택법

무엇인가

Security Baseline Review는 합의된 현재 상태를 이해하는 데 적합하고, Website Hardening은 확정된 구성 우선순위를 통제된 변경으로 옮기며, Application Security Review는 선택된 애플리케이션 보안 질문을 검토합니다. Application Load & Stress Testing은 합의된 사용 시나리오를 관찰하고, DDoS Resilience Testing은 제공업체 및 안전 경계 안에서 통제된 복원력 조건을 점검합니다. Red Team Exercise는 수행 규칙에 따라 관리되는, 목표 중심의 승인된 학습 연습입니다. 이들은 서로 바꿔 쓸 수 있는 명칭이 아닙니다. 발견 사항 보고서, 구성 변경, 성능 관찰, 복원력 관찰, 조직 학습 연습은 각기 다른 구매자 질문에 답합니다. 더 침습적인 테스트가 자동으로 더 유용한 것은 아닙니다.

누구를 위한 것인가?

이 비교는 다음과 같은 구매자에게 도움이 됩니다.

• 보안이나 안정성에 대한 우려가 있지만 증거, 구현, 검증 또는 더 넓은 학습 연습 중 무엇이 필요한지 아직 확실하지 않은 구매자
• 프로덕션 시스템, 제3자 제공업체, 서면 권한 또는 안전 한도가 선택지에 영향을 미치는지 이해해야 하는 구매자
• 공급업체에 작업 범위를 요청하기 전에 결과물과 경계를 비교하려는 구매자
• 검토, 보안 강화 변경, 통제된 테스트가 상호 배타적이지 않고 순차적일 수 있음을 인식하는 구매자

무엇을 명확히 하는 데 도움이 되는지

이 비교를 활용해 다음 사항을 명확히 하십시오.

• 문제가 알려진 것인지 불확실한 것인지, 그리고 다음 단계가 증거를 만들어야 하는지 합의된 변경을 적용해야 하는지
• 관련 자산이 웹사이트, 애플리케이션, 구성, 고객 여정, 예상 부하 아래의 서비스 또는 복원력 경로 중 무엇인지
• 작업에 서면 권한, 제공업체 동의, 작업 금지 기간, 연락처 또는 즉시 중단 조건이 필요한지
• 지금 유용한 결과가 발견 사항 보고서, 변경 기록, 성능 관찰, 복원력 관찰, 의사 결정용 디브리프 중 무엇인지

포함된 내용

• 기준선 검토, 웹사이트 보안 강화, 애플리케이션 검토, 통제된 부하 테스트, DDoS 복원력 테스트, 레드팀 연습에 대한 알기 쉬운 비교
• 불확실성, 증거 대 구현, 프로덕션 영향, 권한, 제3자, 예상 결과물을 다루는 의사 결정 요소
• 문서화된 검토가 이후의 통제된 작업으로 자연스럽게 이어지는 경우 서비스를 순차적으로 활용하는 방법에 대한 안내
• 질문이 아직 안정되지 않았다면 범위 명확화나 디스커버리가 가장 합리적인 첫 단계일 수 있다는 점에 대한 안내

포함되지 않은 것

• 보편적인 서비스 추천, 인증 또는 어떤 선택지든 모든 리스크를 없앤다는 약속
• 확정된 권한, 안전한 경계, 제공업체 요건, 범위 없이 통제된 테스트를 수행하라는 조언
• 운영상의 테스트 전술, 악용 방법 안내, 서비스 방해 방법 또는 우회 안내
• 검토, 보안 강화 작업 또는 연습이 규정 준수, 가용성, 성능, 복원력 또는 침해 방지를 약속한다는 주장

선택해야 할 때

팀이 작업을 선택하기 전에 선택지를 비교하고 있을 때 이 가이드를 읽으십시오. 한 이해관계자는 “테스트”를 요구하고 다른 이해관계자는 구성 변경이나 서면 평가를 요구하는 경우에 특히 유용합니다. 시스템, 원하는 결정, 소유권 또는 가용 증거가 불분명하다면 선택보다 범위 명확화가 먼저입니다. 짧은 대화로 구매자가 실제로 원하는 것이 현재 상태 검토, 통제된 구현, 특정 애플리케이션 질문, 용량 관찰, 복원력 평가 또는 목표 중심 연습 중 무엇인지 파악할 수 있습니다.

우리의 접근 방식

비즈니스 결정에서 시작한 다음 기술적 질문을 좁히십시오. 영향을 받는 시스템, 이미 알려진 사항, 담당자, 프로덕션이 영향을 받을 수 있는지, 유용한 결과물이 어떤 모습일지를 나열하십시오. 다음으로, 통제된 테스트를 논의하기 전에 권한과 제3자를 파악하십시오. 기준선 검토는 보안 강화를 위한 증거를 만들 수 있고, 보안 강화는 이후 테스트보다 먼저 진행될 수 있으며, 부하 관찰은 인프라 관련 질문을 드러낼 수 있고, 레드팀 연습은 목표와 거버넌스가 성숙한 뒤에야 유용할 수 있습니다. 요점은 고정된 단계를 만드는 것이 아닙니다. 적절하고 승인된 다음 단계를 선택하고, 이후 작업은 별도 범위로 남겨 두는 것입니다. 구매자는 그 선택을 좌우하는 실무적 제약도 기록할 수 있습니다. 가용 증거, 시스템의 연식, 공급업체 약관, 고객 약정, 예상 유지 보수 시간대, 프로덕션 밖에서 변경을 안전하게 테스트할 수 있는지가 이에 해당합니다. 이러한 제약이 그 자체로 서비스를 선택해 주지는 않지만, 이후의 범위를 더 사실에 맞게 만듭니다. 이 비교는 팀이 질문을 잘못된 작업 명칭에 억지로 끼워 맞추기보다 열어 둘 의향이 있을 때 가장 효과적입니다. 연락하기 전에 결정 일자, 영향을 받는 자산, 비즈니스 담당자, 기술 담당자, 주요 공급업체, 현재 진행 중인 변경 활동, 알려진 접근 제한을 간결하게 정리해 두십시오. 이러한 세부 사항은 문제의 증거가 아니라, 제공업체가 표준 범위가 어디에 맞고 어떤 가정을 확인해야 하는지 말할 수 있게 해 주는 맥락입니다. 또한 문제가 아직 정리되지 않았다는 이유만으로 광범위한 테스트를 요청하는 일을 피하기 쉬워집니다. 마감 기한이 있다면 그것이 상업적, 계약상, 운영상 또는 규제상의 것인지, 그리고 무엇이 결정을 유용하게 만드는지 설명하십시오. 그러면 모두가 원하는 결과와 책임 있는 범위 안에서 실제로 수집할 수 있는 증거를 구분할 수 있게 됩니다.

자주 묻는 질문

관련 기사