[첨단 헬로티]

지난해(2019년 6월)에 경제산업성에서 ‘빌딩 시스템의 사이버 피지컬 시큐리티 가이드라인 제1판’이 출시됐다. 지금까지 빌딩 업계에서는 명확한 시큐리티 대책의 ‘기준’조차 없었던 것을 생각하면, 이 가이드라인의 실효성은 앞으로의 평가에 달려 있다고 해도 책정한 것 자체는 빌딩 업계의 시큐리티 대책으로서 첫걸음이라고 할 수 있을 것이다.

빌딩 업계가 이 시기에 시큐리티 대책에 몰두한 이유는 다음의 두 가지를 들 수 있다.

첫 번째는 ‘빌딩’이라는 건물의 범용성에 있다. 빌딩 분야는 정부가 중요 인프라로 자리매김한 14분야에는 포함되지 않지만, 그 14분야의 기업이나 조직의 대부분의 본사나 시설은 ‘빌딩’이라는 건물에 들어가 있다. 즉, 중요 인프라의 14분야는 자기 분야의 시스템 시큐리티 강도에 상관없이 ‘빌딩’의 기능이 정상적으로 작동하지 않을 경우에는 자기 분야의 시스템이 어떠한 영향을 받게 되는 것이다.

두 번째는 빌딩 제어 시스템은 다른 산업계 제어 시스템과 기본적으로 동일하며, 빌딩 제어 시스템의 대책은 다른 제어계 시스템에도 적용할 수 있는 것이 많다.

원래 산업계 제어 시스템은 IT 기술과는 무관했지만, 1980년대 이후 점차 IT 기술이 도입되어 지금은 IT 기술 없이는 제어 시스템을 말할 수 없을 정도가 됐다. 그럼에도 불구하고 제어 현장에는 IT 기술을 충분히 이해한 기술자가 거의 배치되어 있지 않은 것이 현실이다. 이것이 제어 시스템의 현장에서 시큐리티를 확보하는 것에 대해 여러 가지 어려움과 의사소통의 어긋남을 초래하고 있다.

이 글에서는 빌딩 분야의 제어 시스템 시큐리티의 현황을 통해 산업계 제어 시스템 전체가 안고 있는 문제점과 그 해결을 위한 개념을 제시한다. 아울러, 빌딩 분야의 가이드라인 작성에 있어 중시된 문제점과 대책의 기본적인 개념을 설명한다.

빌딩 제어 시스템이란

빌딩을 기능시키기 위해 빌딩에는 각종 시스템이 도입되어 있지만, 그것은 건축 관계 이외의 사람에게는 그다지 알려져 있지 않다. 빌딩의 제어 시스템은 원래 공조용 보일러를 제어하는 ​것에서 시작된 경위가 있으며, PA계 시스템을 베이스로 하고 있다. 그 후 각종 기능을 부가해 현재는 공조․조명․수배전․방재․방범․엘리베이터 등의 여러 가지 제어를 하게 됐다. 시스템의 규모는 40층 전후의 고층 빌딩에서는 서버류 200대 전후, 컨트롤러도 큰 것부터 작은 것까지 모두 합치면 2만대나 되는 것도 있는 등 대규모 시스템으로 되어 있다.

빌딩 제어 시스템의 IT 면의 과제

빌딩 제어 시스템뿐만 아니라 산업계 제어 시스템은 운용상의 특성에서 정보계 시스템과 크게 다른 측면을 가지고 있다. 그렇기 때문에 정보계 시스템 기술자에게는 이것이 이해되지 않으므로 시큐리티 대책을 생각할 때에 제어계 기술자의 생각과 큰 어긋남을 초래하는 경우가 많다. 이 점을 양자가 이해해야 비로소 산업계 제어 시스템의 시큐리티가 가능하게 된다.

빌딩 시스템의 IT 면의 과제는 이하와 같은 것을 들 수 있다.

1. OS나 소프트웨어의 업데이트가 불가능하다

