무서운 핵(hack)과 loT와 관련된 보안 침입에 대한 부족 현상은 없다. Stuxnet을 예로 들어보자. 이것은 보고된 바에 따르면 컴퓨터 산업 PLCs와 SCADA 시스템을 공격하기 위해 설계된 컴퓨터 웜으로써 이란의 핵 연구 프로그램에 의해 사용된 수 백 개의 원심 분리기를 파괴하기 위해 사용되어 지곤 했다 [ST1]. 아니면 환자들을 50피트 밖으로 보내버릴 수 있는 높은 볼트의 충격을 가능하게 만들었던 특정 종류의 심박 조율기의 핵(hack)을 고려해 보자 [DR2]. 아니면 Charlie Miller와 Chris Valasek이 어떻게 DEF CON 해킹 회의에서 전자 조종, 제동, 가속, 엔진 그리고 두 가지의 잘 알려진 자동차 종류들의 다른 특징들을 그들이 조종할 수 있는지 보여줬는지 살펴봐 보자. 우리가 만든 솔루션을 가까스로 보안 장치를 한다면 loT가 유일한 성공적인 방법이 될 것이라는 것은 꽤 명백해 보인다. 많은 사람들은 복잡하고 분배된 IT 시스템을 100% 안전하게 보호하는 것이 절대 가능하지 않을 것이라고 동의할 것이다. 따라서 생각할 수 없는 부분을 생각하고 결과를 미리 준비하는 것이 문제의 또 다른 부분이다.

loT 분야의 많은 선두 회사들이 loT 보안에 대해 매우 사전 대책을 강구하는 접근법을 취하고 있다. 예를 들어 Tesla Motors라는 전기 차 제조업체는 취약성 테스트와 그들의 차의 보안을 감독하기 위해 Kristen Paget라는 유명한 선량한 해커를 고용했다. 그의 첫 번째 작업으로, Paget은 차량을 조종할 수 있는 소프트웨어 상의 보안 취약점을 규명하는 데 필요한 더 많은 해커들을 고용하기 위해 Tesla 차량을 DEF CON 회의에 가져갔다 [DR1].

아래에서 우리는 loT 상의 다른 보안 개념들을 살펴봄으로써 토론을 시작할 것이다. 아래의 수치는 우리의 Asset Integration Architecture에게 주요 보안 개념을 보여준다. 각각의 것들을 우리가 앞으로 간단히 의논해 볼 것이다.

자산 하드웨어 보안 (1): 보통 데이터 서버에의 물리적 접근을 막는 것은 상대적으로 쉽다. 하지만 자산들이 현장에서 효율적으로 사용되고 자산 하드웨어의 물리적 접근을 막는 것이 종종 불가능해질 것으로 보이기 때문에 loT에서는 상황이 매우 다르다고 할 수 있다. 여기서 한가지 중요한 접근법이 TPM (Trusted Platform Module)이다. 이것은 장치에 암호화 키를 통합함으로써 하드웨어를 보호하기 위해 설계된 암호 보조 처리기를 보안하기 위한 국제적인 기준이다. Escrypt [ES1]로부터 나온 CycurHSM 같이 Hardware Security Modules (HSM)은 자동차 산업에 종종 사용된다. HSM은 보통 CPU 코어, 다른 종류의 데이터 저장소, 메모리 보호 단위, 메모리 부호 매김 단계, 센서 그리고 암호화 액셀러레이터로 구성되어져 있다. HSM은 보통 결함을 발견하기 위한 활동적인 센서들과 글리치 공격과 같은 물리적 공격에 대한 대책을 지원할 것이고 사이드 채널 공격에 대항하여 더 강화된 암호화 이행을 이용할 것이다 [ES1]. . 자산의 효율적으로 배치된 보안 특징에 기반을 둔 소프트웨어는 방화벽, 포트 필터링, 신분 확인, 중요 요소 관리, 그리고 안티 바이러스 기능성들을 종종 포함한다. loT 상에서의 가동하는 기술에 대한 전통적인 서버 사이드 보안의 확장은 McAfee와의 전략적인 인수로 loT에서 그들의 결합된 역량을 매우 확장시킨 Intel 사와 같은 회사들에게는 매우 일반적인 전략이다.

