보안 점검 루틴 만들기 (자산관리,자동화,운영)

보안 점검 루틴 만들기 (자산관리,자동화,운영)

 

공격 표면 관리(ASM)는 “도구를 도입하면 끝”이 아니라, 자산을 정의하고 연결해 매일 반복적으로 리뷰하는 운영입니다. PDF는 “매일 아침 시작되는 보안 리뷰(DSR)”라는 생활감 있는 장면으로 ASM을 살림처럼 설명하고, 자산 범위를 서버·도메인·포트·서비스에서 모바일 앱까지 넓혀 현실성을 확보합니다. 다만 실무자가 그대로 적용하려면 정량 지표, 선택 근거, 오탐·운영 비용, 스캔 윤리 같은 실행 정보가 더 필요합니다.

DSR로 ‘매일 굴러가는’ ASM을 만드는 법

이 글의 출발점은 “매일 아침 시작되는 보안 리뷰, DSR(Daily Security Review)”입니다. PDF 2페이지는 DSR을 단순 회의가 아니라 보안 운영의 리듬으로 제시합니다. 보안팀이 하루를 시작하며 “어제 새로 드러난 노출이 무엇인지”, “오늘 먼저 처리해야 할 리스크가 무엇인지”를 동일한 형식으로 확인하는 흐름입니다. 이런 루틴은 화려한 스캐너보다 강합니다. 이유는 간단합니다. 공격 표면은 하루 단위로 변하고, 한 번의 큰 프로젝트보다 “반복되는 작은 의사결정”이 실제 리스크를 줄이기 때문입니다.

DSR의 장점은 ‘책임을 배분’할 수 있다는 점입니다. PDF는 자산이 여러 팀에 걸쳐 있고(7~8p), 운영조직이 함께 굴려야 한다는 현실을 정면으로 다룹니다. DSR이 없으면 보안팀이 모든 노출을 “중앙 처리”하려다 과부하가 나고, 결국 중요한 건 놓치게 됩니다. 반대로 DSR을 운영하면 “누가 소유자이고, 누구에게 티켓이 가고, 언제까지 확인하는지”를 매일 작은 단위로 정리할 수 있습니다. 이때 핵심은 회의 시간을 줄이는 것이 아니라, DSR의 입력과 출력을 고정하는 것입니다.

저는 DSR을 설계할 때 다음 4가지를 최소 규격으로 권합니다. 첫째, 입력은 ‘변화’ 중심이어야 합니다. 신규 자산(새 도메인, 새 포트, 새 서비스), 기존 자산의 구성 변경(인증 우회 가능, 헤더 변화, TLS 설정 변화), 스캔 결과의 급격한 악화 같은 변화가 우선입니다. 둘째, 출력은 ‘행동’이어야 합니다. 대시보드 조회로 끝나면 DSR이 습관으로 굳지 않습니다. 티켓 발행, 담당자 지정, 재스캔 예약, 스코프 조정 같은 액션이 남아야 합니다. 셋째, 우선순위는 “심각도×노출 가능성×확산 위험”으로 단순화해야 합니다. 복잡한 점수는 회의 시간을 늘립니다. 넷째, 매일 지표를 1~2개만 보아야 합니다. 예를 들어 “신규 노출 탐지 리드타임”과 “DSR 자동화 비율”처럼 운영의 건강도를 보여주는 지표면 충분합니다.

사용자 총평에서 지적한 정량이 바로 여기서 힘을 발휘합니다. DSR은 문화 소개로도 훌륭하지만, 숫자 2개가 붙는 순간 운영 체계로 바뀝니다. 공개 가능한 범위 내에서 다음 중 1~2개만 있어도 설득력이 급상승합니다. “자산 커버리지(자산 유형별 등록률)”, “신규 노출 탐지까지 평균 시간”, “DSR 처리량(하루 처리 티켓 수)과 자동화 비율”, “노출 MTTR(평균 해결 시간) 변화” 같은 지표입니다. 숫자가 부담이라면 “전후 개선 방향”만 제시해도 됩니다. DSR의 목적은 ‘완벽한 측정’이 아니라 ‘일관된 반복’이기 때문입니다.