대규모 빌딩은 한 동 한 동 장소도 다르지만 모양도 다르기 때문에 빌딩 제어 시스템에서 사용되는 프로그램은 그 빌딩 특유로 커스터마이즈되어 있는 것이 대부분이다. 그렇기 때문에 시스템을 업데이트하려고 해도 그 업데이트를 실시한 경우에 시스템이 정상적으로 가동하는지의 여부를 확인할 수 있는 검증 시스템이 없는 한 업데이트가 불가능하다. 이것은 OS 업데이트에 대해서도 마찬가지이다. 그렇기 때문에 OS에 시큐리티 패치가 발행돼도 패치를 적용하는 것조차 할 수 없는 것이 현 상황이다. 빌딩을 포함해 대부분의 제어 시스템이 검증용 시스템을 가지고 있지 않다. 물론 이것은 코스트의 문제이다.

2. 사용되고 있는 OS는 오래된 것이 많다

앞에서 말한 바와 같이 소프트웨어의 업데이트가 불가능하기 때문에 동일한 버전의 소프트웨어와 OS를 오랫동안 계속 사용하게 된다. 더구나 정보계 시스템의 세계에서는 서버나 PC의 수명이라고 하는 5년에서 7년으로 기기를 교체하는 경우가 많지만, 빌딩에서는 설비의 교체는 15년에서 20년을 예상하고 계획되어 있기 때문에 빌딩과 공장에서는 동일한 시스템을 15년에서 20년 계속 사용하게 되고, 결과적으로 오래된 OS를 계속 사용하게 된다. 이것은 공장 등의 제어 시스템도 똑같은 문제를 안고 있다.

또한, 빌딩 제어 시스템의 OS를 낡게 하는 이유가 한 가지 더 있다. 그것은 빌딩의 설계에서 건축에 소요되는 기간의 문제이다. 빌딩 제어 시스템은 빌딩의 설계 시에 기능과 OS까지 결정된다. OS를 선택할 때에는 프로그램을 커스터마이즈해 만들기 때문에 정보계 시스템 개발과 마찬가지로 ‘낡은’ OS를 선택하게 된다. 즉, 이 시점에서 최신의 OS가 아니라 출시된 지 몇 년이 지난 OS를 선택하게 된다. 그리고 대형 빌딩의 건축에는 3년 정도의 기간이 소요되고 가동을 맞이하게 된다. 즉, 대형 신축 빌딩이 준공됐을 때에는 빌딩 시스템의 OS가 출시된 지 짧아도 7, 8년이 경과된 것이다. 그 결과, 현재 가동하고 있는 빌딩에서 사용되고 있는 OS는 새로운 것이라도 Windows Server 2012이다. 오래된 빌딩 시스템에서는 Windows NT Server가 사용되고 있는 것도 있다.

이와 같이 빌딩 등의 제어 시스템에서는 오래된 OS로, 더구나 최신 시큐리티 패치를 적용하는 것도 불가능한 시스템을 이용하면서 시큐리티 대책을 생각해야 하는 것이다.

3. 바이러스 대책 소프트웨어를 도입할 수 없다

정보계 시스템의 시큐리티 대책에는 바이러스 대책 소프트웨어를 이용하는 것이 기본인데, 빌딩 등의 제어계 시스템에서는 도입이 그렇게 간단한 문제가 아니다. 앞에서 말했듯이 검증용 시스템이 없기 때문에 시스템 설계 당초부터 바이러스 대책 소프트웨어의 도입을 예상하고 있으면 문제가 없지만, 기존의 빌딩 제어 시스템에는 새롭게 도입할 수 없다.

더구나 신축 빌딩과 공장에서 처음부터 바이러스 대책 소프트웨어를 도입하는 경우에도 바이러스 대책 소프트웨어의 패턴 파일을 갱신하는 방법을 별도로 검토해 둬야 한다. 시큐리티 패치를 적용할 수 없는 OS를 이용하는 조건 하에서는 인터넷을 통해 패턴 파일을 갱신하는 것은 불가능하다. 패턴 파일을 갱신하기 위한 시스템을 별도로 준비하거나, 수동으로 갱신하게 된다.

또한, 빌딩 제어 시스템에서는 그다지 문제가 되지 않지만, 공장 등에서 몇 십분의 일초 단위로 제어를 하고 있는 시스템은 바이러스 대책 소프트웨어가 시스템 내를 검색할 때에 CPU의 가동률이 일시적으로 100% 가까이까지 상승하는 경우가 있으며, 이때에 정확한 시간 단위의 제어를 할 수 없다는 문제도 있다.