보안 의사소통 (2): 자산과 백엔드 사이의 의사소통 보안을 확인하는 것은 다는 아니더라도 많은 loT 솔루션을 위해 필수적이다. 대부분의 솔루션들은 어플리케이션 층 (Transport Layer Security 또는 TLS와 같은)에 또는 IP 프로토콜 층 (Internet Protocol Security 또는 IPsec 같은)에 있는 암호화 기술들을 활용한다. 이러한 기술들에서 한가지 중요한 차이점은 그들이 큰 규모의 장치를 위해 행정 수뇌부에 영향력을 미치는 방화벽과 횡단 NAT를 어떻게 다루는 가이다. 또한 암호화와 더해 Transparent Network Substrate (TNS) 기술들은 인증 부분을 다루고 있다.

자격 관리 (3): 자격은 Transport Layer Security (TLS)의 중요한 부분이라고 할 수 있다. 자격증은 공개 키의 소유권을 입증하기 위한 전자적 문서이다. 자격증은 키와 그것의 주인 정체성, 그리고 자격증 내용이 올바르다는 사실을 증명하는 디지털 서명에 대한 정보들을 포함한다. 큰 규모의 loT 환경에서 효과적인 자격 관리는 필수적이기 때문에 자산들과 장치들은 그 자신들이 진짜임을 증명하고 백엔드에서 안전하게 의사소통할 수 있을 것이다.

AAA (4): 종종 단순하게 AAA라고 불리는 입증, 허가, 그리고 회계업무는 어플리케이션에의 접근을 조종하고, 정책을 강화하고, 사용을 감사하기 위해서 설계된 틀이라고 할 수 있다. loT에서 이것은 매우 중요해질 것이다. 어떤 건설 장비의 조각이 건설 장소를 떠나도록 요청하고 있는가? 현재의 스케줄에 따르면 이러한 장비가 그렇게 하도록 허가하고 있는가? 만약 그렇다면, 그것이 남긴 것에 대해서 메모를 해보자.

백엔드 보안 (5+6): 마지막으로 우리는 백엔드와 사회 기반 시설에 대한 보안 장치를 강구해야만 한다. 이것은 Denial of Service (DoS) 공격, Intrusion Detection Systems (IDS), 방화벽, 패킷 필터링, 그리고 리버스 프록시에 대한 방지를 포함할 것이다.

                            Security concepts in the IoT – mapped to the AIA
                            

앞서 본 바와 같이, loT 시스템 보안에 사용될 수 있거나 사용되어야 하는 다양한 기술과 개념들이 존재한다. 솔루션 개발자의 관점에서 볼 때 중요한 것은, 보안은 시스템의 근본적인 부분에서부터 구축되어야 한다는 점이다. 이는 보안 설계 [SD1]라고도 한다. 보안 설계는 시스템에 대한 공격은 물론, 보안 취약점이 발견되었을 때 받게 될 영향을 줄인다. 또 다른 중요한 특징은 모든 것이 가능한 한 최소한의 권한만으로 수행된다는 것이다.

“loT 프로젝트 시작” 부분에서 우리는 교차 업무에 있어서 보안이 중요하다고 추천한다. 이를 분명히 하는 것만이 loT 프로젝트에 포함된 다른 모든 교차 업무의 보안 설계를 해낼 수 있는 방법이다.

우리가 보안 설계의 아이디어에 대해 믿는 만큼, 모든 loT 프로젝트는 확실한 보안 테스트 전략이 필요하다. 가장 좋은 방법은 보안 침투 테스트만을 위한 하나의 팀을 조직하는 것이다. 여기에는 두 가지 방법이 있다. 첫째는 시스템에 대한 전반적인 지식을 갖고 있는 팀 구성원에 의해 수행되는 화이트 테스트이고, 둘째는 좀 더 현실적인 시나리오를 위해서 시스템 내부에 대한 지식이 없는 외부의 제삼자에 의해 수행되는 블랙 테스트이다.

