2019년 가장 위험한 소프트웨어 오류: 역사가 반복되고 있다는 또 다른 증거

이 기사는 원래 Information Security Buzz에 게재되었으며, 여러 다른 매체에서도 인용되었습니다. 본 게시물은 신디케이션을 위해 업데이트되었습니다.

작년 말, MITRE의 훌륭한 커뮤니티에서 2019년 전 세계에 영향을 미친 CWE 상위 25대 가장 위험한 소프트웨어 오류 목록을 발표했습니다. 이 목록은 주관적인 의견이 아니라 NIST와 같은 기관의 연구 결과와 공개된 CVE(Common Vulnerabilities and Exposures) 데이터를 활용한 다각적 분석의 결과물입니다. "최상위" 결함을 결정하기 위해 현재 소프트웨어에서의 심각성, 악용 가능성, 발생 빈도를 기준으로 점수가 매겨집니다. 분명한 것은, 이 목록이 결코 자랑스러운 성적표는 아니라는 점입니다.

하지만 매년 발표되는 연말 결산과는 달리, 이 목록에 오른 항목 중 다수는 예전에도 반복해서 등장했던 것들입니다. 만약 이것이 빌보드 차트라면, 브리트니 스피어스의 Baby One More Time이나 백스트리트 보이즈의 I Want It That Way가 발매 이후 매년 차트에 오르는 것과 같습니다. 왜 하필 이 노래들이냐고요? 이 노래들이 나온 지 대략 20년이 지났기 때문입니다(벌써 세월이 이렇게 흘렀나 싶으시죠?). 수십 년 전에 발견되었음에도 불구하고 2020년 현재까지 우리를 괴롭히는 위험한 소프트웨어 오류들도 이와 마찬가지입니다.

왜 오래된 버그들이 여전히 위험할까요? 우리는 그것들을 고치는 방법을 모르는 걸까요?

현재 MITRE 목록에서 6위를 차지한 것은 CWE-89, 즉 SQL 인젝션(SQLi)입니다. SQLi 취약점은 1998년에 처음 발견되었습니다. 당시 우리 중 많은 이들은 구글 대신 'Ask Jeeves'에 궁금한 점을 묻곤 했죠. 그 직후 해결책이 나왔음에도 불구하고, 이는 2019년에도 가장 많이 사용되는 해킹 기법 중 하나로 남아 있습니다. 아카마이(Akamai)의 인터넷 현황(State of the Internet) 보고서에 따르면, SQLi는 전체 웹 애플리케이션 공격의 3분의 2를 차지하는 주범이었습니다.

복잡성 측면에서 볼 때, SQL 인젝션은 결코 천재적인 수준의 공격이 아닙니다. 웹 개발자에게는 간단히 해결할 수 있는 문제이며, 우리는 이 취약점이 공격자에게 소중한 데이터를 노출하지 않도록 방지하는 방법을 확실히 알고 있습니다. 문제는 오늘날에도 많은 개발자에게 보안이 우선순위가 아니라는 점입니다. 20년 전에는 쉬웠을지 몰라도, 오늘날과 미래에 쏟아져 나오는 엄청난 양의 소프트웨어를 고려할 때, 이제는 이런 관행이 더 이상 지속되어서는 안 됩니다.

개발자들은 (대부분의 경우) 망가진 시스템 속에서 일하고 있습니다.

개발자가 "나쁜" 코드를 작성한다고 비난하기는 너무 쉽습니다. 하지만 진실은 그들의 우선순위가 보안 팀의 우선순위와는 완전히 다르다는 것입니다. 일반적인 개발 팀은 가능한 한 빨리 아름답고 기능적인 소프트웨어를 만들라는 지시를 받습니다. 소프트웨어에 대한 사회의 끝없는 수요로 인해 개발 팀은 이미 한계치까지 일하고 있으며, 보안은 최우선 고려 사항이 아닙니다. 어차피 그건 AppSec 전문가들이 할 일 아닌가요? 소프트웨어 엔지니어들은 보안 팀과 다소 서먹한 관계에 익숙합니다. 문제가 생겼을 때만 보안 팀의 연락을 받게 되고, 그 문제들은 힘들게 만든 작업물의 출시를 지연시키기 때문입니다.

반면, AppSec 전문가들은 모든 스캔과 수동 코드 검토에서 끊임없이 튀어나오는 수십 년 된 오류를 수정하는 데 지쳐 있습니다. 이 전문가들은 귀하고 몸값도 비싼 인력인데, 이들의 시간을 뻔한 버그를 반복해서 잡는 데 쓰는 것은 매우 비효율적입니다. 이들의 시간은 더 복잡한 보안 결함을 해결하는 데 쓰여야 합니다.

