"취약점은 디지털 생활의 일부다. 모든 취약점을 제거하는 것은 불가능하다. 그보다는 취약점 조치를 개선해 보안 위험을 줄이고 디지털 전환 시대의 신뢰를 도모해야 한다."
보안 취약점이 드러나는 것을 사업 리스크나 잘못으로 받아들이기보다, 일상적인 현상으로 이해하고 관련 제보 체계 및 지속적인 보안 업데이트를 정착시켜야 한다는 경제협력개발기구(OECD) 보고서가 나와 눈길을 끈다.
한국인터넷진흥원(KISA)는 OECD가 이같은 내용을 담아 지난달 발표한 '취약점 조치의 장려(Encouraging vulnerability treatment)' 보고서 번역본을 지난 16일 공유했다.
■ 취약점 알려줘도 고소·고발로 받아치는 경우 허다
해당 보고서는 "소프트웨어(SW) 및 하드웨어(펌웨어)의 코드에는 심각도와 위험도의 차이가 있을 뿐, 항상 취약점이 존재한다"고 주장했다. 따라서 '코드 소유자(제품 개발자)'는 보안에 주의를 기울여 제품을 개발한 뒤, 제품 출시 이후에도 보안 위협에 대응할 의무가 있다고 지적했다. 코드 기반의 제품을 사용하는 기업·기관인 '시스템 소유자'는 취약점 관리를 통해 보안 사고 시 영향을 받을 수 있는 제3자를 보호해야 한다고 봤다.
이를 실현하려면 이해 당사자들이 나서 체계적으로 취약점 대응 및 관리 절차를 수립해야 하나, 현실은 그렇지 못하다고 봤다.
이해관계자의 인식 및 협력 부족이 원인 중 하나다. 특히 화이트해커가 SW 상의 취약점을 찾아 개발 업체에 제보하더라도, 이에 방어적으로 대응하는 경우가 나타난다는 것이다.
보고서는 "보안 연구자는 악성 행위자가 취약점을 악용하기 전 취약점 소유자가 이를 찾아 공개하도록 지원하지만, 많은 경우 연구자의 취약점 신고를 환영하지 않는다"며 "대부분의 경우 (취약점에 대한) 책임감을 느끼지 못하거나 연구자의 신고를 위협을 느낄 수 있다"고 설명했다.
실제로 취약점을 제보받은 곳들이 화이트해커를 압박한 사례도 소개했다. 핀란드 온라인 게임 플랫폼 하보의 경우 취약점을 신고한 10대 청소년을 형사고발했다. 글로벌 컨설팅 업체 PwC에 취약점을 신고한 보안 연구자들은 침해중지요구서를 전달받았다. 치과 SW가 환자 2만2천여명의 건강정보를 암호화하지 않는 사실을 제보한 화이트해커는 미국 연방수사국(FBI)의 압수수색을 받기도 했다.
■ "취약점 제보자에 '면책' 필요"…화이트해커-SW회사 공조 체계 활성화해야
보고서는 취약점이 발견될 경우 이를 제보한 화이트해커와, 취약점이 발견된 SW 개발 업체가 협력해 보안 패치 개발, 취약점 정보 공개를 하는 것이 바람직하다고 봤다. 그러나 여러 한계로 아직 이같은 사례가 흔치 않은 편이라고 언급했다.
향후 이해관계자들이 취약점에 대해 보다 적극적으로 대응하기 위해서는 정책기관의 역할이 중요하다는 설명이다. 보고서는 "디지털 전환의 가속화는 엄청난 이익을 가져왔으나, 잠재적으로 취약한 IoT 장비와 수천억줄의 코드가 포함된 정보 시스템에 위험하게 의존하게 되는 결과도 가져왔다"며 정책적 노력을 통해 잠재된 보안 위협을 해소해야 한다고 봤다.
먼저 정부기관에 적용할 취약점 처리 절차 수립을 제안했다. 정부에서 선제적으로 이같은 정책을 도입함에 따라 민간 내 취약점에 대한 인식 변화도 촉진할 수 있다고 덧붙였다. 미국 CISA가 각 연방기관을 대상으로 취약점 공개 정책을 발표하도록 요구하는 지침을 시행하고 있는 점을 사례로 들었다.
각종 분야별, 제품별 규제나 표준에 취약점 조치 내용을 포함하게 하고, 채택을 장려하는 것도 해결책으로 제시했다.
관련기사
- 해커, 작년 '모바일·IoT' 집중 공략했다2021.03.10
- 국내 SW, 잘 알려진 보안 취약점도 대응 못해2021.02.19
- 구글, 작년 '보안 취약점' 포상금에 75억원 썼다2021.02.05
- 해킹 치밀해지는데…'보안 취약점 포상제' 활성화 언제?2020.12.31
화이트해커 등 보안 연구자를 보호하기 위한 면책 조항 도입도 주장했다. 보안 위험을 줄이기 위해 정책기관이 보안 연구자를 보호하고, 소송 등의 위험에 처하지 않도록 법적 환경을 개선해야 한다는 것이다.
취약점 신고 시 포상금을 지급하는 '버그 바운티' 프로그램에 대해서는 취약점 관리 프로세스가 정립된, 성숙한 조직엔 적합하지만 만능책이 될 수 없다고 지적했다. 보고서는 "버그 바운티는 제품 또는 제품 라인의 기본 설계 상 보안 한계점을 개선할 수 없는 사후 대응적 조치"라며 "코드 검토, 감사, 네트워크 침투 테스트 등의 위험을 줄이기 위한 많은 다른 도구 중 하나로 사용돼야 한다"고 조언했다.