가동 중인 제어 장비에 일반 서버와 같은 취약점 점검을 수행해도 괜찮을까요? 산업제어시스템에서는 점검 도구가 보내는 통신 자체가 장비의 응답이나 생산 공정에 영향을 줄 수 있어, 평가 방법부터 운영 조건에 맞춰 설계해야 합니다. 이 글은 OT 보안 진단의 범위와 안전한 수행 절차, 법정 평가와 인증의 차이, 비용을 판단할 때 필요한 기준을 설명합니다.
OT 보안 평가의 출발점은 공정과 안전 조건이다
OT 환경의 보안 평가는 취약점 목록보다 먼저 정상 운전의 조건을 파악하는 작업입니다. 일반 IT 환경에서는 정보 유출이나 계정 탈취를 중심으로 위험을 설명하는 경우가 많지만, 산업 현장에서는 통신 지연과 제어 값 변경이 어떤 공정 결과로 이어지는지까지 살펴야 합니다. 그렇다고 일반 IT 환경이 언제나 기밀성을 최우선으로 두거나, OT 환경에서는 기밀성이 중요하지 않다는 뜻은 아닙니다. 실제 우선순위는 업무 목적, 공정 특성, 안전 요구사항에 따라 결정됩니다.
예를 들어 생산 이력 서버의 장애와 제어기 통신 장애는 같은 네트워크 문제여도 영향이 다를 수 있습니다. 전자는 기록 누락으로 이어질 수 있고, 후자는 설비 정지나 운전 상태 변경을 유발할 수 있습니다. 따라서 평가자는 생산 담당자에게 허용 가능한 중단 시간, 안전 정지 조건, 수동 운전 가능 여부를 확인해야 합니다. 안전 기능을 수행하는 장치와 일반 공정 제어 장치의 역할도 구분해야 하며, 보안 담당자가 임의로 시험 범위를 정해서는 안 됩니다.
평가 범위에는 제어기, 운영 화면, 엔지니어링 작업용 컴퓨터뿐 아니라 생산 관리 서버, 원격 유지보수 연결, 시간 동기화 장치, 백업 저장소도 포함될 수 있습니다. 장비별로 소유 부서, 운영 책임자, 유지보수 업체, 복구 절차를 연결해 두면 발견 사항의 조치 담당자를 빠르게 정할 수 있습니다. 핵심은 모든 장비를 동일하게 검사하는 것이 아니라, 공정에 미치는 영향에 맞춰 점검 강도와 순서를 조절하는 것입니다.
OT 보안 진단은 자산과 통신 흐름부터 확인한다
현장 도면과 실제 통신 구성이 일치하는지 확인하면 숨겨진 위험을 상당 부분 드러낼 수 있습니다. 설비 증설이나 유지보수 과정에서 추가된 연결은 자산 목록에 반영되지 않은 채 남기도 하므로, 문서 검토와 현장 확인을 함께 진행해야 합니다. 제어 장비의 주소, 운영체제, 펌웨어, 사용 프로토콜, 지원 종료 여부를 정리하되 확인할 수 없는 항목은 추정값으로 채우지 않는 것이 좋습니다. 자산의 존재를 확인한 시점과 확인 방법도 기록하면 이후 변경 관리에 도움이 됩니다.
통신 흐름은 출발지와 목적지뿐 아니라 연결 목적, 방향, 허용 시간, 인증 방식까지 기록해야 합니다. 기업 업무망에서 생산 관리 서버로 들어오는 연결과 외부 유지보수 업체가 엔지니어링 작업용 컴퓨터에 접근하는 연결은 서로 다른 통제가 필요합니다. 인터넷에 직접 연결되지 않은 설비도 업무망, 이동식 저장장치, 노트북을 통해 외부 위험과 연결될 수 있습니다. 네트워크가 분리되어 있다는 설명만으로 충분하지 않으며, 방화벽 정책과 실제 통신 기록을 함께 확인해야 합니다.
가동 중인 환경에서는 수동적 관찰을 우선 검토할 수 있습니다. 이 방식은 장비에 직접 질의하지 않고 관찰 지점에서 통신을 분석하지만, 관찰하지 못하는 구간이나 통신하지 않는 장비까지 모두 식별해 주지는 않습니다. 반대로 능동적 점검은 장비에 요청을 보내므로 제조사 권고, 시험 환경 검증, 현장 승인 절차가 필요합니다. 두 방식의 장단점을 조합하고, 식별되지 않은 자산과 검사하지 못한 항목을 보고서에 명시해야 평가 결과를 과신하지 않게 됩니다.
OT 보안 진단에서 놓치기 쉬운 계정·경계·물리 접근
취약한 장비 하나보다 그 장비까지 도달하는 접근 경로가 더 중요한 경우가 있습니다. 기본 계정, 공동 사용 계정, 퇴사자 계정, 유지보수용 계정을 구분하고 각 계정이 어떤 기능을 수행할 수 있는지 확인해야 합니다. 인증 기능이 제한적인 구형 장비는 설정 변경만으로 개선하기 어려울 수 있으므로, 상위 접근 구간의 인증과 승인, 접속 기록으로 보완할 수 있습니다. 다만 공용 계정을 그대로 둔 채 접속 기록만 수집하면 실제 작업자를 식별하기 어려워 책임 추적에 한계가 남습니다.
업무망과 제어망 사이에서는 꼭 필요한 통신만 허용하는지, 관리용 접속이 일반 업무 트래픽과 분리되어 있는지 살펴야 합니다. 중간 완충 구간을 두더라도 서버가 여러 네트워크를 동시에 연결하거나 예외 규칙이 넓게 설정되어 있으면 경계 통제가 약해질 수 있습니다. 원격 유지보수는 승인된 시간과 대상에 한정하고, 접속 종료 후 권한이 회수되는지까지 확인하는 편이 좋습니다. 추가 인증을 적용하기 어려운 장비에는 중계 접속 지점에서 인증을 강화하는 방법을 검토하되, 긴급 복구 시 접근 가능성도 함께 검증해야 합니다.
물리적 접근은 사이버 평가와 별개의 문제가 아닙니다. 제어반 열쇠 관리, 작업용 컴퓨터의 화면 잠금, 사용하지 않는 연결 단자의 통제, 외부 작업자의 출입 기록은 실제 설정 변경 가능성과 연결됩니다. 특히 설비 가까이에 있는 작업용 컴퓨터가 높은 권한을 가진 경우에는 네트워크 경계가 견고해도 현장 접근으로 우회될 수 있습니다. 오래된 장비의 취약점을 즉시 제거할 수 없다면 접근 제한, 통신 최소화, 이상 징후 감시, 복구 준비를 묶어 잔여 위험을 관리해야 합니다.
주요정보통신기반시설 취약점 분석 평가의 범위와 산출물
법정 평가와 일반 보안 점검은 목적과 책임 구조가 다릅니다. 주요정보통신기반시설로 지정된 시설의 관리기관은 관련 법령과 적용 기준에 따라 취약점 분석·평가 및 보호대책 수립 의무를 확인해야 합니다. 산업제어시스템을 운영한다는 이유만으로 모든 공장이 같은 법정 평가 대상이 되는 것은 아니며, 지정 여부와 지정 범위가 출발점입니다. 적용 대상과 수행 주기, 제출 또는 관리 절차는 현행 법령과 소관 기관의 기준으로 확인해야 하고, 외부 업체에 맡겨도 관리기관의 책임이 없어지는 것은 아닙니다.
평가 착수 단계에서는 지정된 시설 범위와 실제 운영 자산 사이의 차이를 먼저 정리하는 것이 좋습니다. 관리적·물리적·기술적 보호조치가 어떤 기준으로 평가되는지, 산업제어시스템의 특성을 어떤 방식으로 반영하는지 확인해야 합니다. 현장 증적에는 계정 관리 기록, 접근 승인 내역, 네트워크 구성도, 설정 자료, 백업 및 복구 시험 기록 등이 포함될 수 있습니다. 실제 필요한 자료는 적용 기준과 시설 특성에 따라 달라지며, 문서가 존재한다는 사실과 그 절차가 운영되고 있다는 사실은 구분해야 합니다.
보고서는 발견 사항, 판단 근거, 영향 범위, 개선 권고, 조치 책임자와 일정으로 연결되어야 합니다. 장비 제약 때문에 즉시 개선하지 못하는 항목에는 대체 통제와 잔여 위험의 승인 근거가 필요합니다. 기밀 구성도와 계정 정보가 평가 과정에서 외부로 전달될 수 있으므로 자료 반출 승인, 보관 기간, 접근 권한, 폐기 방법도 정해야 합니다. 법정 평가 보고서가 있다는 사실만으로 모든 공격 경로나 운영 위험이 검증되었다고 해석하지 않는 것이 중요합니다.
IEC 62443 인증 절차는 대상과 요구사항 선택부터 시작한다
IEC 62443은 하나의 단일 점검표가 아니라 산업 자동화 및 제어시스템 보안을 다루는 여러 표준으로 구성됩니다. 자산 소유자의 보안 관리 체계, 서비스 제공자의 활동, 시스템의 보안 요구사항, 제품 개발 과정과 구성요소의 요구사항은 서로 구별됩니다. 따라서 IEC 62443 인증 절차를 검토할 때는 공장 전체, 특정 제어시스템, 개별 제품, 개발 조직 중 무엇을 인증 대상으로 삼는지 먼저 정해야 합니다. 인증 프로그램에 따라 인정 범위와 심사 방식이 다를 수 있으므로 적용 표준 부분과 인증서의 범위를 함께 확인해야 합니다.
일반적인 준비 과정은 범위 정의, 요구사항과 현재 상태의 차이 분석, 개선 작업, 증적 준비, 심사, 부적합 사항 시정으로 이어집니다. 시스템 관점에서는 위험 분석을 통해 보안 요구사항이 비슷한 자산을 구역으로 묶고, 구역 사이의 통신 경로를 정의하는 접근이 중요합니다. 목표 보안 수준은 높은 숫자를 선택하는 문제가 아니라 예상 위협과 필요한 방어 능력을 근거로 설정하는 문제입니다. 제품의 보안 기능이 존재하는지와 현장 구성에서 그 기능이 올바르게 적용되었는지는 별도로 검증해야 합니다.
인증 준비에는 정책 문서뿐 아니라 설정 기록, 설계 근거, 시험 결과, 변경 관리와 취약점 처리 절차가 필요할 수 있습니다. 제품 인증을 받은 구성요소를 사용한다고 해서 이를 연결한 공장 전체가 자동으로 인증되는 것은 아닙니다. 마찬가지로 인증은 정해진 범위와 기준에 대한 적합성 확인이지 무사고 보증이 아닙니다. 유지 심사나 변경 시 재평가 여부는 인증 프로그램의 규칙과 계약 조건에 따라 확인해야 하며, 인증 이후 운영 방식이 바뀌면 기존 증적의 유효성도 다시 검토해야 합니다.
IEC 62443 인증 비용과 주요정보통신기반시설 평가 비용의 차이
두 비용은 총액만 비교하면 판단이 흐려집니다. IEC 62443 인증 비용에는 인증 대상 분석, 부족한 요구사항의 개선, 시험 환경 구성, 심사와 시정 대응 등이 영향을 주는 반면, 주요정보통신기반시설 평가 비용에는 시설 범위, 현장 수, 점검 대상, 증적 수집 난이도, 보고서와 재점검 범위 등이 영향을 줍니다. 특히 평가 수행 비용과 실제 보완 비용은 별개의 항목일 수 있어, 계약 금액만으로 전체 예산을 판단하기 어렵습니다.
견적을 비교할 때는 동일한 자산 수와 현장 범위뿐 아니라 허용된 점검 방식, 야간 작업 여부, 현장 체류 조건을 맞춰야 합니다. 보고서 작성만 포함하는지, 개선 방안 설계와 조치 후 검증까지 포함하는지도 구분해야 합니다. 인증의 경우 외부 심사 관련 비용과 준비 컨설팅 비용이 분리되는지, 시험이나 추가 심사가 어떤 조건에서 발생하는지 확인하면 누락된 예산을 줄일 수 있습니다.
생산 중단, 시험 장비 확보, 내부 담당자의 투입 시간도 사업 비용으로 관리할 필요가 있습니다. 저렴한 평가가 반드시 부실한 것은 아니지만 범위가 좁거나 검증 깊이가 다르면 결과의 활용도도 달라집니다. 금액의 적정성은 특정 평균값보다 수행 범위와 산출물, 현장 안전 조건, 개선 후 확인 책임을 기준으로 판단하는 편이 합리적입니다.
SK쉴더스 OT 보안 진단과 안랩 OT 보안 솔루션을 비교하는 기준
업체 이름보다 먼저 구분해야 할 것은 진단 서비스와 보안 제품의 역할입니다. SK쉴더스 OT 보안 진단을 검토하는 경우에는 위험 분석과 현장 점검, 개선 계획 수립이 어떤 범위로 제공되는지 확인하는 관점이 필요합니다. 안랩 OT 보안 솔루션을 검토하는 경우에는 대상 장비와 통신 환경에서 어떤 기능을 사용할 수 있는지, 운영에 어떤 제약이 생기는지 확인하는 관점이 필요합니다. 두 이름을 같은 범주에 놓고 단순 비교하기보다는 실제 제안된 서비스와 제품의 구성, 책임 범위를 기준으로 평가해야 합니다.
진단 수행 역량은 산업 공정 이해도, 생산 담당자와의 협의 방식, 검사 중단 기준, 구형 장비에 대한 점검 경험으로 확인할 수 있습니다. 제품은 설치 위치, 지원 환경, 통신 관찰 범위, 탐지 근거, 오탐 처리 방식, 장애 발생 시 동작을 확인해야 합니다. 장비에 프로그램을 설치하는 방식이라면 자원 사용량과 제조사 지원 조건을 확인하고, 네트워크 관찰 방식이라면 관찰 지점 밖의 구간이 남는지 검토해야 합니다. 기능 설명에 같은 용어가 쓰여도 실제 차단 범위와 필요한 권한은 다를 수 있습니다.
평가 기준은 시험 환경에서 재현할 수 있는 질문으로 만드는 편이 좋습니다. 승인되지 않은 유지보수 접속을 식별할 수 있는지, 장비의 정상 동작 변화를 공격으로 오인하지 않는지, 탐지 결과가 운영 담당자에게 이해 가능한 형태로 전달되는지 확인할 수 있습니다. 제품 도입 이후에는 경보를 검토할 담당자와 대응 절차가 있어야 하며, 진단 이후에는 개선 과제를 실행할 책임자가 있어야 합니다. 브랜드나 제품명만으로 현장 적합성, 인증 충족, 사고 예방 효과를 단정할 수는 없습니다.
스마트공장 보안 인증에 관한 흔한 오해
스마트공장 보안 인증이라는 표현만으로는 무엇을 검증하는 제도인지 알 수 없습니다. 공장 운영 체계, 특정 제품, 제어시스템, 특정 사업의 요구사항 중 무엇이 대상인지 구분하고, 인증 주체와 적용 기준, 인증서에 적힌 범위를 확인해야 합니다. 다른 분야의 인증이나 스마트화 수준 평가를 산업제어시스템 보안 적합성의 증거로 그대로 대체해서는 안 됩니다.
인터넷과 연결되지 않으면 안전하다는 생각도 주의해야 합니다. 정비용 노트북, 이동식 저장장치, 외부 공급업체의 업데이트 파일, 업무망과 연결된 중간 서버가 실제 접근 경로가 될 수 있습니다. 반대로 모든 장비에 같은 보안 프로그램을 설치하는 것이 항상 좋은 해결책도 아니며, 호환성 검증 없이 적용하면 운영상의 부담이 생길 수 있습니다.
취약점이 발견되면 곧바로 패치해야 한다는 주장 역시 현장 조건을 생략한 설명입니다. 패치는 제조사 지원 여부와 공정 영향, 시험 결과, 중단 가능 시간, 복구 수단을 확인한 뒤 적용하고, 그동안에는 접근 제한이나 통신 통제 같은 대체 조치를 검토해야 합니다. 패치를 미루는 결정에는 책임자, 근거, 검토 기한이 필요하며, 단순히 오래된 설비라는 이유만으로 위험을 무기한 받아들이는 것은 적절하지 않습니다.
OT 보안 평가 결과를 실행 가능한 개선 계획으로 바꾸기
좋은 평가의 마지막 산출물은 취약점 개수가 아니라 실행 순서가 정해진 개선 계획입니다. 우선순위는 기술적 심각도뿐 아니라 공정 영향, 실제 접근 가능성, 기존 통제, 복구 가능성을 함께 고려해 정해야 합니다. 외부에서 접근 가능한 원격 유지보수 경로의 과도한 권한과 격리된 시험 장비의 취약점은 같은 방식으로 처리할 필요가 없습니다. 각 과제에는 책임자, 승인권자, 목표 일정, 필요한 중단 시간, 완료 확인 방법을 연결해야 합니다.
점검 전에는 허용 작업과 금지 작업, 중단 신호, 비상 연락망, 복구 담당자를 문서로 합의하는 것이 좋습니다. 점검 후에는 설정을 변경했다는 기록만 남기지 말고 업무와 공정이 정상인지, 통제가 의도대로 작동하는지 확인해야 합니다. 백업은 파일 존재 여부보다 실제 복구 가능성이 중요하므로 장비 설정, 제어 프로그램, 필요한 소프트웨어와 사용 권한까지 복구 범위에 포함되는지 검토해야 합니다. 생산 시스템에 위험을 주지 않는 시험 환경이나 승인된 정비 시간을 활용하면 검증의 현실성을 높일 수 있습니다.
국내에서는 한국인터넷진흥원의 산업제어시스템 관련 보안 자료를 위험관리와 보호조치 검토의 참고 기준으로 활용할 수 있습니다. 미국 사이버보안·인프라보안국의 산업제어시스템 보안 자료도 운영 제약을 이해하는 데 참고가 되지만, 해외 지침이 국내 법정 의무를 대신하는 것은 아닙니다. 제로 트러스트 원칙을 검토할 때도 연결마다 신뢰를 확인한다는 방향과 제어 통신의 지연·안정성 요구를 함께 고려해야 합니다. 첫 단계는 자산 목록과 통신 흐름을 정리하고, 적용 의무를 확인한 뒤, 현장 승인 아래 검증 가능한 범위부터 평가하는 것입니다.