Open Web Application Security Project (OWASP) Top Ten은 웹 어플리케이션의 잠재적 리스크와 관련된 가장 인기 있는 목록이다. OWASP는 또한 연간 발생하는 보안 문제 top 10개의 목록도 발행하기 시작했는데 [OW1], 이 목록에 근거하여 InfoSec Institue는 loT솔루션을 위한 구체적인 테스트 전략을 제시하였다 [1S1]:

• 안전하지 않은 웹 인터페이스를 사용하는 loT 장치 테스트: OWASP에 따르면 다음과 같은 loT 장치의 경우, 각 장치가 제공하는 웹 사이트를 검색할 때 장치 별 표준 포트 스캐너를 사용하기를 추천한다.
 초기 설치 중에 변경되어야 하는 경우
 복잡한 비밀번호가 강요되는 경우
 교차 사이트 스크립팅을 검토하는 경우
 SQL 주입
 사이트 교차 요청 위조에 취약한 경우

• 인증/승인 부분이 취약한 loT 장치 테스트: 이는 다음과 같은 표준 테스트를 포함한다.
 설치 초기 비밀번호의 취약성 테스트
 비밀번호 완전성 인식 테스트(비밀번호를 입력하지 않았거나 모두 입력하지 않은 경우)
 (암호화되지 않았거나 불완전하게 암호화된 비밀번호를 찾는 경우에) 프록시와 스니퍼의 사용여부 테스트

• 안전하지 않은 네트워크 서비스를 사용하는 loT 장치 테스트: 이 테스트에는 Tenet, FTP, Finger, TFTP, SMB와 같은 중요 서비스를 찾기 위한 침투 테스트 툴(Nessus 또는 Open VAS)과 같은 포트 스캔 툴(Nmap)이 포함된다.

• 암호화 전송이 되지 않는 loT 장치 테스트: 커뮤니케이션을 적절히 암호화하는 기본 테스트

• 개인 정보 문제와 관련된 loT 장치 테스트: 개인 정보(ex.집주소), 금융 정보(ex. 신용카드번호) 건강정보 등

• 안전하지 않은 클라우드 인터페이스를 사용하는 loT 장치 테스트: loT솔루션의 백엔드 서비스는 타 웹 어플리케이션이 직면하는 문제와 같은 문제에 직면할 수 있다. 따라서 loT장치 테스트 역시 HTTPS사용 여부 체크, 사용자명 수집 또는 무차별 대입 시도와 같은 기본적인 테스트를 포함한다.

• 안전하지 않은 모바일 인터페이스를 사용하는 loT 장치 테스트: 몇몇 loT 장치는 무선 접속기기(WAPs)와 같이 작동하므로 보안테스트가 필요하다.

• 보안 설정이 불완전한 loT 장치 테스트: 비밀번호 정책 시행, 데이터 암호화, 그리고 접속 레벨의 다양화와 같은 기본적인 점검

• 안전하지 않은 소프트웨어/펌웨어를 사용하는 loT 장치 테스트: 이 테스트는 모든 원거리 소프트웨어 업데이트가 안전하게 암호화되었는지 확인한다. 이 테스트를 통해 loT 장치가 악성코드에 감염되는 것을 방지할 수 있다.

• 물리적 보안이 취약한 loT 장치 테스트: 이 마지막 테스트는 저장매체의 제거, 저장된 데이터의 암호화, USB와 같은 포트의 물리적 보호, 분해 위험, 그리고 불필요한 포트의 불능화 등을 체크하는 것이다.

위에 언급된 기술과 프로세스는 loT 보안에 있어 중요한 요소들이다. 그중 하나만으로는 보안이 유지되기 어렵다. 복잡하고 높은 수준의 보안이 요구되는 loT 솔루션을 개발하는 사람들은 특히 loT 안전 프로그램의 실행에 주목해야 할 것이다. I Am the Cavalry와 같은 조직을 예로 들어보자. I Am the Cavalry는 자동차의 산업분야의 컴퓨터 보안과 공공 안전의 교차점에 집중하는 작은 조직이다. 2014년 DEF CON 해킹 회의에서 공개적으로 그들은 5가지 자동차 사이버 안전 프로그램을 제시하였다 [FS1]. 이 프로그램은 다음과 같이 구성되어 있다.

