소프트웨어 공급업체도 귀하만큼 보안을 중요하게 생각할까요?

이 기사의 원문은 Security Magazine에 게재되었습니다. 본 내용은 업데이트되어 이곳에 다시 게시되었습니다.

‍

보안 전문가들에게 12월 13일은 특별한 날입니다. 우리가 SQL 인젝션을 영원히 근절한 날일까요? 물론 아닙니다. 혹시 '국제 보안 종사자의 날'일까요? 그것도 아닙니다. 이날은 파이어아이(FireEye)와 맨디언트(Mandiant)가 솔라윈즈(SolarWinds) 사태로 알려지게 된, 이전까지는 알려지지 않았던 글로벌 침해 캠페인에 대한 충격적인 보고서를 발표한 날입니다. 이 보고서는 솔라윈즈의 인기 있는 오리온(Orion) 관리 소프트웨어 업데이트 내부에 악성 코드가 깊숙이 숨겨져 있었던, 진행 중이었고 거의 믿기 힘든 공격에 대해 상세히 다루었습니다.

이미 18,000곳 이상의 솔라윈즈 고객이 손상된 업데이트를 다운로드한 상태였습니다. 많은 고객이 조직 및 네트워크 내의 수많은 다른 소프트웨어 업데이트와 마찬가지로 이를 자동으로 수행했습니다. 공격자들은 솔라윈즈 침해를 통해 접근 권한을 얻은 후, 공격 대상을 매우 선별적으로 선택했습니다. 수많은 대기업과 정부 기관이 데이터를 탈취당하고 네트워크가 침해되었습니다. 이는 역사상 가장 규모가 크고 아마도 가장 큰 피해 비용을 발생시킨 침해 중 하나였으며, 특히 정부 기관의 경우 피해 규모가 완전히 공개된 적이 없다는 점에서 더욱 그렇습니다.

이 모든 일은 사람들이 소프트웨어 공급망 내의 공급업체를 제대로 검증하거나 확인하지 않고 신뢰했기 때문에 발생했습니다.

공급망 보안으로의 거대한 전환

경고가 울리자 기업, 조직, 정부 기관은 신속하게 대응했습니다. 솔라윈즈 침해는 물론 중단되었지만, 이 공격은 규제되지 않고 모니터링되지 않는 소프트웨어 공급망의 위험성을 드러냈습니다. 솔라윈즈 사건은 발견 즉시 해결되었지만, 공급망이 공격 벡터로 어떻게 악용되었는지에 대한 영향은 여전히 지속되고 있습니다. 이번 공격에서 얻은 유일한 교훈이 있다면, 사이버 보안의 중요하지만 간과되었던 측면에 주목하게 되었다는 점입니다.

솔라윈즈 공격에 대한 가장 주목할 만한 대응 중 하나는 바이든 대통령의 행정 명령인 '국가 사이버 보안 개선'입니다. 이 명령은 미국에서 발표된 가장 포괄적인 사이버 보안 지침 중 하나입니다. 이 명령은 정부 기관 및 정부와 거래하는 기업에 더 나은 사이버 보안을 요구하고, 제로 트러스트 네트워킹과 같은 고급 보호 조치를 옹호하며, 소프트웨어 공급망 보안의 필요성을 강조합니다.

이 행정 명령은 정부에 국한된 것이지만, 다른 그룹들도 솔라윈즈와 같은 공격을 방지하기 위해 공급망 보안의 중요성을 강조하기 시작했습니다. 예를 들어, 팔로알토 네트웍스는 최근 Unit 42 클라우드 위협 보고서인 "클라우드 보안을 위한 소프트웨어 공급망 보안"을 발표했습니다. 이 보고서는 소프트웨어 공급망 보안 없이는 어떤 클라우드 배포도 완전히 안전할 수 없다고 명시합니다. 클라우드 네이티브 컴퓨팅 재단(CNCF) 역시 이에 동의하며, 솔라윈즈 사태 이후 반드시 준수해야 할 핵심 소프트웨어 공급망 모범 사례를 담은 백서를 발표했습니다.

지난 몇 년간 사이버 보안 표준은 획기적인 변화를 겪었습니다. 의무 사항은 아니지만, 모든 조직은 이를 따라야 하며, 공급업체의 보안 관행을 마치 자사의 내부 보안 프로그램의 일부인 것처럼 철저히 검토하는 것을 목표로 삼아야 합니다. CISA의 새로운 전략 계획과 같은 이니셔티브는 보안을 공동의 책임으로 접근하는 방식이 모든 소프트웨어 개발자, 특히 핵심 인프라나 소프트웨어 공급망에 관여하는 이들에게 새로운 표준의 일부로 자리 잡고 있음을 보여주는 추가적인 증거입니다.