따라서 가이드라인의 작성에 있어서는 위에서 말한 특징을 전제로 대책을 생각해 갈 필요가 있으며, 이를 위해 빌딩 분야의 가이드라인은 정보계 시스템과 같이 IT 기술 주체의 대책뿐만 아니라 운용면의 대책을 중시한 것으로 되어 있다.

빌딩 제어 시스템의 운용면의 과제

빌딩 운영에 종사하는 직원에게는 다양한 법적 자격이 요구된다. 물론 빌딩의 규모와 그 기능에 따라 필요한 자격은 다르며, 자격을 갖춘 직원의 상주가 요구되는 경우도 있다. 구체적으로는 전기 주임 기술자와 같은 전기계, 보일러 기사 등의 가스계, 기타 소방이나 환경 위생 관련 등 여러 방면에 걸쳐 15종류나 된다.

이러한 자격은 모두 빌딩을 운영하는 현장에서 필요하게 되는 기기의 취급에 필요한 것이지만, 이 중에 IT에 관련된 자격은 없다. 빌딩 제어 시스템은 당연히 IT 기술로 구축된 IT 지식 없이는 운용할 수 없는 것이지만, 빌딩 운영의 현장에서는 IT 기술이 필수적인 것으로 자림매김되어 있지 않다. 사이버 시큐리티 대책을 추진해 가는데 있어서는 현장 직원의 기초적인 IT 지식의 취득은 필수이며, 대규모 빌딩에서는 IT 기술자의 배치도 고려할 필요가 있다.

이 문제는 빌딩 운영의 현장만의 문제가 아니라, 설계 단계에서도 동일한 문제를 안고 있다. 빌딩 자체를 제어하는 ​​설비 설계 기술자와 IT 기술자를 연결할 수 있는 기술자가 크게 부족하다. 빌딩 현장의 실태를 이해할 수 있는 IT 기술자가 부족한 것이다.

생산성 및 안전성 향상을 위해 제어 현장에 IT 기술은 계속 도입되어 가지만, IT 지식은 아직 현장에 침투해 있지 않다.

그대로 적용할 수 없는 정보계 시스템의 시큐리티 대책

여기까지 설명했듯이 빌딩 제어 시스템의 시큐리티 대책에는 정보계 시스템의 개념을 그대로는 적용할 수 없는 것이 많다. 적용하는데 있어서는 어떠한 대책이 필요하다. 여기서는 이미 언급한 시스템 업데이트와 바이러스 대책 소프트웨어 도입 이외에 대표적인 것을 설명한다.

1. 감시․제어 단말의 로그인 ID․비밀번호의 설정

앞에서 말한 바와 같이 빌딩 제어 시스템은 주로 방재센터에서 집중 제어되고 있다. 정보계 시스템의 개념에서는 이 방재센터 내의 시스템 감시․제어 단말의 조작자를 제한하거나 조작 내용을 기록하기 위해서는 로그인 ID와 비밀번호를 설정하는 것이 당연하다고 생각한다. 그러나 빌딩 운영의 현장에서는 감시․제어 담당 직원은 고장 대응 등으로 자리를 비우는 경우도 있다. 이러한 상태일 때에 긴급한 조작 대응이 필요한 경우에 다른 직원이 로그인할 수 없어 조작할 수 없는 상태를 피하기 위해 ID나 비밀번호 설정을 하지 않고 운용하는 것이 일반적이다. 이것은 공장 등의 집중감시센터 등에서도 마찬가지이다.

물론 이러한 작업을 하기 위해서는 방재센터에 입퇴실을 엄격하게 관리하는 것이 전제이다. 더구나 조작자를 특정할 필요가 있는 것이라면, 감시 카메라 등으로 실내를 기록하는 등의 대책도 필요하다. 한편 소규모 빌딩 등에서 입퇴실을 엄격하게 관리할 수 없는 경우는 ID·비밀번호의 설정은 필수적인 것이 된다.

2. 컨트롤러의 ID·비밀번호 설정 및 정기적인 변경

