글로벌 칼럼 | 스타벅스 사례로 본 앱 테스트와 생략의 죄

글로벌 칼럼 | 스타벅스 사례로 본 앱 테스트와 생략의 죄

암호를 일반 파일에 보관했던 스타벅스를 둘러싼 논란은 스타벅스가 문제의 모바일 결제 앱을 수정하면서 사그라지는 분위기다. 그러나 이 사건은 스타벅스 보안이 아닌, 모든 모바일 앱 개발자들에 대한 경고다.

스타벅스는 분명 ‘생략의 죄’를 저지른 것으로 보인다. 스타벅스는 2013년 5월 문제의 앱을 내놓기 전 테스트를 실시했지만 앱이 저장하는 데이터에 대해 세세히 살펴보지는 않았고, 구현하고자 한 기능이 제대로 작동하는지 확인하는 데 주력했다.

이와 같이 보안 테스트 ‘생략의 죄’는 많은 수의 대기업들이, 특히 모바일 앱에 관해 흔히 저지르는 죄다.

스타벅스의 공식적인 입장은 경영진은 앱 충돌 분석 프로그램(작년에 트위터가 인수한 크래실리틱스(Crashlytics))에 대해 알지 못했으며, 충돌 발생 후 원활한 복구를 위해 데이터를 캡처할 때 암호를 일반 텍스트 파일에 저장했다는 것이다. 대변인 린다 밀스는 “2013년 5월 충돌 진단을 위한 임시 충돌 로그 파일의 존재는 알았지만 일반 텍스트에 사용자 이름과 암호가 포함되어 있다는 점은 몰랐다”고 말했다.그러나 필자가 그 조기 테스트에 참여했던 사람에게 들은 바로는 스타벅스 경영진은 암호가 일반 텍스트에 포함되어 있다는 사실을 알고 있었다. 과연 어느 쪽이 진실일까? 알 수 없다. IT 부서의 누군가가 암호 문제를 알고 있었지만 이를 보고 라인을 통해 제대로 전파하지 않았을 가능성도 있다.

그것보다 더 큰 문제는 따로 있다. 단순히 스타벅스에 국한된 문제가 아니다. 많은 기업들이 앱을 개발할 때 별 생각 없이 두는 전제, 바로 ‘민감한 정보가 포착되고 표시될지도 모른다’는 의심을 할 이유가 없다는 전제다. 이 전제하에서는 아무도 그 부분에 주의하지 않는다. 그리고 나중에 그런 일이 실제로 발생하면 깜짝 놀란다.

이런 태도를 갖고 앱을 개발할지도 모를 모든 회사에게 전하고 싶은 메시지가 있다.모바일 앱을 ‘위험한 정보 생물체’로 보라는 것이다. 즉, 앱이 어떤 동작을 하는지에 대한 심층적인 관찰을 포함한 훨씬 더 많은 테스트를 실시해야 한다.

그럴 시간이나 돈이 없다고? 아니다. 보안 연구원 다니엘 우드는 스타벅스의 파일들을 점검하고 전적 분석을 실시했지만 수중에 많은 예산이 없었으며 실제 작업에 그렇게 많은 시간이 들지도 않았다. 우드는 “이러한 유형의 테스트는 임시 캐시 파일이나 메모리, 일반적인 작업에 사용되는 영구 데이터 파일 등 그 형태에 관계없이 어떤 데이터 요소들이 디스크에 저장되는지 집중적으로 살펴본다”며 “또한 애플리케이션 파일에서 부적절한 프로그램 메서드나 함수의 활용을 분석하며, 보안 코드 리뷰라는 절차를 통해 다른 개념들 사이에 위치한 입력과 출력이 적절히 보안 처리되는지 파악한다”고 말했다.

이런 유형의 테스트를 실시하기 위한 시간과 돈을 마련할 이유는 충분하다. 테스트를 하지 못할 경우 결국 곤경과 고객 분노에 직면할 수 있기 때문이다. 확인해야 할 것들에 대해 생각하라. 첫째, 코드가 사용될 장치의 모바일 OS와 해당 코드가 어떻게 상호 작용하는가? 사용되는 서드 파티 코드(스타벅스 사건의 원인)는 무엇인가?스타벅스의 서드파티 앱은 하지 말아야 할 몇 가지 작업을 했고 이것이 앱의 다른 부분에서 암호 유출과 같은, 누구도 가능하리라 생각하지 않았던 일이 일어나는 원인으로 작용했다.

이런 사건이 실제 일어날 수 있다고 전제하고 그 부분을 구체적으로 살펴봐야 한다.

PCI, HIPAA, 사베인 옥슬리와 같은 산업 및 정부 규정과 충돌할 수 있는 부분을 살펴야 한다. 결제 카드 데이터, 의료 보건 정보 또는 민감한 금융 데이터를 노출하는 앱을 내놓고 싶진 않을 것이다. 우드가 말하는 철저한 테스트를 실행하지 않는 한 이런 사건들이 일어나지 않는다고 확신할 수 없다.

현재 컨설턴트로서 스타벅스와 긴밀히 협력 중인(현재 무보수로 작업 중) 우드는 이 사건과 관련된 스타벅스의 많은 직원들과 이야기를 나누고 그 나름대로 사건의 발생 과정에 대한 결론을 내렸다. “검토 결과 스타벅스 직원들은 애플리케이션을 테스트하고 보안 기능이 제대로 작동한다고 확신했다. 그러나 실수였든 뭐든 문제의 애플리케이션은 민감한 사용자 데이터를 노출했다. 이는 비즈니스에서 IT 또는 보안을 이해하지 못하는 전형적인 경우다. 크든 작든 거의 모든 조직에서 이런 현상이 일반적으로 나타난다. 처음 계획과 라이프사이클 시작 단계부터 보안 설계자/엔지니어를 프로젝트에 참여시키면 이러한 사고들을 대부분 방지할 수 있다. 포함할 서드 파티 서비스 등에 대해 보안 영향 분석을 실시했어야 했고, 보안 테스트에서도 이 부분에 집중했어야 했다. 그랬다면 이런 결함을 사전에 포착했을 가능성이 높다. 앱과 관련된 일련의 의사 결정 과정에 직접 참여했던 것은 아니므로 어디까지나 추측이지만 아마 이런 부분에 소홀했을 것이다.”

결론은 이 사건이 스타벅스만의 문제가 아니란 점이다. “크든 작든 거의 모든 조직에서 이런 현상이 일반적으로 나타난다”는 우드의 말을 되새겨 보자. 오늘 여러분의 팀에게 현재 수행하는 모바일 앱용 보안 테스트의 수준에 대해 물어보라. 기능 테스트가 아니라, 진정한 보안 테스트를 물어야 한다. 그것 만으로 큰 골칫거리를 사전에 예방할 수도 있다. editor@itworld.co.kr
   

 
 
 
 
Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중