CVE가 해결을 위해 우선 순위 1을 받아야 하는 이유
애플리케이션 보안이 스택 인 이유에 대해 이전에 설명했습니다. 다시 한번 말씀드리는 이유는 최신 애플리케이션은 결코 단독으로 배포되지 않는다는 사실을 가끔 상기시켜줄 필요가 있기 때문입니다. 그렇지 않아요.
모든 최신 애플리케이션은 어떤 종류의 플랫폼에 배포됩니다. Apache나 IIS가 될 수 있습니다. Oracle이나 IBM 애플리케이션 서버일 수 있습니다. Express가 포함된 node.js나 모든 필수 라이브러리가 포함된 Python이 될 수 있습니다. 우리가 네트워킹을 제공하기 위해 운영 체제와 가상화/컨테이너에 의존하는 것처럼, 애플리케이션은 TCP와 HTTP와 같은 것을 처리하기 위해 플랫폼과 라이브러리에 의존합니다.
또한 개발자는 기능을 위해 라이브러리를 사용합니다. 바퀴를 새로 만드는 것은 시간 낭비이므로 개발자들은 JSON 파서, 파일 관리, 인증 및 권한 부여, 데이터베이스 지원을 위한 오픈 소스와 다른 경로를 찾습니다. UI 레이아웃과 관리도 그렇습니다. 오늘날 대부분의 개발자는 라이브러리를 이용하여 이러한 기능을 제공받고, 이를 통해 가치를 더하는 부분, 즉 비즈니스 로직과 서비스에 집중할 수 있습니다.
Contrast Labs가 2017년에 실시한 애플리케이션 검사에서 "타사 소프트웨어 라이브러리가 애플리케이션 코드의 79%를 차지한다"는 결과가 나왔습니다. Java의 경우 평균 107개의 서로 다른 라이브러리가 있었습니다. .NET의 경우? 19. 비공식적으로 말씀드리자면, 저는 node.js와 함께 적어도 다섯 가지 다른 라이브러리를 사용하고 있습니다.
하지만 눈살을 찌푸리게 만드는 것은 이 분열과 관련한 안보 상황에 대해 그들이 발견한 내용입니다.
앱의 79%가 라이브러리로 구성되어 있지만 알려진 취약점(CVE)의 2%에 불과합니다. 사용자 지정 코드는 취약점의 97.3%로 나머지를 대부분 차지합니다.
라이브러리와 취약성 간의 불균형적인 소싱 보안 위험은 SANS 설문 조사에서 "응답자의 23%가 타사 소프트웨어 제품 및 서비스(COTS, 클라우드 기반 서비스 및 오픈 소스 소프트웨어)에 크게 의존하고 있지만, 타사 솔루션의 보안을 보장하는 데 충분한 책임을 지지 않는다"는 결과를 보인 이유를 설명할 수 있습니다. 보안 프로그램의 23%만이 COTS를 포함합니다."
흠. 그렇다면 Kenna Security에서 보고한 대로 취약점 해결에 대한 대응률이 낮은 이유 를 설명할 수 있겠습니다. 2015년 Kenna Security는 2억 5천만 개의 취약성과 10억(BILLION) 이상의 침해 사건이 있는 50,000개 조직 샘플을 대상으로 수행한 연구를 보고했고 취약성 해결과 관련하여 매우 흥미로운 두 가지 사항을 발견했습니다.
- 평균적으로 기업이 취약점을 해결하는 데 100~120일이 걸립니다.
- 40~60일이 지나면 CVE가 악용될 확률이 90%가 넘습니다.
- 취약점이 악용될 가능성이 높은 시점과 취약점이 해결될 때까지의 기간은 약 60일이다.
다시 말해, 대부분의 조직은 이 2%의 취약점을 충분히 빠르게 해결하지 못해 이 취약점으로 인해 손상되는 것을 방지하지 못하고 있습니다. 아마도 조직의 보안 프로그램에 포함되지 않은 라이브러리에 위치하기 때문일 수 있습니다.
그 이유가 무엇이든 , 그것이 최우선순위가 되어야 합니다 . 그 이유를 설명하겠습니다.
예전에는 공격자가 다음을 수행해야 했습니다.
- 취약점에 대해 알아보세요
- 피해자 사이트를 찾아보세요
- 익스플로잇 실행 시도
이는 수동적이고 시간이 많이 걸리는 작업이었습니다. 당신이 유명한 표적이 아닌 이상, 누구도 당신에게 시간을 낭비하지 않을 것입니다.
오늘날 취약점은 인터넷 속도로 공유됩니다. (혹시 궁금하시다면, 빛의 속도입니다.) 광 백본과 대상 발견은 자동화됩니다. 스크립트와 봇은 사람보다 훨씬 빠르게(그리고 더 저렴하게) 사이트를 찾아내서 침해할 곳을 표시할 수 있습니다. 이는 보안되지 않은 IoT 기기를 이용해 데스 스타 규모의 봇넷이 구축되는 방식과 같습니다. 자동화는 단순히 좋은 사람들의 생산성을 향상시키는 것이 아닙니다.
이는 특정 대상을 지정하지 않은 공격입니다. 말하자면, 계획되지 않은 기회 공격이죠. 가치 있거나 흥미로운 데이터는 없을지 몰라도 리소스는 있습니다. 그리고 그 자원은 다른 희생자를 찾고 다른 공격을 저지르는 데 사용될 수도 있고, 글쎄요, 이게 어떻게 끝날지는 여러분도 잘 알고 계시죠.
CVE가 공개된 후에는 대상을 지정하지 않은 공격이 특히 흔해집니다. 사용자 정의 코드는 고유하기 때문에 취약점이 많이 있지만, 이를 찾는 데는 시간과 노력이 필요합니다. 일반적으로 사용되는 라이브러리나 플랫폼에 존재하는 CVE를 악용하는 건 아주 쉬운 일이죠. 이 기회는 놓칠 수 없을 만큼 좋습니다. 투자 수익률이 매우 높기 때문입니다. 2015년 Verizon DBIR은 "공격의 70%가 패치가 가능한 알려진 취약점을 악용했다"고 밝혔습니다.
따라서 애플리케이션을 구성하는 79%의 라이브러리에서 새로운 CVE가 공개되면 실제 소프트웨어 업데이트를 통한 패치나 웹 애플리케이션 방화벽 을 통한 가상 패치를 최우선순위로 적용해야 합니다. 해당 CVE가 플랫폼 과 관련된 경우 (Apache Killer를 생각해 보세요) 우선순위를 "모두 삭제"로 지정하는 것이 좋습니다 . 라이브러리의 취약점을 스캔하는 것보다 웹 및 앱 서버의 지문을 수집하는 것이 더 쉽기 때문입니다.
진실은 표적이 될 만큼 유명하지 않다면 여전히 위험에 처해 있다는 것입니다. 여러분은 아마도 유명 조직과 동일한 스택을 사용하고 있을 것이고, 즉, 타깃이 지정되지 않은 공격이 여러분을 찾아낼 가능성이 높다는 뜻입니다. 그렇지 않을 것 같다면 CVE 데이터베이스로 가서 node.js와 관련된 모든 게시된 CVE를 찾아 보세요. 그런 다음 builtwith.com 으로 가서 node.js 프레임워크인 Express로 만든 웹사이트를 검색합니다. 저는 이 사이트에서 "Express를 사용하는 230,116개의 라이브 웹사이트 와 과거에 Express를 사용했던 263,872개의 사이트 "에 대한 정보를 알고 있을 뿐만 아니라 이를 다운로드할 수 있는 링크도 편리하게 제공한다는 사실을 알게 되었습니다.
웹 앱의 shodan.io만큼은 아니지만, 두 가지를 합쳐서 성공적인 익스플로잇을 만드는 건 그렇게 어렵지 않습니다.
따라서 라이브러리나 웹 플랫폼의 CVE를 무시할 수 있을 만큼 "규모가 크지 않다"는 생각으로 실수를 저지르지 마십시오.
그렇게 해서 사람들이 트위터 트렌드에 오르게 되는 거예요. 그것도 좋은 방향으로가 아니었습니다.
안전하세요. 전체 앱 스택에 영향을 미치는 CVE에 대한 대응을 우선시합니다. 위에서 아래까지.