빌딩 내에 설치되어 있는 컨트롤러나 IoT 기기에 모두 다른 ID·비밀번호를 설정하고, 비밀번호를 정기적으로 변경한다는 것은 소규모 빌딩에서도 수백 개, 대규모 빌딩에서는 수만 개나 되는 컨트롤러 등의 수로부터 생각해도 현실적이지 않다.

하지만 공격자의 시스템 내 침입을 방지하기 위해서도 ID·비밀번호의 설정은 필수인 것에는 변함이 없다. 그래서 컨트롤러와 IoT 기기의 ID·비밀번호는 모든 기기마다 다른 것을 사용하는 것이 아니라, 보수 작업 등을 고려해 공통의 ID·비밀번호를 이용하는 것도 필요하다. 대규모 빌딩의 경우는 빌딩 내 모두 공통의 ID·비밀번호를 사용하는 것이 아니라, 뱅크마다 변경하는 등의 조치도 효과적이다.

또한, 이러한 ID·비밀번호 설정은 빌딩의 건축 현장에서 대응할 수 있는 것은 아니다. 공장에서 출하 전에 설정 변경을 완료해 둘 필요가 있다. 그러기 위해서는 발주 시에 건축업자에 대한 사양서에 기재해 둬야 한다.

3. IPS(침입 방지 시스템)․IDS(침입 검지 시스템)의 도입

IPS와 IDS를 도입해 시스템 내를 감시하는 것 자체는 시큐리티 대책으로는 나쁜 것은 아니다. 단, 빌딩이나 공장의 시스템에 도입하는 경우에는 이하와 같은 문제점이 있으므로 도입 시에는 신중하게 검토할 필요가 있다.

우선 첫 번째로는 IPS·IDS를 감시하는 인재의 문제가 있다. IPS·IDS를 도입해도 그 경보 등의 의미를 이해할 수 있는 인재가 빌딩이나 공장 현장에는 없다. 또한, 인재가 있다고 해도 외부와의 통신이 엄격하게 제한되어 있는 시스템에서는 외부와 빈번하게 통신하는 정보계 시스템에 비해 경보가 나는 빈도는 상당히 적다고 생각되며, 인재를 유효하게 활용할 수 있다고는 생각할 수 없다.

두 번째는 코스트의 문제이다. IPS·IDS는 고액이며, 빌딩이나 공장 한 동 한 동에 도입하기에는 부담이 너무 크다. 도입은 코스트가 들더라도 지켜야 하는 시설에 한정될 것이다.

4. 로그의 취득

시스템 내에서 무엇이 일어났는지 어떠한 조작이 이루어졌는지를 확인, 시큐리티를 향상시키기 위해 로그의 취득은 중요하다. 단, 제어 시스템의 경우는 원래 네트워크 내에 흐르는 통신의 양은 정보계에 비교하면 매우 적고, 그렇기 때문에 네트워크 자체도 다량의 통신에 견딜 수 있도록 설계되어 있지 않다. 로그의 취득도 함부로 실시하면 네트워크를 압박할 가능성이 있기 때문에 취득하는 로그의 종류를 충분히 검토한 후에 선택할 필요가 있다.

정보계 시스템의 경우에는 기본적으로 정보를 지키는 점에 시큐리티의 주 목적이 있고, 그것을 감시할 수 있는 로그가 취득되어 있다. 제어 시스템의 경우는 정보를 지키기보다는 대상의 제어기기를 적절하고 안전하게 제어하는 ​​것이 중요하며 이에 필요한 로그를 취득해야 하는데, 그것이 어떤 로그의 조합인지의 여부는 그다지 연구되어 있지 않다. 요약하면, 어떤 로그가 중요한지의 여부 판단은 아직 되어 있지 않는 것이 실정이다. 제어 대상마다 필요한 로그의 종류는 다르기 때문에 업계마다 취득해야 할 로그는 무엇인지를 연구할 필요가 있다. 또한, 로그의 취득법과 어디에 보관할지도 검토해야 한다. 공격자는 로그 자체를 조작하거나 공격 대상으로 하는 경우도 있다. 또한, 로그 서버가 가득 차있기 때문에 시스템 전체가 정지하는 등의 주객전도한 일이 되어서는 안 된다.

