Digital Transformation에서 AI로 이어지는 일련의 흐름 속에서, IT와 구분되는 OT 영역의 자동제어시스템은 과거처럼 온도와 압력 등 개별 공정값을 안정적으로 제어하는 수준을 넘어, 생산 데이터의 통합과 공정 운영 정보의 실시간 활용, 데이터와 AI의 결합을 통해 새로운 가치를 창출하는 기반으로 확장되고 있다.

이러한 변화는 OT 네트워크의 경계를 근본적으로 바꾸고 있다. 기존에는 공장 내부의 On-Premise 시스템을 중심으로 상대적으로 폐쇄적으로 운영되던 제어 네트워크가 이제는 SaaS, 클라우드, 원격 유지보수, IIoT Gateway, 데이터 분석 플랫폼 등 다양한 외부 시스템과 연결되며 그 범위를 넓혀가고 있다. 네트워크의 확장은 동시에 관리해야 할 자산과 접점 그리고 공격 표면의 증가를 의미한다. 과거와 같은 수동 점검이나 개별 장비 중심의 관리 방식만으로는 복잡하고 고도화된 OT 환경의 보안 요구에 효과적으로 대응하기 어렵다.

실제로 IIoT 적용의 주요 장애요인을 조사한 산업 자동화 관련 조사에서도 Cybersecurity가 가장 큰 도전 과제로 제시되고 있다. 이는 보안이 Digital Transformation을 위한 부수적인 조건이 아니라, 디지털 전환을 안정적으로 추진하기 위한 핵심 전제임을 보여준다. 특히 OT 환경에서 보안은 단순히 외부 공격을 차단하는 기술적 영역에 그치지 않는다. 생산 연속성, 설비 안전, 품질, 환경, 나아가 기업의 브랜드 신뢰성까지 영향을 미치는 운영 리스크 관리의 핵심 요소로 이해할 필요가 있다.

증가되는 위협

이는 단순한 기우가 아니다. IoT 연결의 증가 추세와 OT 영역에서 발생하는 보안사고, 특히 산업 랜섬웨어의 증가 추이를 비교해 보면, 연결성이 확대되는 속도에 비례하거나 그 이상으로 보안 위협과 사고가 증가하고 있음을 확인할 수 있다. 이는 OT 환경의 연결성이 빠르게 확대되는 반면, 현재의 보안 투자와 관리 체계가 증가하는 위협에 충분히 대응하지 못하고 있음을 시사한다.

OT 네트워크가 과거보다 더 많은 시스템과 연결되고, 더 많은 데이터를 외부 시스템과 교환하며, 사용자와 벤더의 원격 접근이 확대될수록 공격자가 활용할 수 있는 진입 경로 역시 다양해진다. 또한 유지보수용 노트북과 USB 저장장치, 원격 접속 계정, IT·OT 연계 구간, 미흡하게 설정된 방화벽 정책, 패치되지 않은 서버와 엔드포인트 등이 모두 잠재적인 침투 경로가 될 수 있다. 따라서 OT 보안은 특정 보안 솔루션 하나를 도입하는 것으로 해결할 수 있는 문제가 아니다. 자산 식별과 네트워크 분리, 접근 통제, 실시간 모니터링, 사고 대응 절차, 복구 체계가 유기적으로 연계되고 함께 작동하는 통합적인 보안 체계로 접근해야 한다.

 

AI, 적과 아군 모두에게 강력한 무기

ChatGPT의 등장 이후 급격히 발전한 AI는 창작, 문서 작성, 코딩, 분석 등 과거에는 상당한 시간과 전문성이 필요했던 작업을 훨씬 짧은 시간 안에 수행할 수 있도록 하였다. 이는 생산성과 의사결정의 효율을 높이는 강력한 도구로 자리 잡고 있다. 그러나 보안 위협 측면에서도 유사한 변화가 나타나고 있다. 공격자는 AI를 활용해 공개정보(OSINT) 수집을 자동화하고, 악성 스크립트나 피싱 문구를 빠르게 생성하며, 공격 대상에 맞춘 정교한 사회공학적 메시지를 제작할 수 있다.

