48. 여러 보안 솔루션을 한 번에 운영해 보면서 느낀 ‘기본기’의 중요성

이전에 보안관제와 정보보안 담당자로 일하면서
여러 장비와 솔루션을 동시에 다뤄본 적이 있다.

방화벽, IPS, WAF, DLP, NAC, EDR,
그리고 SIEM과 NMS까지 한 화면 안에서 돌아가는 환경이었다.

제품 이름은 다르지만,
시간이 지나면서 공통적으로 느낀 건
결국 “기본기가 잡힌 구조인지”가
장비 스펙보다 훨씬 중요하다는 점이었다.

장비 종류보다 “어디를 막고, 어디를 보려고 하는지”가 먼저

솔루션 이름부터 나열하다 보면
환경이 굉장히 든든해 보인다.

하지만 실제로 이벤트를 분석해 보면
가장 먼저 확인하게 되는 건 이런 것들이다.

• 내부망과 외부망이 어떻게 나뉘어 있는지
• 어떤 구간에 어떤 장비가 위치해 있는지
• 그 장비를 통과하는 트래픽이
  실제로 무엇인지

구조가 애매하면,
좋은 장비를 써도
어디까지 막고 보는지 자신 있게 말하기 어렵다.

그래서 나중에는
새 장비를 도입했다는 말보다,

“이 구간에 들어오는 건 이런 종류의 트래픽이고,
이 장비는 여기서 이 역할을 맡는다”

라는 문장을 먼저 정리해 보는 습관이 생겼다.

SIEM과 NMS는 “화려한 대시보드”보다 “운영 루틴”이 먼저

SIEM과 NMS를 같이 운영해 보면
대시보드는 금방 채울 수 있다.

문제는 그 다음이다.

• 어떤 알람을 누가, 언제, 어떻게 확인하는지
• 장애나 공격 징후를 발견했을 때
  어디까지 자체 조치하고, 언제 누구에게 넘기는지
• 주간·월간 보고서에
  어떤 지표를 추려서 올릴지

이 부분이 정리가 안 돼 있으면
아무리 화면이 좋아도
“보안이 잘 된다”고 말하기가 어렵다.

실제로는

• 요일·시간대별 점검 루틴
• 특정 심각도 이상 이벤트에 대한 대응 플로우
• 반복되는 오탐에 대한 공유와 튜닝

같은 것들이 쌓이면서
조직의 보안 수준이 천천히 올라가는 것 같다.

DLP·NAC·EDR은 “정책을 얼마나 현실적으로 가져갔는지”가 관건

DLP, NAC, EDR 같은 솔루션도
이름만 보면 굉장히 강력해 보이지만,
실제 운영에서는 “정책 강도”가 항상 고민이다.

너무 강하게 잡으면
업무 불편과 민원이 폭발하고,
너무 느슨하면
솔루션이 있어도 의미가 약해진다.

그래서 개인적으로는
이런 순서를 선호하게 됐다.

• 첫 단계는 “가시성 확보”
  → 어디에서 어떤 행위가 발생하는지 보는 용도
• 두 번째는 “명백히 위험한 행위 차단”
  → 예를 들어, 악성코드 탐지, 외부로의 대량 반출 등
• 세 번째는 “업무와 충돌이 적은 범위부터 규제 강화”
  → 반복적으로 문제가 되는 패턴부터 하나씩 좁혀가기

이렇게 가져가면
현업과의 충돌을 줄이면서도
정책 강도를 점진적으로 올릴 여지가 생긴다.

인프라 보안 경험이 지금 개인정보 영향평가에 주는 도움

지금은 개인정보 영향평가 업무를 하고 있지만,
예전에 보안관제와 인프라 보안을 했던 경험 덕분에

• 망 구조도나 장비 구성이 나오면
  대략 어떤 이벤트가 어디서 나올지
• 암호화, 접근통제, 로그 관련 설계를 보면
  실제 운영에서 어떤 문제가 생길지

조금 더 구체적으로 상상할 수 있게 된 것 같다.

그래서 평가 문서를 쓸 때도
가능하면 “장비 유무”만 적기보다는,

“이 구조라면 이런 유형의 공격·오류가 많이 발생할 수 있고,
그걸 잡기 위해 이런 보완이 필요하다”

라는 식으로,
실제로 화면을 본다는 느낌으로 적어보려고 한다.

마무리

여러 보안 솔루션을 동시에 운영해 본 경험을 돌이켜보면,

• 장비 이름보다
  “어디를 막고, 어디를 보느냐”라는 구조가 먼저이고
• SIEM/NMS는 대시보드보다
  운영 루틴과 대응 플로우가 더 중요하고
• DLP/NAC/EDR은
  현실적인 정책 강도와 단계적 적용이 핵심이고
• 이런 인프라 보안 경험이
  지금 하는 개인정보 영향평가에서도
  설계의 “현실성”을 체크하는 데 도움을 준다는 점

이 네 가지가 크게 남는다.

앞으로도 새로운 솔루션을 볼 때
스펙보다 구조와 운영 방식을 먼저 보는 습관을
계속 유지하고 싶다.