그리고 가장 중요한 것인데 로그는 취득하는 것만으로는 의미가 없고, 시스템이 정상적으로 가동하고 있는지 항상 로그를 확인하는 체제를 구축해야 한다.

5. 바이러스 감염 시의 대응

정보계 시스템이 바이러스에 감염됐을 때에는 감염이 의심되는 PC나 서버를 네트워크에서 분리하는 것이 초기 대응으로서 권장되고 있다. 그러나 제어 시스템의 경우는 다르다. 제어 시스템의 경우는 네트워크의 분리는 기본적으로 할 수 없다고 생각할 것이다. 일반적으로 제어 시스템은 지속적으로 가동을 계속하는 가용성이 중요하며, 일부의 PC나 서버를 분리하는 것은 시스템의 정지로 이어질 가능성이 있다. 시스템을 정지시키기 위해서는 시스템에 의해 절차가 규정되어 있으며, 그것에 따라 정지시키지 않으면 경우에 따라서는 크게 안전성을 저해할 가능성조차 있다.

바이러스 감염에 의한 증상을 확인하면서 어떻게 시스템을 안전하게 정지시킬지를 검토한 후에 대응하는 것이 요구된다.

최근의 빌딩 제어 시스템에서 볼 수 있는 시큐리티 상의 문제점

다음으로 현재 실제로 가동하고 있는 빌딩이나 공장의 제어 시스템에서 자주 볼 수 있는 시큐리티 상의 문제점이나 운용면의 문제점을 들고 싶다. 상당히 많은 현장에서 볼 수 있는 것도 있기 때문에 꼭 이 관점에서 자사의 제어 시스템을 확인해서, 사이버 시큐리티 향상에 도움이 되길 바란다.

1. 네트워크가 단일

이것은 빌딩 제어 시스템에 자주 있는 문제로, 공장 등에서는 그다지 보이지 않는다. 시스템의 네트워크에 세그먼트가 잘려져 있지 않고 모든 기기가 동일한 계층 내에서 연결되어 있다. 이러한 네트워크의 경우, 네트워크 내의 기기가 바이러스 감염되면 모든 기기가 감염되어 버릴 가능성이 높다. 또한, 공격자가 네트워크 내에 침입한 경우에도 네트워크의 전체상을 쉽게 파악할 수 있게 된다.

2. 공장 출하 시 그대로의 ID·비밀번호

빌딩에 설치되어 있는 컨트롤러의 ID·비밀번호가 공장 출하 시 그대로의 상태로 되어 있는 케이스가 많다. 이 경우는 공격자가 쉽게 제어를 점령하는 것이 가능해진다. 컨트롤러가 이 상태인 경우는 IoT 기기도 거의 동일하게 공장 출하 시의 그대로의 상태로 되어 있다.

3. 최신 기기 네트워크도가 정비되어 있지 않다

빌딩이나 공장 신축 시의 네트워크도는 납품도서로서 정비되지만, 그 후의 갱신이 반영되지 않고 최신 상태가 불명확한 케이스가 대부분이다. 이 경우 바이러스 감염 등이 발생했을 때에는 감염 범위를 특정할 수 없어 대응에 시간이 걸릴 위험성이 있다.

4. 장비의 적절한 백업이 없다

빌딩 제어 시스템뿐만 아니라 다른 제어 시스템에서도 마찬가지로 컨트롤러 등의 적절한 백업이 되어 있지 않는 경우가 많다. 이것도 바이러스 감염 시에 수복에 시간이 걸리게 된다. 백업 방법에 대해서는 모든 기기가 동일할 필요는 없으며, 디스크 이미지를 취득하는 등의 풀 백업, 프로그램만을 준비하는 것, 설정 수치만을 기록하는 것 등 백업 방법은 기기에 따른 것으로 한다. 또한 이 작업은 빌딩이나 공장의 현장 직원만으로는 대응할 수 없기 때문에 시스템 벤더에 의뢰하는 보수 업무에 포함시키는 것이 바람직하다.

5. 에너지 절약 관련 시스템 접속을 위한 안전하고 쉬운 정보계 시스템과의 접속