안전에 기반을 둔 설계 (1): 이러한 프로그램은 안전한 소프트웨어 개발 라이프 사이클을 발행해야 하는데, 다음과 같은 주요 구성요소를 사용해야 한다. ISO, NIST와 같은 표준, 추적 가능한 하드웨어, 소프트웨어 공급체인.
타 그룹과의 협력 (2): 이 프로그램에는 타 그룹 연구진과의 합동 연구 결과를 공개하는 정책도 포함된다. 여기에는 버그 보고에 대한 “안전과 보상” 시스템을 통해 긴밀한 협업을 이끌어 내는 것도 필요하다.
증거 확보 (3): 차량은 안전 조사를 용이하게 하기 위해 임의 조작에 대한 과학적으로 탄탄한 증거 확보 기능을 지원해야 한다.
보안 업데이트 (4): 치명적인 버그에 대비하기 위해 즉각적이고 믿을 수 있으며 안전한 차량용 원격 소프트웨어 업데이트가 가능해야 한다. 이는 매우 중요하다. 왜냐하면 소프트웨어 사용이 증가하면서 더 많은 업데이트가 필요하게 되었고 수백만 대의 차량이 출고되는 만큼 리콜은 대안이 될 수 없기 때문이다.
분할과 고립 (5): 중요 시스템과 그렇지 않은 시스템을 나누기 위해 물리적, 논리적 고립과 같은 수단이 실행되어야 한다.

드디어, 우리는 loT 개인 정보 보호 정책을 살펴보게 될 것이다. 비록 이것은 정확하게 기술 프로파일이라고 할 수는 없지만, 악의적 공격을 막기 위해 탄생한 것이 보안이라는 점에서 볼 때 loT 솔루션 공급자는 개인 정보 보호 정책에 대한 정의를 우선 내릴 필요가 있다. loT 보안 연구소에서는 Google Nest 개인정보 보호정책을 만들었는데 이는 다음과 같이 정의된다 [IL1]:

• 개인 정보 보호 정책은 찾기 쉬워야 한다. 예를 들면 각 페이지마다 링크가 들어가야 한다.
• 개인 정보에 대한 요약은 사용자를 대상으로 하는 것이지 변호사들을 위한 것이 아니다.
• 개인 정보 보호 정책은 보안에 대한 것이어야 한다.
• 구매자가 개인 정보에 대한 사용과 보유를 결정할 수 있어야 한다. 즉, 누가 볼 수 있으며 얼마나 사용될 수 있는지는 구매자가 정해야 한다.
• 웹과 장치의 개인 정보 보호 정책은 분명하게 나누어져야 한다.
• 큰 데이터 시대인 만큼 데이터는 발표되기 전에 익명으로 만들어져야 한다.
• 개인 정보에 대한 접근은 Q&A 메일과 같은 방법이어야 한다.

많은 구매자들에게 있어 개인 정보 보호 정책은 제품을 사고 이용하려는 의지를 결정할 것이다. loT솔루션 공급자들은 이러한 정책들을 정의하고 실행하는데 큰 노력을 기울일 필요가 있다.

선두적인 보안 솔루션 공급업체인 ESCRYPT의 책임자 Thomas Wollinger 박사와의 대화를 통해 loT보안에 대한 전망을 들어보자.

Dirk Slama: loT어플리케이션 보안 솔루션의 주요 요소에는 무엇이 있을까요?

Thomas Wollinger: 암호와 관련된 기초적인 요소들이 loT 어플리케이션을 보호하는데 사용될 수 있겠습니다. 경우에 따라 다양한 보안 목적이 있을 수 있겠는데, 이를 따르는 것이 적절하겠지요. 예를 들면, 전송된 데이터에 대한 기밀 유지에는 데이터 암호화가 사용될 수 있겠습니다. 또한 어플리케이션은 데이터 조작으로부터 보호받을 필요가 있습니다. 이는 전자서명과 같은 메커니즘을 사용함으로써 가능합니다.

모든 암호 관련 기초 요소는 어플리케이션의 라이프 사이클 내내 보안 키에 의해 관리되어야 합니다. 보안 키 관리는 필수적입니다. 보안 키는 무작위로 설정되어야 하며 그 분배와 저장 역시 중요합니다.