또 하나 중요한 보완은 약어 진입장벽입니다. PDF는 ASM/DSR/VF 같은 약어를 비교적 자연스럽게 사용합니다(2~4p, 4p의 VF 맥락). 따라서 섹션 시작마다 “이번 절에서 얻어갈 것 1줄”과 “용어 박스 2줄”을 넣으면, 보안팀뿐 아니라 플랫폼팀/PM도 더 쉽게 따라옵니다. “DSR은 매일 반복되는 보안 운영 루틴입니다” 같은 한 문장이 생각보다 큰 차이를 만듭니다.

자산을 정의해야 ‘공격 표면’이 숫자가 됩니다

ASM에서 가장 어려운 질문은 “우리 자산이 무엇입니까”입니다. PDF 3~4페이지는 자산의 범위를 넓게 잡습니다. 서버/도메인/포트/서비스는 물론이고 모바일 앱까지 포함합니다. 그리고 자산을 단순 목록으로 끝내지 않고, “정의→연결”해야 공격 표면이 보인다고 강조합니다. 3페이지에는 자산 타입과 예시가 정리되어 있고, 여러 소스에서 자산을 수집하는 방식(테이블/예시)과 자산 간 관계를 나타내는 그림이 제시됩니다. 4페이지에는 자산 관계가 얽혀 있는 그래프 형태의 도식이 등장하며, “관계가 있어야 영향 범위를 판단할 수 있다”는 메시지가 강화됩니다.

실무에서 자산 정의가 실패하는 흔한 이유는 ‘경계가 흐리기 때문’입니다. 예를 들어 도메인을 자산으로 보면 쉬워 보이지만, 실제 서비스는 서브도메인, CDN, 임시 테스트 도메인, 캠페인 랜딩 페이지 같은 변종이 계속 생깁니다. 포트를 자산으로 보면 명확해 보이지만, 동일 포트라도 인증 여부, 내부망 노출 여부, WAF 뒤에 있는지 여부에 따라 리스크가 달라집니다. 모바일 앱은 더 복잡합니다. 앱 번들, 딥링크, API 엔드포인트, 서드파티 SDK까지 한 번에 엮이기 때문입니다. 따라서 자산은 “한 줄 정의 + 필수 속성 5개”로 표준화되어야 합니다. 예를 들어 자산 ID, 타입, 소유팀, 환경(Prod/Staging), 노출 경로(인터넷/내부/VPN), 마지막 확인 시각 같은 속성이 최소입니다.

자산을 ‘연결’하는 단계가 더 중요합니다. PDF 3페이지의 “Asset #1~#3” 그림은 HTTP/HTTPS 같은 프로토콜과 서비스 스택(예: nginx, echo 등)이 자산 위에 얹히는 모습을 보여주며, 단일 자산이 아니라 “자산+서비스” 단위로 공격 표면을 이해하게 만듭니다. 이런 연결이 있어야 “한 취약점이 어디까지 번지는지”를 말할 수 있습니다. 예를 들어 특정 도메인의 TLS 설정 문제가 발견되었을 때, 그것이 어떤 서비스 스택과 연결되어 있고, 어떤 모바일 앱 버전이 이를 호출하는지까지 이어지면 우선순위가 달라집니다.

여기서 실무자가 가장 원하는 것은 ‘한 장짜리 운영 표준’입니다. 아래 표는 PDF의 자산 정의/연결 메시지를 운영 규격으로 바꾼 예시입니다. 조직에 맞게 열을 바꾸어도 되지만, “소유·갱신·관측”은 반드시 남기는 것이 좋습니다.

자산 타입	필수 속성(운영 규격)	갱신 주기/책임
Domain	소유팀, 환경, DNS/서브도메인 범위, 인증/노출 경로	주 1회, 서비스 오너
Service/Port	프로토콜, 인증 유무, 공개 범위, WAF/CDN 경유 여부	일 1회, 플랫폼/보안 공동
Mobile App	패키지/버전, 딥링크, 호출 API, SDK/서드파티	릴리즈마다, 앱 오너

이 표가 있으면 “자산이 많아 수동 관리가 불가능하다”는 PDF의 비유(5p 차량 더미)가 단순한 공감이 아니라 운영 설계로 연결됩니다. 즉, 자산이 많을수록 ‘정의의 표준화’가 먼저이고, 그 다음이 자동 스캔입니다.

협업이 없으면 ASM은 ‘보안팀의 취미’로 끝납니다

