팀 간 인계: 검증 시나리오에서 보안정책·탐지·재시험까지

01팀 이름보다 입력과 산출물이 중요하다

• 역할별 입력과 산출물역할 분담 예: PM, 네트워크, 서버, Red, Purple 담당으로 나누고 각 산출물을 최종 검증 결과에 연결한다.

  • 역할명과 분담 범위는 프로젝트에 맞게 정의한다.
  • 조직마다 직무 명칭과 업무 경계는 다르지만, 환경을 제공하는 역할·검증 조건을 만드는 역할·관측하고 판단하는 역할 사이의 전달 자료는 필요하다.
• 연결 지점의 합의Red의 시나리오만 받아서는 탐지나 차단을 설계하기 어렵다.

  • 대상 서비스와 계정 권한, 요청의 종류, 기대한 상태 변화, 시간과 관찰 지점이 있어야 한다.
  • 서버·네트워크 역할은 정상 서비스 흐름과 허용 경계를 제공하고, 관제 역할은 패킷·로그에서 볼 수 있는 정보와 볼 수 없는 정보를 되돌려 준다.
  • 통합 작업은 이런 차이를 맞추는 과정이다.

02검증 결과를 보안정책으로 연결하는 단계

1. 자산·흐름 파악보호할 서비스와 정상 트래픽, 관측 위치와 팀별 관리 구간을 확인한다.
2. 시험 조건 정의검증할 행위, 대상, 전제 조건과 예상 로그·경보를 정한다.
3. 관찰 자료 수집센서·서버·네트워크의 시간과 식별자를 맞춰 실제 수신·탐지 여부를 확인한다.
4. 정책 명세출발지·목적지·방향·프로토콜·포트·행위 조건과 적용 위치·예외·소유자를 적는다.
5. 적용 후 재시험동일 시나리오와 정상 요청을 비교해 차단·탐지·업무 영향, 오탐과 미탐을 확인한다.
6. 인계와 운영룰 버전·증적·변경/복구 절차·알려진 한계를 전달하고 수신 담당자가 재현하는지 확인한다.

03검증 결과를 정책으로 구체화하기

• 검증에서 정책으로검증 시나리오의 패킷·로그 패턴을 분석해 보안정책과 Snort 룰의 조건을 정한다.

  • 네트워크와 서버 중 적용 위치를 협의하고 구현 담당자에게 전달한다.
  • 이 순서는 관찰한 현상과 통제 지점을 연결하는 방법으로 읽는다.
  • 문서가 그렇게 서술한다는 사실과 모든 규칙의 효과가 검증되었다는 사실은 구분해야 한다.
• 차단 조건의 구체화발표의 보완점에는 룰 검토가 충분하지 않았고 차단 정책을 얼마나 구체적으로 전달해야 할지 혼선이 있었다는 내용이 있다.

  • 이를 해결하려면 “해당 공격 차단”이라는 요청을 출발지·목적지·방향·조건·예외·로그·원복·재시험이 있는 명세로 바꾼다.
  • 네트워크가 볼 수 없는 애플리케이션 권한 문제는 애플리케이션에서 해결하고, 경계 통제와 탐지는 보조 역할로 설계한다.

04정책 명세의 최소 필드

• 정책 명세정책 명세는 장비 명령어보다 상위의 의도를 담는다.

  • 어느 업무 흐름을 허용하고 무엇을 제한하는지, 정상 사용자가 영향을 받지 않는 조건은 무엇인지가 먼저다.
  • 구현은 장비별 문법으로 변환하되 원래 정책 ID를 남긴다.
  • 적용 전후의 정상 요청과 거부 요청을 함께 시험해야 잘못된 차단을 발견할 수 있다.
• 소유자와 적용 위치NAT나 프록시를 거치면 장비가 보는 출발지와 애플리케이션이 기록하는 주소가 달라질 수 있다.

  • “출발지 주소 기준 차단”이라고만 쓰면 적용 위치마다 결과가 달라진다.
  • 관측 위치, 변환 전후 주소의 의미, 신뢰하는 전달 헤더의 출처를 명세에 포함한다.

06탐지 관리 대장은 룰 코드와 별도로 필요하다

• 룰과 관리 대장룰 관리에는 식별자, 개정, 목적, 적용 센서와 엔진 버전, 필요한 데이터, 정상·탐지 샘플, 알려진 한계를 기록한다.

  • 중복 SID나 서로 다른 버전의 문법이 섞이면 룰 수가 많아도 어떤 규칙이 로드되었는지 알기 어렵다.
  • 코드 저장소의 버전과 센서가 실제 로드한 버전, 시험 결과가 일치해야 한다.
