Cisco ISE 권한 상승 취약점과 Zero Trust NAC 재설계

Cisco ISE CVE-2026-20180·20186·20147의 RBAC 경계 문제와 패치, 관리자 접근 통제, Zero Trust NAC 전환 방안을 다룬다.

2026-08-14 · 최초 발행 2026-08-02

읽기전용 관리자 계정이 OS 경계에 닿는 문제

2026년 4월 공개·패치된 Cisco ISE(Identity Services Engine)의 CVE-2026-20180, CVE-2026-20186, CVE-2026-20147은 모두 CVSS 9.9로 분류됐다. 읽기전용 관리자 계정만으로 기반 OS에서 root 권한 명령 실행으로 이어질 수 있다는 점에서, 단순한 개별 버그보다 관리자 권한 모델의 경계가 어디까지 이어지는지를 다시 점검하게 한다.

세 취약점은 경로가 다르지만 공통적으로 애플리케이션 계층의 RBAC가 OS 계층 실행 컨텍스트까지 일관되게 적용되지 않는다는 문제를 드러낸다.

CVE CVSS 공격 조건 취약 경로 영향
CVE-2026-20180 9.9 읽기전용 Admin 인증 Admin GUI REST API 입력 검증 부재 OS 임의 명령 실행 → root 권한 상승
CVE-2026-20186 9.9 읽기전용 Admin 인증 CLI 권한 검증 로직 우회 Privileged exec mode 진입
CVE-2026-20147 9.9 유효한 Admin 인증 노드 간 통신 역직렬화 취약점 클러스터 전체 RCE

이 세 건은 인증된 공격자를 전제로 한다. 하지만 읽기전용 관리자 계정은 모니터링 팀, 헬프데스크, 감사 담당자에게 넓게 배포되는 경우가 많다. 내부자 위협이나 계정 탈취가 발생했을 때 공격 가능성을 낮게 볼 수 없는 이유다.

Cisco ISE 버전 분류ISE 3.3 이하ISE 3.4ISE 3.5CVE-2026-20180CVE-2026-20186CVE-2026-20147(EoS: 패치 없음, 즉시업그레이드 필수)CVE-2026-20180CVE-2026-20186CVE-2026-20147 3.4 Patch 6으로 해결CVE-2026-20147(CVE-20180/20186은3.5에서 미영향) 3.5 Patch 3으로 해결즉시 마이그레이션 권고3.4 Patch 6 적용3.5 Patch 3 적용

ISE 3.5는 CVE-2026-20180과 CVE-2026-20186의 영향을 받지 않는다. ISE 3.5 개발 과정에서 Admin GUI API 레이어 일부가 리팩토링됐기 때문이다. 반면 역직렬화 취약점인 CVE-2026-20147은 3.5에도 남아 있다. ISE 3.3 이하는 공식 보안 패치가 제공되지 않으므로 3.4 또는 3.5로의 업그레이드 계획이 필요하다.

API와 OS 사이에서 끊어진 권한 검증

CVE-2026-20180·20186은 애플리케이션 권한과 OS 실행 권한이 분리되지 않은 구조에서 발생한다. ISE Admin GUI는 OS 명령을 래핑하는 REST API를 사용한다. 읽기전용 관리자는 API 응답을 조회할 수 있지만, OS 명령을 호출하는 래퍼 함수에 입력값 검증이 빠진 경우 조회 권한의 범위를 넘어설 수 있다.

조작된 HTTP 요청파라미터에 OS 명령 삽입입력 검증 없음(CVE-2026-20180)직접 OS 명령 실행user-level 실행로컬 권한 상승 기법(SUID, sudomisconfiguration)읽기전용 Admin(공격자)ISE Admin GUIREST APIOS Command Wrapper함수Linux OS(ISE 기반)명령 출력 반환root 권한 획득NAC 정책 전체 변조백도어 설치자격증명 탈취

CVE-2026-20180의 경우 진단 API가 네트워크 연결성 확인을 위해 ping, traceroute, nslookup 같은 OS 유틸리티를 호출한다. 읽기전용 관리자가 접근 가능한 엔드포인트에서 입력값 검증이 누락되면 OS Command Injection이 성립한다.

