.jpg)
취약점 관리 시스템은 한계에 봉착했다. 등록도 어렵고 열람도 어려워, 사실상 취약점 관리 시스템으로서는 활용도가 크게 떨어지기 때문이다. 문제는 작은 곳에 있다.
[보안뉴스 문가용 기자] 취약점이 발견됐다면, 그 다음부터가 더 문제다. 그 취약점의 영향을 받는 소프트웨어 구성 요소나 제품을, 취약점 관리 주체인 NVD(국가 취약점 데이터베이스)가 어떤 이름으로 부르느냐를 알아내야 하기 때문이다. NVD는(그러므로 NVD의 운영 주체인 NIST는) 소프트웨어 제품들마다 고유의 CPE 이름을 별도로 붙이는데, 이 이름을 찾아낸다는 게 여간 어려운 일이 아니다.
NVD는 각 구성 요소들을 명확히 구분하기 위해 벤더사의 이름과 제품의 이름, 버전 번호 등을 참고하여 고유의 CPE 이름을 부여하도록 한다. 고유해야 하기 때문에 CPE 이름은 복잡하고, 한 글자라도 틀리면 검색이 되지 않는다. 실제 현장에서 특정 요소의 CPE 이름을 찾는 것이 여간 고된 일이 아니라는 걸 취약점 전문가들이라면 다 알고 있다. 오픈소스 요소든 유료 소프트웨어 구성 요소든 마찬가지다. 이 어려움 때문에 취약점 관리를 자동화 기술로 처리하는 게 되지 않고 있으며, 이는 소프트웨어 구성표(SBOM) 제도를 정착시키는 데에도 큰 장애로 작용한다.
NVD에서 취약점 정보를 찾는 건 너무나 어려운 일
이 문제를 보다 명확히 설명하려면 취약점 등록 과정에서 흔히 나타나는 문제들을 시나리오로 묶어 예로 드는 것이 좋을 것이다. 몇 가지 사례들은 다음과 같으며, 이런 문제들에 봉착했을 때에는 해결책을 찾는 게 불가능에 가깝다.
1. NVD는 취약점들에 CVE 번호를 부여한다. CVE-2022-12345와 같은 형식의 번호는 보안 업계에 있는 사람이라면 누구나 한 번쯤 봤을 것이다. 그리고 각 취약점에는 CVSS라는 점수가 부여된다. 이 점수를 보고 사람들은 취약점이 얼마나 위험한지 가늠할 수 있다. 그런데 문제가 발견된 소프트웨어의 개발사나 공급사가 취약점을 한 번도 등록한 적이 없고, 그래서 그 소프트웨어와 관련된 CVE 번호가 한 번도 발행된 적이 없다면, 해당 소프트웨어의 CPE 번호도 NVD 안에는 존재하지 않는다.
개발사가 취약점을 등록하지 않았다는 것은, 소프트웨어가 정말로 무결해서 아무런 취약점이 존재하지 않았기 때문일 수도 있고, 취약점은 있는데 보고 절차가 귀찮거나 까다로워서 침묵하고 있어서일 수도 있다. 어느 쪽이든 NVD에 한 번도 등록되지 않은 소프트웨어라면 CPE 번호가 존재하지 않고, 취약점을 등록하기 위해 CPE 번호를 아무리 찾아도 오류 메시지만 뜬다. 그러면 이름을 새로 등록해야 한다.
2. CPE 이름을 새로 등록하는 과정에 오류 확인 기능은 존재하지 않는다. NVD에 새로운 CPE 이름을 입력할 때 사실상 아무런 이름이나 넣을 수 있게 된다. 명명법이라는 게 있긴 있으나, 모든 사람이 그 규칙을 완벽히 익히고 있다고 보기는 힘들다. 그러니 누군가는 명명법을 지키더라도 조금씩 실수를 하기 마련이다. 그러면 CPE 이름이 등록되더라도 규칙을 따르지 않아 검색하기 힘든 이름이 등록된다.
나중에 취약점을 등록하고자 하는 한 사용자가 명명법에 따라 CPE를 검색할 때 어떤 일이 일어날까? 위 1번과 같이 찾고자 하는 CPE 번호가 없다는 오류만 받게 된다. 원래 오류가 없는 소프트웨어였거나, 오류가 있어도 개발사가 등록하지 않은 경우라고 오해하기 십상이다. 그럼에도 ‘내가 오타를 냈다’거나 ‘원 CPE 등록자가 잘못 이름을 붙였다’고 의심하는 건 쉽지 않다. 백이면 백, ‘이 제품과 관련된 취약점은 한 번도 등록된 적이 없다’고 생각할 것이다. 취약점을 추적하고 현황을 업데이트하는 게 틀어진다.
3. 시간이 지나면서 제품의 이름이나 개발사의 이름이 바뀔 수 있다. M&A가 일어난다든지, 회사가 리브랜딩을 감행했다면 얼마든지 가능한 일이다. 그럴 때 CPE 이름이 자동으로 바뀌면 좋으련만 절대로 그렇지 않다. CPE까지 챙겨가며 이름을 바꿔주는 회사가 있는가 하면, 그렇지 않은 회사들도 있다. 그러니 산업 내 상황이 바뀔 때마다 CPE들은 구버전이 그대로 사용되기도 하고 신버전이 아무도 몰래 등록되는 등 혼란이 가중된다. 특정 요소에 어떤 취약점들이 있는지 조사하려 해도 잘 되지 않는다.
4. 기업 이름이 바뀌지 않는다고 하더라도, 기업에는 여러 가지 이름이 있다. 예를 들어 누군가는 그냥 ‘마이크로소프트’라고 부르지만, 어떤 사람은 ‘마이크로소프트 사’라고 하기도 한다. 제품의 이름도 사정은 비슷하다. ‘마이크로소프트 워드’라고 하는 사람도 있고, ‘오피스 워드’라고 하는 사람도 있으며, ‘MS 워드프로세서’라고 하는 사람도 있다. 이런 경우들도 CPE 이름을 제각각으로 만들며, 따라서 NVD에서의 취약점 검색을 훨씬 어렵게 만든다.
5. 위 4번과 비슷한데, 오픈소스의 경우 취약점 등록이나 열람을 하려는 사람이 훨씬 많고, 따라서 CPE 이름도 많은 사람들이 중구난방으로 등록할 수 있다. 이런 경우 ‘이 모든 CPE들이 결국 한 제품을 말하는 것이고, 따라서 이 CVE 번호들은 한 가지 취약점을 가르키는 것’이라고 종합할 수 있는 관점을 갖는 게 불가능에 가깝게 된다. 엄청난 행정 낭비와 인력 낭비가 발생하고, 취약점 관리는 더 어려워진다.
6. 많은 경우 취약점들은 한 가지 라이브러리의 한 가지 모듈에만 영향을 준다. 하지만 CPE는 제품 전체의 이름이다. 모듈에 따라 이름이 붙지 않는다는 것이다. 그러므로 취약점의 정확한 내용을 인지하려면 CVE 보고서 전체를 읽어야 한다. 하지만 보고서 전체를 꼼꼼히 읽는 사람은 그리 많지 않다. 대부분 제목만 훑고 지나간다. 그러면 불필요한 패치에 시간을 낭비하게 될 수밖에 없다.
공급망 문제와 취약점 관리의 효율을 높이려면 현재 NVD가 고수하고 있는 명명 체계부터 손을 봐야 한다. 이미 OWASP, 리눅스재단, 오라클 등 여러 단체와 조직들에서 이 문제를 인지하고 작업을 시작했다. 하지만 아직 이렇다 할 해결책이나 제안이 나온 것은 아니다. 지금의 문제들을 해결할 수만 있다면 취약점 관리 체제에는 큰 변화가 있을 것으로 기대한다.
글 : 커티스 얀코(Curtis Yanko), 수석 아키텍트, GrammaTech
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 취약점이 발견됐다면, 그 다음부터가 더 문제다. 그 취약점의 영향을 받는 소프트웨어 구성 요소나 제품을, 취약점 관리 주체인 NVD(국가 취약점 데이터베이스)가 어떤 이름으로 부르느냐를 알아내야 하기 때문이다. NVD는(그러므로 NVD의 운영 주체인 NIST는) 소프트웨어 제품들마다 고유의 CPE 이름을 별도로 붙이는데, 이 이름을 찾아낸다는 게 여간 어려운 일이 아니다.
[이미지 = utoimage]
NVD는 각 구성 요소들을 명확히 구분하기 위해 벤더사의 이름과 제품의 이름, 버전 번호 등을 참고하여 고유의 CPE 이름을 부여하도록 한다. 고유해야 하기 때문에 CPE 이름은 복잡하고, 한 글자라도 틀리면 검색이 되지 않는다. 실제 현장에서 특정 요소의 CPE 이름을 찾는 것이 여간 고된 일이 아니라는 걸 취약점 전문가들이라면 다 알고 있다. 오픈소스 요소든 유료 소프트웨어 구성 요소든 마찬가지다. 이 어려움 때문에 취약점 관리를 자동화 기술로 처리하는 게 되지 않고 있으며, 이는 소프트웨어 구성표(SBOM) 제도를 정착시키는 데에도 큰 장애로 작용한다.
NVD에서 취약점 정보를 찾는 건 너무나 어려운 일
이 문제를 보다 명확히 설명하려면 취약점 등록 과정에서 흔히 나타나는 문제들을 시나리오로 묶어 예로 드는 것이 좋을 것이다. 몇 가지 사례들은 다음과 같으며, 이런 문제들에 봉착했을 때에는 해결책을 찾는 게 불가능에 가깝다.
1. NVD는 취약점들에 CVE 번호를 부여한다. CVE-2022-12345와 같은 형식의 번호는 보안 업계에 있는 사람이라면 누구나 한 번쯤 봤을 것이다. 그리고 각 취약점에는 CVSS라는 점수가 부여된다. 이 점수를 보고 사람들은 취약점이 얼마나 위험한지 가늠할 수 있다. 그런데 문제가 발견된 소프트웨어의 개발사나 공급사가 취약점을 한 번도 등록한 적이 없고, 그래서 그 소프트웨어와 관련된 CVE 번호가 한 번도 발행된 적이 없다면, 해당 소프트웨어의 CPE 번호도 NVD 안에는 존재하지 않는다.
개발사가 취약점을 등록하지 않았다는 것은, 소프트웨어가 정말로 무결해서 아무런 취약점이 존재하지 않았기 때문일 수도 있고, 취약점은 있는데 보고 절차가 귀찮거나 까다로워서 침묵하고 있어서일 수도 있다. 어느 쪽이든 NVD에 한 번도 등록되지 않은 소프트웨어라면 CPE 번호가 존재하지 않고, 취약점을 등록하기 위해 CPE 번호를 아무리 찾아도 오류 메시지만 뜬다. 그러면 이름을 새로 등록해야 한다.
2. CPE 이름을 새로 등록하는 과정에 오류 확인 기능은 존재하지 않는다. NVD에 새로운 CPE 이름을 입력할 때 사실상 아무런 이름이나 넣을 수 있게 된다. 명명법이라는 게 있긴 있으나, 모든 사람이 그 규칙을 완벽히 익히고 있다고 보기는 힘들다. 그러니 누군가는 명명법을 지키더라도 조금씩 실수를 하기 마련이다. 그러면 CPE 이름이 등록되더라도 규칙을 따르지 않아 검색하기 힘든 이름이 등록된다.
나중에 취약점을 등록하고자 하는 한 사용자가 명명법에 따라 CPE를 검색할 때 어떤 일이 일어날까? 위 1번과 같이 찾고자 하는 CPE 번호가 없다는 오류만 받게 된다. 원래 오류가 없는 소프트웨어였거나, 오류가 있어도 개발사가 등록하지 않은 경우라고 오해하기 십상이다. 그럼에도 ‘내가 오타를 냈다’거나 ‘원 CPE 등록자가 잘못 이름을 붙였다’고 의심하는 건 쉽지 않다. 백이면 백, ‘이 제품과 관련된 취약점은 한 번도 등록된 적이 없다’고 생각할 것이다. 취약점을 추적하고 현황을 업데이트하는 게 틀어진다.
3. 시간이 지나면서 제품의 이름이나 개발사의 이름이 바뀔 수 있다. M&A가 일어난다든지, 회사가 리브랜딩을 감행했다면 얼마든지 가능한 일이다. 그럴 때 CPE 이름이 자동으로 바뀌면 좋으련만 절대로 그렇지 않다. CPE까지 챙겨가며 이름을 바꿔주는 회사가 있는가 하면, 그렇지 않은 회사들도 있다. 그러니 산업 내 상황이 바뀔 때마다 CPE들은 구버전이 그대로 사용되기도 하고 신버전이 아무도 몰래 등록되는 등 혼란이 가중된다. 특정 요소에 어떤 취약점들이 있는지 조사하려 해도 잘 되지 않는다.
4. 기업 이름이 바뀌지 않는다고 하더라도, 기업에는 여러 가지 이름이 있다. 예를 들어 누군가는 그냥 ‘마이크로소프트’라고 부르지만, 어떤 사람은 ‘마이크로소프트 사’라고 하기도 한다. 제품의 이름도 사정은 비슷하다. ‘마이크로소프트 워드’라고 하는 사람도 있고, ‘오피스 워드’라고 하는 사람도 있으며, ‘MS 워드프로세서’라고 하는 사람도 있다. 이런 경우들도 CPE 이름을 제각각으로 만들며, 따라서 NVD에서의 취약점 검색을 훨씬 어렵게 만든다.
5. 위 4번과 비슷한데, 오픈소스의 경우 취약점 등록이나 열람을 하려는 사람이 훨씬 많고, 따라서 CPE 이름도 많은 사람들이 중구난방으로 등록할 수 있다. 이런 경우 ‘이 모든 CPE들이 결국 한 제품을 말하는 것이고, 따라서 이 CVE 번호들은 한 가지 취약점을 가르키는 것’이라고 종합할 수 있는 관점을 갖는 게 불가능에 가깝게 된다. 엄청난 행정 낭비와 인력 낭비가 발생하고, 취약점 관리는 더 어려워진다.
6. 많은 경우 취약점들은 한 가지 라이브러리의 한 가지 모듈에만 영향을 준다. 하지만 CPE는 제품 전체의 이름이다. 모듈에 따라 이름이 붙지 않는다는 것이다. 그러므로 취약점의 정확한 내용을 인지하려면 CVE 보고서 전체를 읽어야 한다. 하지만 보고서 전체를 꼼꼼히 읽는 사람은 그리 많지 않다. 대부분 제목만 훑고 지나간다. 그러면 불필요한 패치에 시간을 낭비하게 될 수밖에 없다.
공급망 문제와 취약점 관리의 효율을 높이려면 현재 NVD가 고수하고 있는 명명 체계부터 손을 봐야 한다. 이미 OWASP, 리눅스재단, 오라클 등 여러 단체와 조직들에서 이 문제를 인지하고 작업을 시작했다. 하지만 아직 이렇다 할 해결책이나 제안이 나온 것은 아니다. 지금의 문제들을 해결할 수만 있다면 취약점 관리 체제에는 큰 변화가 있을 것으로 기대한다.
글 : 커티스 얀코(Curtis Yanko), 수석 아키텍트, GrammaTech
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
