로그4j 취약점은 보안 역사상 최악의 취약점으로 꼽히기에 손색이 없는 버그로, 아마 해결에만 수년이 걸릴 것으로 예상된다. 이는 보안 책임자들에게는 오히려 기회가 될 수 있다. 말만 잘하면 말이다.
[보안뉴스 문가용 기자] 기업들을 겨냥한 사이버 공격은 이제 흔한 것이 되어버렸고 점점 더 심해지고 있다. 그러니 경영진들도 신경을 안 쓸 수가 없고, 보안에 대한 투자 규모를 늘려가고 있기도 하다. 최근 가트너가 조사한 바에 따르면 기업들은 보안 사고를 사업상의 리스크로 보고 있으며, 기술적 위험으로 인지하고 있는 경영진의 비율은 상당히 낮은 것으로 나타났다. 그러면서도 사업 경영 회의에 보안 전담 인력을 두지 않고 있는데, 그러므로 인식과 달리 실제 현장에서 보안은 아직도 임원진이 직접 신경 써야하는 분야로서 취급되지는 않고 있다는 걸 알 수 있다.
최근 보안 업계의 가장 큰 염려거리는 로그4j(Log4j)에서 지난 달 발견된 취약점이다. 이는 단순히 경영진을 설득해 보안 관련 재정을 늘리는 것만으로 접근해야 할 문제가 아니다. 로그4j 취약점 해결은 사이버 보안에 대한 전반적인 관심을 필요로 한다. 즉 담당자에게 조치를 지시하는 정도의 해결책보다 깊은 관여가 있어야 한다는 것이다. 왜?
로그4j는 오픈소스 코드로 만들어진 라이브러리로, 해커들이 이곳의 취약점을 통해 아무 코드나 원하는 대로 실행할 수 있게 된다. 또한 애플리케이션들 내부로 침투하는 것도 가능하다. 이 취약점은 로그4셸(Log4Shell)이라고도 불리는데, 이는 최초로 발견된 ‘오리지널 취약점’이고, 여기서 파생된 다른 취약점들도 존재한다. 이 취약점들이 얼마나 위험한지 미국의 보안 전담 기관인 CISA까지도 패치하라는 권고문을 내놓았다. 심지어 FTA가 조치를 취하지 않는 기업들은 페널티를 받게 될 것이라고도 경고했다.
CISA의 메시지야 보안 담당자와 책임자가 알아서 처리해도 그만이다. 하지만 FTA까지 나서서 기업 전체에 책임을 묻겠다고 한 것은 차원이 다른 문제다. 이것 때문에라도 기업의 경영진들이 로그4j에 대해 관심을 가져야 한다. FTC는 “로그4j의 취약점을 해커들이 익스플로잇 하게 되면 개인정보, 금융 정보 등이 유출되고 필요치 않은 피해를 입을 수 있다”며 “이러한 사태를 막기 위해 최선을 다하는 게 기업으로서의 마땅한 할 일”이라고 천명했었다.
그러니 경영진들에게 이 로그4j 익스플로잇이라는 건 그야말로 사업적 리스크가 되어버렸다. 미국 내에서는 FTC에 찍히느냐 마느냐의 기로 그 자체가 된 것이다. 게다가 이런 은밀한 표준들이 미국에서 정립되면 세계로 뻗쳐나가기도 하니, 미국 땅에서만의 문제는 아닐 것이다. 여기서 경영진들이 할 수 있는 일은 무엇일까? 가장 빠른 건 경영 회의 때 CISO를 회의 테이블에 앉히는 것이다. 이 때 주의할 것이 있다. 이미 팬데믹 기간 동안 각종 보안 강화 작업 때문에 지칠 대로 지친 것이 지금의 보안 전문가들이라는 것이다. 그래서 적잖은 사람들이 로그4j가 사소한 문제라며 경영진을 안심시키려 들 것이다. 이를 아무런 의심 없이 받아들인다면 그 후 어떤 일이 벌어지더라도 경영진의 책임이다.
그렇다면 CISO들은 경영진들과의 회의 자리에서 어떤 말을 해야 할까? 일단 “잘 모르겠습니다”나 “제가 담당해야 할 일이 아닙니다”는 최고의 오답이다. 사실 제대로 된 CISO라면 알아서 피할 답이기도 하다. 로그4j 취약점에 대해 CISO가 할 말은 대충 이렇다. “통합적인 런타임 분석을 통해 탐지하고 패치해야 할 취약점으로 새로운 접근법을 필요로 한다” 정도다. 물론 일반 경영진들에게는 어려운 말이다. 그러니 ‘새로운 접근법’을 강조하며 ‘회사 전체의 보안 강화를 필요로 한다’는 것을 힘줘서 말할 수 있어야 한다. 그러려면 이 로그4j 사태를 실제로 조직 전체의 보안 강화를 위한 계기로 삼으려는 CISO의 진심이 필요하다.
로그4j의 중요성을 설득시키기
보안은 더 이상 IT 기술의 한 하위 분야로 국한될 수 없다. 이는 대부분의 경영진들이 어렴풋이라도 느끼고 있는 개념일 것이다. 그러니 지금의 로그4j 사태를 보안 강화의 계기로 삼으려는 CISO들이 처음부터 보안과 경영의 관계성을 설명해 들어갈 필요는 없을 것이다. 다만 그렇다고 해서 보안 전문 용어들을 마구 써도 되는 건 아니다. 일반 사람들이 이해할 수 있는 용어로 이 사태를 표현할 수 있어야 한다. 그래야 설득을 위한 기초가 마련된다. 그 기초 중 핵심은 “로그4j가 기업 네트워크 곳곳에 너무나 조용하고 은밀하게 자리를 잡고 있어서 찾아내는 데에만도 상당한 노력과 시간이 필요하다”는 것이다.
경영진들이 아무리 보안에 관심을 갖더라도 기술적 세부 내용에까지, 그리고 그에 대한 전략적 대처의 상세한 부분까지 관심을 갖지는 않는다. 이들은 어디까지나 조직의 전체적인 전략과 대응이 궁금할 수밖에 없다. 그러니 조직 전체 곳곳에 어딘가 숨어 있다는 말로도 충분할 수 있다(사람과 상황에 따라 세세한 표현 방법은 달라질 수 있다).
여기에 더해 IT에 대해 전혀 모르는 경영진이라도 한 번쯤 들어봤을 만한 기업들의 이름을 대며 이런 글로벌한 기업들도 이 취약점 때문에 고생하고 있으며, 이런 대기업들의 사업 진행 역시 평탄치 않다고 말하는 것도 이해를 돕는다. 아마존, 오라클, 시스코, IBM, VM웨어 등과 같은 기업들이 실제로 로그4j에 대한 장기적인 패치 작업을 진행 중에 있다.
정말로 로그4j는 세상 어디에나 다 있다. 가장 간단한 가전제품에서부터 우주를 돌아다니는 최첨단 탈것까지 말이다. 로그4j라는 것이 또 다른 로그4j를 로딩할 수 있기 때문에 표면에 보이는 로그4j 하나 찾았다고 해서 다 찾은 게 아니다. 그 안에 다른 로그4j가 있을 수 있고, 그 안에 또 다른 로그4j가 있을 수 있다. 즉 러시아의 마트료시카처럼 인형 안에 같은 모양의 인형이 반복해서 들어있는 것이다. 러시아 마트료시카 인형과 비유하면서 로그4j를 설명해도 괜찮다.
그렇기 때문에 이 로그4j를 전부 찾아내 패치한다는 게 앞으로 수년은 걸릴 일이라는 것은 분명하다. 아마 CISO들이라면 이점을 잘 이해하고 있을 것이다. 그래서 CISA만이 아니라 FTA까지 나서서 기업들에 강한 압박을 하고 있는 것이라는 걸 이해시켜야 한다. 이를 최대한 정성스럽게 해결하지 않으면 진짜로 기업들은 각종 보안 사고에 휘말려들 것이다.
이렇게 로그4j가 위험하며, 그렇기에 조직 전체의 보안 강화가 필요하다는 설명을 진행할 때 CISO들은 스스로에게 어떤 질문을 던져야 할까? 필자는 다음 몇 가지를 꼽는다.
1) 총 책임자 혹은 책임 조직은 누구인가?
2) 로그4j의 취약점이 우리 조직에 미칠 영향력을 제대로 이해하고 있는가?
3) 모든 자바 기반 애플리케이션들에 대한 가시성을 확보하고 있는가? 그러므로 잃을 수 있는 것들과 예상 피해 규모를 제대로 파악하고 있는가?
4) 이 사태를 해결해 나갈 인재와 자원, 도구, 예산을 충분히 확보하고 있는가?
5) 이 취약점으로 인해 공급망에도 영향이 있는가? 긴급 대처 계획이 있는가?
6) 복구 계획을 가지고 있는가? 그러면서 사업 연속성을 확보할 수 있는가?
어쩌면 이 질문들은 경영진들에서부터 나오게 될지도 모른다. 그러니 CISO들은 미리 질문들에 대한 답을 확보하고 있어야 한다. 앞으로 해야 할 일들에 대한 단기 및 장기 계획 모두를 늘 염두에 두어야 한다.
이미 공격자들은 로그4j의 취약점을 악용하기 위한 연구를 맹렬히 진행하고 있다. 아마 우리는 올해 내내 잊을 만하면 한 번씩 로그4j 익스플로잇 기법이 새롭게 개발되는 것을 볼 것이다. 공격자들은 이 취약점을 통해 네트워크에 몰래 들어와 악성 행위를 저지를 것인데 그것이 당신이 속한 조직이 되지 말란 법은 어디에도 없다.
로그4j는 해결이 간단한 취약점이 아니다. 어쩌면 보안 분야 역사상 가장 복잡한 해결을 요구하는 취약점일 수도 있다. 앞으로 어떤 익스플로잇 방법이 등장할지도 모르고, 심지어 구멍이 어디에 있는지도 우리는 다 파악하지 못하고 있다. 그렇기 때문에 전체적인 보안 강화가 필요하다. 취약한 로그4j를 골라서 해결하는 게 차라리 더 어렵기 때문이다. 그 동안 보안 인식 제고나 보안 예산을 유치할 수 없었던 보안 책임자에게 로그4j는 어쩌면 기회가 될 수 있다.
글 : 리란 탱크만(Liran Tancman), CEO, Rezilion
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 기업들을 겨냥한 사이버 공격은 이제 흔한 것이 되어버렸고 점점 더 심해지고 있다. 그러니 경영진들도 신경을 안 쓸 수가 없고, 보안에 대한 투자 규모를 늘려가고 있기도 하다. 최근 가트너가 조사한 바에 따르면 기업들은 보안 사고를 사업상의 리스크로 보고 있으며, 기술적 위험으로 인지하고 있는 경영진의 비율은 상당히 낮은 것으로 나타났다. 그러면서도 사업 경영 회의에 보안 전담 인력을 두지 않고 있는데, 그러므로 인식과 달리 실제 현장에서 보안은 아직도 임원진이 직접 신경 써야하는 분야로서 취급되지는 않고 있다는 걸 알 수 있다.
[이미지 = utoimage]
최근 보안 업계의 가장 큰 염려거리는 로그4j(Log4j)에서 지난 달 발견된 취약점이다. 이는 단순히 경영진을 설득해 보안 관련 재정을 늘리는 것만으로 접근해야 할 문제가 아니다. 로그4j 취약점 해결은 사이버 보안에 대한 전반적인 관심을 필요로 한다. 즉 담당자에게 조치를 지시하는 정도의 해결책보다 깊은 관여가 있어야 한다는 것이다. 왜?
로그4j는 오픈소스 코드로 만들어진 라이브러리로, 해커들이 이곳의 취약점을 통해 아무 코드나 원하는 대로 실행할 수 있게 된다. 또한 애플리케이션들 내부로 침투하는 것도 가능하다. 이 취약점은 로그4셸(Log4Shell)이라고도 불리는데, 이는 최초로 발견된 ‘오리지널 취약점’이고, 여기서 파생된 다른 취약점들도 존재한다. 이 취약점들이 얼마나 위험한지 미국의 보안 전담 기관인 CISA까지도 패치하라는 권고문을 내놓았다. 심지어 FTA가 조치를 취하지 않는 기업들은 페널티를 받게 될 것이라고도 경고했다.
CISA의 메시지야 보안 담당자와 책임자가 알아서 처리해도 그만이다. 하지만 FTA까지 나서서 기업 전체에 책임을 묻겠다고 한 것은 차원이 다른 문제다. 이것 때문에라도 기업의 경영진들이 로그4j에 대해 관심을 가져야 한다. FTC는 “로그4j의 취약점을 해커들이 익스플로잇 하게 되면 개인정보, 금융 정보 등이 유출되고 필요치 않은 피해를 입을 수 있다”며 “이러한 사태를 막기 위해 최선을 다하는 게 기업으로서의 마땅한 할 일”이라고 천명했었다.
그러니 경영진들에게 이 로그4j 익스플로잇이라는 건 그야말로 사업적 리스크가 되어버렸다. 미국 내에서는 FTC에 찍히느냐 마느냐의 기로 그 자체가 된 것이다. 게다가 이런 은밀한 표준들이 미국에서 정립되면 세계로 뻗쳐나가기도 하니, 미국 땅에서만의 문제는 아닐 것이다. 여기서 경영진들이 할 수 있는 일은 무엇일까? 가장 빠른 건 경영 회의 때 CISO를 회의 테이블에 앉히는 것이다. 이 때 주의할 것이 있다. 이미 팬데믹 기간 동안 각종 보안 강화 작업 때문에 지칠 대로 지친 것이 지금의 보안 전문가들이라는 것이다. 그래서 적잖은 사람들이 로그4j가 사소한 문제라며 경영진을 안심시키려 들 것이다. 이를 아무런 의심 없이 받아들인다면 그 후 어떤 일이 벌어지더라도 경영진의 책임이다.
그렇다면 CISO들은 경영진들과의 회의 자리에서 어떤 말을 해야 할까? 일단 “잘 모르겠습니다”나 “제가 담당해야 할 일이 아닙니다”는 최고의 오답이다. 사실 제대로 된 CISO라면 알아서 피할 답이기도 하다. 로그4j 취약점에 대해 CISO가 할 말은 대충 이렇다. “통합적인 런타임 분석을 통해 탐지하고 패치해야 할 취약점으로 새로운 접근법을 필요로 한다” 정도다. 물론 일반 경영진들에게는 어려운 말이다. 그러니 ‘새로운 접근법’을 강조하며 ‘회사 전체의 보안 강화를 필요로 한다’는 것을 힘줘서 말할 수 있어야 한다. 그러려면 이 로그4j 사태를 실제로 조직 전체의 보안 강화를 위한 계기로 삼으려는 CISO의 진심이 필요하다.
로그4j의 중요성을 설득시키기
보안은 더 이상 IT 기술의 한 하위 분야로 국한될 수 없다. 이는 대부분의 경영진들이 어렴풋이라도 느끼고 있는 개념일 것이다. 그러니 지금의 로그4j 사태를 보안 강화의 계기로 삼으려는 CISO들이 처음부터 보안과 경영의 관계성을 설명해 들어갈 필요는 없을 것이다. 다만 그렇다고 해서 보안 전문 용어들을 마구 써도 되는 건 아니다. 일반 사람들이 이해할 수 있는 용어로 이 사태를 표현할 수 있어야 한다. 그래야 설득을 위한 기초가 마련된다. 그 기초 중 핵심은 “로그4j가 기업 네트워크 곳곳에 너무나 조용하고 은밀하게 자리를 잡고 있어서 찾아내는 데에만도 상당한 노력과 시간이 필요하다”는 것이다.
경영진들이 아무리 보안에 관심을 갖더라도 기술적 세부 내용에까지, 그리고 그에 대한 전략적 대처의 상세한 부분까지 관심을 갖지는 않는다. 이들은 어디까지나 조직의 전체적인 전략과 대응이 궁금할 수밖에 없다. 그러니 조직 전체 곳곳에 어딘가 숨어 있다는 말로도 충분할 수 있다(사람과 상황에 따라 세세한 표현 방법은 달라질 수 있다).
여기에 더해 IT에 대해 전혀 모르는 경영진이라도 한 번쯤 들어봤을 만한 기업들의 이름을 대며 이런 글로벌한 기업들도 이 취약점 때문에 고생하고 있으며, 이런 대기업들의 사업 진행 역시 평탄치 않다고 말하는 것도 이해를 돕는다. 아마존, 오라클, 시스코, IBM, VM웨어 등과 같은 기업들이 실제로 로그4j에 대한 장기적인 패치 작업을 진행 중에 있다.
정말로 로그4j는 세상 어디에나 다 있다. 가장 간단한 가전제품에서부터 우주를 돌아다니는 최첨단 탈것까지 말이다. 로그4j라는 것이 또 다른 로그4j를 로딩할 수 있기 때문에 표면에 보이는 로그4j 하나 찾았다고 해서 다 찾은 게 아니다. 그 안에 다른 로그4j가 있을 수 있고, 그 안에 또 다른 로그4j가 있을 수 있다. 즉 러시아의 마트료시카처럼 인형 안에 같은 모양의 인형이 반복해서 들어있는 것이다. 러시아 마트료시카 인형과 비유하면서 로그4j를 설명해도 괜찮다.
그렇기 때문에 이 로그4j를 전부 찾아내 패치한다는 게 앞으로 수년은 걸릴 일이라는 것은 분명하다. 아마 CISO들이라면 이점을 잘 이해하고 있을 것이다. 그래서 CISA만이 아니라 FTA까지 나서서 기업들에 강한 압박을 하고 있는 것이라는 걸 이해시켜야 한다. 이를 최대한 정성스럽게 해결하지 않으면 진짜로 기업들은 각종 보안 사고에 휘말려들 것이다.
이렇게 로그4j가 위험하며, 그렇기에 조직 전체의 보안 강화가 필요하다는 설명을 진행할 때 CISO들은 스스로에게 어떤 질문을 던져야 할까? 필자는 다음 몇 가지를 꼽는다.
1) 총 책임자 혹은 책임 조직은 누구인가?
2) 로그4j의 취약점이 우리 조직에 미칠 영향력을 제대로 이해하고 있는가?
3) 모든 자바 기반 애플리케이션들에 대한 가시성을 확보하고 있는가? 그러므로 잃을 수 있는 것들과 예상 피해 규모를 제대로 파악하고 있는가?
4) 이 사태를 해결해 나갈 인재와 자원, 도구, 예산을 충분히 확보하고 있는가?
5) 이 취약점으로 인해 공급망에도 영향이 있는가? 긴급 대처 계획이 있는가?
6) 복구 계획을 가지고 있는가? 그러면서 사업 연속성을 확보할 수 있는가?
어쩌면 이 질문들은 경영진들에서부터 나오게 될지도 모른다. 그러니 CISO들은 미리 질문들에 대한 답을 확보하고 있어야 한다. 앞으로 해야 할 일들에 대한 단기 및 장기 계획 모두를 늘 염두에 두어야 한다.
이미 공격자들은 로그4j의 취약점을 악용하기 위한 연구를 맹렬히 진행하고 있다. 아마 우리는 올해 내내 잊을 만하면 한 번씩 로그4j 익스플로잇 기법이 새롭게 개발되는 것을 볼 것이다. 공격자들은 이 취약점을 통해 네트워크에 몰래 들어와 악성 행위를 저지를 것인데 그것이 당신이 속한 조직이 되지 말란 법은 어디에도 없다.
로그4j는 해결이 간단한 취약점이 아니다. 어쩌면 보안 분야 역사상 가장 복잡한 해결을 요구하는 취약점일 수도 있다. 앞으로 어떤 익스플로잇 방법이 등장할지도 모르고, 심지어 구멍이 어디에 있는지도 우리는 다 파악하지 못하고 있다. 그렇기 때문에 전체적인 보안 강화가 필요하다. 취약한 로그4j를 골라서 해결하는 게 차라리 더 어렵기 때문이다. 그 동안 보안 인식 제고나 보안 예산을 유치할 수 없었던 보안 책임자에게 로그4j는 어쩌면 기회가 될 수 있다.
글 : 리란 탱크만(Liran Tancman), CEO, Rezilion
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
.jpg)
.jpg)