즉, 과거에는 공격 의도가 있더라도 기술적 역량이나 자원이 부족했던 공격자가 이제는 AI 에이전트와 생성형 AI, 이른바 ‘바이브 코딩(vibe coding)’ 등을 활용해 부족한 역량을 보완할 수 있게 되었다. 이는 동일한 공격 시나리오라도 AI의 지원을 받으면 공격 준비 시간이 단축되고, 공격 규모가 확대되며, 공격의 정교함까지 높아질 수 있음을 의미한다. 특히 OT 환경에서는 공격의 결과가 단순한 정보 유출에 그치지 않고 설비 정지, 품질 저하, 안전사고, 환경 사고 등으로 이어질 수 있기 때문에 이러한 변화에 더욱 주목할 필요가 있다.

반대로 방어자에게 AI는 보안 역량을 강화하는 중요한 도구가 될 수 있다. 네트워크 이상 징후 탐지, 로그 상관분석, 자산 식별, 취약점 우선순위화, 사고 대응 지원 등은 AI 기반 분석과 자동화를 효과적으로 적용할 수 있는 영역이다. 다만 OT 환경에서는 자동화된 대응이 곧바로 공정 운영에 영향을 미칠 수 있으므로, AI 기반 보안 기능을 적용할 때에도 설비 가용성, 운전 안전성, 변경 및 승인 절차 등을 함께 고려해야 한다. AI는 방어의 효율성과 대응 속도를 높이는 강력한 수단이 될 수 있지만, OT 환경에서의 최종 의사결정과 대응은 반드시 공정 운영과 안전이라는 맥락 안에서 통제되어야 한다.

AIC vs CIA, OT와 

IT 보안의 근본적인 차이

보안 침해 사고의 최악의 경우를 상상해 보자. IT 관점에서는 고객 정보와 영업 기밀의 유출, 업무 시스템 중단 등이 대표적인 피해로 떠오른다. IT라는 명칭 자체가 Information Technology인 만큼 정보의 기밀성(Confidentiality)이 중요한 보안 요소로 다뤄진다. 반면 OT 관점에서 제어 네트워크의 최악의 상황은 제어시스템이 기능을 상실해 설비가 제어 불능 상태에 빠지는 것이다. 이는 단순한 업무 불편이나 매출 손실을 넘어 인명과 환경, 설비 자산에 직접적인 피해를 초래할 수 있다.

이 때문에 IT 보안에서 일반적으로 강조되는 CIA, 즉 기밀성(Confidentiality)·무결성(Integrity)·가용성(Availability)의 우선순위가 OT에 그대로 적용되지는 않는다. OT에서는 일반적으로 가용성(Availability)을 최우선으로 보고, 그다음 무결성(Integrity), 기밀성(Confidentiality)의 순으로 중요도를 판단한다. 극단적인 예로 IT에서는 정보가 충분히 보호되지 않는 서버를 일시적으로 중단하는 의사결정이 가능할 수 있지만, OT에서는 설비의 제어 기능과 안전한 운전을 유지하기 위해 제한적인 운전 데이터를 외부로 반출하는 결정을 내려야 하는 상황이 발생할 수 있다.

패치 적용 역시 같은 맥락에서 이해할 수 있다. IT 환경에서는 취약점을 줄이기 위해 최신 OS 패치를 신속하게 적용하는 것이 합리적일 수 있다. 그러나 OT에서는 운전 중인 제어시스템에 충분히 검증되지 않은 패치를 적용하는 행위 자체가 새로운 리스크가 될 수 있다. 패치로 인해 Controller Engineering Tool·HMI·Historian·통신 드라이버·제어 로직 등의 호환성에 문제가 발생하면, 보안을 강화하기 위한 조치가 오히려 생산 중단이나 안전 리스크로 이어질 수 있기 때문이다.

따라서 OT 보안은 IT 보안 기술을 그대로 가져와 적용하는 방식만으로 충분하지 않다. 동일한 방화벽, 백신, 패치 관리, 계정 관리 기술이라도 OT 환경에서는 공정 및 설비에 미치는 영향, 사전 검증 절차, 장애 발생 시 복구 가능성, 벤더의 지원 및 승인 여부, 현장 운전자의 업무 방식 등을 종합적으로 고려해야 한다. 결국 OT 보안의 핵심은 최신 보안 기술을 가장 많이 적용하는 데 있는 것이 아니라, 해당 공정과 설비가 가진 위험을 정확히 이해하고 그에 맞는 통제 수준을 설정한 뒤 이를 지속적으로 유지·개선하는 데 있다.

 

왜 IEC 62443인가?