PDF의 좋은 점은 사람/조직 문제를 피하지 않는다는 점입니다. 7~8페이지는 여러 팀의 자산을 모으고 갱신하는 과정이 얼마나 현실적으로 어려운지, 그리고 왜 협업이 ASM의 핵심인지 보여줍니다. “누가 무엇을 언제 업데이트해야 하는지”, “새 자산이 생겼는데 왜 인벤토리에 안 들어왔는지”, “서비스가 바뀌었는데 스캐너는 여전히 옛 정보를 물고 있는지” 같은 문제는 기술만으로 해결되지 않습니다.

협업을 운영으로 만들려면 원칙이 먼저입니다. 저는 ‘소유(Ownership)–책임(Accountability)–갱신(Update)’ 3가지를 문장으로 박아두는 것을 권합니다. 예를 들어 “자산 소유자는 서비스 오너입니다”, “보안팀은 탐지와 우선순위화를 담당합니다”, “갱신은 릴리즈 이벤트 또는 주기적 체크로 자동화합니다” 같은 형태입니다. PDF가 협업 파트를 더 단단하게 만들려면, 이 원칙을 먼저 제시한 다음, 누가 어떤 채널로(티켓, 슬랙, 대시보드) 어떤 이벤트(신규 자산 발견, 위험도 급상승, 스캔 실패)에서 행동하는지를 정리하는 편이 좋습니다.

여기서 놓치기 쉬운 것이 ‘오탐과 운영 비용’입니다. ASM은 자산을 넓게 잡을수록 오탐이 늘어납니다. 가짜 자산(만료 도메인, 임시 테스트 서버), 가짜 노출(캡처 오탐, 스캐너 파서 오류), 정책상 스캔하면 안 되는 영역(타사 운영 페이지, 파트너 인프라)이 섞이면 협업 비용이 폭증합니다. 그래서 협업 섹션에는 반드시 “오탐 처리 규칙”이 포함되어야 합니다. 예를 들어 (1) 오탐 라벨 체계, (2) 재현 조건(스크린샷/VF 근거, 헤더/응답 코드), (3) 재스캔 정책, (4) 스코프 제외 원칙 같은 항목입니다. 이 규칙이 없으면 DSR이 ‘오탐 처리 회의’로 변질되기 쉽습니다.

또한 스캔 부하와 윤리·정책도 운영의 핵심입니다. 공격 표면을 보기 위해 스캔을 확장하면, 내부 서비스에 부하를 줄 수 있고, 크롤링이 예기치 않은 트래픽을 만들 수 있습니다. 따라서 스케줄링과 레이트 리밋, 허용 스코프, 예외 등록(화이트리스트/블랙리스트)이 필수입니다. PDF가 “ASM은 살림”이라고 말한 맥락은 결국 여기로 수렴합니다. 살림은 매일 굴러가야 하고, 굴러가려면 비용이 통제되어야 합니다.

흥미롭게도 PDF 9페이지는 이런 협업 비용을 낮추기 위한 장치로 “AI 어시스턴트”를 소개합니다. “이 자산이 왜 위험한지”, “어느 팀이 소유자인지”, “DSR에서 어떤 액션이 필요한지”를 도와주는 방향입니다. 보안상 민감해 구체 로그를 다 공개할 수 없다면, 가명/축약 형태의 예시 1개만 넣어도 임팩트가 커집니다. 예를 들어 “질문: 이 도메인의 443 포트 노출이 왜 뜬 것입니까 / 근거: 신규 서브도메인 발견+인증 없는 엔드포인트 응답 / 추천 액션: 소유팀 확인→인증 적용→재스캔 예약” 같은 3단 구성입니다. 이렇게 쓰면 AI는 ‘멋진 기능’이 아니라 ‘협업 마찰을 줄이는 도구’로 이해됩니다.

자산 수집 아키텍처를 운영 언어로 다시 읽는 방법

PDF 6페이지의 Scheduler–Queue–Worker 구조는 매우 좋은 한 장짜리 설계입니다. 스캐닝/수집이 늘어나면 결국 병렬화와 재시도가 필요하고, 이를 위해 작업을 큐로 분리해 워커로 확장하는 구조가 자연스럽습니다. 다만 그림만으로는 “무엇이 오가고, 어디서 정규화되고, 어디서 중복 제거되는지”가 독자에 따라 흐릿할 수 있습니다.

