버그의 탄생
소프트웨어 취약점(버그)이란 무엇이며 어디서 발생하나요?
몇 가지 정의는 맥락에 도움이 됩니다:
Gartner® 정의: " 버그는 소프트웨어 또는 하드웨어의 예기치 않은 문제입니다. 일반적인 문제는 개발자가 예상하지 못한프로그램 성능에 대한 외부 간섭으로 인해 발생하는 경우가 많습니다 ."
Mitre는 취약점을 "…해커가 시스템 또는 네트워크에 액세스하는 데 직접 사용할 수 있는 소프트웨어의 실수"로 정의합니다.
버그와 취약점은 새로운 약점, 점점 더 정교해지는 새로운 공격 방법, 새로운 기술, 인프라 및 개발 관행의 도입, 인력 부족 등 다양한 이유로 발생할 수 있습니다. 대부분의 경우 원인은 사람의 실수입니다. 이는 소프트웨어 버그가 계속 존재한다는 것을 의미합니다. 이제 버그의 일생과 이에 대해 어떻게 대처할 수 있는지 살펴보겠습니다.
재미있는 버그 사실:
최초의 컴퓨터 버그는 1947년 하버드의 마크 II 컴퓨터를 단락시킨 나방이라는 소문이 돌았습니다. 컴퓨터는 ‘디버깅’되었고, ‘버그’는 실험실의 기술자가 보관하는 로그북 입력 페이지에 테이프로 붙여져 있었습니다. 버그 리포트에 대해 이야기해 보세요!
버그 찾기
소프트웨어 취약점은 어떻게 발견되나요?
대부분의 소프트웨어 버그는 버그 “바운티 헌터”라 불리는 보안 연구원이 발견합니다. 버그 바운티 는 소프트웨어 공급업체(및 외부 보안 회사)가 운영하는 프로그램으로, 공급업체가 복제할 수 있는 버그를 발견하여 보고하고 궁극적으로 패치 또는 구성 변경 지침의 형태로 ‘수정’을 제공하는 위협 연구자 및 윤리적 해커에게 현금 보상을 지급하는 경우가 많으며, 주로 소프트웨어 공급업체에서 운영합니다.
비윤리적인 해커나 명예롭지 않은 목적을 가진 ‘빌런’에 의해서도 버그가 발견될 수 있습니다. 그리고 이러한 악의적인 공격자들은 바운티 헌터의 친구들과는 달리 취약점을 발견해도 공급업체나 그 누구에게도 신고하지 않습니다. 이들은 악의적인 용도로 이를 무기화합니다.
알려진 익스플로잇 취약점 카탈로그에는 침해 또는 일련의 침해 조사 결과 악의적인 의도로 악용된 취약점이 알려진 경우, 알려진 취약점이 나열되어 있습니다.
덜 명예로운 해킹 동기로는 다음과 같은 것들이 있습니다:[1]
- 금전적 이득: 랜섬웨어, 피해자로부터의 직접적인 절도, 다크 웹에서의 데이터 판매 등이 포함
- 정치적 발언: "해키비스트"는 특정 이념을 지지하기 위해 웹사이트, 시스템 등을 교란
- 복수: 불만을 품은 직원, 불만을 품은 고객 또는 개인적인 복수를 위해 피해를 입힌 사람
- 명성: 인정을 받고자 하는 해커
- 지적 재산 도용: 지적 재산 절도의 동기는 무기 설계도에서 제품 특허에 이르기까지 모든 것을 노리는 국가 및 기업 후원 공격이 이 범주에 포함되기 때문에 기업 및 기타 조직에 특히 위험 국가가 후원하는 해커는 공격 대상을 해킹할 방법을 찾는 데 시간과 자금이 무제한인 경우가 많습니다.
Mitre는 위협 그룹의 전체 목록을 추적합니다. 이러한 국가적 행위자의 예로는 지능형 지속 위협(APT) 그룹이있습니다.[2] 중국의 디피도그(APT17), 버키아이(APT3), 무서운 더블 드래곤(APT41) 등이 있습니다.[3].
Gartner는 또한 "어떤 조직이든 보안 성숙도 수준에서 취약점 제로를 달성하는 것은 불가능하다"며 보안에 대한 우려를 표명했습니다.[4]
재미있는 버그 사실:
많은 소프트웨어 공급업체는 취약점의 조기 공개를 방지하고 악의적인 공격자가 고객이 패치를 검색, 테스트 및 적용할 기회를 갖기 전에 취약점을 무기화하는 것을 막기 위해 버그 바운티 프로그램 참여 시 기밀유지계약(NDA)을 요구합니다.[5]
소프트웨어 공급업체 승인
공급업체가 버그에 대응하는 방법
소프트웨어에서 버그가 발견되면 공급업체가 어떤 조치를 취해야 하는지 알고 계신가요? 일반적으로는 아무것도 없습니다. 왜 안 될까요? 사용자 계약에 따라[6] 일반적으로 보증 및 구제책에 대한 면책 조항을 통해 공급업체를 보호합니다. 실망스러운 일이지만 벤더들은 행동에 나섭니다. 보통은 그렇습니다:
- 버그 제출 검토
- (바운티 헌터 안내를 통해) 복제하기
- 버그를 검증하고, 영향을 받는 제품을 식별하고, 추가 조치를 위해 버그를 수락
- 패치 개발
- Oracle 중요 패치 업데이트(CPU) 또는 SAP 보안 패치 데이와 같은 업데이트 패키지에 새 패치를 추가합니다.
이 과정은 짧게는 몇 주에서 길게는 몇 년까지 시간이 걸릴 수 있습니다.
재미있는 버그 사실:
NIST는 국가 취약점 데이터베이스 (NVD)에서 새로운 취약점 제출을 추적합니다. 2023년에는 29,000개 이상의 보안 취약점이 일반 취약점 및 노출(CVE)로 등록되었으며, 2024년에는 2023년을 앞지를 것으로 예상됩니다.[7]
버그 이름 지정하기
일반적인 취약성 및 노출(CVE)을 식별하는 방법
소프트웨어 버그에 이름(실제로는 숫자)이 있으면 도움이 됩니다. 다행히도 연구자 및 소프트웨어 공급업체를 포함한 CVE 번호 지정 기관은[8] 는 NIST에서 제공하는 사전 할당된 예약 번호 블록에서 CVE ID를 할당합니다.[9] 사이버 보안 전문가가 소프트웨어 수정 및 완화를 추적하고 보고할 수 있도록 제출된 취약점당 하나의 CVE 레코드를 할당합니다.
참고: CVE가 생성된 날짜는 공급업체에 번호가 처음 발급된 날짜를 반영하며, 이는 취약점이 발견된 날짜와 크게 다를 수 있습니다![10]
재미있는 버그 사실:
공급업체는 신규 또는 기존 소프트웨어의 버그를 보고할 의무가 없기 때문에 CVE 목록은 자발적이고 불완전한 정의에 따라 작성됩니다.[11] 또한 MITRE와 NIST는 일관성을 보장하기 위해 CVE 제출에 대한 가이드라인과 표준을 제공하지만 공급업체가 이를 따라야 할 의무는 없습니다.
소프트웨어 취약성에 대해 할 수 있는 일
보안 및 위험 관리(SRM) 대응 개발 방법
새로운 소프트웨어 버그에 대해 알게 된 후의 반응은 “또 다른 버그! 그리고 또 다른 패치!”
그러나 해당 버그나 취약점은 개발자가 처음 소프트웨어를 만들 때부터 존재했을 가능성이 높으며(패치를 통해 도입된 것이 아니라면) 악의적인 공격자가 버그를 빠르게 악용할 수 있으므로 버그 방어 계획을 마련하는 것이 현명합니다.
공급업체 패치는 다음과 같은 단계를 거쳐야 하는 일반적이지만 힘든 방어 수단입니다:
- 오라클 CPU 또는 SAP 보안 패치 데이에 패치를 선택합니다.
- 패치를 번들로 묶어 비프로덕션 서버에서 테스트하기
- 재무 잔액이나 건강 기록과 같은 중요한 데이터에 영향을 미치지 않는지 확인합니다.
- 다운타임을 예약하고 패치를 위해 프로덕션 시스템을 오프라인 상태로 전환하세요.
- 공급업체가 원래 패치에 대한 사용자 피드백에 따라 새 패치를 발행하는 경우 전체 프로세스를 반복합니다.
재미있는 버그 사실:
2024년 버그가 악용되는 데 걸리는 평균 시간은 4일에 불과했습니다.[12]2014년의 74일 이상에서 줄어든다고 합니다.[13]
버그 해결
보안 패치에 접근하는 방법
공급업체의 보안 패치를 최신 상태로 유지하는 것이 취약성을 완화하는 기존의 방법이었지만[14]기업이 패치를 적용하는 데 어려움을 겪는 것은 드문 일이 아닙니다.[15] 패치가 필요할 수 있기 때문입니다:
- 숙련된 IT 리소스[16] 광범위한 계획, 테스트 및 시스템 가동 중단 시간[17]
- 소프트웨어 취약점을 탐지하고 패치를 제공, 테스트 및 설치하기까지 수개월 또는 수년을 기다려야 합니다.[18]
- 더 이상 소프트웨어 공급업체의 보안 업데이트를 받지 않는 소프트웨어 릴리스에 대해 새로운 공급업체의 보안 패치를 계속 받기 위해 비용이 많이 들고 ROI가 낮은 소프트웨어 업그레이드[19]
패치에만 의존하는 전략은 문제가 있습니다:
- 모든 사이버 보안 위험의 신속한 완화[20]
- 고유한 시스템 구성 또는 데이터에 대한 설명[21]
- 공급업체 패치는 고객이 개발한 사용자 지정 코드를 보호하거나 고객의 고유한 환경 및 아키텍처를 해결하기 위해 특별히 설계되지 않았습니다.
- 공급업체의 보안 업데이트를 개발하고 적용하는 데 시간이 오래 걸리므로 알려진 위협으로부터 보호하는 데 시간이 지연될 수 있습니다.
또한 시스템을 패치하고 업데이트하려면 상당한 양의 다운타임이 필요합니다. 이로 인해 위험을 줄이기 위해 사용 가능한 모든 전술을 배포하려는 보안 팀과 가동 시간과 비즈니스 연속성을 책임지는 IT 운영 팀 간에 마찰이 발생할 수 있습니다.[22]
재미있는 버그 사실:
단일 솔루션으로 모든 취약점을 찾아서 수정할 수는 없습니다.[23]
버그 극복하기
Rimini Protect™가 소프트웨어 취약성을 해결하는 방법
많은 엔터프라이즈 소프트웨어 시스템은 수십 년 동안 고객의 비즈니스를 이끌어 왔으며 현재 공급업체의 지원 종료일이 지났기 때문에 이러한 시스템에 대한 새로운 보안 패치가 제한적이거나 전혀 제공되지 않습니다. 또한 고객이 공급업체의 지원을 중단하면 일반적으로 보안 패치를 사용할 수 없습니다.
리미니스트리트는 리스크 완화의 우선순위를 정하는 비즈니스 및 데이터 중심 접근 방식을 지원합니다. 공급업체가 제공하는 보안 패치를 적용하거나 공급업체 코드를 수정하지 않고도 보안 태세를 개선하고 보안 위험 노출을 줄이는 데 중점을 둡니다.
많은 기업은 이미 제한된 보안 패치 가용성으로 인해 엔터프라이즈 소프트웨어를 보호하기 위해 다른 방어 전략을 수립했습니다. Rimini Protect 솔루션은 고객의 에코시스템에 맞춰 고객의 기존 보안 전략을 보완하고 강화하여 알려진(발견된) 위협과 알려지지 않은(발견되지 않은) 위협 및 취약성으로부터 보호할 수 있도록 지원합니다.
소프트웨어 취약성 FAQ
소프트웨어 취약성에 대한 일반적인 질문에 대한 답변
소프트웨어 약점과 취약점이란 무엇인가요?
약점은 취약점으로 이어질 수 있는 소프트웨어 또는 하드웨어 상태를 말합니다. Mitre는 공통 약점 열거(CWE)로 알려진 취약점 목록을 관리합니다. 취약점은 시스템을 악용(액세스)하는 데 직접적으로 사용될 수 있는 ‘버그’ 또는 실수를 말합니다. NIST는 알려진 공통 취약성 열거(CVE)에 대한 국가 취약성 데이터베이스를 관리합니다.
소프트웨어 취약점의 예로는 어떤 것이 있나요?
취약점은 컨텍스트(약점)를 이용하여 시스템을 악용할 수 있는 방법이라고 생각하세요. CWE-787을 통해 이 취약점이 시스템을 익스플로잇하는 데 사용된 여러 가지 방법의 일부 목록이 있습니다. 소프트웨어 취약점의 예로는 메모리 손상(CVE-2021-28664), 테스트 또는 샌드박스 환경에서 ‘이탈’ 기능 활성화(CVE-2020-0041) 등이 있습니다.
소프트웨어 취약점의 예로는 어떤 것이 있나요?
소프트웨어의 약점을 상황의 맥락으로 생각하세요. 예를 들어 CWE-787은 프로그램이 액세스하려는 메모리 영역의 앞이나 뒤에 데이터를 쓰는 것으로 설명되는 ‘Out-of-bounds Write’라는 제목이 붙어 있습니다. 예상치 못한 메모리 영역에 데이터를 쓰도록 허용하면 예상치 못한 결과가 발생할 수 있으며 이는 약점입니다.
멀웨어와 소프트웨어 취약점의 차이점은 무엇인가요?
멀웨어는 “피해자의 데이터, 애플리케이션 또는 운영 체제의 기밀성, 무결성 또는 가용성”을 손상시키기 위한 익스플로잇을 통해 설치될 수 있는 프로그램입니다. 소프트웨어 취약점은 시스템을 악용하는 데 사용될 수 있는 ‘버그’입니다.
익스플로잇이란 무엇인가요?
익스플로잇은 보안 취약점을 이용하기 위해 프로그램이나 코드를 사용하는 ‘악의적 행위자’를 말합니다. CISA는 KEV 카탈로그라는 알려진 익스플로잇 취약점 목록을 보관하고 있습니다.
익스플로잇의 예로는 어떤 것이 있나요?
익스플로잇의 몇 가지 예는 다음과 같습니다:
- 개인 또는 조직이 CVE-2021-28664에 설명된 방법을 사용하여 회사의 데이터베이스를 손상시킬 수 있는 코드를 작성하는 경우.
- 개인 또는 조직이 CVE-2020-0041에 설명된 방법을 사용하여 컴퓨터의 파일에 무단으로 액세스하여 고객 정보 또는 영업 비밀을 훔칠 수 있는 코드를 작성하는 경우.
CWE가 중요한 이유는 무엇인가요?
전반적인 취약점을 완화하면 일반적으로 하나의 CWE에 언급된 모든 CVE를 무효화할 수 있습니다. 이는 동일한 취약점에 의존하는 미래의 취약점으로부터 보호합니다. (사전 예방적 보호) 이는 각 취약점을 하나씩 해결하려고 시도하는 것보다 훨씬 효율적입니다.