영국 화웨이 보안 문제는 안전한 코딩의 필요성을 보여줍니다.

원문은 Information Age에 게재되었습니다. 이 글은 윈드리버 시스템즈(Wind River Systems)의 실시간 운영체제 제품인 VxWorks에 대한 지속적인 보안 지원과 관련하여 내용을 수정한 업데이트 버전입니다.

영국 화웨이 사이버 보안 평가 센터의 최근 보고서는 화웨이의 소프트웨어 엔지니어링 프로세스 내에 심각한 보안 문제가 있음을 지적했습니다. 이 중요한 보고서에 대한 뉴스는 대부분 전년도부터 해결되지 않은 문제들에 집중하고 있지만, 더 위험하고 간과된 문제는 화웨이가 보안 코딩 가이드라인과 관행을 제대로 적용하지 않고 있다는 점입니다. 하지만 이는 충분히 해결 가능한 문제입니다.

중국 통신 대기업 화웨이에게 악재가 계속되고 있습니다. 미국은 화웨이의 향후 정부 사업 참여를 전면 금지했지만, 영국은 화웨이 장비와 코드의 근본적인 결함 중 상당수가 수정 가능하다는 점을 인정하는 보다 유연한 태도를 보였습니다. 영국은 2010년 화웨이 사이버 보안 평가 센터(HCSEC)를 설립하여 화웨이 제품의 보안 문제를 평가 및 해결하고 연례 보고서를 발행해 왔습니다. 그러나 올해 보고서는 특히나 치명적이었습니다.

2019년 HCSEC 보고서에 대한 언론의 관심은 주로 전년도에 지적된 보안 결함이 거의 해결되지 않았다는 사실에 집중되었습니다. 여기에는 곧 지원이 종료될 예정인 윈드리버의 구형 VxWorks 실시간 운영체제 사용 문제가 포함됩니다. 화웨이는 이 문제를 해결하겠다고 약속했으며(윈드리버 시스템즈로부터 지속적인 지원을 받을 예정이지만), 해당 운영체제는 여전히 영국 통신 인프라의 핵심 구성 요소로 남아 있습니다.

주류 언론 대부분이 간과한 것으로 보이는 결정적인 요인은 회사의 새로운 소프트웨어 및 하드웨어 개발과 배포 과정 전반에 걸쳐 근본적인 결함이 존재할 가능성입니다. 보고서는 화웨이의 내부 엔지니어링 방식에 "심각한 기술적 문제"가 있다고 지적합니다.

보고서에 명시된 기술적 문제의 몇 가지 사례를 살펴보겠습니다. 화웨이가 엔지니어와 프로그래머의 새로운 코드 배포를 돕기 위해 보안 코딩 가이드라인을 만든 것은 매우 잘한 일입니다. 해당 가이드라인은 신뢰할 수 있는 라이브러리의 안전한 시스템 함수와 프로세스를 사용하고, 알려진 취약점이 있는 변형은 절대 사용하지 않는 등 광범위한 모범 사례를 다루고 있습니다. 이론적으로는 훌륭하지만, 영국 내 화웨이 생산 시스템을 실제 평가한 결과, 이러한 가이드라인은 프로그래머에게 전달되지 않았거나, 무시되었거나, 혹은 단순히 강제되지 않았던 것으로 드러났습니다.

보고서는 공개된 애플리케이션 내의 특정 메모리 처리 함수를 조사했는데, 이번 사례에서는 사용자가 프로그램 기능을 통해 입력을 추가할 수 있는 게시판 세트를 확인했습니다. 사용자 입력 영역은 결코 "신뢰할 수 있는" 곳으로 간주해서는 안 되므로, 화웨이 내부 가이드라인에 따라 해당 영역에는 보안 코드가 포함되어야 했습니다. 특히 테스터들은 해당 생산 시스템 내에서 memcpy(), strcpy(), sprintf()와 같은 메모리 처리 함수가 직접 호출되는 방식을 조사했는데, 이는 1988년부터 버퍼 오버플로우와 같은 심각한 보안 문제를 일으킬 수 있다고 알려진 함수들입니다.

