ELC + OpenIoT 서밋에서 인텔 보안 아키텍트 Ryan Ware가 취약점 홍수에 대응하고 제품의 보안을 관리하는 방법을 설명할 것입니다.
오픈소스 소프트웨어를 개발할 때, 고려해야 할 보안 취약점이 당신을 압도할 수 있습니다. 일반 취약점 및 노출(CVE) ID, 제로데이 취약점 및 기타 취약점이 매일 발표되는 것 같습니다. 이러한 정보 홍수 속에서 어떻게 뒤처지지 않을 수 있을까요?
인텔 보안 아키텍트 Ryan Ware는 “Linux 커널 4.4.1을 기반으로 제품을 발표했다면, 해당 커널은 오늘까지 이미 9개의 CVE가 있습니다. 이것들은 모두 당신의 제품에 영향을 미치지만, 사실 당신이 그것들을 탑재했을 때는 몰랐습니다”라고 말합니다.
ELC + OpenIoT 서밋에서 인텔 보안 아키텍트 Ryan Ware의 연설은 제품의 보안을 구현하고 성공적으로 관리하는 전략을 소개할 것입니다. 그의 연설에서 Ware는 가장 일반적인 개발자 실수, 최신 취약점을 따라가는 전략 등을 논의합니다.
Linux.com: 처음부터 시작합시다. 일반 취약점 및 노출(CVE), 제로데이 및 기타 취약점에 대해 간단히 소개해 주시겠습니까? 그것들은 무엇이며, 왜 중요합니까?
Ryan Ware: 좋은 질문입니다. 일반 취약점 및 노출(CVE)는 미국 정부의 요청에 따라 MITR Corporation(비영리 조직)이 유지 관리하는 데이터베이스입니다. 현재 미국 국토안보부의 자금 지원을 받습니다. 1999년에 생성되어 발표된 모든 보안 취약점에 대한 정보를 포함합니다. 이러한 취약점 각각은 자체 식별자(CVE-ID)를 가지며 참조될 수 있습니다. CVE라는 용어는 전체 데이터베이스를 지칭하는 것에서 점차 개별 보안 취약점을 대표하는 것으로 진화했습니다: CVE 취약점.
CVE 데이터베이스에 나타나는 많은 취약점은 처음에 제로데이 취약점이었습니다. 이러한 취약점은 어떤 이유로든 “책임 있는 공개“와 같은 더 질서 있는 공개 과정을 따르지 않았습니다. 핵심은 소프트웨어 공급업체가 어떤 유형의 수정(보통 소프트웨어 패치)으로 응답할 수 없다면, 그것들은 공개되고 악용 가능하게 됩니다. 이러한 것들과 다른 패치되지 않은 소프트웨어 취약점은 매우 중요합니다. 왜냐하면 소프트웨어가 패치되기 전까지 취약점은 악용될 수 있기 때문입니다. 많은 면에서 CVE 또는 제로데이를 발표하는 것은 총을 쏘는 것과 같습니다. 경기가 끝나기 전까지 당신의 고객은 쉽게 피해를 입을 수 있습니다.
Linux.com: 취약점이 얼마나 많습니까? 당신의 제품과 관련된 것을 어떻게 결정합니까?
Ryan: 얼마나 많은지 논의하기 전에, 어떤 형태로든 소프트웨어를 발표하는 모든 사람이 기억해야 합니다. 당신이 발표하는 소프트웨어에 알려진 취약점이 없도록 모든 노력을 기울이더라도, 당신의 소프트웨어는 취약점이 있을 것입니다. 그것들은 단지 알려지지 않았을 뿐입니다. 예를 들어, Linux 커널 4.4.1을 기반으로 제품을 발표했다면, 오늘까지 이미 9개의 CVE가 있습니다. 이것들은 모두 당신의 제품에 영향을 미치지만, 사실 당신이 그것들을 사용했을 때는 몰랐습니다.
현재 CVE 데이터베이스는 80,957개의 항목을 포함합니다(2017년 1월 30일 기준), 1999년으로 거슬러 올라가는 모든 기록을 포함하며, 당시 894개의 기록된 문제가 있었습니다. 지금까지 1년 중 가장 큰 숫자가 나타난 것은 2014년으로, 당시 7,946개의 문제가 기록되었습니다. 즉, 지난 2년간 숫자가 감소한 것이 보안 취약점의 감소 때문이라고 생각하지 않습니다. 이것은 제가 연설에서 말할 것입니다.
Linux.com: 개발자는 이러한 정보를 따라가기 위해 어떤 전략을 사용할 수 있습니까?
Ryan: 개발자는 다양한 방식으로 이러한 홍수처럼 밀려오는 취약점 정보를 따라갈 수 있습니다. 제가 가장 좋아하는 도구 중 하나는 CVE Details입니다. MITRE의 정보를 매우 이해하기 쉬운 방식으로 보여줍니다. 가장 좋은 기능은 사용자 정의 RSS 피드를 생성할 수 있는 능력으로, 당신이 관심 있는 구성 요소의 취약점을 추적할 수 있습니다. 더 복잡한 추적 요구 사항이 있는 사람은 MITR CVE 데이터베이스(무료 제공)를 다운로드하고 정기적으로 업데이트하는 것부터 시작할 수 있습니다. cvechecker와 같은 다른 훌륭한 도구는 소프트웨어에서 알려진 취약점을 확인할 수 있게 합니다.
소프트웨어 스택의 핵심 부분에 대해 저는 매우 유용한 도구를 추천합니다: 상위 커뮤니티에 참여하는 것입니다. 이들은 당신이 사용하는 소프트웨어를 가장 잘 이해하는 사람들입니다. 그들보다 더 나은 전문가는 세상에 없습니다. 그들과 협력하세요.
Linux.com: 당신의 제품이 모든 취약점을 해결했는지 어떻게 알 수 있습니까? 추천하는 도구가 있습니까?
Ryan: 불행히도 위에서 말한 것처럼, 당신은 제품에서 모든 취약점을 제거할 수 없습니다. 위에서 언급한 일부 도구는 핵심입니다. 하지만 저는 아직 언급하지 않은 것이 있습니다. 당신이 발표하는 모든 제품에 필수적인 부분: 소프트웨어 업데이트 메커니즘입니다. 당신이 현장에서 제품 소프트웨어를 업데이트할 수 없다면, 고객이 영향을 받을 때 보안 문제를 해결할 수 없습니다. 당신의 소프트웨어는 업데이트할 수 있어야 하며, 업데이트 과정이 쉬울수록 고객은 더 잘 보호받을 것입니다.
Linux.com: 개발자가 보안 취약점을 성공적으로 관리하기 위해 무엇을 더 알아야 합니까?
Ryan: 제가 반복해서 보는 실수가 있습니다. 개발자는 항상 공격 표면을 최소화하는 아이디어를 명심해야 합니다. 이것은 무엇을 의미합니까? 실제로 이것은 당신의 제품이 실제로 필요한 것만 포함한다는 것을 의미합니다! 이것은 무관한 소프트웨어 패키지를 제품에 추가하지 않는 것을 보장할 뿐만 아니라, 필요하지 않은 기능의 구성을 닫아 프로젝트를 컴파일할 수도 있습니다.
이것이 어떻게 도움이 됩니까? 2014년이라고 상상해 보세요. 당신은 방금 출근해서 Heartbleed 기술 뉴스를 보았습니다. 당신은 제품에 OpenSSL을 포함했다는 것을 알고 있습니다. 왜냐하면 일부 기본 암호화 기능을 수행해야 하지만, TLS 하트비트를 사용하지 않으며, 그 문제는 그 취약점과 관련이 있습니다. 당신은:
a. 고객과 파트너와 협력하여 중요한 소프트웨어 업데이트를 통해 이 높은 보안 문제를 해결하는 데 시간을 소비하시겠습니까?
b. 고객과 파트너에게 “-DOPENSSLNOHEARTBEATS” 플래그로 OpenSSL 제품을 컴파일했다고 말하고, 그들은 피해를 입지 않으며, 당신은 새로운 기능과 다른 생산 활동에 집중할 수 있다고 말하시겠습니까?
취약점을 해결하는 가장 간단한 방법은 그 취약점을 포함하지 않는 것입니다.
(제목 이미지: Creative Commons Zero Pixabay)
출처 명시:개발자 관계 »
