요즘 해커들이 애플리케이션을 주로 노리는 이유
- 애플리케이션 표적으로 한 사이버 공격이 주류
- 애플리케이션 개발의 방법이 근본적으로 바뀐 게 문제
- 게다가 인공지능이 공격자들을 도와주기도
‘해킹 공격’은 사실 지나치게 광범위한 용어다. 그 짧은 말 안에 너무나 많은 전술과 기법이 녹아 있다. 그 중에는 ‘애플리케이션을 직접 공략하는 것’도 포함되어 있는데, 그 중에서도 기업 내에서 업무용으로 사용하는 앱들이 주요 공략 대상이 되고 있다고 한다. 버라이즌(Verizon)과 구글 맨디언트(Google Mandiant)는 최근 보고서를 통해 “당신의 애플리케이션이 3분에 한 번씩 공격 받고 있다”는 충격적인 내용을 발표했다.
보안 업체 콘트라스트시큐리티(Contrast Security)는 “최근 공격자들 사이에서 애플리케이션 계층을 공격하는 게 일반화 됐다”고 말한다. 애플리케이션들은 EDR이나 WAF로 보호되어 있는데, 공격자들에게 있어 이런 방어 수단들을 회피하는 건 그리 어려운 일이 아닌 것이 되어가는 중이라는 경고까지 덧붙었다. 세 회사의 발표 내용 전부 “애플리케이션을 좀 더 강력하게 보호해야 한다”는 것으로 귀결된다.
애플리케이션을 왜?
왜 공격자들 사이에서 애플리케이션이 점점 주목받고 있는 걸까? 콘트라스트 측은 “애플리케이션 공격이 근본부터 변화되고 있기 때문”이라고 말한다. “애플리케이션을 뚫어내는 데에 대한 획기적인 변화가 있었다는 뜻입니다. 마치 랜섬웨어 공격자들 사이에서 ‘이중 협박’이라는 전략이 크게 유행하면서 랜섬웨어가 중흥기를 맞이한 것과 비슷합니다.” 그 획기적인 변화란, 인공지능이라고 콘트라스트는 지적한다. “인공지능 덕분에 공격자들은 보다 쉽게 애플리케이션 공략법을 찾아내고, 보다 쉽게 다량의 공격을 수행할 수 있습니다. WAF, SAST, EDR 같은 도구들은 힘을 쓰기 힘든 구도로 전장이 변하고 있습니다.”
인공지능만 문제가 아니다. 더 근본적으로는 소프트웨어 개발 방식의 변화 때문에 이러한 현상이 야기된다고도 볼 수 있다. 콘트라스트는 “API에 대한 의존도가 높아진 게 핵심 변화”라고 정리한다. “예전에는 소프트웨어를 개발할 때 모든 코딩을 손으로 직접 했습니다. 그래서 하나의 커다란 결과물이 나왔어요. 요즘에는 필요한 기능들을 API로 가져다가 붙입니다. 레고 블록 쌓듯이, 부품들을 구해다가 이어붙여 완성시킵니다. 그러다 보니 방어자 입장에서는 그런 블록 하나하나를 다 검사하고 보완해야 하는데, 그게 말처럼 쉬운 게 아닙니다. 그래서 구멍도 많아지고 있고, 공격자들도 이 지점을 노리는 겁니다.”
‘블록 쌓기’ 식으로 만들어진 현대 애플리케이션들은 하나 평균 30개의 고위험군 취약점을 포함하고 있는 것으로 집계됐다. 이 취약점들 중 대부분은 이미 잘 알려진 것들이며, 따라서 데이터가 충분히 축적되어 있다. 이 데이터를 인공지능 모델들이 학습했고, 그래서 취약점 자체도 잘 찾아내고, 공략법 역시 빠르게 알아낼 수 있다. 이는 곧 공격의 질적 및 양적 증가로 이어졌다는 게 콘트라스트의 설명이다.
이 때문에 현대 소프트웨어 생태계에서 개발자의 역할이 중요해진다. “애플리케이션들에서는 매월 평균 17개의 취약점이 나옵니다. 그런데 개발자들이 픽스를 적용하는 건(혹은 그 외 수단으로 고치는 건) 단 6개입니다. 반도 되지 않죠. 반면 공격자들의 취약점 익스플로잇 속도는 점점 빨라집니다. 취약점 공개 후 단 5일 만에 공격이 시작되는 게 현실입니다. 참고로 취약점 공개와 패치 사이에 걸리는 시간은 평균 84일입니다.” 이런 숫자들을 환산해 한 줄로 정리하면 “3분에 한 번씩 공격받는다”가 된다.
그래서 확보해야 하는 것은 가시성
클라우드가 본격적으로 상용화 되던 때, 보안 전문가들이 강조하던 개념이 하나 있는데, 바로 ‘가시성’이었다. 클라우드라는 생소한 인프라로 데이터를 이전시켜도 좋다, 다만 자기 데이터가 어디에 있는지, 어떻게 활용되고 있으며, 어떤 경로로 움직이는지 정도는 알고 있으라는 의미였다. 보여야 보호할 수 있으니까.
새 애플리케이션 개발법이 이미 대세가 된 지금도 보안 업계는 같은 개념을 강조한다. 가시성이다. 애플리케이션을 이루는 각 요소들(즉 블록들)에 대해 잘 알고 있어야 한다는 의미다. 어떤 요소가 사용됐고, 그 요소는 어떤 취약점 및 패치 히스토리를 가지고 있는지, 그 요소의 메인테이너들이 패치를 주기적으로 내놓고 있는지, 아니면 개발을 중단하고 잠적해 있는지를 다 ‘보고’ 있어야 한다. 보여야 보호할 수 있다는 건 여기서도 매한가지다.
“실제 많은 기업들이 애플리케이션 가시성 확보 쪽으로 보안 전략을 수정하고 있습니다. 이는 필연적으로 ‘선제적 보안’의 자세를 취할 수밖에 없습니다. 사고가 일어난 다음에 가시성 확보를 하는 것도 나쁘지야 않지만 비효율적이죠. 미리부터 애플리케이션 구성 요소들을 파악해 두는 게 더 나은 ‘가시성 확보’입니다.”
보안 팀과 개발 팀의 협업도 필수다. 개발 팀이 애써 만들어 놓은 것을 보안 팀이 갈기갈기 분석해 빨간 줄을 그어놓으면 기분 좋을 사람이 없다. 기획 단계에서부터 보안 팀과 개발 팀이 머리를 맞대고 가시성 확보 전략을 마련해야 한다. “그러면서 요소 하나하나를 튼튼히 만든 다음 가져다 쓰는 쪽으로 개발 과정을 다듬어 나가야합니다. 그렇게 했을 때 비용도 아낄 수 있고, 보안에 의한 피로도도 낮출 수 있습니다.”