조직이 소프트웨어 공급망을 개선하기 위해 무엇을 할 수 있을까요?

이러한 상황에서 많은 공급업체는 자사의 공급망을 보호하기 위해 무엇을 해야 하는지 고민하고 있습니다. 조직이 공급업체도 자신만큼 사이버 보안을 중요하게 생각하도록 보장하려면 어떻게 해야 할까요?

행정 명령은 소프트웨어 개발자의 영향력과 그들이 검증된 보안 기술 및 인식을 갖춰야 할 필요성을 구체적으로 명시하고 있습니다. 이는 핵심 보안 기술을 통한 사람 중심의 방어보다는 도구에만 집착하는 업계에서 종종 잊히는 부분입니다.

오늘날 사이버 보안에 대한 포괄적인 접근 방식에는 기술적 보안 통제뿐만 아니라 파트너가 조직 내에서 거버넌스, 위험, 규정 준수를 어떻게 바라보는지에 대한 평가를 포함하는 상세한 제3자 위험 평가가 반드시 포함되어야 한다는 점이 분명해졌습니다.

모든 제3자 평가에는 소프트웨어 공급망에 있는 업체들이 검증된 인증서 서명과 함께 안전한 프로그램 업데이트를 어떻게 배포할 계획인지, 그리고 모든 소프트웨어와 장치의 ID를 관리하는 데 어떻게 도움을 줄 것인지에 대한 보증과 상세한 계획이 포함되어야 합니다. 또한 제품에 대한 암호화 업그레이드 및 업데이트를 위한 명확한 경로를 제시해야 합니다.

이제 개발자가 소프트웨어 공급망 보안의 핵심 요소로 인식되고 있는 만큼, 모든 평가에는 개발 커뮤니티 내에서 안전한 코딩과 지속적인 개선을 어떻게 장려하는지에 대한 보고서와, 이상적으로는 그들의 기술 및 현재 교육 수준에 대한 벤치마킹이 포함되어야 합니다. 개발자 역량 강화에 대한 강조가 개선되고 있다는 것은 알고 있지만, 개발자의 48%가 취약한 코드를 알고도 배포한 적이 있다고 인정했습니다.

시간 제약과 보안이 그들의 세계에서 최우선 순위(또는 성공의 척도)가 아니라는 현실은 코드 수준의 취약점이 제때 해결되지 않는 환경을 조성합니다. 우리가 소프트웨어 공급망이 감염되는 것을 막으려면, 모든 조직이 개발자 친화적인 보안 프로그램에 전념해야 합니다.

다음 단계는 무엇일까요?

위험 평가는 매우 중요합니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하면 그 위험을 그대로 떠안아 생태계에 영향을 미치고 그 결과를 감당해야 하기 때문입니다. 하지만 조직은 공급업체가 실제로는 더 안전할 수도 있고, 개발자 커뮤니티를 지원하는 데 더 뛰어날 수도 있다는 점을 깨달아야 합니다.

제3자 위험 평가를 자체 보안을 평가하는 보조적인 수단으로 활용할 수 있습니다. 만약 공급업체가 보안의 특정 측면을 내부보다 더 잘 처리하고 있다면, 그들의 방법을 채택하여 조직의 보안을 개선할 수 있습니다.

마지막으로, 소프트웨어 공급망을 실질적으로 개선하기 위한 다음 큰 단계는 개발자를 위한 안전한 코딩 인증을 구현하는 것입니다. 좋은 계획을 세우는 것이 첫걸음이지만, 그것이 실제로 잘 이행되고 안전한 코드를 생산하는 데 도움이 되는지 검증하는 것 또한 필수적입니다.

개발자가 안전한 코딩을 일상적으로 수행할 수 있는 환경이 마련되지 않는다면, 위협 행위자가 침투하기 전에 보안 취약점을 해결하는 일은 항상 뒤처질 수밖에 없습니다. 하지만 올바른 지원과 함께라면 지금이라도 긍정적인 변화를 만들어낼 수 있습니다. 애자일 학습의 힘을 통해 개발자가 실무에 즉시 적용 가능한 핵심 보안 역량을 어떻게 강화할 수 있는지 지금 확인해 보세요.