내가 작성한 리스크 발견 사항에 비즈니스가 어떻게 대응하게 할까?

대부분의 보안 발견 사항이 스프레드시트에서 죽는 이유는 다른 보안 담당자를 위해 작성되었기 때문이지, 예산 승인을 하는 사람을 위해 작성되지 않았기 때문이다. 보고서에 "CVE-2023-XXXX, CVSS 9.8, 즉시 패치하세요"라고 쓰면 리스크를 설명한 것이 아니라 취약점을 설명한 것이다. 비즈니스는 취약점에 대응하지 않는다. 그것은 시각화할 수 있는 결과에 대응한다.

심각도 점수만으로는 아무도 움직이지 않는 이유

CVSS는 결함이 얼마나 심각한지 독립적으로 알려준다. 그 결함이 실제로 접근 가능한지, 그 결함 뒤에 있는 자산이 수익에 중요한지, 아니면 이미 보정 제어가 그것을 약화시키는지에 대해서는 아무것도 말하지 않는다. 인터넷 경로가 없고 민감한 데이터가 없는 내부 개발 상자의 9.8은 결제 게이트웨이의 7.5와 같은 대화가 아니다. 순수하게 CVSS로 결과를 순위 매기면 아무도 악용할 생각이 없는 것들을 패치하면서 신용도를 소모하게 되고, 실제로 중요했던 결과는 소음에 묻힌다.

실행되는 리스크는 세 가지 요소를 가진다: 영향에 미치는 타당한 경로, 그 영향에 붙은 금전적 또는 운영 비용, 그리고 실제로 그것을 해결할 수 있는 담당자. 이 중 하나라도 놓치면 결과는 백로그에 머물러 있다.

스캐너 출력이 아닌 시나리오를 중심으로 결과를 작성하라

"/login 엔드포인트에서 발견된 SQL 인젝션" 대신에 시나리오를 작성하라: "인증되지 않은 공격자가 로그인 폼을 통해 해시된 비밀번호와 청구 주소를 포함한 전체 고객 테이블을 추출할 수 있다. 이 테이블은 40,000개의 활성 계정을 지원하며 동일한 데이터베이스는 PCI 범위와 연결된 주문 이력을 보유하고 있다." 이제 독자는 취약점 클래스를 파싱하지 않고 침해 통지 서한과 컴플라이언스 통화를 그려본다.

각 결과에 대한 유용한 구조:

• 어떤 일이 발생할 수 있는가 — 공격 경로를 일반적인 언어로, 한두 문장으로.
• 그것이 무엇을 건드리는가 — 특정 시스템, 특정 데이터, 특정 비즈니스 프로세스.
• 그 비용이 얼마나 드는가 — 다운타임 시간, 규제 노출, 고객 신뢰, 계약상 위약금. 가능한 곳에는 실제 숫자를 사용하라 (SLA 위약금 조항, 과거 사건 비용, 사이버 보험 공제액).
• 수정에 필요한 것이 무엇인가 — "패치하세요"뿐만 아니라 노력. 때때로 수정은 오늘의 WAF 규칙과 다음 스프린트의 코드 변경이다.
• 누가 수정을 소유하는가 — "IT"가 아닌 이름 또는 팀.

결과를 비즈니스가 이미 추적하는 것과 연결하라

모든 회사는 리더십이 이미 감시하는 지표를 가지고 있다: 가동 시간 SLA, 이탈, 최근 SOC 2 사이클의 감사 결과, 사이버 보험료, 보안 조항이 있는 특정 고객 계약. 기존 라인 중 하나와 결과를 연결할 수 있다면 — "이것은 우리 보험사가 마지막 갱신에서 지적한 것과 동일한 클래스의 문제입니다" 또는 "이 데이터 흐름은 Q3의 SOC 2 감사 범위에 있습니다" — 당신은 그들에게 새로운 것을 신경 쓰라고 요청하지 않는다. 당신은 이미 책임을 지고 있는 위협을 보여주는 것이다.

또한 이것은 보고서를 최종화하기 전에 비즈니스 측과 대화하는 것이 가치를 발하는 곳이다. 특정 시스템의 4시간 중단이 실제로 비용이 얼마나 드는지에 대해 재무 또는 운영 부서와 10분 정도 대화하는 것이 일반적인 "평판 손상" 라인보다 낫다. 숫자를 얻고, 인용하고, 계속하라.

CVSS만이 아닌 익스플로이트 가능성과 영향 범위로 순위 매기라

적절한 우선순위 지정 방식:

1. 인터넷에서 접근 가능한가, 아니면 먼저 내부 액세스가 필요한가?
2. 공개 익스플로잇이 있는가, 아니면 이론적인가?
3. 규제 데이터 (PCI, PHI, PII) 또는 핵심 시스템을 건드리는가?
4. 실제 수정 시간과 비용 대 방치 비용이 얼마인가?

도달 가능성과 영향 범위에서는 높지만 CVSS에서만 중간 수준인 결과는 종종 MFA가 있는 점프 박스 뒤에 3개의 네트워크 홉이 깊숙이 묻힌 중요도로 평가된 버그를 큐에서 뛰어넘을 자격이 있다.

문제가 아닌 요청을 작성하라

각 결과를 다음으로 끝내라: 구체적인 요청 — 예산 라인, 변경 윈도우, 닫을 정책 예외, 또는 일자까지 필요한 명시된 결정. "수정을 권장합니다"는 무시된다. "15일 전에 결제 게이트웨이를 패치하기 위해 4시간의 유지보수 윈도우가 필요하거나 서면으로 남은 리스크를 수용합니다"는 한 방향 또는 다른 방향으로 결정을 강제한다. 리더십에게 명시적인 리스크 수용 옵션, 서면으로, 그들의 이름이 있는 것을 제공하는 것은 종종 최종적으로 수정이 승인되도록 하는 것이다.

원본 스캔 출력을 이런 결과로 변환하는 연습을 하고 싶다면, Korra Studio의 Blue Team과 Offensive 세그먼트를 함께 작업하라 — 익스플로잇 컨텍스트를 보고 드릴과 짝지으면 이 기술이 실제로 날카로워지는 곳이다.