.jpg)
보안, 소프트웨어 빨리 구현하고 수익 내는 데 장애물로 여겨져
보안이 수익과 직결돼있다는 사고 전환 있어야 우선시 될 수 있어
[보안뉴스 오다인 기자] 에퀴팩스 사태가 터진 뒤 많은 비판과 책임론이 이어지고 있다. 나 역시 에퀴팩스를 감싸고 돌 생각은 없다. 다만 에퀴팩스 사태로 인해 에퀴팩스라는 한 조직뿐만 아니라 소프트웨어 개발 분야 전반에 깔려있는 잘못된 추진제들이 드러났다는 사실을 짚어보고 싶다. 이 추진제들부터 바꾸지 않는 이상 보안은 언제나 문제가 될 것이다. 이걸 짚는 이유는 ‘제2의 에퀴팩스’를 막으려면 무엇을 해야 할까, 에 대한 답을 찾기 위해서다.
소프트웨어의 경제학
일단 소프트웨어 업체 또는 개발자의 입장에서 한 번 생각해보자. 개발자가 더 나은 보안을 구축하고 싶어서 더 오래 프로젝트를 붙잡고 있었다면, 그 사람에게 보너스를 주거나 승진시킨 일이 있었나? 제품 매니저가 소프트웨어 취약점 때문에 또는 적절한 보안성 검토가 부족했기 때문에 소프트웨어 출시를 중단시켰다면, 그 사람에게 포상을 해줬던 일은 있었나? 소프트웨어 업체가 엔드유저를 탓하지 않고 자사 코드가 엉터리였다고 책임진 사례는 언제가 마지막이었나? 벤처캐피탈리스트가 회사의 보안 프로세스 때문에 투자 가치를 높여준 사례는 언제가 마지막이었나?
소프트웨어를 자동차에 비유하면 현재 소프트웨어 업계가 하고 있는 행위를 더 쉽게 이해할 수 있다. 지금 우리는 안전벨트와 에어백이 제대로 작동하지 않는다는 사실을 알면서도 사고 같은 건 나지 않을 거라는 희망 하나에 모든 것을 걸고 운전자에게 자동차를 팔아넘긴 뒤 ‘혹시 사고가 나도 제조사 책임은 아님’이라고 적힌 계약서에 도장 찍으라고 강요하고 있는 것과 같다.
새로운 기능을 빠르게 구현하는 것. 이것이 소프트웨어 개발의 가장 중요한 추진제이자 목표다. 그 누구보다 먼저 새로운 기능을 추가하고 소비자에게 제공하기 위해 우리는 눈에 불을 켜고 소프트웨어를 만든다. 아니, 그것 자체가 소프트웨어 개발이라는 것의 정의다. 우리가 자주 외는 주문인 “프로토타입도 빨리 실패도 빨리”가 모든 것을 설명한다. 결국 “사업을 빨리 빨리 굴리려면 절차나 원칙을 좀 무시해야 한다”는 뜻이기 때문이다. 비로소 보안에 대해 걱정하기 시작하는 때는 제품이 성숙기에 접어들고 고객도 있는 시점에서다. 현실에선 그나마도 거의 일어나지 않는다. 왜냐면 제품이 더 큰 성공을 거둘수록 다른 고객 이슈나 사업 우선순위로 인해 보안 문제가 퇴색되기 때문이다.
에퀴팩스 취약점
이러한 문제점에 대한 생각을 가지고 에퀴팩스 사건으로 악명이 드높아진 아파치 스트러츠 취약점을 살펴보자. 먼저 아파치 스트러츠 취약점이란, 공격자가 Content-Type이라는 HTTP 헤더 내에 특별한 문구를 삽입할 수 있게 해주는 것으로, 악용될 경우 원격 코드 실행까지 성공할 수 있게 해주는 것이다.
그러나 Content-Type에 악성 코드가 작성되어 있어도 누군가 이 부분을 유심히 들여다본다면, 뭔가 잘못되었다는 걸 금방 파악할 수 있다. 즉 문장의 구조를 분석하고 오류를 점검해주는 프로그램인 파서(parser)가 얼마든지 미리 짚어낼 수 있는 문제라는 것이다. 결국 아파치 스트러츠 취약점이 공략 당했다는 건 파서가 어쩐 일인지 제대로 작동하지 않았다는 걸 뜻한다. 파서 기능의 문제인 걸까? 아니다.
우리는 이미 Content-Type 필드에 어떤 값을 사용할 수 있는지 전 세계적으로 약속을 한 상태다. 이는 IETF RFC 2616의 14.17번 조항을 통해 규정되어 있다. 이 ‘약속’은 여기를 클릭해 상세히 살펴볼 수 있다. 즉, 아무런 값이나 Content-Type에 집어넣을 수 없는 게 맞고, 거기에 이상한 값들이 마구 작성되어 있더라도 IETF RFC라는 약속 혹은 표준에 의해 걸러낼 수 있어야 정상이라는 것이다. 그렇기에 이는 기능의 문제가 아니라 약속 이행의 문제에 가깝다.
애초에 파서를 제대로 설계하는 게 어려웠을까? Content-Type 필드 내에 들어갈 수 있는 것들을 미리 정하는 게 어려웠나? 그럼으로써 대형 사고를 막는다는 게 우리가 가진 역량 바깥에 있는 일인가? 실험이라도 미리 해볼 수 없었나? 역시, 아니다. 전부 가능했고, 가능하다.
문제라는 것에 봉착했을 때, 공학적인 해결책을 모색한다는 건 의외로 더 많은 문제들을 낳을 수 있다. 그래서 우리에겐 표준이라는 것이 있는 것이고, 그 표준이 정확하고 온전하게 정의되면 될수록 수학적으로 오류 발생률이 낮으며 검증된 파서를 동원할 수 있게 된다. 그런 파서가 있을 때 우리는 마음 놓고 퍼즈 테스팅을 통해 규범이나 표준을 침해하고 있는지 점검할 수 있게 된다. 이걸 우리가 몰라서 혹은 능력이 없어서 못하는가? 아니다. 그 표준의 규정이 너무 길어서 몇날며칠 동안 지겹게 명세 페이지를 들여다봐야 하는 게 힘들어서고, 무엇보다 그 힘든 일을 하는 의미나 보람이 없기 때문이다. 새로운 기능 하나 만들어내지 못하고 표준 지키기에만 매달리는 것이 지금 소프트웨어 개발 업계 분위기 속에서 얼마나 가치가 없는지.
기준은 왜곡하고, 보안은 망가뜨리고
그런 와중에 어떤 방화벽 혹은 웹방화벽 제조업체들이 파서를 기가 막히게 꼼꼼하게 만들었던 것 같다. 고집스럽게 한 땀 한 땀 모든 RFC 문서의 글자를 그대로 정책으로 변환시켜 방화벽에 도입시켰나 보다. 사고 대응 시 방화벽이 제일 먼저 RFC 표준 확인부터 하는 경우가 몇 있었다. 그렇지만 그렇게 완벽하고 꼼꼼하고 장인정신 가득한 방화벽이라도 실제로 구축되고 나서 무용지물에 가깝게 변한다고 해도 전혀 놀라울 것이 없는 일이다. 왜냐하면 많은 사용자들이 사용성 때문에 일부 표준 혹은 표준의 일부를 어기도록 설정하기 때문이다.
회사 내에서 자체 개발한 미디어 파일의 유형이 방화벽 정책에 위반된다면, 그래서 제대로 개발이나 실험을 할 수가 없다면 우린 표준을 지키려는 것보다 어기는 것을 먼저 떠올린다. 그리고 이걸 융통성 있는 적용이라고 여긴다. 빠르게 개발을 마치고 출시해야 하는 분위기 속에서 이는 칭찬받을 행위가 된다. 실제로 라이브러리나 프레임워크 개발자들이 유연성이나 맞춤형을 목적으로 심심찮게 하는 행동들이기도 하다.
더 빨리 소프트웨어를 구현하기 위해 기준을 왜곡하거나 원칙을 무시하는 일은 흔히 발생한다. 기업들은 보안 엔지니어에게 특정 통제 장치나 정책이 애플리케이션을 “망가뜨리기 때문에” 이를 없애달라고 자주 요구한다. 새로운 기능을 구현하는 일은 보안보다 더 많은 수익을 발생시키기 때문에 늘 우선순위에 오른다.
소프트웨어 공학? 경제 때문에 ‘공학’은 죽어나고 소프트웨어만 산다
소프트웨어 산업은 개발에서부터 운영까지, 오로지 빠른 구현과 출시만을 위주로 하고 있다. 보안성을 포함한 ‘질’이라는 것은 철저하게 후순위에 머무른다. 물론 보안은 신문 1면에 실릴 만큼 혁신적이거나 사람들의 이목을 집중시키는 것은 아니다. 그렇기에 보안까지 꼼꼼하게 신경 쓰는 공학적 미덕은 무시되거나, 심지어 방해요소 취급 받는다. 그리고 보안 취약점 대부분이 바로 이 지점에서 탄생하고 무럭무럭 자란다.
그러나 희망은 있다. 에퀴팩스가 5일 동안 시가총액 35%와 함께 수십 억 달러를 날렸다는 사실이다. 이런 ‘금전적인 교훈’은 방정식을 바꿔놓을 만한 계기가 될 수도 있다. 업계 영향력 높은 보안 전문가 브루스 슈나이어(Bruce Schneier)는 정부 개입까지 주창하고 나선 상태다.
만약 경제적이거나 규제적인 장치가 마련되고, 이 때문에 소프트웨어의 ‘질’을 높이려는 분위기가 형성된다면 늘어만 가는 보안 침해 사고의 많은 부분을 해결할 수 있을 것이다. 그런 날이 올 때까지 우리는 계속 절차나 원칙을 무시하면서 돈을 벌거나 아끼기에 바쁠 것이고, 에퀴팩스로부터 나쁜 신용점수를 받을 위험도 각오해야 할 것이다.
글 : 드미트리 스틸리아디스(Dimitri Stiliadis)
[국제부 오다인 기자(boan2@boannews.com)]
보안이 수익과 직결돼있다는 사고 전환 있어야 우선시 될 수 있어
[보안뉴스 오다인 기자] 에퀴팩스 사태가 터진 뒤 많은 비판과 책임론이 이어지고 있다. 나 역시 에퀴팩스를 감싸고 돌 생각은 없다. 다만 에퀴팩스 사태로 인해 에퀴팩스라는 한 조직뿐만 아니라 소프트웨어 개발 분야 전반에 깔려있는 잘못된 추진제들이 드러났다는 사실을 짚어보고 싶다. 이 추진제들부터 바꾸지 않는 이상 보안은 언제나 문제가 될 것이다. 이걸 짚는 이유는 ‘제2의 에퀴팩스’를 막으려면 무엇을 해야 할까, 에 대한 답을 찾기 위해서다.
[이미지=iclickart]
소프트웨어의 경제학
일단 소프트웨어 업체 또는 개발자의 입장에서 한 번 생각해보자. 개발자가 더 나은 보안을 구축하고 싶어서 더 오래 프로젝트를 붙잡고 있었다면, 그 사람에게 보너스를 주거나 승진시킨 일이 있었나? 제품 매니저가 소프트웨어 취약점 때문에 또는 적절한 보안성 검토가 부족했기 때문에 소프트웨어 출시를 중단시켰다면, 그 사람에게 포상을 해줬던 일은 있었나? 소프트웨어 업체가 엔드유저를 탓하지 않고 자사 코드가 엉터리였다고 책임진 사례는 언제가 마지막이었나? 벤처캐피탈리스트가 회사의 보안 프로세스 때문에 투자 가치를 높여준 사례는 언제가 마지막이었나?
소프트웨어를 자동차에 비유하면 현재 소프트웨어 업계가 하고 있는 행위를 더 쉽게 이해할 수 있다. 지금 우리는 안전벨트와 에어백이 제대로 작동하지 않는다는 사실을 알면서도 사고 같은 건 나지 않을 거라는 희망 하나에 모든 것을 걸고 운전자에게 자동차를 팔아넘긴 뒤 ‘혹시 사고가 나도 제조사 책임은 아님’이라고 적힌 계약서에 도장 찍으라고 강요하고 있는 것과 같다.
새로운 기능을 빠르게 구현하는 것. 이것이 소프트웨어 개발의 가장 중요한 추진제이자 목표다. 그 누구보다 먼저 새로운 기능을 추가하고 소비자에게 제공하기 위해 우리는 눈에 불을 켜고 소프트웨어를 만든다. 아니, 그것 자체가 소프트웨어 개발이라는 것의 정의다. 우리가 자주 외는 주문인 “프로토타입도 빨리 실패도 빨리”가 모든 것을 설명한다. 결국 “사업을 빨리 빨리 굴리려면 절차나 원칙을 좀 무시해야 한다”는 뜻이기 때문이다. 비로소 보안에 대해 걱정하기 시작하는 때는 제품이 성숙기에 접어들고 고객도 있는 시점에서다. 현실에선 그나마도 거의 일어나지 않는다. 왜냐면 제품이 더 큰 성공을 거둘수록 다른 고객 이슈나 사업 우선순위로 인해 보안 문제가 퇴색되기 때문이다.
에퀴팩스 취약점
이러한 문제점에 대한 생각을 가지고 에퀴팩스 사건으로 악명이 드높아진 아파치 스트러츠 취약점을 살펴보자. 먼저 아파치 스트러츠 취약점이란, 공격자가 Content-Type이라는 HTTP 헤더 내에 특별한 문구를 삽입할 수 있게 해주는 것으로, 악용될 경우 원격 코드 실행까지 성공할 수 있게 해주는 것이다.
그러나 Content-Type에 악성 코드가 작성되어 있어도 누군가 이 부분을 유심히 들여다본다면, 뭔가 잘못되었다는 걸 금방 파악할 수 있다. 즉 문장의 구조를 분석하고 오류를 점검해주는 프로그램인 파서(parser)가 얼마든지 미리 짚어낼 수 있는 문제라는 것이다. 결국 아파치 스트러츠 취약점이 공략 당했다는 건 파서가 어쩐 일인지 제대로 작동하지 않았다는 걸 뜻한다. 파서 기능의 문제인 걸까? 아니다.
우리는 이미 Content-Type 필드에 어떤 값을 사용할 수 있는지 전 세계적으로 약속을 한 상태다. 이는 IETF RFC 2616의 14.17번 조항을 통해 규정되어 있다. 이 ‘약속’은 여기를 클릭해 상세히 살펴볼 수 있다. 즉, 아무런 값이나 Content-Type에 집어넣을 수 없는 게 맞고, 거기에 이상한 값들이 마구 작성되어 있더라도 IETF RFC라는 약속 혹은 표준에 의해 걸러낼 수 있어야 정상이라는 것이다. 그렇기에 이는 기능의 문제가 아니라 약속 이행의 문제에 가깝다.
애초에 파서를 제대로 설계하는 게 어려웠을까? Content-Type 필드 내에 들어갈 수 있는 것들을 미리 정하는 게 어려웠나? 그럼으로써 대형 사고를 막는다는 게 우리가 가진 역량 바깥에 있는 일인가? 실험이라도 미리 해볼 수 없었나? 역시, 아니다. 전부 가능했고, 가능하다.
문제라는 것에 봉착했을 때, 공학적인 해결책을 모색한다는 건 의외로 더 많은 문제들을 낳을 수 있다. 그래서 우리에겐 표준이라는 것이 있는 것이고, 그 표준이 정확하고 온전하게 정의되면 될수록 수학적으로 오류 발생률이 낮으며 검증된 파서를 동원할 수 있게 된다. 그런 파서가 있을 때 우리는 마음 놓고 퍼즈 테스팅을 통해 규범이나 표준을 침해하고 있는지 점검할 수 있게 된다. 이걸 우리가 몰라서 혹은 능력이 없어서 못하는가? 아니다. 그 표준의 규정이 너무 길어서 몇날며칠 동안 지겹게 명세 페이지를 들여다봐야 하는 게 힘들어서고, 무엇보다 그 힘든 일을 하는 의미나 보람이 없기 때문이다. 새로운 기능 하나 만들어내지 못하고 표준 지키기에만 매달리는 것이 지금 소프트웨어 개발 업계 분위기 속에서 얼마나 가치가 없는지.
기준은 왜곡하고, 보안은 망가뜨리고
그런 와중에 어떤 방화벽 혹은 웹방화벽 제조업체들이 파서를 기가 막히게 꼼꼼하게 만들었던 것 같다. 고집스럽게 한 땀 한 땀 모든 RFC 문서의 글자를 그대로 정책으로 변환시켜 방화벽에 도입시켰나 보다. 사고 대응 시 방화벽이 제일 먼저 RFC 표준 확인부터 하는 경우가 몇 있었다. 그렇지만 그렇게 완벽하고 꼼꼼하고 장인정신 가득한 방화벽이라도 실제로 구축되고 나서 무용지물에 가깝게 변한다고 해도 전혀 놀라울 것이 없는 일이다. 왜냐하면 많은 사용자들이 사용성 때문에 일부 표준 혹은 표준의 일부를 어기도록 설정하기 때문이다.
회사 내에서 자체 개발한 미디어 파일의 유형이 방화벽 정책에 위반된다면, 그래서 제대로 개발이나 실험을 할 수가 없다면 우린 표준을 지키려는 것보다 어기는 것을 먼저 떠올린다. 그리고 이걸 융통성 있는 적용이라고 여긴다. 빠르게 개발을 마치고 출시해야 하는 분위기 속에서 이는 칭찬받을 행위가 된다. 실제로 라이브러리나 프레임워크 개발자들이 유연성이나 맞춤형을 목적으로 심심찮게 하는 행동들이기도 하다.
더 빨리 소프트웨어를 구현하기 위해 기준을 왜곡하거나 원칙을 무시하는 일은 흔히 발생한다. 기업들은 보안 엔지니어에게 특정 통제 장치나 정책이 애플리케이션을 “망가뜨리기 때문에” 이를 없애달라고 자주 요구한다. 새로운 기능을 구현하는 일은 보안보다 더 많은 수익을 발생시키기 때문에 늘 우선순위에 오른다.
소프트웨어 공학? 경제 때문에 ‘공학’은 죽어나고 소프트웨어만 산다
소프트웨어 산업은 개발에서부터 운영까지, 오로지 빠른 구현과 출시만을 위주로 하고 있다. 보안성을 포함한 ‘질’이라는 것은 철저하게 후순위에 머무른다. 물론 보안은 신문 1면에 실릴 만큼 혁신적이거나 사람들의 이목을 집중시키는 것은 아니다. 그렇기에 보안까지 꼼꼼하게 신경 쓰는 공학적 미덕은 무시되거나, 심지어 방해요소 취급 받는다. 그리고 보안 취약점 대부분이 바로 이 지점에서 탄생하고 무럭무럭 자란다.
그러나 희망은 있다. 에퀴팩스가 5일 동안 시가총액 35%와 함께 수십 억 달러를 날렸다는 사실이다. 이런 ‘금전적인 교훈’은 방정식을 바꿔놓을 만한 계기가 될 수도 있다. 업계 영향력 높은 보안 전문가 브루스 슈나이어(Bruce Schneier)는 정부 개입까지 주창하고 나선 상태다.
만약 경제적이거나 규제적인 장치가 마련되고, 이 때문에 소프트웨어의 ‘질’을 높이려는 분위기가 형성된다면 늘어만 가는 보안 침해 사고의 많은 부분을 해결할 수 있을 것이다. 그런 날이 올 때까지 우리는 계속 절차나 원칙을 무시하면서 돈을 벌거나 아끼기에 바쁠 것이고, 에퀴팩스로부터 나쁜 신용점수를 받을 위험도 각오해야 할 것이다.
글 : 드미트리 스틸리아디스(Dimitri Stiliadis)
[국제부 오다인 기자(boan2@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
오다인기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