• 변경·배포·재시험원본에는 탐지 제목과 조건이 맞지 않는 예가 보인다.

  • TCP 기반 웹 실습을 대상으로 하면서 광범위한 UDP 빈도만 세는 조건은 그 웹 요청을 입증하지 못한다.
  • SSH SYN의 빈도는 연결 시도 관찰이며 암호화된 인증 실패 횟수와 동일하지 않다.
  • 정상 도구의 User-Agent나 세미콜론 같은 문자도 단독으로 공격 성공을 증명하지 않는다.
  • 따라서 이름보다 실제 조건과 관측 가능한 데이터로 룰의 의미를 설명한다.

07자산→데이터→규칙→대응의 매핑

• 자산과 데이터자산의 중요한 상태 변화가 어느 로그에 어떤 필드로 나타나는지 매핑한다.

  • HAProxy backend의 DOWN 상태는 서버 이름, 상태 검사 결과, 시각이 필요하고, 메일 전달은 메시지 식별자와 큐 상태를 연결한다.
  • 네트워크 이웃 상태 변화는 장비·인터페이스·이웃·영역이 있어야 영향 범위를 좁힐 수 있다.
• 규칙과 대응 책임소스가 조용한 것과 수집기가 고장 난 것은 다르다.

  • 마지막 발생 시각과 마지막 수신 시각, 파서 실패, 입력량, 수집기 연결 상태를 함께 본다.
  • 각 시나리오에 Source·Field·Rule·Owner·Response를 연결한다.
  • 경보가 없을 때 수집원·필드·규칙·전달 경로 중 어느 단계가 원인인지 나누어 확인한다.
  • 데이터 수집 상태도 관제의 대상이다.

09통합 시나리오는 한 번에 한 조건씩 바꾸기

• 변경 조건의 통제통합 실습은 사전 합의 → 정상 기준선 → 한 가지 변경 → 관찰·대응 → 원복 → 같은 조건 재시험 순으로 진행한다.

  • 애플리케이션 health check 실패와 NIC 장애를 동시에 일으키면 어느 계층에서 복구가 일어났는지 분리하기 어렵다.
  • 먼저 backend 하나의 상태 실패를 관찰하고 원복한 뒤 링크 장애를 시험하는 방식으로 원인과 결과를 연결한다.
• 관측과 기대 결과각 실행에는 시험 ID와 실행 ID를 붙인다.

  • 프로토콜 자체 로그에 사용자 정의 ID를 넣을 수 없다면 시작·종료 시각, 대상 역할, 요청 특성, 장비 인터페이스와 변경 기록으로 묶는다.
  • 시각 기준이 다르면 사건 순서가 뒤집혀 보일 수 있으므로 시간대와 동기화 상태도 시험 전제에 들어간다.
  • 아래 양식은 실제 값을 채워 팀별 증거를 연결하기 위한 것이다.

시나리오: WEB-HEALTH-01 / 실행: RUN-01
정상: backend 두 개 정상, 시험 요청 성공
변경 하나: 승인된 한 backend의 상태 검사 실패
예상: 해당 backend 제외, 다른 backend로 요청 처리
서버 증거: 서비스/애플리케이션 상태와 시각
관제 증거: 상태 경보·요청 로그·수집 지연
복구: 변경 원복 후 재편입과 정상 요청 확인
판정: 예상과 실제의 일치·차이·추가 확인

프로젝트 문서 작성 연습용 예시. 실제 수행 결과가 아니다.

10인계는 전달·수신·검증까지 닫기

• 인계의 완료 조건정책을 보냈다는 기록만으로 구현이 완료된 것은 아니다.

  • 받은 팀이 해석한 대상과 방향을 확인하고, 적용 버전·작업 시각·검증 결과를 회신해야 한다.
  • 탐지 규칙도 작성, 문법 검증, 배포, 로드 확인, 샘플 시험이 각각 다른 단계다.
  • 스캐너 결과의 조치도 변경 완료와 동일 조건 재시험 통과를 나눠 관리한다.
• 역할과 수행 근거마지막 인계 묶음에는 요구사항·정책·탐지·시험 ID의 대응표, 실제 설정 버전, 정상과 실패 증거, 미해결 항목, 담당자와 복구 절차가 포함된다.

  • 사용자에게 보여 줄 발표에서는 핵심 흐름을 간결하게 설명하되, 기술 결과와 판단 근거를 담은 보고서는 별도로 유지한다.
  • 세부 기술은 관련 관제·취약점 문서에서 이어서 학습한다.