POST /api/v1/diagnostics/network-check
Authorization: Bearer <read-only-admin-token>
{
  "target": "8.8.8.8; id; whoami; cat /etc/shadow"
}

CVE-2026-20186은 IOS 스타일 명령 체계를 쓰는 ISE CLI의 권한 검증 우회와 관련된다. 읽기전용 계정은 show 계열 명령만 허용돼야 하지만, 특정 파이프라인 조합에서 검증 코드 경로가 누락됐다.

ise# show running-config | exec /bin/bash
# (privileged shell 획득)

CVE-2026-20147은 다중 노드 배포의 PAN(Primary Admin Node)과 PSN(Policy Service Node) 통신에서 Java 직렬화 객체를 사용하는 구조와 연결된다. 인증된 공격자가 Gadget Chain 기법으로 조작한 직렬화 페이로드를 PSN에 전송하면 해당 노드에서 임의 코드가 실행될 수 있다. 이후 클러스터 내부 신뢰 관계를 악용하면 NAC 인프라 전체로 영향이 확대될 수 있다.

역할 이름이 아니라 실제 허용 경로를 나누기

Cisco ISE의 기본 RBAC 모델은 5~6개의 미리 정의된 역할(Predefined Role)을 중심으로 구성되며, 기능 단위 권한 분리는 제한적이다. 이번 사례에서 문제였던 것은 읽기전용이라는 이름이 아니라 그 역할에 실제로 연결된 API, CLI, OS 실행 경로였다.

현행 문제 개선 방향
읽기전용 역할도 진단 API 엔드포인트 접근 가능 역할별 API 엔드포인트 화이트리스트 적용
CLI 접근 권한이 역할과 독립적으로 부여됨 CLI 접근 자체를 별도 권한 그룹으로 분리
노드 간 통신 API에 최소 권한 검증 없음 서비스 계정 인증서 기반 상호 TLS 인증 강제
관리자 역할에 2단계 인증 선택 사항 Super Admin 포함 모든 관리자 MFA 필수화

ISE 3.x는 Admin Group으로 커스텀 역할을 만들 수 있다. 하나의 Read-Only Admin 역할에 묶여 있던 권한을 정책 조회, 리포트 조회, 엔드포인트 조회, 감사 조회처럼 업무 기능별로 나누면 불필요한 접근을 줄일 수 있다.