이러한 배경을 고려하면 OT 보안에는 IT 보안과는 다른 기준과 언어가 필요하다. IEC 62443은 산업 자동화 및 제어시스템(IACS)을 대상으로 보안 요구사항과 절차, 역할, 제품 및 시스템 요구사항 등을 폭넓게 다루는 표준 체계다. Asset Owner, System Integrator, Product/Solution Provider 등 각 이해관계자의 역할에 따라 적용해야 할 요구사항을 구분하고, 보안 정책과 절차부터 시스템 설계, 컴포넌트 요구사항까지 연결되는 종합적인 프레임워크를 제공한다.

전력 분야의 NERC-CIP, 선박 분야의 IACS UR E26/27과 같이 특정 산업이나 세그먼트에 특화된 규정과 기준도 존재한다. 이러한 규정은 해당 산업의 특수한 운영 환경과 위험에 맞춰 설계됐다는 장점이 있지만, 모든 OT 환경에 동일하게 적용하기에는 한계가 있다. 반면 IEC 62443은 특정 산업에 국한되지 않고 산업 자동화 및 제어시스템 전반에 적용할 수 있는 공통의 보안 언어와 프레임워크를 제공한다는 점에서 의미가 크다.

특히 IEC 62443은 단순히 ‘어떤 제품이 보안 기능을 갖추고 있는가’를 확인하는 데 그치지 않는다. 위험성 평가를 통해 보호 대상과 위협, 취약성·잠재적 영향을 분석하고, 그 결과를 바탕으로 목표 보안 수준(Security Level Target, SL-T)을 설정한다. 이후 시스템의 설계와 구현, 운전 과정에서 실제로 달성된 보안 수준(Security Level Achieved, SL-A)을 평가하고 검증하도록 한다. 즉, IEC 62443의 핵심은 개별 보안 기능의 보유 여부를 확인하는 체크리스트가 아니라, 공정과 시스템의 위험을 기반으로 필요한 보안 수준을 정의하고 이를 설계와 운영에 반영하는 리스크 기반의 보안 접근이라고 할 수 있다.

보안 위험에 정성적 접근이 필요한 이유

기업이 무한한 보안 예산을 보유하고 있는 것은 아니다. 현실적으로 보안 투자는 줄이고자 하는 리스크의 규모와 균형을 이루어야 한다. 최악의 피해 규모가 제한적인 소형 설비에 과도한 비용의 보안 솔루션을 적용하는 것이 반드시 합리적인 것은 아니다. 반대로 동일한 PLC라도 폭발성 물질이 담긴 용기의 압력을 제어하거나, 대규모 생산라인의 긴급 정지를 담당하거나, 환경 배출과 직접 연결된 설비를 제어한다면 요구되는 보안 수준은 크게 달라져야 한다.

이는 ‘PLC에는 반드시 특정 보안 기능이 있어야 한다’는 식의 획일적인 접근에서 벗어나야 한다는 의미다. 해당 PLC가 어떤 공정에 설치되어 있는지, 기능 상실이나 오동작이 어떤 결과로 이어질 수 있는지, 어떤 위협과 취약성에 노출되어 있는지를 종합적으로 평가해야 한다. 물리적으로 동일한 모델의 PLC라 하더라도 폭발성 물질이 담긴 용기의 압력을 제어하는 PLC와 단순한 환기 설비를 제어하는 PLC에 동일한 수준의 보안 투자를 요구하는 것은 합리적이지 않다.

이러한 판단을 위해서는 보안 위험에 대한 정성적 평가가 필요하다. Consequence는 안전·환경·생산·품질·법적 책임·브랜드 신뢰도 등 다양한 측면에서 평가할 수 있으며, Likelihood는 해당 위협이 실제 사고로 이어질 가능성을 위협과 취약성의 관점에서 판단한다. 따라서 OT의 보안 수준은 단순히 기술적 취약점의 존재 여부만으로 결정해서는 안 된다. 사업에 미치는 영향과 운전 조건, 공정의 위험성, 기존 방호 계층, 유지보수 체계 등을 종합적으로 고려해 해당 설비와 공정에 적합한 보안 수준을 결정해야 한다.

리스크의 정량화와 대응 수단의 확립

: IEC 62443 Security Level

IEC 62443의 보안 수준 접근은 위험성 평가를 기반으로 한다. 기본적으로 Risk는 Consequence와 Likelihood의 함수로 이해할 수 있으며, Likelihood는 다시 Threat와 Vulnerability의 조합을 통해 평가할 수 있다. 조직은 이러한 평가를 바탕으로 자체적으로 정의한 리스크 매트릭스에서 완화 조치 이전의 위험(Unmitigated Risk)과 허용 가능한 위험(Tolerable Risk)을 비교하고, 필요한 위험 저감 수준을 CRRF(Cyber Risk Reduction Factor)로 산출할 수 있다.

