끝없이 확장되는 공격 표면의 시대, 예방이 답이다

이 기사는 SD Times에 게재되었던 내용을 업데이트하여 이곳에 다시 발행한 것입니다.

‍

발전에 대해 이야기할 때, 보통 디지털 기술의 진보가 가장 먼저 언급됩니다. 우리는 모든 것이 더 좋고, 빠르고, 편리하며, 강력해지기를 원합니다. 또한 더 적은 비용과 시간, 위험으로 이를 달성하고자 합니다. 대부분의 경우 이러한 '불가능해 보이는' 목표들은 결국 달성됩니다. 수년이 걸리고 여러 번의 버전을 거쳐야 할 수도 있으며(기능 설계를 또 한 번 바꾸라는 요구에 개발팀이 반기를 들지도 모르지만), 매일 코드는 세상을 변화시키고 있습니다.

하지만 소프트웨어가 크게 확장되는 만큼 책임도 커지며, 현실적으로 우리는 보안 측면에서 이를 감당할 준비가 되어 있지 않습니다. 소프트웨어 개발은 더 이상 고립된 영역이 아닙니다. 클라우드, 가전제품 및 차량의 임베디드 시스템, 핵심 인프라, 그리고 이 모든 것을 연결하는 API에 이르기까지 소프트웨어 기반의 모든 위험 요소를 고려하면, 공격 표면은 경계 없이 통제 불능 상태에 놓여 있습니다.

모든 코드 라인을 숙련된 보안 전문가가 꼼꼼하게 검토하는 마법 같은 시대를 기대할 수는 없습니다. 보안 인력 부족 문제는 단기간에 해결되지 않을 것입니다. 하지만 업계 차원에서 코드 수준의 보안에 대해 보다 전체적인 접근 방식을 채택할 수는 있습니다.

가용 도구를 활용하여 이 무한한 공격 표면을 어떻게 통제할 수 있을지 살펴보겠습니다.

비즈니스 위험 수준(및 수용 가능한 범위)을 현실적으로 파악하십시오

완벽한 보안은 지속 가능하지 않지만, 눈을 가리고 모든 것이 괜찮다고 믿는 것도 마찬가지입니다. 기업들이 취약한 코드를 알고도 배포한다는 사실은 이미 잘 알려져 있으며, 이는 분명 새로운 기능과 제품의 출시 속도를 고려한 계산된 위험입니다.

특히 DevSecOps가 표준 개발 방법론으로 자리 잡지 않은 곳에서 속도를 유지하며 보안을 챙기는 것은 어려운 일입니다. 하지만 최근의 Log4Shell 취약점 사례를 보면 코드 내의 비교적 작은 보안 문제가 어떻게 성공적인 공격의 기회가 될 수 있는지 알 수 있으며, 품질이 낮은 코드를 배포하는 계산된 위험의 결과가 예상보다 훨씬 클 수 있음을 깨닫게 됩니다.

(액세스) 제어에 집착하는 것을 당연하게 여기십시오

상당히 많은 비용이 발생하는 데이터 유출 사고가 잘못 구성된 클라우드 스토리지 환경으로 인해 발생하고 있으며, 액세스 제어 오류로 인한 민감한 데이터 노출 위험은 여전히 대부분의 조직 보안 팀을 괴롭히고 있습니다.

2019년, 포춘 500대 기업인 First American Financial Corp.는 이 사실을 뼈저리게 경험했습니다. 비교적 해결하기 쉬웠던 인증 오류 하나가 은행 명세서, 모기지 계약서, 신분증 사진을 포함한 8억 건 이상의 기록 노출로 이어졌습니다. 문서 링크에 사용자 식별이나 로그인이 필요하지 않아 웹 브라우저만 있으면 누구나 접근할 수 있었습니다. 더 심각한 것은 문서 번호가 순차적으로 부여되어 있어 링크의 숫자만 바꾸면 새로운 데이터 기록이 노출되었다는 점입니다.

