2019년 가장 위험한 소프트웨어 오류: 기록 반복의 더 많은 증거

이 문서는 원래 정보 보안 버즈에 등장하고, 다른 여러 콘센트에 의해 포착되었다. 여기에 신디케이션을 위해 업데이트되었습니다.

작년 말, MITRE의 놀라운 커뮤니티는 2019년에 세계에 영향을 미쳤던 CWE 상위 25대 가장 위험한 소프트웨어 오류 목록을 발표했습니다. 이 목록은 의견 중심이 아니며 NIST와같은 조직의 작업을 활용하는 다각적 인 분석의 결과이며 공통 취약점 및 노출 (CVE) 데이터를 공개했습니다. "상단" 결함을 확인하기 위해 점수는 현재 소프트웨어의 심각도, 악용 가능성 및 보급에 따라 기인합니다. 그것은 어떤 긍정적 인 찬사를 이길 거야 목록의 종류가 아니다, 그건 확실히.

그러나, 연간 랩업의 대부분과는 달리,이 목록에 참가자의 대부분은 전에 등장 ... 또 다시. 빌보드 핫 100 차트라면 브리트니 스피어스의베이비 원 모어 타임과 백스트리트 보이즈의'I Want It That Way'가 첫 출시 이후 매년 출연할 것입니다. 그리고 왜 그 노래를 골라했는가? 글쎄, 그들은 약 스물 살 (아직 고대 느낌?), 수십 년 전에 발견에도 불구하고 2020 년까지 우리를 괴롭히는 이러한 위험한 소프트웨어 오류 중 일부와 비슷합니다.

오래된 버그는 여전히 그렇게 위험한 이유는 무엇입니까? 우리는 그들을 해결하는 방법을 몰라?

현재 MITRE 목록의 6위는 SQL 주입(SQLi)으로 더 잘 알려진 CWE-89입니다. SQLi 취약점은 1998년에 처음 발견되었으며, 우리 중 많은 사람들이 여전히 Google 대신 Jeeves에게 불타는 질문을 던졌습니다. 수정 은 곧 알려졌다, 아직, 이것은 가장 많이 사용되는 해킹 기술 중 하나 남아 2019. Akamai의 인터넷 현황 보고서에 따르면 SQLi가 모든 웹 애플리케이션 공격의 3분의 2에 대한 주범이라고 합니다.

복잡성이 있는 한 SQL 주입은 천재 수준의 악용과는 거리가 멀다. 웹 개발자를 위한 간단한 수정 사항이며, 이 취약점이 공격자에게 귀중한 데이터를 노출하는 것을 방지하는 방법을 주저하지 않고 알고 있습니다... 문제는 오늘날에도 많은 개발자에게 보안이 우선 순위가 아니라는 것입니다. 이것은 20 년 전에 쉬웠을 수도 있지만, 현재와 미래에 소프트웨어의 엄청난 볼륨으로, 이것은 더 이상 규범을 유지할 수 없습니다.

개발자는 깨진 시스템(대부분의 시간)에서 작동합니다.

그것은 앉아서 "나쁜"코드를 제공에 대한 개발자를 비난하는 모든 너무 쉽습니다. 진실은, 그들의 우선 순위는 보안 팀의 것과 격렬하게 다릅니다. 평균 개발 팀은 가능한 한 빨리 아름답고 기능적인 소프트웨어를 만들어야 합니다. 소프트웨어에 대한 사회의 무심해의 필요성은 개발자 팀이 이미 늘어나고 보안이 주요 고려 사항이 아님을 보장합니다. 결국, AppSec 전문가가 존재하는 이유가 아닌가요? 소프트웨어 엔지니어는 보안과 다소 쌀쌀한 관계에 익숙합니다 - 문제가 발생할 때만 그들로부터 듣고, 이러한 문제는 그들의 노력의 생산을 유지할 수 있습니다.

울타리의 반대편에, AppSec 전문가는 모든 스캔 및 수동 코드 검토에 팝업 계속 수십 년 된 오류를 수정의 아픈. 이러한 전문가는 비싸고 부족하며, 잘 알려진 버그를 반복해서 분쇄하는 대신 복잡한 보안 결함에 훨씬 더 많은 시간을 소비합니다.

