.jpg)
국가 사이버 보안 전략은 소프트웨어 개발 생태계에 여러 가지 변화를 가져다 줄 것으로 예상된다. 그 중 가장 중요한 것은 소프트웨어 취약점으로 인한 사고 발생 시 개발사에게 어느 정도 책임을 묻겠다는 것이다.
[보안뉴스 문정후 기자] 지난 3월 미국 백악관은 국가 사이버 보안 전략(National Cybersecurity Strategy)이라는 것을 발표했다. 2018년에 나온 것을 최신 위협 상황을 반영해 개정한 것이다. 이 때문에 상당히 많은 변화가 있을 것으로 예상되는데, 그 중 하나가 소프트웨어 취약점이 발견됐을 때 누구에게 책임을 묻는가의 문제이다. 사이버 범죄가 점점 더 극성스러워지는 때에 사용자들 편에서만 책임을 지게 하는 방식은 더 이상 유효하지 않다는 게 백악관의 생각이다.
책임의 새로운 분배
현재 소프트웨어 벤더사들이 맺는 계약서들은 소프트웨어 벤더사들에 크게 유리한 게 보통이다. 소프트웨어에서 혹은 소프트웨어로 인해 문제가 발생했을 때 자신들이 최대한 책임을 지지 않기 위한 항목들로 빼곡하기 때문이다. 이런 계약서 한 장이면 되기 때문에 사실 소프트웨어 개발사들이 굳이 안전하고 취약점 없는 제품을 만들 필요가 없었다.
하지만 이번에 백악관에서 이 부분을 강력하게 지적하게 됐으니 상황은 바뀔 예정이다. 이제 연방 정부는 소프트웨어 제품과 서비스를 만드는 자들에게도 사고에 대한 책임을 물을 것이라고 한다. 뿐만 아니라 정부 기관과 의회, 민간의 협력을 강화하기 위한 전략도 마련함으로써 채찍과 당근을 모두 준다고 공표한 것이나 다름없다. 정부가 제대로 마음을 먹었다고 봐도 무방하다.
물론 이런 국가 전략이 소프트웨어 개발사들의 개발 태도를 바꿀 것이라고 100% 장담할 수는 없다. 벤더들이 우리가 생각했던 것과 다른 방향에서 색다른 접근법을 가지고 여전히 책임을 회피할 수도 있다. 하지만 아직까지 그런 방법을 생각해낸 사람은 아무도 없다. 그러니 기술 분야의 종사자들이라면 소프트웨어의 개발 철학이 서서히 뒤바뀌게 될 것을 미리 대비하는 것이 나을 것으로 예상된다.
수년 전부터 금융안정위원회(Financial Stability Board)는 “널리 사용되는 서드파티 서비스 제공업체의 제품을 사용해 사회 주요 기반이 되는 시설이나 시스템을 운영하게 될 경우 금융의 안정성을 훼손시킬 수 있다”고 경고해 왔었다. 즉 너무 유명한 소프트웨어 제품에 대한 의존성이 크면 클수록 위험하다는 건데, 이번에 새롭게 발표된 국가 사이버 보안 전략과 맞물렸을 때 사회 기반 시설 분야의 소프트웨어를 위한 새로운 규정과 정책이 발표될 가능성이 높아 보인다. 사회 기반 시설 분야 소프트웨어 벤더사나 사용자 모두 지금 보유하고 있는 제품의 보안성이나 안정성을 새롭게 검토할 필요가 있다.
예외가 있긴 하다
사이버 범죄자들은 계속해서 전략을 발전시키고 있으며, 그렇기 때문에 어제는 안전했던 소프트웨어라고 하더라도 오늘은 중요한 공격의 통로로서 작용할 수 있다. 소프트웨어 몇 개 꼼꼼하게 점검하고 개발한다고 해서 위협에서 벗어날 수 있는 게 아니라는 뜻이다. 어떤 소프트웨어라도 안전하게 개발하고 사용할 수 있게 해 주는 통합적인 ‘안전 프레임워크’가 필요하다.
사실 이건 너무나 당연한 결론이다. 백악관은 이번 사이버 보안 전략을 통해 “소프트웨어 개발사들이 더 안전한 소프트웨어를 만드는 데 주력하도록 강제하겠다”는 방향성을 노골적으로 보여주었기 때문이다. 그러니 개발사들은 소프트웨어 개발 철학과 접근법 자체를 바꾸는 게 맞다. 그것을 프레임워크라는 장치에 담아내야 하고, 그것을 따름으로써 백악관의 공격적인 보안 강화 전략에 방햇거리가 되어서는 안 된다. 정부를 적으로 돌리는 건 해커에 의해 당하는 것보다 훨씬 더 무서운 일이다.
다만 이전부터 계속해서 안전한 소프트웨어 개발 수칙을 제대로 지켜온 기업이라면 크게 걱정할 일이 없다. 사고에 대한 책임을 무조건 소프트웨어 개발사가 지게 한다는 게 이번 전략의 핵심이 아니기 때문이다. 베스트 프랙티스라는 것을 준수해 왔고, 그것에 따라 충실하게 제품을 출시해 왔다는 것만 증명할 수 있다면 국가로서도 회사가 책임을 지게 만들기 어렵다. 그렇기 때문에 최근 서서히 무르익고 있는 ‘보안 사고 책임을 소프트웨어 회사가 진다’는 분위기에서 살아남으려면 안전한 개발을 위한 각종 베스트 프랙티스를 잘 따르도록 개발 과정을 처음부터 점검하는 것을 권장한다.
안전한 소프트웨어 개발을 위한 절차들
그렇다면 어떤 베스트 프랙티스를 따라야 실제로도 안전하고 법원에서도 안전할 수 있을까? 미국에서는 가장 대표적인 것이 NIST의 SSDF라는 것이다. 안전한 소프트웨어 개발 프레임워크(Secure Software Development Framework)의 준말로, 다른 여러 나라에서도 이 SSDF를 기준으로 자기들의 상황에 부합한 안전 장치를 만들어 적용하고 있기도 하다. 보안 전담 기관 CISA의 경우도 다른 여러 정부 기관들과 협력하여 ‘설계와 기본값에 의한 보안을 위한 접근법과 원리(Principles and Approaches for Security-by-Design and -Default)’라는 프레임워크를 개발한 바 있다.
다만 이 두 가지 소프트웨어 개발 프레임워크에서는 서드파티 벤더들의 역할이 크게 강조되지는 않는다는 한계가 존재한다. 사실 현실적으로 일개 보안 부서가 파트너사의 보안 부서 사람들과 만나 이런 저런 요구 사항을 전달하면서 수정을 요구할 수는 없다. 오히려 경영진이 나서야 한다. 기업 대 기업의 파트너십을 형성해가는 과정 속에서 서드파티 보안 문제를 다루는 게 현재로서는 이상적이다.
소프트웨어 개발사 내 보안 팀들이라면 이와 같은 각종 프레임워크에 대한 관심을 깊이 가지고 있어야 한다. NIST와 CISA라는 미국 대표 기관들이 만드는 것도 중요하지만, 유럽연합과 나머지 서방 국가들의 움직임도 중요하다. 테크 분야에서는 유럽연합과 미국이 도입한 기술이나 접근법이 수년 안에 전 세계로 퍼져가는 게 보통이다. 그러니 NIST와 CISA, 그에 준하는 유럽의 정보 기관들이 발표하는 프레임워크에 관심을 가져야 할 것은 미국 개발사만이 아닐 것이다.
글 : 알란 하트웰(Alan Hartwell), CTO, IRIS
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 지난 3월 미국 백악관은 국가 사이버 보안 전략(National Cybersecurity Strategy)이라는 것을 발표했다. 2018년에 나온 것을 최신 위협 상황을 반영해 개정한 것이다. 이 때문에 상당히 많은 변화가 있을 것으로 예상되는데, 그 중 하나가 소프트웨어 취약점이 발견됐을 때 누구에게 책임을 묻는가의 문제이다. 사이버 범죄가 점점 더 극성스러워지는 때에 사용자들 편에서만 책임을 지게 하는 방식은 더 이상 유효하지 않다는 게 백악관의 생각이다.
[이미지 = gettyimagesbank]
책임의 새로운 분배
현재 소프트웨어 벤더사들이 맺는 계약서들은 소프트웨어 벤더사들에 크게 유리한 게 보통이다. 소프트웨어에서 혹은 소프트웨어로 인해 문제가 발생했을 때 자신들이 최대한 책임을 지지 않기 위한 항목들로 빼곡하기 때문이다. 이런 계약서 한 장이면 되기 때문에 사실 소프트웨어 개발사들이 굳이 안전하고 취약점 없는 제품을 만들 필요가 없었다.
하지만 이번에 백악관에서 이 부분을 강력하게 지적하게 됐으니 상황은 바뀔 예정이다. 이제 연방 정부는 소프트웨어 제품과 서비스를 만드는 자들에게도 사고에 대한 책임을 물을 것이라고 한다. 뿐만 아니라 정부 기관과 의회, 민간의 협력을 강화하기 위한 전략도 마련함으로써 채찍과 당근을 모두 준다고 공표한 것이나 다름없다. 정부가 제대로 마음을 먹었다고 봐도 무방하다.
물론 이런 국가 전략이 소프트웨어 개발사들의 개발 태도를 바꿀 것이라고 100% 장담할 수는 없다. 벤더들이 우리가 생각했던 것과 다른 방향에서 색다른 접근법을 가지고 여전히 책임을 회피할 수도 있다. 하지만 아직까지 그런 방법을 생각해낸 사람은 아무도 없다. 그러니 기술 분야의 종사자들이라면 소프트웨어의 개발 철학이 서서히 뒤바뀌게 될 것을 미리 대비하는 것이 나을 것으로 예상된다.
수년 전부터 금융안정위원회(Financial Stability Board)는 “널리 사용되는 서드파티 서비스 제공업체의 제품을 사용해 사회 주요 기반이 되는 시설이나 시스템을 운영하게 될 경우 금융의 안정성을 훼손시킬 수 있다”고 경고해 왔었다. 즉 너무 유명한 소프트웨어 제품에 대한 의존성이 크면 클수록 위험하다는 건데, 이번에 새롭게 발표된 국가 사이버 보안 전략과 맞물렸을 때 사회 기반 시설 분야의 소프트웨어를 위한 새로운 규정과 정책이 발표될 가능성이 높아 보인다. 사회 기반 시설 분야 소프트웨어 벤더사나 사용자 모두 지금 보유하고 있는 제품의 보안성이나 안정성을 새롭게 검토할 필요가 있다.
예외가 있긴 하다
사이버 범죄자들은 계속해서 전략을 발전시키고 있으며, 그렇기 때문에 어제는 안전했던 소프트웨어라고 하더라도 오늘은 중요한 공격의 통로로서 작용할 수 있다. 소프트웨어 몇 개 꼼꼼하게 점검하고 개발한다고 해서 위협에서 벗어날 수 있는 게 아니라는 뜻이다. 어떤 소프트웨어라도 안전하게 개발하고 사용할 수 있게 해 주는 통합적인 ‘안전 프레임워크’가 필요하다.
사실 이건 너무나 당연한 결론이다. 백악관은 이번 사이버 보안 전략을 통해 “소프트웨어 개발사들이 더 안전한 소프트웨어를 만드는 데 주력하도록 강제하겠다”는 방향성을 노골적으로 보여주었기 때문이다. 그러니 개발사들은 소프트웨어 개발 철학과 접근법 자체를 바꾸는 게 맞다. 그것을 프레임워크라는 장치에 담아내야 하고, 그것을 따름으로써 백악관의 공격적인 보안 강화 전략에 방햇거리가 되어서는 안 된다. 정부를 적으로 돌리는 건 해커에 의해 당하는 것보다 훨씬 더 무서운 일이다.
다만 이전부터 계속해서 안전한 소프트웨어 개발 수칙을 제대로 지켜온 기업이라면 크게 걱정할 일이 없다. 사고에 대한 책임을 무조건 소프트웨어 개발사가 지게 한다는 게 이번 전략의 핵심이 아니기 때문이다. 베스트 프랙티스라는 것을 준수해 왔고, 그것에 따라 충실하게 제품을 출시해 왔다는 것만 증명할 수 있다면 국가로서도 회사가 책임을 지게 만들기 어렵다. 그렇기 때문에 최근 서서히 무르익고 있는 ‘보안 사고 책임을 소프트웨어 회사가 진다’는 분위기에서 살아남으려면 안전한 개발을 위한 각종 베스트 프랙티스를 잘 따르도록 개발 과정을 처음부터 점검하는 것을 권장한다.
안전한 소프트웨어 개발을 위한 절차들
그렇다면 어떤 베스트 프랙티스를 따라야 실제로도 안전하고 법원에서도 안전할 수 있을까? 미국에서는 가장 대표적인 것이 NIST의 SSDF라는 것이다. 안전한 소프트웨어 개발 프레임워크(Secure Software Development Framework)의 준말로, 다른 여러 나라에서도 이 SSDF를 기준으로 자기들의 상황에 부합한 안전 장치를 만들어 적용하고 있기도 하다. 보안 전담 기관 CISA의 경우도 다른 여러 정부 기관들과 협력하여 ‘설계와 기본값에 의한 보안을 위한 접근법과 원리(Principles and Approaches for Security-by-Design and -Default)’라는 프레임워크를 개발한 바 있다.
다만 이 두 가지 소프트웨어 개발 프레임워크에서는 서드파티 벤더들의 역할이 크게 강조되지는 않는다는 한계가 존재한다. 사실 현실적으로 일개 보안 부서가 파트너사의 보안 부서 사람들과 만나 이런 저런 요구 사항을 전달하면서 수정을 요구할 수는 없다. 오히려 경영진이 나서야 한다. 기업 대 기업의 파트너십을 형성해가는 과정 속에서 서드파티 보안 문제를 다루는 게 현재로서는 이상적이다.
소프트웨어 개발사 내 보안 팀들이라면 이와 같은 각종 프레임워크에 대한 관심을 깊이 가지고 있어야 한다. NIST와 CISA라는 미국 대표 기관들이 만드는 것도 중요하지만, 유럽연합과 나머지 서방 국가들의 움직임도 중요하다. 테크 분야에서는 유럽연합과 미국이 도입한 기술이나 접근법이 수년 안에 전 세계로 퍼져가는 게 보통이다. 그러니 NIST와 CISA, 그에 준하는 유럽의 정보 기관들이 발표하는 프레임워크에 관심을 가져야 할 것은 미국 개발사만이 아닐 것이다.
글 : 알란 하트웰(Alan Hartwell), CTO, IRIS
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