최근에는 에너지 절약의 관점에서 빌딩이나 공장의 에너지 사용량을 감시하고 있는 기업이 많다. 또한, 정부나 지자체에 사용량 보고가 의무화되어 있는 사업소도 있다. 그 사용량을 파악하기 위해 전력미터기 등으로부터 직접 사용량 데이터를 취득하는 시스템을 구축하고 있는 사업소도 많은데, 이때 어떤 시큐리티 대책도 강구하지 않고 전력미터기에서 데이터를 취득해 결과적으로 제어 시스템이 외부 시스템과 시큐리티 대책 없이 연결되는 케이스를 볼 수 있다.

또한, 에너지 사용량을 관리하는 부서는 주로 총무계 부문이 되기 때문에 데이터 취득 후 기업 내 인트라넷을 통해 데이터 수집을 하고 있는 사업소도 있다. 이 경우, 결과적으로 제어 시스템과 기업 인트라넷이 직접 연결되어 매우 위험한 상황이 되는 케이스도 볼 수 있다. 데이터 관리가 주로 총무계 부문이기 때문에 건물이나 공장의 시스템 담당과 충분한 의사소통이 없이 공사가 진행된 결과인 것 같다.

6. 각종 설비 시스템에서 부적절한 프린터 공유

빌딩이나 공장의 시스템은 시스템의 가동 상황을 확인하기 위해 일보나 월보로 확인하는 것이 있다. 기본적으로는 시스템마다 프린터가 설치되지만, 여러 개의 시스템을 이용하고 있는 경우에는 프린터의 유효 이용을 위해 시스템 간에 공유되는 경우가 많다. 공유 설정은 시스템 신설 시에는 적절한 시큐리티 관리가 이루어지고 있지만, 시스템 증설이나 교체 시, 갱신 시에 프린터 접속 설정이 변경되어 여러 개의 시스템이 의도하지 않게 접속되는 경우도 볼 수 있다. 이와 같은 케이스는 그리 많지는 않지만, 프린터를 통해 사내 시스템이나 경우에 따라서는 인터넷으로 이어지는 경우도 있어 충분한 주의가 필요하다.

7. 분전반 등의 열쇠가 공통

분전반의 핵심은 본래 문이 부주의하게 개폐돼 감전되는 것을 방지하기 위해 설치된 것으로, 시큐리티 확보를 목적으로 하는 것은 아니다. 그렇기 때문에 작업 효율을 중시해 대부분의 분전반 열쇠가 특정 메이커의 특정 품번의 열쇠가 사용되고 있다. 그러나 최근 설비에 IT 기술이 도입됨에 따라 분전반 내에 컨트롤러 등이 설치되는 경우가 많아져 시큐리티 확보의 필요성이 높아지고 있음에도 불구하고 열쇠는 공통인 상태 그대로가 이어져, 결과적으로 시큐리티 상의 문제점이 되고 있다. 일반적으로 설비 발주 시에 빌딩이나 공장의 오너가 분전반의 열쇠까지 지정할 수 없기 때문에 관습적으로 동일한 열쇠가 사용되는 케이스가 많은데, 발주 시에 열쇠의 종류․기능을 지정하고 시큐리티 향상을 도모하는 것이 필요하다.

마지막으로

이 글에서 설명한 빌딩 제어 시스템의 시큐리티 상의 문제점에 대응하기 위한 구체적인 대책이나 개념은 가이드라인에 제시되어 있으므로 참조하기 바란다. 작성에 있어서는 멤버 사이에서는 가급적 현장 쪽에서 알기 쉬운 표현으로 작성하고, 또한 IT 기술면에 치우치지 않게 운용면의 대책도 중시하면서 작성하는 것을 의식해 왔다. 그리고 빌딩의 시큐리티 대책을 추진하는데 있어 필수적인 규제가 아니라, 어디까지나 시큐리티 대책의 지표를 제공하고 대책의 실행 가부는 빌딩 오너가 선택하면 되는 것으로 자리매김했다.

단, 이 가이드라인은 대책의 구체적인 사례를 제시하는 것까지는 다룰 수 없었기 때문에 조속히 구체적인 대책을 해설하는 가이드라인의 상세판을 작성하기로 관계자는 합의했다. 이 가이드라인이 출시되어 빌딩 업계의 시큐리티에 대한 의식이 조금이라도 향상되기를 기원한다.

와타나베 소우이치, 이힐스주식회사