이러한 팀 사이에 손가락을 가리키는 무언의 문화가 있지만 보안 소프트웨어와 같은 목표를 가지고 있거나 가져야 합니다. 개발자는 보안 코딩 측면에서 거의 성공할 수 있는 최고의 기회를 제공하는 환경에서 운영되고 있습니다. 보안 모범 사례는 고등 교육의 일환으로 거의 가르쳐지지 않으며, 실무 교육은 종종 너무 드물거나 완전히 비효율적입니다. 보안 인식과 심층적 인 관련 교육에 중점을 두지 않으며, 그 결과는 커밋된 코드에서 오래된 버그를 수정하는 천문학적 비용과 평판 을 죽이는 데이터 유출의 임박한 위협입니다.

인적 요인, 일명 "왜 이러한 모든 도구가 우리의 데이터를 더 안전하게 만들지 않습니까?"

자주 나타나는 또 다른 문제는 교육 대신 소프트웨어가 야생으로 출시되기 전에 문제를 찾는 작업에 방대한 보안 도구가 투입된다는 것입니다. 어레이 애플리케이션 스캐닝 및 보호도구(SAST/DAST/RASP/IAST)는보안 소프트웨어 생산을 확실히 지원할 수 있지만 자체 적인 문제가 있습니다. 그들에 대한 완전한 의존은 보안을 보장하지 않습니다, 때문에:

• 모든 사용 사례에서 모든 취약점을 검사할 수 있는 "one" 도구는 없습니다.
• 특히 정적 및 동적 코드 분석을 모두 제공하기 위해 함께 실행할 때 속도가 느려질 수 있습니다.
• 거짓 긍정은 계속해서 문제가 됩니다. 이러한 경우 종종 생산을 중단하고 경고를 이해하기 위해 불필요한 수동 코드 검토가 필요합니다.
• 보안 코드는 이러한 도구가 문제를 일으킬 것이라는 기대와 함께 우선 순위가 저하되어 보안이 잘못된 보안 감각을 만듭니다.

도구는 확실히 패치 할 수있는 보안 결함을 발굴하지만, 그들은 모든 것을 찾을 것인가? 100% 적중률은 보장할 수 없으며, 공격자는 입구를 확보하고 하루를 망치기 위해 문을 하나만 열어 두어야 합니다.

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

개발자는 자신의 언어를 구사하는 교육과 함께 번창 할 수있는 기회를 제공해야합니다, 자신의 직업과 관련이 있으며, 적극적으로 보안에 대한 흥분을 가져옵니다. 버그가없는 코드는 기능적으로 킥 엉덩이를 구축하는 것과 마찬가지로 동료의 존경을 이길 수있는 자부심의 포인트여야합니다.

최신 보안 프로그램은 비즈니스 우선 순위가 되어야 합니다.

개발 팀은 부트스트랩을 통해 스스로를 끌어올려 회사 전체에 긍정적인 보안 인식을 제고할 수 없습니다. 처음부터 소프트웨어 개발 프로세스에 보안을 적용하기 위해 올바른 도구, 지식 및 지원이 필요합니다.

MITRE의 목록이 여전히 너무 많은 오래된 보안 버그를 보여주는 경우 오래된 교육 방법은 분명히 작동하지 않습니다, 그래서 새로운 것을 시도. 다음과 같은 교육 솔루션을 찾습니다.

• 실습; 개발자는 비디오에서 말하는 머리를 보고하지 않고 "함으로써 배우는 것"을 좋아합니다.
• 관련; 매일 Java를 사용하는 경우 C #에서 훈련을 하지 마십시오.
• 참여; 한입 크기의 학습은 소화하기 쉽고 개발자가 이전 지식을 계속 구축할 수 있습니다.
• 측정 가능한; 그냥 상자를 체크하고 이동하지 마십시오. 교육이 효과적인지 확인하고 개선을 위한 통로를 조성합니다.
• 재미; 긍정적인 보안 문화를 지원하는 것 외에도 보안 인식을 구축할 수 있는 방법과 응집력 있는 팀 환경을 만드는 방법을 살펴보십시오.

CISO는 데이터를 더 안전하게 유지하기 위한 모든 수준에서 가시성있고 투명하게 표시되어 조직의 모든 사람에게 보안을 최우선 과제로 삼아야 합니다. 내 말은, 누가 반복에 같은 오래된 노래를 듣고 싶어? 그것은 좋은 오래된 버그를 분쇄에 대한 심각한 얻을 시간이다.