그래서 저는 이 그림 옆에 반드시 다음 3줄을 붙이는 것을 권합니다. 첫째, 입력입니다. 입력은 자산 소스(CMDB, DNS, 클라우드 계정, 앱 레포, 네트워크 스캔 결과 등)와 스캔 대상 목록입니다. 둘째, 처리입니다. 처리에는 스캔(포트/HTTP/스크린샷 기반 VF 등), 정규화(자산 ID 통일), 중복 제거(동일 도메인/동일 서비스 병합), 신뢰도 계산(오탐 필터) 같은 단계가 들어갑니다. 셋째, 출력입니다. 출력은 티켓/알림(DSR로 들어갈 항목), 대시보드(커버리지/추세), 그리고 예외 목록(스코프/정책)입니다.

이 3줄이 붙으면, “왜 이 선택인가”에 대한 근거도 자연스럽게 설명됩니다. 상용 ASM을 쓰면 편할 수 있지만, 조직의 자산 소스와 협업 흐름(티켓/권한/스코프)이 다르기 때문에 내부 최적화가 필요할 수 있습니다. 반대로 자체 구축을 하면 유연하지만 운영 비용이 커지므로, 큐 기반 확장 구조와 DSR 프로세스가 함께 있어야 지속 가능해집니다. 결국 선택의 기준은 “기능 목록”이 아니라 “조직의 변경 속도와 소유 구조”입니다.

마지막으로, ‘실패/한계’를 문서에 넣어야 신뢰가 생깁니다. 예를 들어 스캐너는 결국 완벽할 수 없고, 자산 그래프는 항상 최신이 아닙니다. 그렇다면 운영 원칙은 “완벽한 발견”이 아니라 “빠른 발견과 빠른 복구”가 되어야 합니다. 여기서 정량 지표가 다시 중요해집니다. 커버리지 100%를 약속하기보다, 신규 노출 리드타임과 MTTR을 줄이는 방향이 실무적으로 더 건강합니다. PDF가 문화 소개를 넘어 기술 글로 더 깊어지려면, 공개 가능한 범위에서 이 운영 철학을 숫자 1~2개로 묶어주는 것이 가장 효과적입니다.

이 글은 ASM을 도구가 아니라 “매일 반복되는 DSR 프로세스”로 풀어 운영조직이 이해하기 쉽게 만들었습니다. 다만 사례 소개를 넘어 실행 가능한 기술 문서가 되려면 자산 커버리지·탐지 리드타임·DSR 자동화 비율 같은 정량, 오탐/스캔 부하/스코프 윤리 같은 부작용, 그리고 선택 근거(대안 대비)를 보강해야 합니다.

자주 묻는 질문 (FAQ)

Q. ASM과 취약점 진단은 무엇이 다릅니까 A. ASM은 특정 시스템을 한 번 점검하는 진단이 아니라, 자산을 정의·연결·갱신하면서 공격 표면을 지속적으로 추적하는 운영입니다. DSR 같은 반복 루틴이 붙어야 효과가 누적됩니다.

Q. DSR을 도입하면 무엇부터 좋아집니까
A. 신규 노출을 “늦게 크게” 발견하는 대신 “빨리 작게” 발견하게 되는 경향이 큽니다. 이를 확인하려면 신규 노출 탐지 리드타임, DSR 처리량, 자동화 비율 같은 지표를 1~2개라도 고정해 보는 것이 좋습니다.

Q. ASM에서 가장 흔한 실패 원인은 무엇입니까
A. 자산 소유가 불명확해 협업이 무너지는 경우와, 오탐/스캔 부하를 통제하지 못해 운영 비용이 폭증하는 경우입니다. 소유·갱신 주기·스코프·오탐 처리 규칙을 먼저 표준화하는 것이 안전합니다.

Q. AI 어시스턴트는 어디에 가장 도움이 됩니까
A. DSR에서 “이 항목이 왜 위험한지”와 “누가 소유자인지”를 빠르게 연결해 주는 데 도움이 됩니다. 다만 보안상 민감한 정보가 섞일 수 있으므로, 근거 제시 방식과 접근 권한 정책을 먼저 설계하는 것이 중요합니다.

 

[출처]
https://tech.kakao.com/posts/798