이 보안 문제는 언론에 보도되기 전 내부적으로 먼저 식별되었습니다. 그러나 이를 고위험 보안 문제로 적절히 분류하지 못했고, 경영진에게 보고하여 긴급히 해결하지 못한 탓에 오늘날까지도 여파가 이어지고 있습니다.

잘못된 액세스 제어가 현재 OWASP Top 10의 최상위에 위치한 데에는 이유가 있습니다. 이는 매우 흔한 문제이며, 개발자들은 인증 및 권한과 관련된 모범 사례를 익히고 검증된 보안 인식을 갖추어 민감한 데이터 노출을 방지하기 위한 확인 절차를 마련해야 합니다.

API의 특성상 다른 애플리케이션과 매우 빈번하게 통신하도록 설계되어 있어 특히 주의가 필요합니다. 개발팀은 모든 잠재적 액세스 지점에 대한 가시성을 확보해야 합니다. 결국, 더 안전한 소프트웨어를 제공하려는 노력 속에서 알 수 없는 변수와 사용 사례까지 모두 고려할 수는 없기 때문입니다.

보안 프로그램을 분석하십시오: 예방에 얼마나 중점을 두고 있습니까?

보안 프로그램의 상당 부분이 사고 대응 및 처리에 할애되는 것은 당연하지만, 많은 조직이 보안 사고를 사전에 방지할 수 있는 가용 자원을 충분히 활용하지 못해 위험 최소화의 기회를 놓치고 있습니다.

물론 문제 있는 버그를 찾아내는 데 도움을 주는 포괄적인 보안 도구 스택은 존재하지만, 기업의 거의 50%가 취약점이 있다는 사실을 알면서도 코드를 배포한다고 인정했습니다. 시간 제약, 도구 세트의 복잡성, 보고에 대응할 숙련된 전문가의 부족은 본질적으로 계산된 위험을 초래해 왔습니다. 하지만 클라우드, 애플리케이션, API 기능, 임베디드 시스템, 라이브러리 등 점점 더 넓어지는 기술 환경 전반에서 코드를 보호해야 한다는 사실은 현재의 접근 방식으로는 항상 한발 뒤처질 수밖에 없음을 보여줍니다.

보안 버그는 사람이 만드는 문제이며, 로봇이 모든 것을 해결해 주길 기대할 수는 없습니다. 개발 팀의 역량을 효과적으로 강화하지 않는다면, 즉 연례 세미나가 아닌 체계적인 교육 기반을 마련하지 않는다면, 저품질 코드를 표준으로 받아들이고 그에 따른 보안 위험을 항상 감수해야 할 것입니다.

개발자의 준비 상태를 과대평가하고 있지는 않습니까?

개발자가 보안 코딩 능력을 평가받는 경우는 드물며, 그것이 우선순위(많은 경우 KPI조차 아님)가 되는 일도 거의 없습니다. 더 나은 방법을 제시받거나 그것이 성공의 척도라는 점을 교육받지 못한 상태에서, 개발자에게 보안 관행 미흡의 책임을 전가할 수는 없습니다.

하지만 조직 내에서는 제공된 지침이 엔지니어링 팀의 일반적인 보안 위험 완화 준비에 효과적이었다고 가정하는 경우가 너무 많습니다. 교육 내용과 보안 모범 사례를 적용하려는 인식에 따라, 개발자들은 이상적인 최전방 방어선 역할을 수행할 준비가 되어 있지 않을 수 있으며, 이로 인해 펜테스트 보고서에는 끝없는 인젝션 결함이 쌓이게 됩니다.

이상적인 상태는 복잡도가 점진적으로 높아지는 학습 과정을 완료하고, 그 결과로 얻은 기술이 실제 개발 환경에서 효과적으로 작동하는지 검증하는 것입니다. 그러나 이를 위해서는 개발자를 처음부터 고려하고 올바르게 지원하는 문화적 기준이 필요합니다. 우리가 스스로 만든 방대한 코드 환경을 지키기 위해 업계 차원에서 노력한다면, 가능한 모든 도움이 필요할 것입니다. 그리고 사실 우리가 생각하는 것보다 더 많은 도움이 바로 우리 앞에 있습니다.