인터넷에 노출된 냉동·설비 제어기를 발견한 공격자는 로그인 화면만 보지 않는다. 기본 계정, 알려진 CGI 경로, 오래된 펌웨어의 취약점, 산업 프로토콜 포트까지 함께 탐색한다. 이때 허니팟은 공격을 막아 주는 방화벽이 아니다. 공격자가 무엇을 찾고 어떤 자격 증명을 시도하며 어떤 공개 공격 경로를 재현하는지 관측하기 위한 센서에 가깝다.
따라서 CTO나 개발 리드가 먼저 내려야 할 결정은 “어떤 장비처럼 보이게 할 것인가”가 아니다. 운영망과 분리된 미끼 시스템에서 수집한 신호를 누가 해석하고, 어떤 조건에서 실제 자산 점검과 대응으로 전환할 것인가를 정할 수 있는지가 도입의 출발점이다.
공개된 냉동 제어기형 허니팟 구현 사례에는 웹 로그인, 제어 대시보드, XML 기반 관리 경로, 선택적 Modbus TCP 서비스를 흉내 내고 로그인 시도·공격 요청·가짜 제어 명령을 기록하는 방식이 포함돼 있다. 이런 기능은 인터넷에서 산업 장비를 탐색하는 행위를 관측하는 데 쓸 수 있다. 다만 실제 장비와 가까운 외형을 만들었다는 사실이 운영 환경에 안전하게 배치됐다는 뜻은 아니다.
도입 판단은 “탐지 가치”보다 “대응 가능성”에서 시작한다
허니팟이 수집하는 이벤트는 대개 세 부류로 나뉜다.
- 로그인 화면이나 관리 경로를 찾는 일반 스캔
- 기본 계정이나 약한 비밀번호를 대입하는 인증 시도
- 알려진 취약점의 요청 형식을 재현하는 공격 시도
세 신호 모두 유용할 수 있지만, 수집 자체가 목표가 되면 운영 부담만 남는다. 예를 들어 특정 제어기 형태를 겨냥한 요청이 관측됐을 때, 조직이 보유한 실제 자산의 노출 여부, 펌웨어 상태, 계정 정책을 확인할 담당자와 절차가 없다면 그 이벤트는 경보 목록에 쌓일 뿐이다.
도입은 다음 질문에 모두 답할 수 있을 때 검토할 만하다.
- 외부에 노출됐거나 노출 가능성이 있는 산업용 IoT 자산의 목록을 책임 있게 확인할 수 있는가.
- 허니팟 이벤트가 들어왔을 때 보안 담당자와 OT 운영 담당자 중 누가 1차 판단을 내리는가.
- 관측된 공격 패턴을 실제 장비의 계정, 펌웨어, 외부 접속 정책 점검으로 연결할 수 있는가.
- 허니팟 자체가 침해돼도 운영 설비, 관리 서버, 자격 증명 저장소로 이동할 수 없게 설계할 수 있는가.
앞의 세 항목이 없으면 허니팟은 정보 수집 도구가 아니라 새로운 인터넷 노출 자산이 될 가능성이 높다.
요구사항 단계에서 먼저 고정할 네 개의 경계
산업용 IoT 허니팟의 요구사항 문서에는 “실제 장비와 유사한 응답을 제공한다”보다 아래 경계를 먼저 적는 편이 안전하다.
1. 네트워크 경계: 운영망으로 가는 길을 만들지 않는다
허니팟이 실제 PLC, 냉동기 제어기, BMS, 원격 유지보수 게이트웨이와 같은 네트워크 구간에 있어야 할 이유는 제한적이다. 인터넷 공격을 관측하려는 목적이라면, 허니팟은 운영망과 별도 구간에 두고 외부에서 허용할 포트만 열어야 한다.
특히 Modbus TCP처럼 산업 장비 탐색에 쓰일 수 있는 서비스를 노출할 때는 더 엄격히 판단해야 한다. 해당 서비스는 공격 관측 범위를 넓힐 수 있지만, 허니팟이 운영망의 제어 트래픽을 중계하거나 실제 장비를 조회하는 구조여서는 안 된다. 요구사항에는 허니팟에서 운영망으로 향하는 연결을 허용하지 않는다는 원칙과, 예외가 생길 경우 승인 주체를 함께 명시하는 편이 좋다.
2. 데이터 경계: 실계정·실설비 데이터는 넣지 않는다
허니팟의 화면, 계정, 설비 상태, 온도값, 제어 버튼은 공격자를 관측하기 위한 가짜 데이터여야 한다. 운영자 편의를 위해 실제 매장명, 실제 설비 목록, 실온도, 실제 유지보수 계정을 가져오는 순간 미끼 시스템은 정보 유출 지점이 된다.
냉동 제어기 펌웨어의 과거 취약점 사례는 이 구분이 왜 필요한지 보여 준다. 특정 펌웨어 버전에서는 인증 없이 파일 경로를 벗어나 민감한 파일을 읽을 수 있었고, 다른 취약점과 결합하면 높은 권한의 명령 실행으로 이어질 수 있었다. 허니팟이 이런 공격을 흉내 내는 요청을 기록하더라도, 읽히거나 실행될 실제 운영 데이터와 실행 환경을 제공해서는 안 된다.
3. 권한 경계: 관측 시스템도 최소 권한으로 운용한다
허니팟은 공격자가 의도적으로 접촉하는 시스템이다. 따라서 배포 편의 때문에 호스트 관리자 권한, 광범위한 클라우드 권한, 운영용 SSH 키, 공유 비밀을 함께 두면 안 된다.
컨테이너로 배포한다면 컨테이너 격리만으로 충분하다고 가정하지 말고, 호스트 파일 접근 범위, 비밀값 주입 방식, 관리 접속 경로를 별도로 검토해야 한다. 한 공개 구현은 소스 IP 기록을 위해 특정 컨테이너 실행 방식이 필요할 수 있음을 언급한다. 이런 구현 조건은 “컨테이너를 쓴다”는 선택보다, 실제 배포 방식이 로그 정확도와 격리 수준에 어떤 영향을 주는지 확인해야 한다는 신호로 읽는 편이 맞다.
4. 책임 경계: 보안팀과 OT팀의 다음 행동을 분리해 적는다
허니팟 이벤트를 받은 사람이 곧바로 생산·매장 설비를 변경해서는 안 된다. 반대로 OT 운영팀이 보안 이벤트의 의미를 전부 해석하기도 어렵다. 따라서 대응 절차는 다음처럼 역할을 나눠 적어야 한다.
| 단계 | 보안 담당 | OT·설비 운영 담당 |
|---|---|---|
| 이벤트 분류 | 스캔, 인증 시도, 취약점 탐색, 제어 명령 시도로 구분 | 관련 장비군과 운영 영향 확인 |
| 자산 대조 | 노출 자산 목록과 외부 접속 경로 확인 | 실제 설치 모델, 펌웨어, 유지보수 방식 확인 |
| 조치 결정 | 계정 정책, 접근 제어, 모니터링 변경 제안 | 점검·패치·현장 작업 가능 시점 판단 |
| 사후 기록 | 공격 지표와 대응 이력 보존 | 설비 변경 결과와 운영 영향 기록 |
이 표의 핵심은 조직도를 만드는 데 있지 않다. 이벤트 하나가 들어왔을 때 “누가 확인하고, 누가 승인하고, 누가 실제 설비를 건드리는가”를 미리 결정하는 데 있다.
구현은 모방 기능보다 관측 경로를 먼저 검증한다
구현 순서는 다음과 같이 잡을 수 있다.
-
관측 목표를 한 문장으로 제한한다.
예를 들어 외부에서 냉동·설비 관리 인터페이스를 찾는 스캔과 인증 시도를 파악하는 데 초점을 둔다. 산업 프로토콜 탐색까지 볼지, 웹 관리 인터페이스만 볼지도 여기서 정한다. -
가짜 서비스 목록을 정한다.
HTTP, HTTPS, 특정 관리 경로, 선택적 산업 프로토콜 중 관측 목표에 필요한 것만 연다. 서비스가 많아질수록 관측 범위는 넓어질 수 있지만, 운영해야 할 공격 표면도 늘어난다. -
로그 스키마를 먼저 합의한다.
최소한 시간, 출발지 정보, 요청 경로, 인증 시도 여부, 탐지된 공격 유형, 가짜 제어 행위 여부를 구분해 남길지 결정한다. 로그가 남아도 담당자가 자산 점검으로 연결할 수 없다면 필요한 필드가 빠진 것이다. -
격리 검증을 기능 검증보다 앞에 둔다.
허니팟에서 운영망 주소로 연결할 수 없는지, 호스트의 민감한 파일이나 배포 비밀을 읽을 수 없는지, 관리용 접속이 외부 노출 포트와 분리됐는지 확인한다. -
공격 재현은 안전한 시험 범위에서 수행한다.
테스트 환경에서 로그인 실패, 가짜 계정 로그인, 알려진 취약점 형태의 요청, 가짜 제어 명령이 각각 다른 이벤트로 기록되는지 확인한다. 이때 검증 대상은 공격 성공 여부가 아니라 기록의 정확성과 운영망 비접근성이다.
운영 전환을 막아야 할 조기 신호
다음 상태라면 외부 공개를 미루는 편이 낫다.
- 이벤트를 검토할 담당자가 정해지지 않았다.
- 허니팟 로그가 운영 자산 목록과 연결되지 않는다.
- 실제 계정, 인증서, 설비 이름, 온도 데이터가 테스트 편의상 포함돼 있다.
- 허니팟 관리 접속과 일반 인터넷 노출 접속이 같은 경로에 섞여 있다.
- 이벤트가 들어왔을 때 계정 점검, 외부 접속 차단, 펌웨어 확인 중 무엇을 할지 결정돼 있지 않다.
- 산업 프로토콜을 열었지만 해당 포트를 관측 목표에 포함한 이유를 설명할 수 없다.
이 항목들은 제품의 기능 부족을 뜻하지 않는다. 조직이 아직 관측 결과를 안전한 운영 행동으로 바꿀 준비가 안 됐다는 뜻에 가깝다.
첫 번째 산출물은 배포 문서가 아니라 대응 시나리오여야 한다
요구사항 단계에서 가장 먼저 만들 문서는 설치 명령이나 화면 목록이 아니라 짧은 대응 시나리오다. 예를 들어 “특정 냉동 제어기 관리 경로를 겨냥한 인증 우회 시도가 기록되면, 보안 담당자는 외부 노출 자산 목록을 대조하고, OT 담당자는 해당 모델의 설치 여부와 펌웨어 상태를 확인하며, 변경 작업은 설비 운영 책임자의 승인 뒤 수행한다”처럼 적는다.
이 문장을 책임자 이름, 자산 목록 위치, 승인 경로까지 채울 수 있다면 허니팟은 관측 도구로 검토할 기반이 있다. 반대로 채울 수 없다면, 먼저 해야 할 일은 더 정교한 장비 모방이 아니라 자산 관리와 대응 책임의 빈칸을 메우는 일이다.