CRRF는 목표 보안 수준인 SL-T를 결정하는 과정에서 활용되는 기준이다. 예를 들어 특정 시나리오의 Unmitigated Risk가 16이고, 조직이 허용 가능한 위험을 4로 설정했다면 필요한 위험 저감 수준인 CRRF는 4가 된다. 이후 해당 조직이 사용하는 리스크 매트릭스와 CRRF-보안 수준 매핑 기준에 따라 필요한 SL-T를 결정한다. 중요한 점은 IEC 62443이 특정 위험값이나 CRRF를 절대적인 기준으로 강제하기보다는, 각 조직이 자사의 리스크 평가 체계와 판단 기준에 따라 위험과 보안 수준의 관계를 정의할 수 있도록 유연성을 제공한다는 것이다.

Security Level은 SL-T, SL-A, SL-C의 세 가지 개념으로 구분해 이해할 필요가 있다. SL-T(Target)는 위험성 평가를 통해 도출된 목표 보안 수준이며, SL-A(Achieved)는 실제 시스템의 설계와 구현, 운영을 통해 달성한 보안 수준을 의미한다. 반면 SL-C (Capability)는 제품이나 컴포넌트가 갖추고 있는 보안 기능과 이를 통해 제공할 수 있는 보안 능력의 수준을 의미한다.

이 세 가지 개념을 혼동하면 ‘제품이 높은 보안 수준 인증을 받았으므로 시스템 전체도 안전하다’는 잘못된 결론에 이를 수 있다. 제품이나 컴포넌트가 높은 SL-C를 갖추고 있더라도, 시스템 통합 과정에서 네트워크 구조가 적절하게 설계되지 않았거나 운영 절차와 계정 관리가 미흡하다면 실제 시스템의 SL-A는 목표 수준인 SL-T에 미치지 못할 수 있다. 결국 IEC 62443의 Security Level 접근에서 중요한 것은 개별 제품의 보안 수준 자체가 아니라, 위험성 평가를 통해 필요한 목표 수준을 설정하고 시스템 설계와 운영 과정에서 이를 실제로 달성하는 것이다.

각 FR에 대한 접근

IEC 62443-3-3은 시스템 보안 요구사항을 7개의 Foundational Requirement(FR)로 체계화한다. 이 7개 FR은 보안 기능을 단순히 나열한 것이 아니라, 산업 자동화 및 제어시스템(IACS)이 보호해야 할 핵심 보안 속성을 구조화한 것이다. 각 FR 아래에는 세부 시스템 요구사항(System Requirement, SR)이 정의되며, Security Level이 높아질수록 강화되는 요구사항(RE)이 SL에 따라 매핑된다.

FR1과 FR2는 접근과 사용을 통제하는 영역이다. 계정 관리, 사용자 인증, 장치 인증, 권한 부여, 세션 관리, 원격접속 통제, 무선 접근 관리 등이 여기에 포함된다. OT 환경에서는 공용 계정이나 장기간 변경되지 않은 비밀번호, 벤더의 공용 계정, 긴급 접근용 계정이 보안 취약점으로 작용할 수 있다. 따라서 중앙 계정 관리, 역할 기반 접근제어(RBAC), 다중 인증(MFA), 승인 기반 원격접속 등 적절한 접근 통제가 중요하다.

FR3과 FR4는 시스템과 데이터의 무결성 및 기밀성 보호를 다룬다. OT 환경에서는 기밀성보다 가용성이 우선된다고 해서 기밀성이 중요하지 않은 것은 아니다. 제어 명령, 레시피, 운전 데이터, 안전 관련 설정값 등이 무단으로 변경되거나 외부에 노출될 경우 설비 운전과 안전에 직접적인 영향을 미칠 수 있다. 따라서 암호화, 무결성 검증, 악성코드 방어, 변경 탐지, 인증서 기반 통신 등의 보안 기술을 공정 특성과 운전 환경에 맞춰 선별적으로 적용해야 한다.

