일부 마케팅 문구에 가려진 보안의 진짜 현실이 있다. 전문가들이 꼽는 가장 중요한 문제 - 그러므로 가장 시급히 해결해야 할 문제 - 는 무엇일까? 7가지로 추려보았다.
[보안뉴스 문가용 기자] 보안 업계도 마케팅 문구가 남발하는 곳이다. 그 속에서 ‘진짜 현실’은 가려진다. ‘진짜 현실’은 무엇일까? 예를 들어 보안 업체 설트시큐리티(Salt Security)의 기술 에반젤리스트인 마이클 이스빗스키(Michael Isbitski)는 “보안의 ‘진짜 현실’이라는 건 시대마다 달라진다”며 “최신 IT 기술의 기반이자 핵심이 되고 있는 API를 보호하는 게 지금 시대에는 보안의 ‘진짜 현실’”이라고 말한다. 이번 주 주말판에서 본지는 현 시대에서의 ‘진짜 보안 현실’을 찾아 나섰다.
1. 클라우드 ‘애플리케이션’이 현실이다
많은 조직들이 클라우드를 빠르게 도입하고 있다. 그러면서 클라우드에 맞는 보안 도구들에도 투자를 하고 있는 상황이다. 주로 클라우드 내 저장된 워크로드를 보호하는 데 특화된 도구나 컨테이너 보안 도구라는 이름표를 단 도구들을 사들인다. 이스빗스키는 “그러한 도구들은 이미 공개된 취약 디펜던시들이나 설정 오류, 워크로드의 마이크로세그멘테이션 오류 등을 탐지해 바로잡는 데에는 큰 도움이 된다”고 말한다. 하지만 그런 오류들이나 취약점들은 최초 침투의 발판이 될 뿐, 그 후에 일어나는 악성 행위에 대해서는 별 다른 효력을 발휘하지 못한다고 그는 지적한다.
“클라우드 보안 도구들에 대한 투자가 이뤄지고 있긴 하지만 대부분의 경우 핀트가 어긋나 있습니다. 애플리케이션 레이어의 보안은 아직도 미비하다는 뜻입니다. 아직은 네트워크 보안과 인프라 보안에 좀 더 집중되어 있습니다. 클라우드 애플리케이션들은 아직 취약합니다. 공공 클라우드는 튼튼한 보안을 가지고 있을지 모르겠지만, 그 클라우드의 고객사인 당신이 만드는 인하우스 앱들이 튼튼하다는 뜻은 아니라는 겁니다.”
2. ‘쉬프트 레프트’가 중요한 만큼 ‘쉬프트 라이트’도 유효하다
‘쉬프트 레프트(shift left)’라는 말이 어느 순간부터 보안 업계의 큰 유행어가 되었다. 보안 기능을 소프트웨어 개발 초기 단계에부터 고려해야 한다는 뜻으로 쓰이는 말인데, 이는 “데브섹옵스(DevSecOps)를 도입하자는 말과 동일한 표현”이라고 이스빗스키는 설명한다. 물론 취약한 소프트웨어가 출시일 당긴다는 핑계로 일찍 시장에 나오는 작금의 현상을 타파하는 데 필요한 개념임에는 분명하다. 실제 많은 기업들이 ‘쉬프트 레프트’ 전략을 도입해 적잖은 이익을 보기도 했다.
“하지만 ‘쉬프트 레프트’니 ‘데브섹옵스’니 하는 것의 근간에 있는 건 ‘보안 우선주의’가 절대 아닙니다. 출시일을 당기기 위해 개발된 작업 프로세스입니다. 출시일도 당기고 보안도 강화하는 방법은 없습니다. 둘은 상충할 수밖에 없어요. 그 누구도 무결점의 완벽한 코드를 만들지 못하고, 그 어느 회사도 보안을 위해 소프트웨어 완성 과정 중에 주기적인 코드 스캐닝을 하지 않습니다. 게다가 한다고 해도 알려진 취약점을 찾아내는 것뿐이지 제로데이와 같은 취약점이 발견된 확률은 낮습니다.” 이스빗스키의 설명이다.
포레스터(Forrester)의 분석가인 샌디 카리엘리(Sandy Carielli)는 “‘왼쪽으로 옮기라(쉬프트 레프트)’라는 말이 급작스럽게 퍼지면서 사람들이 ‘오른쪽을 배제하라’는 식으로 오해하기 시작했다”고 말한다. “새로운 기술의 공격과 제로데이 취약점 발굴은 끊임없이 나타나는 현상입니다. 개발 과정 중에 있는 애플리케이션에 대한 공격도 방비해야 되는 때죠. 기존의 개발 및 보안 방식과 ‘쉬프트 레프트’의 개발 및 보안 방식에서 좋은 것들을 다 사용할 줄 알아야 합니다.”
3. WAF와 게이트웨이가 API를 완전히 보호하지 못한다
이스빗스키는 “현대 애플리케이션들의 근간이 되는 건 API”라고 강조한다. “하지만 아직 API 보안의 중요성이 보편화되지는 않고 있습니다. API가 가진 위험성에 대해 이해하는 곳도 드물죠. 공격자들에게 API는 현재 가장 매력적인 표적입니다. 그런데도 대부분의 조직들은 WAF와 API 게이트웨이 만으로 충분하다고 여기고 있습니다. 현실은 어떨까요? 이 두 가지는 현존하는 API 공격 유형 대부분들을 막지 못합니다. 오히려 ‘이제 괜찮아, 안심해도 돼’라는 잘못된 안도감만 주죠.”
이스빗스키는 “API들은 모든 조직들마다 고유한 특징을 가지고 있고, 그 사정도 고유하기 때문에 일반적이고 정형화된 패턴으로 공격이 이뤄지지 않는다”고 설명을 이어간다. “따라서 API의 행동 패턴과 활용 현황을 끊임없이 모니터링 하는 ‘런타임 보안’을 필요로 합니다. 이건 API의 공격 유형과 상관없이 기본 바탕이 되어 있어야 하는 부분입니다.”
컨설팅 업체인 옴디아(Omdia)의 수석 분석가인 릭 터너(Rik Turner)도 “WAF와 게이트웨이 이상의 API 보호 장치가 시급히 필요한 게 현실”임에 동의한다. “현대의 조직들은 수많은 애플리케이션들을 노출시킨 채 사업을 이뤄가고 있습니다. 이 말은 대량의 데이터가 노출되어 있다는 뜻도 됩니다. 이런 데이터는 API를 통해 교류되고요. 단순 ‘입구 방어’인 WAF와 게이트웨이로 불충분할 수밖에 없습니다.”
4. 전통적 차원의 패치/취약점 관리 도구들도 API를 보호 못한다
애플리케이션이나 OS를 보호하는 데 있어 취약점과 패치를 관리한다는 건 대단히 중요한 일이다. 그러나 API 보안 전략에는 적당치 않다고 이스빗스키는 지적한다. “공격자들은 이미 잘 알려진 취약점들을, 잘 알려진 익스플로잇 방법으로 공략합니다. 최근 익스체인지 사태를 통해 이 부분이 잘 드러났죠. 그러나 API를 겨냥한 공격에서는 공격자들의 행동 패턴이 조금 다릅니다. 조직마다 API의 특성이 다르기 때문이죠. 즉, 공격하려는 곳에 따라 새로운 취약점을 찾는 것이 일반적입니다. 또한 API를 위한 ‘패치’라는 것도 없죠.”
그러면서 이스빗스키는 “CVE보다 CWE에 좀 더 익숙해져야 한다”고 말한다. “CWE ID들이 인하우스 애플리케이션과 API에서 발견된 문제들을 분류하는 데 보다 적합합니다. 스스로 코드를 작성하는 일이 많고, 다른 API나 요소들을 조합해 애플리케이션들을 만들어 쓰는 경우가 많은 조직이라면 CWE와 OWASP에 좀 더 관심을 가져야 할 것입니다.”
5. 기본 보안 인식 제고 훈련으로는 절대 충분치 않다
최근 들어 보안 인식이 전반적으로 어느 정도 수준에 이른 상태다. 옴디아의 수석 연구원인 맥신 홀트(Maxine Holt)는 “기본 보안 인식 제고 훈련 덕분이라고 말할 수 없다”고 다소 박하게 평가한다. “지금의 보안 교육이 사용자들의 행동을 실제로 바꾸고 있나요? 솔직히 말해서 아니죠. 공격자들이 터트리는 사고들이 오히려 그런 면에서는 더 효과가 있습니다. 교육이 효과를 거두지 못하는 것은, 실천 사항 목록을 1년에 한 번이나 두 번 나눠주고 각자 읽어보라고 하는 식의 프로그램이 대다수이기 때문입니다. 보안 교육이란 것이 잊을만하면 한 번쯤 필수로 해야 하는 것 이상의 존재감을 드러내지 못합니다.”
홀트는 “대부분 조직들이 행하는 보안 교육 프로그램들은 시간 낭비, 종이 낭비, 인력 낭비인 것이 현실”이라고 말한다. “어떻게 해야 진짜로 임직원의 행동 패턴을 바꿀 수 있는지를 연구해야 합니다. 직원들 한 사람 한 사람의 특성을 파악하는 것에서부터, 조직적인 업무 프로세스를 분해하는 일까지 아울러야 하는 것이죠. 그리고 교육 시간 한 번에 모든 보안 관련 내용을 다 다루는 것도 금지입니다. 한 번에 하나씩만 가르쳐 줘도 사람들이 들을까 말까입니다.”
6. 최신 보안 도구가 조직을 안전하게 만들지 않는다
가트너(Gartner)의 부회장인 피터 퍼스트브룩(Peter Firstbrook)은 “최신 보안 도구에 대한 의존도가 높은 것도 위험한 일”이라고 말한다. “훌륭한 보안 인력을 구하기 힘든 상황이라 도구라도 최신 것을 써야겠다고 결정하는 마음을 이해 못하는 건 아닙니다. 문제는 그런 도구가 보안을 전부 책임져 줄 거라고 기대하고 다른 부분에서 해이해진다는 겁니다. 최신 도구를 비싼 돈 주고 설치해 놓고도, 기본적인 관리자 설정 오류로 데이터가 고스란히 노출되는 일, 우리 얼마나 많이 봅니까? 최신 도구의 기능을 온전히 다 활용하지도 못하는 곳이 태반이기도 하고요. 새로운 도구 때문에 정책에서 충돌이 생기는데도 이를 알아내지 못하기도 하죠.”
정책을 통해 안전한 행동 수칙을 정해둔다고 해서 모든 임직원이 안전하게만 행동하지 않는 것처럼, 보안에 돈을 덕지덕지 바르기만 한다고 해서 보안 문제가 해결되는 것도 아니라고 퍼스트브룩은 강조한다. “제품을 사지 말라는 게 아니고 정책을 만들지 말라는 게 아닙니다. 둘 다 꾸준한 관리와 사용 연습이 동반되어야 한다는 것이죠.”
7. 시장에 출시된 사물인터넷 장비들, 보안이 허술한 경우가 많다
옴디아의 에릭 파리조(Eric Parizo)는 “자동차 회사들, 가전제품 제조사들, 그 외 많은 사물인터넷 장비 업체들 전부 본질적으로 새로운 분야에서 사업을 하는 것과 마찬가지”라고 지적한다. “스마트폰과 마찬가지인 자동차가 만들어지고 있고, 네트워크 기술이 들어간 전자제품들이 나오고 있는데, 이건 사실 ‘컴퓨팅 기술’의 변화에 가깝습니다. 컴퓨팅에 대한 배경이 없는 회사들이 갑자기 컴퓨팅 진화의 한 복판에 끼어든 겁니다.”
그렇기 때문에 아무리 전통과 명성을 자랑하는 유명 기업이라고 하더라도 기본적인 소프트웨어 및 IT 보안에 대한 개념이 덜 여물어 있을 수 있다는 게 파리조의 설명이다. “앞으로 5G가 보편화 되면서 연결성 기능을 가진 장비들은 더 많이 등장할 겁니다. 지금도 이미 산업 현장에서 그런 장비들이 많이 활약하고 있고요. 하지만 그런 장비들의 보안 문제는 아직도 심각한 수준인 게 현실입니다. 사물인터넷 장비 제조사들 중 보안을 제대로 하고 있다는 곳은 거의 없습니다.”
그래서 파리조는 “앞으로 5G가 기본 통신 수단이 될 때, 더 많은 보안 사고가 터질 것”이라고 예상하고 있다. “특히 봇넷을 이용한 암호화폐 채굴 시도가 더 만연해질 거라고 봅니다. 사물인터넷 장비의 기능도 좋아지고 있고, 인터넷에 연결되어 있으니, 암호화폐 채굴 도구로서 악용되는 사례가 많아질 겁니다. 그런 미래를 예상하고 사물인터넷 장비를 도입해야 할 것입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 보안 업계도 마케팅 문구가 남발하는 곳이다. 그 속에서 ‘진짜 현실’은 가려진다. ‘진짜 현실’은 무엇일까? 예를 들어 보안 업체 설트시큐리티(Salt Security)의 기술 에반젤리스트인 마이클 이스빗스키(Michael Isbitski)는 “보안의 ‘진짜 현실’이라는 건 시대마다 달라진다”며 “최신 IT 기술의 기반이자 핵심이 되고 있는 API를 보호하는 게 지금 시대에는 보안의 ‘진짜 현실’”이라고 말한다. 이번 주 주말판에서 본지는 현 시대에서의 ‘진짜 보안 현실’을 찾아 나섰다.
[이미지 = utoimage]
1. 클라우드 ‘애플리케이션’이 현실이다
많은 조직들이 클라우드를 빠르게 도입하고 있다. 그러면서 클라우드에 맞는 보안 도구들에도 투자를 하고 있는 상황이다. 주로 클라우드 내 저장된 워크로드를 보호하는 데 특화된 도구나 컨테이너 보안 도구라는 이름표를 단 도구들을 사들인다. 이스빗스키는 “그러한 도구들은 이미 공개된 취약 디펜던시들이나 설정 오류, 워크로드의 마이크로세그멘테이션 오류 등을 탐지해 바로잡는 데에는 큰 도움이 된다”고 말한다. 하지만 그런 오류들이나 취약점들은 최초 침투의 발판이 될 뿐, 그 후에 일어나는 악성 행위에 대해서는 별 다른 효력을 발휘하지 못한다고 그는 지적한다.
“클라우드 보안 도구들에 대한 투자가 이뤄지고 있긴 하지만 대부분의 경우 핀트가 어긋나 있습니다. 애플리케이션 레이어의 보안은 아직도 미비하다는 뜻입니다. 아직은 네트워크 보안과 인프라 보안에 좀 더 집중되어 있습니다. 클라우드 애플리케이션들은 아직 취약합니다. 공공 클라우드는 튼튼한 보안을 가지고 있을지 모르겠지만, 그 클라우드의 고객사인 당신이 만드는 인하우스 앱들이 튼튼하다는 뜻은 아니라는 겁니다.”
2. ‘쉬프트 레프트’가 중요한 만큼 ‘쉬프트 라이트’도 유효하다
‘쉬프트 레프트(shift left)’라는 말이 어느 순간부터 보안 업계의 큰 유행어가 되었다. 보안 기능을 소프트웨어 개발 초기 단계에부터 고려해야 한다는 뜻으로 쓰이는 말인데, 이는 “데브섹옵스(DevSecOps)를 도입하자는 말과 동일한 표현”이라고 이스빗스키는 설명한다. 물론 취약한 소프트웨어가 출시일 당긴다는 핑계로 일찍 시장에 나오는 작금의 현상을 타파하는 데 필요한 개념임에는 분명하다. 실제 많은 기업들이 ‘쉬프트 레프트’ 전략을 도입해 적잖은 이익을 보기도 했다.
“하지만 ‘쉬프트 레프트’니 ‘데브섹옵스’니 하는 것의 근간에 있는 건 ‘보안 우선주의’가 절대 아닙니다. 출시일을 당기기 위해 개발된 작업 프로세스입니다. 출시일도 당기고 보안도 강화하는 방법은 없습니다. 둘은 상충할 수밖에 없어요. 그 누구도 무결점의 완벽한 코드를 만들지 못하고, 그 어느 회사도 보안을 위해 소프트웨어 완성 과정 중에 주기적인 코드 스캐닝을 하지 않습니다. 게다가 한다고 해도 알려진 취약점을 찾아내는 것뿐이지 제로데이와 같은 취약점이 발견된 확률은 낮습니다.” 이스빗스키의 설명이다.
포레스터(Forrester)의 분석가인 샌디 카리엘리(Sandy Carielli)는 “‘왼쪽으로 옮기라(쉬프트 레프트)’라는 말이 급작스럽게 퍼지면서 사람들이 ‘오른쪽을 배제하라’는 식으로 오해하기 시작했다”고 말한다. “새로운 기술의 공격과 제로데이 취약점 발굴은 끊임없이 나타나는 현상입니다. 개발 과정 중에 있는 애플리케이션에 대한 공격도 방비해야 되는 때죠. 기존의 개발 및 보안 방식과 ‘쉬프트 레프트’의 개발 및 보안 방식에서 좋은 것들을 다 사용할 줄 알아야 합니다.”
3. WAF와 게이트웨이가 API를 완전히 보호하지 못한다
이스빗스키는 “현대 애플리케이션들의 근간이 되는 건 API”라고 강조한다. “하지만 아직 API 보안의 중요성이 보편화되지는 않고 있습니다. API가 가진 위험성에 대해 이해하는 곳도 드물죠. 공격자들에게 API는 현재 가장 매력적인 표적입니다. 그런데도 대부분의 조직들은 WAF와 API 게이트웨이 만으로 충분하다고 여기고 있습니다. 현실은 어떨까요? 이 두 가지는 현존하는 API 공격 유형 대부분들을 막지 못합니다. 오히려 ‘이제 괜찮아, 안심해도 돼’라는 잘못된 안도감만 주죠.”
이스빗스키는 “API들은 모든 조직들마다 고유한 특징을 가지고 있고, 그 사정도 고유하기 때문에 일반적이고 정형화된 패턴으로 공격이 이뤄지지 않는다”고 설명을 이어간다. “따라서 API의 행동 패턴과 활용 현황을 끊임없이 모니터링 하는 ‘런타임 보안’을 필요로 합니다. 이건 API의 공격 유형과 상관없이 기본 바탕이 되어 있어야 하는 부분입니다.”
컨설팅 업체인 옴디아(Omdia)의 수석 분석가인 릭 터너(Rik Turner)도 “WAF와 게이트웨이 이상의 API 보호 장치가 시급히 필요한 게 현실”임에 동의한다. “현대의 조직들은 수많은 애플리케이션들을 노출시킨 채 사업을 이뤄가고 있습니다. 이 말은 대량의 데이터가 노출되어 있다는 뜻도 됩니다. 이런 데이터는 API를 통해 교류되고요. 단순 ‘입구 방어’인 WAF와 게이트웨이로 불충분할 수밖에 없습니다.”
4. 전통적 차원의 패치/취약점 관리 도구들도 API를 보호 못한다
애플리케이션이나 OS를 보호하는 데 있어 취약점과 패치를 관리한다는 건 대단히 중요한 일이다. 그러나 API 보안 전략에는 적당치 않다고 이스빗스키는 지적한다. “공격자들은 이미 잘 알려진 취약점들을, 잘 알려진 익스플로잇 방법으로 공략합니다. 최근 익스체인지 사태를 통해 이 부분이 잘 드러났죠. 그러나 API를 겨냥한 공격에서는 공격자들의 행동 패턴이 조금 다릅니다. 조직마다 API의 특성이 다르기 때문이죠. 즉, 공격하려는 곳에 따라 새로운 취약점을 찾는 것이 일반적입니다. 또한 API를 위한 ‘패치’라는 것도 없죠.”
그러면서 이스빗스키는 “CVE보다 CWE에 좀 더 익숙해져야 한다”고 말한다. “CWE ID들이 인하우스 애플리케이션과 API에서 발견된 문제들을 분류하는 데 보다 적합합니다. 스스로 코드를 작성하는 일이 많고, 다른 API나 요소들을 조합해 애플리케이션들을 만들어 쓰는 경우가 많은 조직이라면 CWE와 OWASP에 좀 더 관심을 가져야 할 것입니다.”
5. 기본 보안 인식 제고 훈련으로는 절대 충분치 않다
최근 들어 보안 인식이 전반적으로 어느 정도 수준에 이른 상태다. 옴디아의 수석 연구원인 맥신 홀트(Maxine Holt)는 “기본 보안 인식 제고 훈련 덕분이라고 말할 수 없다”고 다소 박하게 평가한다. “지금의 보안 교육이 사용자들의 행동을 실제로 바꾸고 있나요? 솔직히 말해서 아니죠. 공격자들이 터트리는 사고들이 오히려 그런 면에서는 더 효과가 있습니다. 교육이 효과를 거두지 못하는 것은, 실천 사항 목록을 1년에 한 번이나 두 번 나눠주고 각자 읽어보라고 하는 식의 프로그램이 대다수이기 때문입니다. 보안 교육이란 것이 잊을만하면 한 번쯤 필수로 해야 하는 것 이상의 존재감을 드러내지 못합니다.”
홀트는 “대부분 조직들이 행하는 보안 교육 프로그램들은 시간 낭비, 종이 낭비, 인력 낭비인 것이 현실”이라고 말한다. “어떻게 해야 진짜로 임직원의 행동 패턴을 바꿀 수 있는지를 연구해야 합니다. 직원들 한 사람 한 사람의 특성을 파악하는 것에서부터, 조직적인 업무 프로세스를 분해하는 일까지 아울러야 하는 것이죠. 그리고 교육 시간 한 번에 모든 보안 관련 내용을 다 다루는 것도 금지입니다. 한 번에 하나씩만 가르쳐 줘도 사람들이 들을까 말까입니다.”
6. 최신 보안 도구가 조직을 안전하게 만들지 않는다
가트너(Gartner)의 부회장인 피터 퍼스트브룩(Peter Firstbrook)은 “최신 보안 도구에 대한 의존도가 높은 것도 위험한 일”이라고 말한다. “훌륭한 보안 인력을 구하기 힘든 상황이라 도구라도 최신 것을 써야겠다고 결정하는 마음을 이해 못하는 건 아닙니다. 문제는 그런 도구가 보안을 전부 책임져 줄 거라고 기대하고 다른 부분에서 해이해진다는 겁니다. 최신 도구를 비싼 돈 주고 설치해 놓고도, 기본적인 관리자 설정 오류로 데이터가 고스란히 노출되는 일, 우리 얼마나 많이 봅니까? 최신 도구의 기능을 온전히 다 활용하지도 못하는 곳이 태반이기도 하고요. 새로운 도구 때문에 정책에서 충돌이 생기는데도 이를 알아내지 못하기도 하죠.”
정책을 통해 안전한 행동 수칙을 정해둔다고 해서 모든 임직원이 안전하게만 행동하지 않는 것처럼, 보안에 돈을 덕지덕지 바르기만 한다고 해서 보안 문제가 해결되는 것도 아니라고 퍼스트브룩은 강조한다. “제품을 사지 말라는 게 아니고 정책을 만들지 말라는 게 아닙니다. 둘 다 꾸준한 관리와 사용 연습이 동반되어야 한다는 것이죠.”
7. 시장에 출시된 사물인터넷 장비들, 보안이 허술한 경우가 많다
옴디아의 에릭 파리조(Eric Parizo)는 “자동차 회사들, 가전제품 제조사들, 그 외 많은 사물인터넷 장비 업체들 전부 본질적으로 새로운 분야에서 사업을 하는 것과 마찬가지”라고 지적한다. “스마트폰과 마찬가지인 자동차가 만들어지고 있고, 네트워크 기술이 들어간 전자제품들이 나오고 있는데, 이건 사실 ‘컴퓨팅 기술’의 변화에 가깝습니다. 컴퓨팅에 대한 배경이 없는 회사들이 갑자기 컴퓨팅 진화의 한 복판에 끼어든 겁니다.”
그렇기 때문에 아무리 전통과 명성을 자랑하는 유명 기업이라고 하더라도 기본적인 소프트웨어 및 IT 보안에 대한 개념이 덜 여물어 있을 수 있다는 게 파리조의 설명이다. “앞으로 5G가 보편화 되면서 연결성 기능을 가진 장비들은 더 많이 등장할 겁니다. 지금도 이미 산업 현장에서 그런 장비들이 많이 활약하고 있고요. 하지만 그런 장비들의 보안 문제는 아직도 심각한 수준인 게 현실입니다. 사물인터넷 장비 제조사들 중 보안을 제대로 하고 있다는 곳은 거의 없습니다.”
그래서 파리조는 “앞으로 5G가 기본 통신 수단이 될 때, 더 많은 보안 사고가 터질 것”이라고 예상하고 있다. “특히 봇넷을 이용한 암호화폐 채굴 시도가 더 만연해질 거라고 봅니다. 사물인터넷 장비의 기능도 좋아지고 있고, 인터넷에 연결되어 있으니, 암호화폐 채굴 도구로서 악용되는 사례가 많아질 겁니다. 그런 미래를 예상하고 사물인터넷 장비를 도입해야 할 것입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-17] 
.jpg)
.jpg)
