기업에서는 방화벽, IPS, WAF, 서버, 클라우드, 사용자 PC 등 수많은 시스템에서 매일 많은 보안 로그가 발생한다. 하지만 로그가 생성된다는 사실만으로 공격을 막을 수 있는 것은 아니다.
수많은 기록 가운데 실제 위험 신호를 찾아내고, 공격 가능성을 분석하며, 필요한 경우 대응 조직으로 연결하는 과정이 필요하다.
이러한 역할을 수행하는 조직 또는 기능을 일반적으로 SOC(Security Operations Center), 보안관제센터라고 한다.
SOC의 핵심은 화면을 계속 바라보는 것이 아니다. 여러 시스템에서 발생하는 데이터를 수집하고 분석해 정상 활동과 이상 활동을 구분하고, 실제 보안사고로 발전할 가능성이 있는 이벤트를 신속하게 찾아 대응하는 것에 있다.
SOC는 보안 위협을 탐지하고 대응하는 운영 기능이다
SOC는 기업의 시스템과 네트워크에서 발생하는 보안 위협을 지속적으로 관찰하고 분석하는 역할을 수행한다.
기업에 따라 자체 조직으로 운영할 수도 있고 전문 보안관제 업체에 위탁하거나 내부 인력과 외부 서비스를 결합한 형태로 운영할 수도 있다.
조직 형태는 달라도 주요 업무는 비슷하다.
- 보안 로그와 이벤트 모니터링
- 이상행위 및 공격 징후 탐지
- 보안 경보 분석
- 오탐 여부 판단
- 보안사고 가능성 조사
- 침해 범위 확인
- 대응 조직으로의 보고와 에스컬레이션
- 차단 및 격리 지원
- 사고 이후 탐지 규칙 개선
Microsoft는 Security Operations의 주요 활동을 Detect, Respond, Recover로 설명한다. 단순한 탐지만이 아니라 발견된 위협이 실제 공격인지 확인하고 영향을 파악하며, 필요한 조치를 통해 서비스와 시스템의 보안 상태를 복구하는 과정까지 포함한다.
보안 이벤트와 보안사고는 같은 의미가 아니다
SOC 업무를 이해하려면 이벤트, 경보, 사고를 구분할 필요가 있다.
보안 이벤트
시스템이나 보안 장비에서 발생한 하나의 기록이나 활동이다.
- 사용자 로그인
- 방화벽 통신 허용 또는 차단
- 서버 관리자 명령 실행
- 파일 생성 또는 삭제
- IPS 공격 패턴 탐지
- 백신 악성파일 탐지
모든 이벤트가 보안사고를 의미하지는 않는다.
보안 경보
보안 시스템이나 탐지 규칙이 특정 이벤트를 위험 가능성이 있는 상황으로 판단해 분석 대상으로 만든 것이다.
예를 들어 한 사용자가 짧은 시간 동안 수백 번 로그인에 실패하거나 외부 IP에서 여러 서버의 포트를 순차적으로 탐색하면 경보가 발생할 수 있다.
보안사고
분석 결과 실제로 정보시스템의 기밀성, 무결성 또는 가용성에 영향을 주었거나 영향을 줄 가능성이 확인된 상황이다.
로그·이벤트 발생 → 탐지 규칙 적용 → 경보 발생 → 분석 → 사고 여부 판단 → 대응
발생하는 모든 경보를 사고로 처리하면 대응 자원이 부족해지고, 반대로 실제 공격을 단순 이벤트로 판단하면 피해가 확대될 수 있다.
SOC 분석은 다양한 로그 수집에서 시작한다
공격은 하나의 보안 장비에서만 흔적을 남기지 않는다.
공격자가 외부에서 기업 서버에 접근한다면 방화벽과 IPS에 통신 기록이 남을 수 있다. 계정 탈취에 성공하면 인증 시스템에 로그인 기록이 남고, 이후 서버에서 명령을 실행하면 운영체제 로그에도 흔적이 생길 수 있다.
| 로그 유형 | 확인할 수 있는 정보 |
|---|---|
| 방화벽 | 출발지·목적지 IP, 포트, 허용·차단 |
| IDS·IPS | 공격 패턴 및 침입 시도 |
| WAF | 웹 공격과 비정상 HTTP 요청 |
| 서버 | 로그인, 프로세스, 시스템 작업 |
| EDR | 프로세스 실행, 파일·행위 정보 |
| IAM·AD | 사용자 인증과 계정 활동 |
| 애플리케이션 | 서비스 사용 및 업무 행위 |
| 클라우드 | 콘솔 접속, API 실행, 설정 변경 |
로그를 많이 수집한다고 보안 수준이 자동으로 높아지는 것은 아니다. 어떤 로그가 중요한지, 어떤 필드를 수집해야 하는지, 얼마나 오래 보관해야 하는지, 분석에 사용할 수 있는 형태인지까지 함께 고려해야 한다.
SIEM은 여러 로그를 모아 분석할 수 있도록 지원한다
SOC에서 자주 사용되는 대표적인 시스템이 SIEM(Security Information and Event Management)이다.
SIEM은 여러 서버와 보안 장비에서 발생하는 로그를 중앙으로 수집하고 검색·분석할 수 있도록 지원한다.
예를 들어 다음 기록들을 연결할 수 있다.
방화벽: 외부 IP의 서버 접근
인증 로그: 관리자 계정 로그인 성공
서버 로그: 새로운 프로세스 실행
EDR: 의심스러운 파일 생성
SIEM에서는 시간, IP 주소, 계정, 시스템 등의 정보를 연결해 하나의 공격 흐름으로 분석할 수 있다. 이를 상관분석이라고 한다.
다만 SIEM이 곧 SOC인 것은 아니다.
SIEM은 분석을 지원하는 기술이고 SOC는 사람, 절차, 탐지 정책, 대응 체계와 기술을 포함하는 보안 운영 기능이다.
첫 단계는 경보의 우선순위를 판단하는 것이다
SOC에는 하루에도 많은 경보가 발생할 수 있다. 모든 경보를 동일한 수준으로 조사하면 중요한 공격을 놓칠 수 있다.
따라서 경보가 발생하면 먼저 분석 우선순위를 정하는 과정이 필요하다. 이를 일반적으로 Triage라고 한다.
- 공격 대상 시스템의 중요도
- 출발지 IP의 특성
- 사용된 계정
- 공격 패턴
- 동일한 공격의 반복 여부
- 다른 보안 장비의 탐지 여부
- 정상 업무에서 발생 가능한 행위인지
- 실제 피해가 발생했는지
탐지된 기술적 이벤트뿐 아니라 자산 중요도와 업무 맥락을 함께 고려하는 것이 중요하다.
True Positive와 False Positive를 구분해야 한다
보안 장비에서 탐지했다고 해서 모두 실제 공격은 아니다.
정상적인 업무 활동이 탐지 규칙과 일치하면서 경보가 발생하는 경우를 False Positive, 오탐이라고 한다.
반대로 실제 공격 행위가 탐지된 경우는 일반적으로 True Positive, 정탐이라고 표현한다.
오탐이 지나치게 많으면 분석가가 불필요한 경보를 반복적으로 확인하게 되어 중요한 공격을 놓칠 가능성이 커진다.
이를 줄이기 위해 탐지 규칙의 조건, 임계값, 예외 대상을 지속적으로 조정할 필요가 있다.
정탐으로 판단되면 공격 범위를 조사한다
경보가 실제 위협일 가능성이 높다고 판단되면 분석 범위를 확대한다.
분석가는 다음과 같은 질문을 확인할 수 있다.
공격은 언제 시작되었는가.
최초 침투 지점은 어디인가.
어떤 계정이 사용되었는가.
다른 서버로 이동했는가.
외부로 데이터가 전송되었는가.
동일한 공격 흔적이 다른 시스템에도 존재하는가.
이를 위해 방화벽, EDR, 서버, 인증, 프록시, 클라우드 등의 로그를 시간순으로 연결해 공격 흐름을 확인한다.
심각도가 높으면 대응 조직으로 에스컬레이션한다
SOC가 모든 조치를 직접 수행하는 것은 아니다.
조직에 따라 서버 운영자, 네트워크 관리자, 보안담당자, 개인정보 담당자, 사고대응팀 등이 실제 대응에 참여할 수 있다.
- 악성 IP 차단
- 감염 PC 네트워크 격리
- 사용자 계정 잠금
- 관리자 비밀번호 변경
- 악성 프로세스 종료
- 침해 서버 서비스 분리
- 관련 로그와 증거 보존
상황에 따라 너무 이른 조치가 공격자의 행동을 숨기게 하거나 조사에 필요한 증거를 없앨 수도 있다.
따라서 사고의 심각도와 업무 영향, 조사 필요성을 함께 고려해 대응해야 한다.
복구 후에도 SOC 업무는 끝나지 않는다
공격자를 차단하고 시스템을 복구했다고 해서 보안사고 처리가 끝난 것은 아니다.
사고가 발생한 원인과 탐지 과정에서의 문제를 분석해야 한다.
- 공격의 최초 침투 원인
- 최초 공격부터 탐지까지 걸린 시간
- 기존 보안 장비에서 탐지하지 못한 이유
- 발생한 경보 가운데 불필요한 경보
- 대응 과정에서 지연된 부분
- 추가로 수집해야 할 로그
- 새롭게 만들어야 할 탐지 규칙
탐지 → 분석 → 대응 → 복구 → 원인 분석 → 탐지 개선
사고 경험이 다시 탐지 체계 개선으로 이어지는 구조가 중요하다.
SOC의 L1·L2·L3 구조는 조직에 따라 달라질 수 있다
| 구분 | 대표적인 역할 |
|---|---|
| L1 | 경보 모니터링, 1차 분석, 기본 Triage |
| L2 | 상세 분석, 공격 범위 조사, 대응 판단 |
| L3 | 고급 분석, 위협 헌팅, 탐지 로직 개발 |
다만 이것이 모든 SOC에서 동일하게 적용되는 국제 표준 구조는 아니다.
중요한 것은 직급 명칭보다 누가 탐지하고, 누가 분석하며, 누가 대응 결정을 내리고, 언제 상위 조직으로 보고하는지가 명확한가이다.
좋은 SOC는 경보의 개수보다 탐지와 대응 품질이 중요하다
경보가 많다고 반드시 보안관제가 잘 운영되는 것은 아니다.
오탐 경보가 수천 건 발생하고 실제 공격을 놓친다면 많은 탐지 건수는 큰 의미가 없다.
- 실제 공격 탐지 여부
- 탐지까지 걸린 시간
- 분석과 판단에 걸린 시간
- 대응까지 걸린 시간
- 반복되는 오탐 비율
- 중요 자산의 로그 수집 범위
- 사고 이후 탐지 규칙 개선 여부
목표는 모든 이벤트를 많이 탐지하는 것이 아니라 위험한 이벤트를 가능한 한 빠르고 정확하게 발견하고 대응하는 것이다.
SOC의 핵심은 이벤트를 사고 대응으로 연결하는 과정이다
보안관제센터는 수많은 로그를 보는 모니터링 조직에 그치지 않는다.
각종 시스템에서 발생하는 이벤트를 수집하고 이상징후를 탐지한 뒤, 그 경보가 실제 공격인지 분석하고 필요할 경우 대응 조직으로 연결한다.
로그 수집 → 이벤트 분석 → 탐지 규칙 적용 → 경보 발생 → Triage → 정탐·오탐 판단 → 공격 범위 조사 → 사고 등급 결정 → 에스컬레이션 → 차단·격리·복구 → 사후 분석 → 탐지 규칙 개선
이 과정에서 SIEM, EDR, 방화벽과 같은 기술은 중요한 도구가 된다.
하지만 SOC의 성숙도를 결정하는 것은 솔루션 자체만이 아니다.
적절한 로그를 확보하고, 실제 위험을 판단할 수 있는 분석 기준을 만들며, 사고 발생 시 누가 어떤 조치를 수행할 것인지 명확하게 연결하는 운영 체계가 함께 갖춰져야 한다.
보안관제의 본질은 많은 이벤트를 보는 것이 아니라 수많은 이벤트 가운데 기업에 실제 영향을 줄 수 있는 위협을 찾아 탐지에서 대응까지 연결하는 것이라고 볼 수 있다.