.jpg)
.jpg)
내부 제작 앱은 철저한 라이프사이클 관리, 외부 앱은 정책으로
현대 기업들은 대부분 ‘소프트웨어 제작사’ 기능하고 있어
[보안뉴스 문가용] 최근 애플리케이션 층위를 공격하는 사례가 부쩍 늘어났다. 그만큼 많은 기업들이 애플리케이션의 보안에 실패하고 있다고 봐도 된다. 여기엔 여러 가지 이유가 있다. 시간과 자원의 부족, 예산의 압박, 애플리케이션을 얼른 시장에 출시하고자 하는 ‘빨리빨리’ 풍토 등등.
그래서인지 기존의 외곽 보안 및 네트워크 보안에 비해 애플리케이션 보안을 어렵게 생각하는 업체들이 많다. 그러나 이는 사실이 아니다. 세상에 어떤 회사도 애플리케이션 보안 조치를 취하지 못할 이유가 없다. 다음의 간단한 네 가지 방법만 있으면 말이다.
1단계 : 크게 보고 작게 쪼개라
애플리케이션 보안의 첫 걸음은 회사 혹은 조직차원에서 상황에 따른 보안 전략을 수립할 수 있도록 하는 로드맵을 만드는 것이다. 이 로드맵을 가지고 무엇을 우선순위에 놓고, 어떤 일들을 차례로 실행해야 하는지 결정할 수 있다.
시작은 성숙기 평가(maturity assessment)로 하는 게 좋다. 이는 산업 표준 프레임워크를 기반으로 해서 위험할 수 있는 부분을 구체적으로 짚어내는 단계다. 또한 최초 공격이 들어올 만한 지점을 네트워크 외곽에서 찾아내야 한다.
세상에 얼마나 많은 웹 애플리케이션이 존재하고, 또 얼마나 많은 사용자들이 각기 나름의 앱들을 찾아 업무에 적용하는지, 업체들은 짐작도 하지 못한다. 한 예로 지난 48개월 동안 우리 고객 업체들을 대상으로 조사한 결과 업체가 인지하지 못한 웹 애플리케이션의 종류는 35만 개나 되었다.
여기까지가 되었다면 가장 중요한 시스템 5~10개를 추리고, 발견된 취약점들 중 가장 치명적인 것을 5~10개 순서대로 정리한다. 그리고 그에 대한 방지나 복구법을 마련한다. 이 작업이 조직 차원에서 대대적으로 진행되면 될수록 애플리케이션 보안에 대한 일반 직원들의 경각심도 커질 수 있다.
2단계 : 정책과 평가기준을 마련하라
이렇게 대대적인 보안 작업을 진행하는 동안 반드시 염두에 두어야 하는 게 있는데, 바로 산업 내에서 널리 받아들여지고 있는 산업 표준이다. 보안의 목표가 이런 표준들을 무시해서는 절대 안 된다. 가장 널리 받아들여지는 표준은 OWASP에서 발행하는 것들이니 시간 날 때 틈틈이 들여다보면 도움이 될 것이다. 이 표준들에 비교해가며 보면 문제점들이 더 명확히 드러날 수 있다.
중요한 건 OWASP이냐 아니냐가 아니라 위에서 로드맵을 작성하며 발견한 문제점들을 구체적으로 해결해나갈 시간표를 작성하는 것이다. 정확히 언제까지 어떤 취약점들을 해결하겠다, 총 발견된 취약점 몇 가지 중 1/3을 1사분기까지 해결하겠다 등등의 계획표를 짜라는 것이다. 또한 ‘성공’이라든가 ‘아직 더 손봐야 함’ 등 스코어 항목도 정해 그 기간이 지났을 때의 평가도 원활히 할 수 있도록 해야 한다.
3단계 : 소프트웨어 개발 모든 부분에 적용하라
사실 여태까지 애플리케이션 보안은 회사의 사업 운영에 있어 가장 중요한 것들만 그 대상으로 해왔다. 하지만 이는 이미 낡은 생각이다. 회사 네트워크에 존재하는 모든 애플리케이션, 특히 직접 개발하는 앱들도 보안의 대상이 되어야 한다. 물론 그 중요한 애플리케이션들에 더 중요한 정보들이 저장되어 있을 가능성이 높다. 하지만 해커들은 더 이상 곧이 곧대로 중요한 앱만 노리지 않는다. 여러 단계를 거치고 돌아 목적지에 도달하고야 마는 것이다. 그러므로 이제 모든 앱이 탄탄하지 않으면 의미가 없다.
그러면 어떻게 100% 모든 앱의 보안을 신경 쓸 수 있을까? 가장 효율적인 건 앱이 개발되는 전 생애주기에 대한 평가 수순을 도입하는 것이다. 즉 개발에서부터 보안을 반드시 고려하는 과정을 회사가 정착시켜야 한다. 보안은 시작부터 반영되어야지, 나중에 가서 완성품 위에 끼얹는 타르타르 소스가 아니다. 다만 개발자들이 아직 이런 개념을 잘 받아들이지 않는다는 게 문제다. 업체들마다 여러 설득의 방법들을 동원하는 걸 봐왔는데, 나중에 디버깅 작업하는 것보다 시작부터 보안이란 개념에 입각한 앱을 만드는 게 덜 귀찮다는 사실을 보여주는 게 가장 효과가 좋았다.
4단계 : 외부 요소 및 앱을 스캐닝하라
위 3단계까지 읽었다면 아마 이런 궁금증이 생길 것이다. ‘남들이 만든 앱은?’ 이들도 예외는 아니다. 말했다시피 네트워크에 존재하는 모든 앱들이 탄탄해야만 보안이 의미를 갖는다. 하지만 외부 앱들은 회사의 소유가 아니다. 고로 코드를 손볼 수 없다. 그렇기 때문에 많은 업체들이 외부 앱들의 상태에 대해선 방관하거나 포기한다. 하지만 코드를 손 볼 수 없다면, 정책을 강력하게 손봐서 아예 기준에 조금이라도 부합하지 않은 앱이라면 네트워크에 가까이도 못 오게 해야 한다. 절대 해킹과 같은 방법으로 제작사의 동의 없이 외부 앱을 분석해서는 안 된다.
또한 업체로서는 현재 웹에 존재하는 모든 애플리케이션들의 목록을 확보하는 데에 주력해야 한다. 그와 함께 어떤 취약점들이 알려져 있는지, 혹은 발견되었는지도 함께 적어두어 관리해야 한다. 널리 알려지고 한바탕 난리가 났었던 유명 취약점들은 ‘이제 없겠거니’ 생각하지 말고 기본으로 점검하고 넘어간다.
현대의 기업들 대부분은 어느 정도 ‘소프트웨어 제조사’의 기능을 수행한다. 내부 직원들만 사용하는 메신저나 프로그램, 인트라넷 웹 사이트 등이 존재하지 않는 곳을 찾기 힘들 정도다. 이는 고대 사회로 따져보면 마치 영토를 늘리는 것이나 다름이 없다. 자기 영역은 자기가 철저히 관리하는 게 마땅하다. 부디 눈 먼 탐관오리 하나 심어놓고 ‘영토 내 모든 사정이 알아서 관리되길’ 바라지 말 것을 당부한다.
글 : 크리스 와이소팔(Chris Wysopal)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
현대 기업들은 대부분 ‘소프트웨어 제작사’ 기능하고 있어
[보안뉴스 문가용] 최근 애플리케이션 층위를 공격하는 사례가 부쩍 늘어났다. 그만큼 많은 기업들이 애플리케이션의 보안에 실패하고 있다고 봐도 된다. 여기엔 여러 가지 이유가 있다. 시간과 자원의 부족, 예산의 압박, 애플리케이션을 얼른 시장에 출시하고자 하는 ‘빨리빨리’ 풍토 등등.
▲ 지도 안에서 행군하라, 안전하려면.
그래서인지 기존의 외곽 보안 및 네트워크 보안에 비해 애플리케이션 보안을 어렵게 생각하는 업체들이 많다. 그러나 이는 사실이 아니다. 세상에 어떤 회사도 애플리케이션 보안 조치를 취하지 못할 이유가 없다. 다음의 간단한 네 가지 방법만 있으면 말이다.
1단계 : 크게 보고 작게 쪼개라
애플리케이션 보안의 첫 걸음은 회사 혹은 조직차원에서 상황에 따른 보안 전략을 수립할 수 있도록 하는 로드맵을 만드는 것이다. 이 로드맵을 가지고 무엇을 우선순위에 놓고, 어떤 일들을 차례로 실행해야 하는지 결정할 수 있다.
시작은 성숙기 평가(maturity assessment)로 하는 게 좋다. 이는 산업 표준 프레임워크를 기반으로 해서 위험할 수 있는 부분을 구체적으로 짚어내는 단계다. 또한 최초 공격이 들어올 만한 지점을 네트워크 외곽에서 찾아내야 한다.
세상에 얼마나 많은 웹 애플리케이션이 존재하고, 또 얼마나 많은 사용자들이 각기 나름의 앱들을 찾아 업무에 적용하는지, 업체들은 짐작도 하지 못한다. 한 예로 지난 48개월 동안 우리 고객 업체들을 대상으로 조사한 결과 업체가 인지하지 못한 웹 애플리케이션의 종류는 35만 개나 되었다.
여기까지가 되었다면 가장 중요한 시스템 5~10개를 추리고, 발견된 취약점들 중 가장 치명적인 것을 5~10개 순서대로 정리한다. 그리고 그에 대한 방지나 복구법을 마련한다. 이 작업이 조직 차원에서 대대적으로 진행되면 될수록 애플리케이션 보안에 대한 일반 직원들의 경각심도 커질 수 있다.
2단계 : 정책과 평가기준을 마련하라
이렇게 대대적인 보안 작업을 진행하는 동안 반드시 염두에 두어야 하는 게 있는데, 바로 산업 내에서 널리 받아들여지고 있는 산업 표준이다. 보안의 목표가 이런 표준들을 무시해서는 절대 안 된다. 가장 널리 받아들여지는 표준은 OWASP에서 발행하는 것들이니 시간 날 때 틈틈이 들여다보면 도움이 될 것이다. 이 표준들에 비교해가며 보면 문제점들이 더 명확히 드러날 수 있다.
중요한 건 OWASP이냐 아니냐가 아니라 위에서 로드맵을 작성하며 발견한 문제점들을 구체적으로 해결해나갈 시간표를 작성하는 것이다. 정확히 언제까지 어떤 취약점들을 해결하겠다, 총 발견된 취약점 몇 가지 중 1/3을 1사분기까지 해결하겠다 등등의 계획표를 짜라는 것이다. 또한 ‘성공’이라든가 ‘아직 더 손봐야 함’ 등 스코어 항목도 정해 그 기간이 지났을 때의 평가도 원활히 할 수 있도록 해야 한다.
3단계 : 소프트웨어 개발 모든 부분에 적용하라
사실 여태까지 애플리케이션 보안은 회사의 사업 운영에 있어 가장 중요한 것들만 그 대상으로 해왔다. 하지만 이는 이미 낡은 생각이다. 회사 네트워크에 존재하는 모든 애플리케이션, 특히 직접 개발하는 앱들도 보안의 대상이 되어야 한다. 물론 그 중요한 애플리케이션들에 더 중요한 정보들이 저장되어 있을 가능성이 높다. 하지만 해커들은 더 이상 곧이 곧대로 중요한 앱만 노리지 않는다. 여러 단계를 거치고 돌아 목적지에 도달하고야 마는 것이다. 그러므로 이제 모든 앱이 탄탄하지 않으면 의미가 없다.
그러면 어떻게 100% 모든 앱의 보안을 신경 쓸 수 있을까? 가장 효율적인 건 앱이 개발되는 전 생애주기에 대한 평가 수순을 도입하는 것이다. 즉 개발에서부터 보안을 반드시 고려하는 과정을 회사가 정착시켜야 한다. 보안은 시작부터 반영되어야지, 나중에 가서 완성품 위에 끼얹는 타르타르 소스가 아니다. 다만 개발자들이 아직 이런 개념을 잘 받아들이지 않는다는 게 문제다. 업체들마다 여러 설득의 방법들을 동원하는 걸 봐왔는데, 나중에 디버깅 작업하는 것보다 시작부터 보안이란 개념에 입각한 앱을 만드는 게 덜 귀찮다는 사실을 보여주는 게 가장 효과가 좋았다.
4단계 : 외부 요소 및 앱을 스캐닝하라
위 3단계까지 읽었다면 아마 이런 궁금증이 생길 것이다. ‘남들이 만든 앱은?’ 이들도 예외는 아니다. 말했다시피 네트워크에 존재하는 모든 앱들이 탄탄해야만 보안이 의미를 갖는다. 하지만 외부 앱들은 회사의 소유가 아니다. 고로 코드를 손볼 수 없다. 그렇기 때문에 많은 업체들이 외부 앱들의 상태에 대해선 방관하거나 포기한다. 하지만 코드를 손 볼 수 없다면, 정책을 강력하게 손봐서 아예 기준에 조금이라도 부합하지 않은 앱이라면 네트워크에 가까이도 못 오게 해야 한다. 절대 해킹과 같은 방법으로 제작사의 동의 없이 외부 앱을 분석해서는 안 된다.
또한 업체로서는 현재 웹에 존재하는 모든 애플리케이션들의 목록을 확보하는 데에 주력해야 한다. 그와 함께 어떤 취약점들이 알려져 있는지, 혹은 발견되었는지도 함께 적어두어 관리해야 한다. 널리 알려지고 한바탕 난리가 났었던 유명 취약점들은 ‘이제 없겠거니’ 생각하지 말고 기본으로 점검하고 넘어간다.
현대의 기업들 대부분은 어느 정도 ‘소프트웨어 제조사’의 기능을 수행한다. 내부 직원들만 사용하는 메신저나 프로그램, 인트라넷 웹 사이트 등이 존재하지 않는 곳을 찾기 힘들 정도다. 이는 고대 사회로 따져보면 마치 영토를 늘리는 것이나 다름이 없다. 자기 영역은 자기가 철저히 관리하는 게 마땅하다. 부디 눈 먼 탐관오리 하나 심어놓고 ‘영토 내 모든 사정이 알아서 관리되길’ 바라지 말 것을 당부한다.
글 : 크리스 와이소팔(Chris Wysopal)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
