플레이북 설계

플레이북은 코드로 정의된 대응 워크플로입니다. 트리거되면 SOAR 플랫폼이 실행하는 순서가 정해진 분기형 단계 집합입니다. 이는 과거에 위키에 있던 런북을 실행 가능한 형태로 만든 것입니다.

런북이 IP 평판을 조회하십시오라고 말한다면, 플레이북은 실제로 the 평판 API를 호출하고 결과를 구문 분석한 다음 점수에 따라 분기합니다. 플레이북을 잘 설계하는 것은 SOC 자동화 엔지니어링의 핵심 기술입니다.

플레이북을 추상적으로 설계하지 마십시오. 분석가가 today the 경보를 실제로 처리하는 방식을 단계별로 문서화하는 것부터 시작하십시오. 분석가가 내리는 결정과 확인하는 데이터도 포함해야 합니다.

각 단계를 다음 세 가지 범주 중 하나에 배정하십시오.

• 결정적 작업 — 동일한 입력은 항상 동일한 출력을 생성합니다(자동화하기에 안전함).
• 정보 보강 — 부작용 없이 데이터를 수집합니다(자동화하기에 안전함).
• 판단 — 맥락이나 책임이 필요합니다(사람을 참여시킵니다).

모든 플레이북에는 정확한 트리거가 필요합니다. 너무 광범위하면 the 잡음에도 실행되고, 너무 좁으면 실제 사례를 놓칩니다.

트리거는 일반적으로 SIEM 상관 분석 규칙, EDR 탐지 범주 또는 이메일 게이트웨이 판정에 연결됩니다. 진입 조건을 명시적으로 정의하십시오.

플레이북은 트리거 이벤트에서 추출한 지표인 아티팩트를 대상으로 작동합니다. 여기에는 IP, 파일 해시, 사용자 계정, URL 및 호스트 이름이 포함됩니다.

좋은 설계는 초기에 이러한 항목을 일관된 컨텍스트 객체로 정규화합니다. 그러면 이벤트를 생성한 도구와 관계없이 모든 후속 단계가 the 동일한 필드 이름을 참조할 수 있습니다.

• 맨 처음에 아티팩트를 한 번만 추출합니다.
• 유형을 검증합니다(실제로 유효한 IPv4입니까?).
• 전체 흐름에서 공유 컨텍스트를 전달합니다.

실제 워크플로에는 분기가 있습니다. 정보 보강 후에는 증거를 바탕으로 경로를 결정합니다. 분기를 명시적이고 빠짐없이 정의하여 어떤 이벤트도 처리되지 않은 채 빠져나가지 않도록 하십시오.

파괴적이거나 되돌릴 수 없거나 영향 범위가 큰 작업을 수행하기 전에 사람 승인 게이트를 삽입하십시오. 플레이북은 the 증거를 모아 제시하고 결정이 내려질 때까지 실행을 차단합니다.

시간 초과가 발생했을 때 안전한 기본 동작을 하도록 게이트를 설계하십시오. 격리의 경우 응답이 없을 때 시간 초과가 발생하면 자동으로 진행하거나 사례를 조용히 삭제하는 대신 당직 엔지니어에게 에스컬레이션할 수 있습니다.

• 계정 비활성화: 게이트를 적용합니다.
• 대규모 서브넷 차단: 게이트를 적용합니다.
• 지표 정보 보강: 게이트가 필요하지 않습니다.

통합은 실패할 수 있습니다. API는 호출 제한에 걸리거나, 시간 초과가 발생하거나, 잘못된 형식의 데이터를 반환합니다. 모든 호출이 성공한다고 가정하는 플레이북은 인시던트를 미완료 상태로 남깁니다.

다음 항목을 내장하십시오.

• 백오프를 적용한 재시도 — 일시적인 오류(HTTP 429, 503)에 사용합니다.
• 안전 우선 기본값 — 보강에 실패하면 자동 종료하지 말고 사람에게 에스컬레이션하는 것을 기본값으로 설정합니다.
• 처리 불능 이벤트 처리 — 처리할 수 없는 이벤트를 분석가가 검토하는 대기열로 보냅니다.

중복 경보나 재시도로 인해 하나의 이벤트에 플레이북이 두 번 실행될 수 있습니다. 작업은 멱등적이어야 합니다. 두 번 실행해도 피해가 두 배로 발생해서는 안 됩니다.

이미 격리된 호스트를 다시 격리하는 작업은 오류가 아니라 아무 작업도 하지 않는 동작이어야 합니다. 티켓을 생성할 때는 먼저 동일한 중복 제거 키를 사용하는 기존 티켓이 있는지 확인해야 합니다.

인시던트 유형마다 거대한 플레이북 하나를 만드는 방식은 피하십시오. 재사용할 수 있는 하위 플레이북으로 분해하십시오. 예를 들어 보강 하위 플레이북, 억제 하위 플레이북, 알림 하위 플레이북으로 나눌 수 있습니다.

이는 좋은 소프트웨어 설계 방식과 같습니다. 피싱, 무차별 대입, C2 플레이북에서 호출하는 재사용 가능한 IP 보강 블록이 있으면 위협 인텔리전스 API가 변경될 때 한 곳만 수정하면 됩니다.

새 플레이북은 먼저 시험 실행/시뮬레이션 모드로 실행하십시오. 보강과 기록은 실행하되 파괴적인 작업은 대체 처리로 막습니다. 플레이북이 제안한 작업을 분석가가 과거 사례에서 실제로 수행했을 작업과 비교하십시오.

과거의 실제 인시던트를 대상으로 의사 결정 로직이 올바르다는 사실이 확인된 후에만 실시간 작업을 활성화하십시오. 그 경우에도 처음에는 모든 작업에 승인 단계를 적용하십시오.

플레이북은 코드이므로 동일한 수준의 규율이 필요합니다. 모든 변경 사항이 검토되고 추적 가능하며 되돌릴 수 있도록 버전 관리하에 두십시오.

• 변경 기록은 지난달에 이 플레이북이 다르게 동작한 이유는 무엇인가?라는 질문에 답해 줍니다.
• 동료 검토를 통해 위험한 로직이 운영 환경에 도달하기 전에 발견할 수 있습니다.
• 의도한 트리거, 의사 결정, 담당자를 문서화하면 담당자가 바뀌어도 플레이북을 유지 관리할 수 있습니다.

아무도 이해하지 못하는 문서화되지 않은 플레이북은 오작동하는 순간 위험 요소가 됩니다.

실패 시나리오에 플레이북 설계 원칙을 적용해 보십시오.

플레이북 설계의 핵심:

• 플레이북은 실행 가능한 분기형 대응 작업 흐름이며, 실제 수동 프로세스를 바탕으로 설계해야 합니다.
• 단계를 결정적 작업, 보강, 판단으로 분류하고, 판단에는 사람의 승인을 거치게 하십시오.
• 정확한 트리거를 정의하고, 아티팩트를 공유 컨텍스트로 정규화하며, 모든 분기를 빠짐없이 정의하십시오.
• 재시도와 안전한 기본값으로 오류를 처리하십시오. 보강에 실패하면 자동 종료하지 말고 에스컬레이션해야 합니다.
• 작업을 멱등적으로 만들고, 재사용 가능한 하위 플레이북으로 플레이북을 모듈화하십시오. 운영을 시작하기 전에 과거 인시던트를 대상으로 시험 실행하여 테스트하십시오.