충격적이게도, 17개의 안전한 memcpy() 함수가 5,000번 직접 호출되는 동안, 안전하지 않은 변형 함수도 600번 사용되었습니다. 다른 함수들의 비율도 비슷했습니다. 1,400번의 안전한 strcpy() 호출이 있었지만, 취약점이 알려진 잘못된 호출도 400번 있었습니다. sprintf()의 경우 2,000번의 안전한 사용 사례와 비교해 200번의 안전하지 않은 사례가 발견되었습니다. 대부분의 함수 사용이 안전했다는 점은 다행이지만, 여전히 전체 코드의 약 20%가 알려진 공격에 취약하다는 의미입니다. 이는 엄청난 공격 표면이며, 함수 포인터를 통한 간접적인 호출 사례는 고려하지도 않은 수치입니다. 감사관들은 특정 함수들만 조사했지만, 선택된 세 가지 메모리 처리 함수에만 문제가 있다고 보기는 어렵습니다.

화웨이가 프로그래머를 위한 모범 사례 가이드를 만든 것은 긍정적이지만, 더 많은 노력이 필요한 것은 분명합니다. 보안 기대치를 명시하는 것은 첫걸음일 뿐이며, 가이드라인이 개발자들에게 숙지되고 적극적으로 준수될 때만 효과가 있습니다. 화웨이는 내부 가이드라인을 따르는 기본 사항을 훑어보는 수준을 넘어, 프로그래머를 효과적으로 교육하는 데 전념함으로써 보안을 크게 개선할 수 있습니다. 더 나아가 전반적으로 더 안전하게 코딩하는 방법을 보여주어야 합니다. 코더들은 좋은(안전한) 코딩 패턴과 나쁜(안전하지 않은) 코딩 패턴에 대해 충분히 교육받아야 하며, 회사가 강조하는 원칙을 매번 실천할 책임이 주어져야 합니다.

HCSEC 보고서에 명시된 구체적인 코딩 문제 중 다수는 Secure Code Warrior 플랫폼을 통해 해결 및 강제되고 있습니다. 이 플랫폼은 프로그래머와 사이버 보안 팀이 항상 안전한 코드를 배포하고 유지하도록 교육합니다. 사용자 입력을 절대 신뢰하지 않기, 검증된 라이브러리에서 함수 가져오기, 서버로 전달하기 전 모든 입력값 살균하기 등 다양한 안전 코딩 관행이 플랫폼 내에서 지속적으로 시연됩니다. 또한 매우 구체적인 취약점을 살펴보고 이를 방지하고 완화하는 방법을 단계별로 보여줍니다.

숙련된 교육 외에도 화웨이와 같은 기업은 DevSecOps 솔루션을 활용할 수 있습니다. 이는 IDE 내에서 실시간 코칭을 추가하여 회사의 보안 가이드라인에 맞춘 안전한 코딩 레시피를 제공하며, 개발자가 코드를 작성할 때 마치 주방의 수셰프처럼 행동합니다. 이러한 접근 방식은 화웨이 프로그래머들이 숙련도에 관계없이 더 나은 코드를 작성하고 잠재적인 취약점을 인식하도록 도울 수 있으며, 화웨이의 보안 전문가들이 정책을 준수하고 명령 실행을 돕는 "요리책"을 만들 수 있게 해줍니다.

A core lesson from Huawei's troubles should be that creating secure coding guidelines is meaningless if programmers don't know about them, or simply don't know how to follow good coding practices. In this case, the internal best practices guidelines turned out to be Huawei's own zhilaohu; what the West would call "a paper tiger'. It was a document with a lot of style, but no substance. To give it real teeth would require the right practical tools and an actual training program, one that takes a hands-on approach and builds continuous knowledge and skill.