FR5는 OT 보안 설계에서 핵심적인 네트워크 분리와 데이터 흐름 제한을 다룬다. Purdue 모델 기반의 계층 구분, IT·OT DMZ, Zone & Conduit, 방화벽 정책, 기본 거부(Default Deny)와 예외 허용(Allow by Exception) 원칙 등이 밀접하게 연관된다. 모든 자산을 동일한 네트워크에 연결하는 Flat Network 구조는 침해 발생 시 공격이 다른 영역으로 확산될 가능성을 높인다. 따라서 기능과 보안 요구사항이 유사한 자산을 Zone으로 구분하고, Zone 간 통신은 Conduit와 경계 보호 장치를 통해 필요한 범위로 제한하는 것이 바람직하다.

FR6과 FR7은 보안 이벤트의 탐지와 대응 그리고 시스템의 가용성 유지와 관련된다. 보안 이벤트를 탐지하지 못하면 적절한 대응이 어렵고, 대응 절차가 마련되어 있지 않다면 탐지된 이벤트 역시 실제 운영 리스크로 이어질 수 있다. 따라서 로그 수집과 분석, SIEM 또는 OT 보안 대시보드, 네트워크 침입 탐지(NIDS), 자산 식별, 이상 징후 탐지 등을 통해 보안 상태를 지속적으로 모니터링해야 한다. 동시에 백업과 복구 체계, 네트워크 Rate Limiting, 사고 대응 및 복구 절차를 마련하고, 정기적으로 검증함으로써 장애나 침해사고 발생 이후에도 안정적인 운영을 이어갈 수 있도록 해야 한다.

Lifecycle로서의 Cyber Security

Cybersecurity는 일회성 프로젝트가 아니다. 네트워크를 한 번 분리하고, 방화벽을 한 번 설치하며, 백신 서버를 구축했다고 해서 보안이 완료되는 것은 아니다. 위협은 지속적으로 변화하고, 자산은 추가·변경되며, 운영자가 교체되고, 원격 접속 요구는 증가한다. 새로운 취약점과 패치도 계속 발생한다. 따라서 OT 보안은 설계와 구축뿐만 아니라 모니터링, 유지보수, 교육, 사고 대응까지 포함하는 지속적인 Lifecycle로 접근해야 한다. 

IEC 62443-2-1의 CSMS 관점에서도 Lifecycle 접근을 확인할 수 있다. 프로그램을 시작하고 고수준 위험 평가를 수행한 뒤, 보안 정책과 조직 인식을 정립하고 상세 위험 평가를 거쳐 대응책을 선정·구현하며, 이후 CSMS를 지속적으로 유지하는 과정이 반복적으로 연결된다. Schneider Electric의 운영 라이프사이클 접근도 Security Consulting, Design & Implementation, Monitoring & Maintenance, Training으로 이어지는 흐름으로 이해할 수 있다. 이는 보안이 특정 부서가 한 번 수행하고 끝내는 과제가 아니라, 운영 조직 전체가 지속적으로 관리하고 개선해야 하는 체계임을 의미한다.

Patch Management는 Lifecycle 접근을 보여주는 대표적인 사례다. OT에서는 새로운 패치가 나왔다는 사실을 확인하는 것보다 해당 패치를 실제 설비에 적용할 수 있는지 판단하는 과정이 중요하다. 패치의 위험성을 평가하고 변경 내용을 검토한 뒤 설치 및 롤백 절차를 마련하고, 사전 Qualification과 Verification을 거쳐 적절한 일정과 운전 조건을 고려해 배포해야 한다. 이후 적용 결과와 시스템 상태를 검증하고, 그 과정과 결과를 문서화해야 한다. 결국 OT에서 중요한 것은 패치 자체가 아니라, 패치를 안전하게 평가하고 적용하며 그 결과를 검증하는 관리 프로세스다. Lifecycle 기반의 Patch Management가 지속적으로 운영될 때, 비로소 보안 수준을 안정적으로 유지할 수 있다. 

각 SL에 대한 접근

Security Level은 추상적인 숫자에 그치는 개념이 아니라, 실제 보안 아키텍처와 운영 대책으로 구체화되어야 한다. 

SL1은 우발적이거나 실수에 의한 보안 위반에 대해 기본적인 저항성을 제공하는 수준으로 이해할 수 있다. 계정 관리와 기본적인 인증, 방화벽 및 네트워크 모니터링, 네트워크 세그멘테이션, 불필요한 기능의 비활성화, 감사 로그, 백업 등 기본적인 보안 통제가 중심이 된다. SL2는 의도적인 공격이지만 비교적 단순한 수단과 제한된 자원을 사용하는 위협에 대응하는 수준이다. 이 단계에서는 인증서 기반 장치 인증, 중앙 인증, PKI, NIDS, 암호화 통신, 중앙 로그 서버, 보안 원격 접속, 중요 제어 통신의 물리적·논리적 분리, 자산 인벤토리 관리 등이 고려될 수 있다. 