이 팀들 사이에는 서로를 탓하는 암묵적인 문화가 존재하지만, 그들은 모두 '안전한 소프트웨어'라는 같은 목표를 가지고 있습니다(그래야만 합니다). 개발자들은 안전한 코딩을 할 수 있는 최선의 환경을 거의 제공받지 못합니다. 고등 교육 과정에서 보안 모범 사례를 배우는 경우는 드물고, 직무 교육은 너무 드물거나 전혀 효과가 없는 경우가 많습니다. 보안 인식과 심도 있고 관련성 높은 교육에 대한 강조가 현저히 부족하며, 그 결과는 커밋된 코드의 오래된 버그를 수정하는 데 드는 천문학적인 비용과 기업의 명성을 파괴할 수 있는 데이터 유출의 위협으로 돌아옵니다.

인적 요소, 즉 "왜 이 모든 도구들이 우리 데이터를 더 안전하게 만들지 못하는가?"

자주 발생하는 또 다른 문제는 교육 대신 소프트웨어가 배포되기 전에 문제를 찾기 위해 수많은 보안 도구를 동원한다는 점입니다. 다양한 애플리케이션 스캔 및 보호 도구(SAST/DAST/RASP/IAST)가 안전한 소프트웨어 생산에 도움을 줄 수는 있지만, 그 자체로도 문제가 있습니다. 도구에만 전적으로 의존하는 것은 보안을 보장하지 못합니다. 이유는 다음과 같습니다.

• 어떤 도구도 모든 프레임워크와 모든 사용 사례에서 발생하는 모든 취약점을 스캔할 수는 없습니다.
• 특히 정적 및 동적 코드 분석을 동시에 수행할 경우 속도가 느려질 수 있습니다.
• 오탐(False Positive)은 여전히 문제입니다. 이는 종종 생산을 중단시키고 경고의 의미를 파악하기 위해 불필요한 수동 코드 검토를 요구합니다.
• 도구가 모든 문제를 잡아줄 것이라는 기대 때문에 안전한 코딩이 뒷전으로 밀려나면서 잘못된 보안 의식을 심어줍니다.

도구들이 패치 가능한 보안 결함을 찾아내는 것은 분명하지만, 모든 것을 찾아낼 수 있을까요? 100% 탐지율을 보장하는 것은 불가능하며, 공격자는 단 하나의 열린 문만 찾아내도 침입하여 당신의 하루를 완전히 망쳐놓을 수 있습니다.

다행히 많은 조직이 소프트웨어 취약점에 작용하는 인적 요소의 중요성을 깨닫고 있습니다. 대부분의 개발자는 안전한 코딩을 위한 적절한 교육을 받지 못했고, 전반적인 보안 인식도 낮습니다. 하지만 그들은 소프트웨어 개발 수명 주기의 가장 앞단에 있으며, 취약점이 커밋된 코드에 포함되지 않도록 막을 수 있는 최적의 위치에 있습니다. 만약 그들이 처음부터 안전하게 코딩한다면, 매년 수십억 달러의 피해를 주는 파괴적인 사이버 공격에 맞서는 최전방 방어선이 될 것입니다.

개발자들에게는 그들의 언어로 소통하고, 업무와 관련이 있으며, 보안에 대해 적극적으로 흥미를 느낄 수 있는 교육을 제공하여 그들이 성장할 기회를 주어야 합니다. 버그 없는 코드를 작성하는 것은 동료들에게 인정받는 훌륭한 기능을 구현하는 것만큼이나 자부심의 원천이 되어야 합니다.

현대적인 보안 프로그램은 비즈니스의 최우선 순위가 되어야 합니다.

개발팀이 스스로의 힘만으로 전사적인 보안 인식을 개선하기는 어렵습니다. 소프트웨어 개발 초기 단계부터 보안을 내재화하려면 적절한 도구와 지식, 그리고 지원이 뒷받침되어야 합니다.

MITRE 목록에 여전히 수많은 구형 보안 취약점이 나열되어 있다는 것은 기존의 교육 방식이 효과가 없다는 명백한 증거입니다. 이제 새로운 방식을 시도해 보세요. 다음과 같은 교육 솔루션을 찾아야 합니다.

• 실습 중심: 개발자는 영상 속 강사의 설명을 듣기보다 직접 해보며 배우는 것을 선호합니다.
• 관련성: 매일 Java를 사용하는 개발자에게 C# 교육을 강요하지 마세요.
• 참여 유도: 짧고 간결한 학습 콘텐츠는 이해하기 쉬우며, 기존 지식을 바탕으로 꾸준히 역량을 쌓을 수 있게 해줍니다.
• 측정 가능: 단순히 교육 이수 여부만 확인하고 넘어가지 마세요. 교육의 효과를 검증하고 개선을 위한 경로를 마련해야 합니다.
• 재미: 보안 인식을 높이는 동시에 긍정적인 보안 문화를 조성하고, 팀워크를 강화할 수 있는 방법을 고민해 보세요.

보안은 조직 내 모든 구성원이 최우선으로 고려해야 할 과제입니다. CISO는 데이터 보호를 위한 노력을 모든 단계에서 가시적이고 투명하게 공유해야 합니다. 매번 똑같은 이야기만 반복해서는 안 되지 않겠습니까? 이제는 고질적인 보안 취약점을 완전히 뿌리 뽑을 때입니다.