Dirk Slama: 이 모든 것이 오늘날 가능한 겁니까? 아니면 앞으로도 보완되어야 할 점이 있을까요?

Thomas Wollinger: 기술은 이미 갖추어져 있습니다만, 특정한 목적을 가진 loT 어플리케이션에 적응하기 위해선 조정이 필요합니다. 첫째로, 암호 기초 요소와 보안 키 길이와 같은 변수는 loT 플랫폼에 맞춰 세심하게 선택되어야 합니다. 대부분의 loT 플랫폼은 연산 능력과 메모리가 꽤 제한적입니다. 더욱이 loT어플리케이션은 PC와는 반대로 사용자 중심이 아닌 장치 중심 방식으로 작동합니다. 따라서 사용자 인증 대신, 장치 인증 방식이 사용되어야 합니다. 하지만 장치나 플랫폼에서 특별히 요구되는 것이 무엇이든지 간에, 보안이란 단순히 장치나 어플리케이션의 수명에 맞춰 더해질 수 있는 특성이 아닙니다. 정말 안전한 장치를 만들려면 라이프 사이클을 통틀어서, 이를테면 설계부터 시작해서 실행까지 모든 부분에 있어 보안을 신경 써야 합니다. 각 단계마다 보안 관련 적정 수준과 장애물이 있기 때문입니다.

Dirk Slama: 어떻게 프로젝트 책임자가 loT 보안을 단계적으로 다룰 수 있을까요? 체크리스트는 어떤 식일까요?

Thomas Wollinger: 일단 보안 분석을 수행하는 것이 중요합니다. 모든 가능한 보안 위협과 그에 따른 적절한 대안을 찾기 위해서지요. 이 분석을 통해 보안에 필요한 사항, 예를 들면 암호 기초 요소, 프로토콜, 변수 등을 끌어낼 수 있겠습니다. 그러면 이것들이 설계에 반영될 것입니다. 이어서 설계된 시스템이 실행되고 테스트 되겠죠. 코드 리뷰와 보안 테스트는 loT 시스템이 고객에게 전달되기 전에 의무적으로 시행되어야 합니다.

Dirk Slama: 프로젝트 책임자는 loT를 위한 보안 테스트를 어떻게 수행해야 합니까?

Thomas Wollinger: 보안 테스트는 어플리케이션 개발에 있어 필수적인 부분이 되어야 합니다. 게다가 개별 테스트, 통합 테스트, 퍼즈 테스트를 포함한 침투 테스트 또한 고려되어야 합니다.

Dirk Slama: 절대적으로 안전한 솔루션은 없다고 가정했을 때, 긴급사태에 대한 대책은 어떠해야 합니까? 프로젝트 책임자는 솔루션을 시행하기 전에 무엇을 고려해야 할까요?

Thomas Wollinger: 목적을 확실하게 하기 위해서 그리고 오해를 피하기 위해서 말씀드리자면, 앞으로도 절대 100% 안전한 솔루션은 없을 겁니다. 소프트웨어에는 버그가 있을 수 있습니다. 몇몇은 찾기 매우 어려워요. 더욱이 미래에 새로운 취약점들이 떠오를 수 있습니다. 예를 들면 도서관에 버퍼 과부하가 걸리는 것처럼요. 그래서 시스템은 안전한 펌웨어 업데이트를 갖추고 있어야 합니다. 가장 편리하고 비용이 적게 드는 방법은 무선 업데이트입니다. 이때 장치가 읽어 들이기 전에 펌웨어가 인증되어야 합니다. 업데이트가 합법적인 공급자로부터 제공되었는지 확인이 되어야 악의적인 공격으로부터 방어할 수 있기 때문입니다. 다시 말씀드리자면, loT장치 보호에 있어서 암호 기본 요소와 보안 키 관리는 중요 요소입니다. 우리는 또한 자주, 말하자면 매년 전체적으로 보안 분석을 실행하기를 추천합니다. 이를 통해 가장 최근의 공격 벡터를 고려할 수 있습니다.