역할 분리 재설계기존 Read-Only Admin(모든 조회 권한 통합)기능별 최소 권한 역할Policy-Viewer정책 조회만 허용API: /api/v1/policy/**진단 API 접근 차단Report-Viewer리포트·로그 조회만 허용API: /api/v1/reports/**CLI 접근 금지Endpoint-Viewer엔드포인트 목록 조회만 허용API: /api/v1/endpoint/**시스템 진단 API 차단Audit-Viewer감사 로그 조회 전용(외부 SIEM 연동 권고) 역할에 MFA 필수세션 타임아웃 15분IP 소스 제한

ISE 3.4/3.5 기준으로 커스텀 Admin Group을 구성하는 절차는 다음과 같다.

# ISE Admin GUI > Administration > System > Admin Access > Administrators > Admin Groups
# 1. Add Group → 이름: "Policy-Viewer-Custom"
# 2. Permissions 탭 → Menu Access: 정책 관련 메뉴만 체크
# 3. Data Access: ALL_RECORDS → SELECTED_RECORDS로 제한
# 4. Admin GUI에서 API 접근 필터링은 추가 커스텀 설정 필요

# ISE CLI에서 RBAC 검증
ise# show admin-users
ise# show admin-groups

기본 RBAC만으로 API 레벨의 세분화가 어렵다면 ISE 앞단에 API Gateway 또는 역방향 프록시를 배치하고, 역할별 허용 API 경로를 화이트리스트로 통제하는 방안을 검토할 수 있다.

서비스 중단을 고려한 패치 순서

2026년 4월 15일 릴리스된 Cisco 공식 패치 정보는 다음과 같다.

Cisco 공식 패치 정보 (2026년 4월 15일 릴리스):
- ISE 3.4 → 3.4 Patch 6 적용 (CVE-2026-20180, 20186, 20147 해결)
- ISE 3.5 → 3.5 Patch 3 적용 (CVE-2026-20147 해결)
- ISE 3.3 이하 → 공식 패치 없음, 3.4/3.5로 업그레이드 권고
- ISE-PIC → 동일 취약점 적용, ISE-PIC 전용 패치 확인 필요

패치 순서는 ISE 노드 역할(PAN/MnT/PSN)과 네트워크 서비스 의존성을 함께 반영해야 한다. PSN이 재시작되는 동안 해당 노드에 할당된 네트워크 디바이스의 인증 처리가 중단될 수 있기 때문이다.

단계 대상 조치 검증
1단계 (즉시) 읽기전용 Admin 계정 CLI 접근 비활성화, API 접근 IP 제한 계정 목록 감사
2단계 (24시간 내) MnT 노드 (Monitoring) 3.4P6 / 3.5P3 패치 적용 로그 수집 기능 검증
3단계 (48시간 내) Secondary PAN 패치 적용 후 Primary ↔ Secondary 역할 교체 관리 기능 검증
4단계 (72시간 내) Primary PAN 패치 적용, 역할 재교체 전체 정책 동기화 검증
5단계 (1주 내) PSN 노드 (순차) 트래픽 분산 후 순차 패치 인증 처리 연속성 검증

패치를 끝내기 전에는 관리자 접근면을 먼저 축소해야 한다. 읽기전용 계정을 일시 비활성화하거나 허용 소스 IP를 제한할 수 있다.

ISE Admin GUI > Administration > System > Admin Access > Authentication > Allowed Protocols
→ Admin IP Address Range 설정: 관리자 워크스테이션 IP만 허용

ISE 관리 인터페이스의 기본 포트 443에는 SOC와 네트워크 관리 VLAN만 접근하도록 ACL을 적용한다.

# ISE 관리 인터페이스(기본 포트 443)에 접근 가능한 소스 IP를 
# 보안 관제 센터(SOC), 네트워크 관리 VLAN만으로 제한
ip access-list extended ISE-MGMT-ACL
  permit tcp 10.0.100.0 0.0.0.255 host 192.168.1.10 eq 443
  deny   tcp any host 192.168.1.10 eq 443
  permit ip any any

CLI SSH 접근도 별도로 제한한다.

# ISE CLI에서 SSH 허용 소스 제한
ise# configure terminal
ise(config)# ip access-list standard SSH-ALLOWED
ise(config-std-nacl)# permit 10.0.100.0 0.0.0.255
ise(config-std-nacl)# deny any log
ise(config)# line vty 0 4
ise(config-line)# access-class SSH-ALLOWED in

관리 경로를 운영망에서 분리하는 NAC 설계

이번 사례는 경계 신뢰 모델(Perimeter Trust Model)의 한계도 보여준다. 내부 관리자라는 이유로 폭넓은 시스템 접근을 허용하면, 계정 하나의 침해가 NAC 관리면 전체로 번질 수 있다.

Zero Trust NAC는 관리자 요청도 매번 검증하고, 필요한 업무 범위만 권한으로 부여하며, 내부 침해를 전제로 세션 컨텍스트를 지속 검증하는 구조를 지향한다.

관리자 워크스테이션 (격리 VLAN)관리 네트워크 (Out-of-Band Management)운영 네트워크 (Production)MFA + 인증서 인증SSL VPNMFA + 역할 제한감사 로깅세션 녹화정책 동기화(암호화 채널)RADIUS/TACACS+SIEM 연동PSN Node (인증 처리)PSN Node (인증 처리)네트워크 디바이스(스위치, AP, VPN GW)Primary Admin Node(PAN)Monitoring Node(MnT)Bastion Host(점프 서버)SOC보안 관제Super Admin(MFA 인증)Read-Only Admin(최소 권한 재설계)

이 구조에서 Admin GUI와 CLI는 운영 네트워크에서 직접 접근할 수 없다. 관리자는 Bastion Host를 거치고, 해당 구간의 세션은 감사 로그와 세션 녹화 대상으로 남는다. PSN은 운영망에서 RADIUS/TACACS+ 트래픽을 처리하고, 관리 접근은 별도의 Out-of-Band 채널로만 허용한다.

전환은 패치와 임시 완화부터 시작해 권한 모델, 관리망, 지속 검증 체계로 이어질 수 있다.

  • Phase 1 (0~3개월): CVE-2026-20180/20186/20147 패치 적용, 읽기전용 Admin 계정 감사와 불필요 계정 비활성화, Admin GUI 소스 IP 화이트리스트, 모든 Admin 계정 MFA 강제화
  • Phase 2 (3~6개월): Read-Only Admin을 Policy-Viewer, Report-Viewer, Endpoint-Viewer, Audit-Viewer로 세분화하고 Bastion Host 및 세션 감사 로깅을 구성, 관리 인터페이스를 Out-of-Band 관리 VLAN으로 이전
  • Phase 3 (6~12개월): 역할별 API 화이트리스트를 위한 API Gateway, PAM 솔루션, ISE 노드 간 mTLS, UEBA 연동 적용
  • Phase 4 (12~24개월): Cisco ISE와 TrustSec SGT(Security Group Tag) 연동, TACACS+ 중앙화와 읽기전용 계정 재설계, 분기별 RBAC 감사 자동화, 취약점 패치 SLA(72시간 내 적용) 모니터링 자동화

행위 로그에서 찾는 악용 징후

CVE-2026-20180, CVE-2026-20186, CVE-2026-20147은 읽기전용 Admin 계정의 진단 API 대량 호출, CLI에서 show 외 명령을 시도한 오류 로그, ISE 노드의 비정상 외부 연결, 로그인 직후의 다수 API 엔드포인트 호출, root 프로세스 생성 같은 행위로 탐지할 수 있다.

다음은 Splunk SIEM 룰 예시다.

# 탐지 룰 1: 읽기전용 Admin의 진단 API 비정상 호출
index=cisco_ise sourcetype=ise-syslog
| search component="admin-audit" message="*diagnostic*" OR message="*network-check*"
| eval user_role=mvindex(split(msg, "|"), 3)
| where user_role="ReadOnly"
| stats count by user, src_ip, _time
| where count > 5
| alert "ISE Read-Only Admin Diagnostic API Abuse"

# 탐지 룰 2: ISE 노드 OS 레벨 명령 실행 탐지
index=cisco_ise sourcetype=ise-syslog
| search component="ise-runtime" severity="ERROR"
| search message="*command*" OR message="*exec*" OR message="*shell*"
| stats count by hostname, _time
| where count > 3
| alert "ISE Potential OS Command Execution"

# 탐지 룰 3: 관리자 세션 후 다중 API 호출 (공격자 탐색)
index=cisco_ise sourcetype=ise-access-log
| where user_type="ADMIN"
| bucket _time span=5m
| stats dc(api_endpoint) as unique_endpoints by user, _time
| where unique_endpoints > 20
| alert "ISE Admin Anomalous API Enumeration"

NAC 플랫폼별 권한 분리 특성

Cisco ISE, Aruba ClearPass, Microsoft NPS는 RBAC, 관리 인터페이스, OS 계층 분리 방식이 다르다.

비교 항목 Cisco ISE 3.5 Aruba ClearPass 6.12 Microsoft NPS (2025)
RBAC 세분화 중간 (커스텀 역할 제한) 높음 (세분화된 권한 그룹) 높음 (AD 그룹 기반)
관리 인터페이스 분리 낮음 (통합 단일 인터페이스) 중간 (CLI별도 통제) 높음 (Windows 권한 모델)
OS 레이어 격리 이번 CVE로 결함 확인 상대적으로 강함 OS 보안 모델 활용
Zero Trust 통합 Cisco TrustSec 필수 Multi-vendor 강점 Azure AD/Entra ID 연동 시 강함
멀티벤더 지원 제한적 (Cisco 중심) 매우 강함 제한적 (MS 생태계 중심)
운영 복잡도 높음 중간 낮음 (단순 환경 한정)
대규모 엔터프라이즈 매우 강함 강함 소/중규모 적합
CVE 발생 이력 빈번 (2024~2026) 보통 낮음

Cisco 중심 인프라는 ISE를 유지하면서 Zero Trust 재설계를 적용하는 선택지가 있다. 멀티벤더 환경에서는 벤더 중립 정책 엔진을 강점으로 하는 Aruba ClearPass를 검토할 수 있다. Microsoft 중심의 소/중규모 환경은 NPS와 Azure AD 조합을 고려할 수 있으나, 대규모 엔터프라이즈에는 한계가 있다. 클라우드 퍼스트 환경에서는 Cisco ISE Cloud(VM 기반) 또는 Portnox CLEAR(클라우드 네이티브 NAC)를 고려할 수 있다.

패치 공지를 운영 신호로 바꾸기

Cisco 제품 취약점 정보를 수동으로 확인하는 방식은 대응 지연으로 이어질 수 있다. Cisco PSIRT RSS 피드, NVD(National Vulnerability Database) API, CISA KEV(Known Exploited Vulnerabilities)를 연계해 악용이 확인된 취약점을 우선 처리하는 자동화 체계를 구성할 수 있다.

  • Cisco PSIRT RSS 피드: https://tools.cisco.com/security/center/psirt.xml
  • NVD(National Vulnerability Database) API: https://services.nvd.nist.gov/rest/json/cves/2.0
  • CISA KEV(Known Exploited Vulnerabilities): 악용 확인 취약점 우선 처리
# Cisco PSIRT 및 NVD 자동 모니터링 스크립트 예시
import requests
import json
from datetime import datetime, timedelta

NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"
CISCO_PRODUCTS = ["Cisco Identity Services Engine", "Cisco ISE"]

def check_new_cves(days_back=1):
    """최근 N일 내 Cisco ISE 관련 신규 CVE 조회"""
    pub_start = (datetime.utcnow() - timedelta(days=days_back)).strftime(
        "%Y-%m-%dT%H:%M:%S.000"
    )
    params = {
        "keywordSearch": "Cisco ISE",
        "pubStartDate": pub_start,
        "cvssV3Severity": "CRITICAL",
    }
    resp = requests.get(NVD_API, params=params, timeout=30)
    data = resp.json()
    
    critical_cves = []
    for vuln in data.get("vulnerabilities", []):
        cve_id = vuln["cve"]["id"]
        description = vuln["cve"]["descriptions"][0]["value"]
        cvss = vuln["cve"].get("metrics", {}).get("cvssMetricV31", [{}])[0]
        score = cvss.get("cvssData", {}).get("baseScore", 0)
        if score >= 9.0:
            critical_cves.append({
                "cve_id": cve_id,
                "score": score,
                "description": description[:200]
            })
    return critical_cves

# Slack/Teams Webhook으로 알림 전송
def notify_security_team(cves):
    webhook_url = "https://hooks.slack.com/services/YOUR_WEBHOOK"
    if not cves:
        return
    message = f"🚨 Cisco ISE Critical CVE Alert ({len(cves)}건)\n"
    for cve in cves:
        message += f"- {cve['cve_id']} (CVSS: {cve['score']})\n"
    requests.post(webhook_url, json={"text": message})

패치 운영 SLA는 취약점 등급별 인지, 완화, 완료 시간을 명시하는 방식으로 관리할 수 있다.

취약점 등급 CVSS 점수 최대 인지 시간 최대 완화 조치 시간 최대 패치 완료 시간
Critical 9.0~10.0 4시간 24시간 72시간
High 7.0~8.9 24시간 72시간 2주
Medium 4.0~6.9 72시간 1주 1개월
Low 0.1~3.9 1주 1개월 3개월

CVE-2026-20180, CVE-2026-20186, CVE-2026-20147은 CVSS 9.9의 Critical 등급이므로 4시간 내 인지, 24시간 내 임시 완화, 72시간 내 패치 완료 SLA가 적용돼야 했다.

NAC 관리 보안에서 남는 운영 기준

이 사례는 RBAC가 역할 이름을 붙이는 기능만으로 충분하지 않다는 점을 보여준다. 관리자가 호출할 수 있는 API, CLI, 노드 간 통신, OS 실행 컨텍스트까지 같은 최소 권한 원칙으로 연결해야 한다.

ISE 3.4는 Patch 6, ISE 3.5는 Patch 3 적용이 필요하며, ISE 3.3 이하 환경은 업그레이드가 필요하다. 그와 병행해 읽기전용 Admin 역할을 업무별로 분리하고, 관리 인터페이스를 운영망과 격리하며, PAM과 SIEM, 패치 모니터링을 하나의 운영 체계로 묶어야 한다.

Sources

Cisco ISENACRBACZero Trust취약점 관리네트워크 보안