SL2는 상당수 산업 현장에서 현실적으로 달성 가능한 보안 성숙도 향상의 목표 수준이 될 수 있다. SL3는 시스템에 대한 전문적인 지식과 상당한 수준의 자원을 갖춘 공격자에 대응하는 수준이다. 다중 인증(MFA), 하드웨어 기반 키 보호, 무선 위협 탐지, 중앙 관리형 악성코드 방어, SIEM 기반 중앙 감사 추적, 일관된 시간 동기화, 암호학적 무결성 보호 통신, 자동화된 백업, 보안 상태 보고 및 지속적인 모니터링 등이 더욱 중요해진다. 이 단계부터는 개별 장비의 보안 기능만으로는 충분하지 않으며, 전체 시스템을 대상으로 하는 보안 운영 체계와 지속적인 모니터링 및 대응 역량이 특히 중요하다.

다만 Security Level을 높이는 것이 항상 정답은 아니다. 적정한 보안 수준은 리스크 평가 결과와 사업적 현실성을 함께 고려해 결정해야 한다. 모든 설비에 SL3 또는 SL4를 일률적으로 적용하면 비용과 운영 복잡성이 급격히 증가할 수 있다. 반대로 높은 피해가 예상되는 핵심 설비에 낮은 수준의 기본 통제만 적용하는 것도 적절하지 않다. 핵심은 각 Zone과 Conduit 그리고 개별 자산의 기능과 예상되는 결과 피해를 바탕으로 목표 보안 수준을 정의하고, 이를 달성할 수 있도록 보안 아키텍처와 운영 절차를 설계하는 것이다.

결론 : OT Cybersecurity는 

디지털 전환의 비용이 아니라 전제 조건

Digital Transformation은 OT 데이터를 더 많이 연결하고, 더 넓게 활용하며, 이를 더 빠르게 의사결정에 반영하는 방향으로 발전하고 있다. 그러나 연결성과 지능화가 확대될수록 새로운 보안 리스크 역시 함께 증가한다. 따라서 OT Cybersecurity는 디지털 전환을 가로막는 비용 항목이 아니라, 디지털 전환을 지속 가능하게 추진하고 안정적으로 운영하기 위한 필수 조건이다.

OT 보안의 출발점은 ‘어떤 보안 솔루션을 도입할 것인가’가 아니다. ‘무엇을 보호해야 하는가’, ‘어떤 사고가 가장 치명적인가’, ‘리스크를 어느 수준까지 낮춰야 하는가’를 먼저 정의해야 한다. IEC 62443은 이러한 질문에 답하기 위한 공통의 보안 프레임워크를 제공한다. 위험성 평가를 통해 목표 보안 수준(SL-T)을 정의하고, 시스템의 설계와 구현을 통해 달성된 보안 수준(SL-A)을 확보하며, 제품과 컴포넌트의 보안 능력(SL-C)을 적절히 활용해야 한다. 목표 수준을 충족하기 위해 필요한 경우에는 보상대책을 적용하고, 그 근거와 적용 내용을 문서화하는 것도 중요하다.

또한 OT 보안은 한 번의 프로젝트로 완료되는 것이 아니라 Lifecycle을 통해 지속적으로 관리되어야 한다. 자산 인벤토리, Zone & Conduit, 접근 통제, 패치 관리, 엔드포인트 보호, NIDS, SIEM, 백업과 복구, 사고 대응 절차, 교육과 훈련 등이 지속적으로 연결되고 개선될 때 OT 보안은 문서상의 요구사항을 넘어 실제 현장의 회복탄력성(Resilience)으로 작동할 수 있다.

결국 좋은 OT Cybersecurity의 목표는 공격자를 완전히 제거하는 데 있지 않다. 공격자가 침투하기 어렵게 만들고, 침투하더라도 다른 영역으로 확산하기 어렵게 하며, 이상 징후를 신속하게 탐지하고, 사고가 발생하더라도 정상 운영을 빠르게 회복할 수 있는 구조를 만드는 것이다. 이것이 바로 Digital Transformation 시대에 OT Cybersecurity가 선택적 투자가 아니라 필수적인 기반이며, IEC 62443 기반의 리스크 중심 보안 접근이 필요한 이유다.

 

sangyong.shin@se.com