금융 보안 교육 - 안전한 소프트웨어를 위한 시큐어 코딩의 이해

A. 개요

1. 시큐어 코딩이 필요한 이유

국내 가상화폐 거래소 C사가 2018년 6월, 해킹을 당했습니다. 해킹으로 유출된 가상화폐는 펀디엑스, 애스톤, 엔퍼 등인데요. C사의 해킹 피해 규모는 보유 코인의 30%에 해당하며 400억 원 상당이 유출된 것으로 추정되었습니다. C사에 앞선 해킹 사례로는, “Y사”가 55억 원 상당의 비트코인을, “U사”가 172억 원 상당의 피해를 본 바 있습니다. 당시, C사는 24시간 거래량으로 세계 90위권의 중소거래소로, 한국블록체인협회에 가입하지 않았습니다. 또 국내 최고 수준의 공인 정보보호관리체계인 ISMS 인증도 받지 않았습니다.

 

C사 이외에도 국내 가상화폐 거래소 중 전년도 매출과 이용자 규모에 따라 상위 4개 업체모두 ISMS 인증 의무대상으로 지정되었으나, 이 가운데 ISMS 인증을 받은 업체는 한 곳도 없었습니다. 우연이라도 이들이 해킹 공격을 받게 된다면 엄청난 피해를 입게 될 것이 자명해 보입니다.

 

그렇다면 이러한 정보보안의 이슈는 보안담당자, 보안담당 부서가 책임져야 할 문제일까요? 그렇지 않습니다. 모든 임직원이 정보보안에 대한 중요성을 인식하고 맡은 업무에서 정보보안을 실천해야 합니다. 설계자, 개발자, 운영자들도 보안사고의 개념과 발생 원인을 사전에 인지하여 외부공격에 안전한 애플리케이션을 개발할 수 있도록 노력해야 합니다. 또한, 안전한 소프트웨어 개발을 위해 개발 초기 단계인 요구사항을 수집하는 단계에서부터 분석, 설계, 개발, 테스트, 배포, 운영하는 전 단계에서 적절한 보안활동을 수행해야 합니다. 이 중 개발자들이 수행할 수 있는 보안 활동 중 하나가 바로 시큐어코딩입니다.

 

2. 사고 사례를 통한 시큐어코딩의 필요성

다음으로 사고 사례를 통한 시큐어코딩의 필요성에 대해 살펴보겠습니다.

 

첫 번째 사고 사례 (SQL 인젝션)

웹사이트의 ‘SQL인젝션’ 취약점을 이용하여 고객 개인정보가 탈취된 사고입니다. 해킹 과정을 살펴봅시다. 공격자는 SQL인젝션 취약점을 가지고 있는 웹서버를 통해 DB에 저장된 세션정보를 탈취하였습니다. 이렇게 탈취된 관리자의 세션정보를 사용하여 외부에 노출된 서비스관리 웹사이트에 관리자 권한으로 우회접속하여 예약정보, 제휴점정보 및 회원정보를 유출하였는데요.

 

이 사고는 애플리케이션이 외부에서 입력된 값을 검증하지 않고 DB쿼리에 삽입함으로써 공격자가 의도하는 쿼리문이 실행되었기 때문에 발생된 것입니다. 이처럼 SQL 인젝션 취약점은 가장 위험도가 높은 취약점으로, 대부분의 기업들이 반드시 제거하도록 보안 정책이나 시큐어코딩 기준으로 정의하고 있습니다. 그럼에도 불구하고 이러한 침해사고가 발생되어서 다시 한번 주의를 기울이게 했습니다.

 

공격과정

웹서버(SQL 인젝션 취약점 보유) -> DB에 저장된 세션정보 탈취 -> 탈취된 관리자 정보를 통해 우회접속 -> 정보유출

 

SQL 인젝션 취약점으로 개인정보 유출

 

두 번째 사고 사례 (URL 파라미터 조작)

URL 파라미터 조작을 통한 개인정보 노출 사고입니다. 이 사이트는 배송정보 조회라는 기능을 클릭하게 되면 URL에 주문번호를 파라미터로 전달하여 사용자의 배송정보를 응답해 줍니다. 하지만 로그인하지 않은 사용자가 URL에 포함되어 있는 주문번호를 조작하여 다른 사용자의 주문 정보를 요청해도, 서버가 이것을 인지하지 못하고 이름, 주소, 전화번호와 같은 정보를 응답해 줌으로써 개인정보가 유출되었습니다.

 

많은 개발자들이 체크 박스나 셀렉트 박스, 또는 링크의 URL에 코딩된 입력 값들을 받아서 처리할 때 이 값에 대한 변조의 위협을 고려하지 않는 경우가 많습니다. 하지만 이러한 값들은 충분히 변조되어서 서버로 전달될 수 있기 때문에 이를 고려해서 입력 값에 대한 검증 작업을 수행한 뒤 값이 사용되도록 프로그램을 작성해야 합니다. 다행히 공격자에 의해 취약점이 발견되지 않고 일반 사용자에 의해 취약점이 발견되어 대량의 고객정보 유출 사고는 발생되지 않았지만, 취약점을 발견하고도 3주나 취약점 제거가 이루어지지 않아서 취약점 대응에 대한 문제점도 같이 보여 주었던 사례입니다.

 

공격과정

URL에 포함된 주문번호 조작 -> 서버가 오인식하여 응답 -> 개인정보 유출

 

URL 파라미터 조작

 

세 번째 사고 사례 (무작위 대입공격)

무작위 대입공격으로 기프트 카드 정보가 유출되었던 사례입니다. 온라인으로 기프트 카드를 사용하기 위해서는 카드번호, 유효기간, 보안번호, 등록한 비밀번호를 입력해야 결제가 가능한데요. 16자리 카드번호 가운데 일부 숫자만 바꾸면 유효기간이 같은 새로운 카드번호가 생성된다는 점을 이용해 카드번호와 유효기간을 확인한 다음 000에서 999까지 숫자를 무한 반복 대입하여 보안 번호를 알아내 3억 5천만 원 상당의 기프트 카드 정보를 판매한 사례입니다.

이 사고는 기프트 카드가 무기명이라 소유자가 바뀌는 경우도 많고 잔액 확인도 잦아 오류 횟수를 제한하면 고객이 불편을 겪을 수 있어 보안 번호 입력 횟수를 제한하지 않았기 때문에 공격자가 무작위 대입으로 보안번호를 유추할 수 있었던 것인데요. 시스템 설계 시 보안과 고객의 편의성에 대한 트레이드오프의 한 단면으로 볼 수 있었던 사고 사례입니다. 이러한 보안 위협은 소프트웨어를 분석하고 설계하는 단계에서 충분히 고려되어 설계되고 구현되도록 조치해야 합니다. 이 사고 사례의 경우에는 사고 이후 잔액 조회 때 휴대전화 인증을 실시하고 보안번호를 다섯 번 잘못 입력 시 조회를 제한하도록 로직을 변경하였습니다.

 

공격과정

카드번호의 생성 메커니즘 취약점 파악 -> 숫자 무한 반복 대입 -> 보안 번호 탈취 -> 정보 유출

 

무작위 대입공격

 

네 번째 사고 사례 (웹 애플리케이션 취약점)

웹 애플리케이션 취약점을 이용하여 발생한 사고 사례입니다. 접근제어 기능이 취약한 애플리케이션을 대상으로 공격자는 서버로 전달되는 파라미터를 자동화된 툴을 이용하여 조작한 후 1200만 건의 고객정보를 유출하였습니다. 해킹 경로를 살펴보면, 공격자는 먼저, 정상적으로 취약한 홈페이지에 로그인합니다. 로그인한 사용자는 요금명세서 조회라는 기능을 사용할 수 있는데요, 조회를 요청하게 되면 클라이언트 프로그램은 조회를 위해 9자리 숫자로 된 고객번호를 파라미터 값으로 서버에 전달하게 됩니다.

 

공격자는 이 9자리 고객번호를 자동생성해서 전송하는 프로그램을 만들어서 서버와 클라이언트 사이에 송수신되는 값을 모니터링하거나 위변조 할 수 있는 프록시 도구인 파로스에 플러그인으로 설치하여 약 6개월 동안 지속적으로 서버에 요청을 보내 고객정보를 탈취한 사고입니다. 이 사고의 경우 정상적으로 로그인한 사용자가 9자리 숫자로 된 고객번호를 파라미터 값으로 요청을 보냈기 때문에 방화벽이나 IDS/IPS, 웹방화벽과 같은 보안 솔루션에서 이상징후로 탐지하기는 어려웠습니다. 따라서 애플리케이션을 설계할 때에는 고객번호와 같이 서버가 클라이언트로 전송했다가 다시 서버로 전달받는 입력된 값에 대한 유효성 검사를 실시해야 하고 조회 횟수를 제한하거나 초과된 요청에 대한 보안조치를 고려하여 이러한 침해사고가 발생되지 않도록 해야 합니다.

 

공격과정

취약한 홈페이지 로그인 -> 변조된 클라이언트 프로그램 파라미터 값 생성 -> 값을 위변조 할 수 있는 도구(파로스)를 설치 -> 고객정보 탈취

 

웹 애플리케이션 취약점

 

3. 시큐어코딩

시큐어코딩은 안전한 소프트웨어 개발을 위해 구현단계에서 소스코드 등에 존재할 수 있는 잠재적인 보안 약점을 제거하는 보안활동을 의미합니다. 그러면, 안전한 소프트웨어란 무엇일까요? 사람의 실수로 인해서 발생되는 오류가 프로그램에 포함되는 것을 결함, 결점 또는 버그라고 합니다. 이러한 결함이 제거되지 않고 동작되었을 때 장애나 문제가 발생할 수 있는데요. 이런 장애나 문제가 발생되지 않는 소프트웨어를 안전한 소프트웨어라고 정의할 수 있습니다. 이렇게 안전하게 동작되는 소프트웨어를 만들기 위해서는 개발자들은 구현단계에서 소스코드 등에 존재할 수 있는 보안 약점을 제거하는 시큐어코딩을 수행합니다. 하지만 구현단계의 시큐어코딩만으로는 안전한 소프트웨어를 만드는 것은 쉽지 않고 보안을 고려하여 기능을 설계 및 구현하는 등 SW 개발 과정에서 일련의 보안활동을 수행하는 SW 개발 보안을 함께 적용해야 합니다.

 

안전한 소프트웨어란?

한편, 보안 약점과 보안 취약점은 어떻게 다를까요? 소프트웨어에 입력 값을 제대로 검증하지 않고 사용하였거나 프로그램 오류를 제대로 처리하지 않을 경우 프로그램이 정상적으로 동작되지 않는 상황이 발생될 수 있습니다. 즉, 프로그램이 정상적으로 안전하게 동작되지 않아 해킹 등 보안 사고에 악용될 수 있는 문제점들을 weakness, 보안 약점이라고 부릅니다. 이러한 보안 약점들 중에 발견된 것들도 있고 발견되지 않은 것들도 있는데요. 이렇게 발견된 보안 약점들을 모아서 목록화해 놓은 대표적인 사이트가 CWE입니다.

 

보안약점과 보안취약점

 

 

현재 1000개가 넘는 보안 약점에 대한 발생 원인, 대응 방법 등을 설명하고 있습니다. 그중에서도 가장 위험한 소프트웨어 에러 목록을 25개 항목으로 분류하여 제공하고 있는 것이 SANS TOP 25입니다. 이런 보안 약점들 중에 실제 침해사고 발생원인이 된 보안 약점을 보안 취약점(vulnerabilities)라고 합니다. 이는 소프트웨어를 실행하고 데이터 입출력이 있는 시점에 보통 발견됩니다. 이렇게 발견된 보안 취약점은 CVE 사이트에서 목록화하여 분석하고 대응 방법을 설명하고 있습니다. 해당 설명을 다이어그램으로 표시하면 다음과 같습니다. 해마다 등록되는 CVE 목록 중에 여전히 가장 위험한 25가지의 보안 약점들이 침해사고의 원인인 경우가 많은데요. 이는 소프트웨어를 개발하는 단계에서 보안 약점을 제거하는 것이 취약점 발생률을 줄일 수 있는 방안임을 보여주고 있습니다.

소프트웨어의 취약성에 대해 한번 생각해 보면 소프트웨어가 가지고 있는 보안 취약점은 혼자 스스로 침해사고를 일으키지는 않습니다. 대부분 파일이나. 네트워크, 키보드, 시스템 객체 등과 같이 공격자는 자신이 조작할 수 있는 입력 값 또는 객체를 통해서 소프트웨어의 취약성을 공격하여 의도한 동작이 수행되도록 합니다. 즉, 신뢰되지 않는 외부 입력을 그대로 사용하는 것이 침해사고의 중요한 원인 중 하나인 것입니다.

 

이를 개발자의 관점에서 한번 살펴보겠습니다. 공격자가 자신이 의도하는 동작을 수행하기 위해 입력 값을 조작하여 전송한다고 설명하였습니다. 그렇다면 개발자는 반대로 외부 입력 값 중 자신이 의도하는 입력 값만 받아서 처리하고 그 외의 값은 모두 차단하는 정책을 구현하게 되면 공격자는 해당 시스템을 공격하기가 상당히 어렵게 됩니다.

 

개발자들은 먼저 신뢰하는 구간과 신뢰하지 않는 구간을 나눠야 합니다. 일반적으로 신뢰하는 구간을 웹 애플리케이션 컴포넌트로 정의할 수 있습니다. 그렇게 되면 사용자로부터 들어오는 입력 값이나 DB에서 읽어오는 입력 값들은 신뢰하지 않는 구간이 됩니다. 이렇게 신뢰되지 않은 구간에서 입력 값이 들어오게 되면 먼저 규범화나 정규화를 통해 컴포넌트에서 처리하기 위한 가장 단순한 형식으로 데이터를 가공하는 작업을 수행합니다. 두 단어의 차이점은 원래 값이 변경되는가 여부인데요.

 

입력값 검증

 

예를 들어 a/../b/c.txt라는 파일 경로명이 입력되었을 때, 이 값을 규범화를 수행하게 되면 b/c.txt라는 값이 됩니다. 하지만 이 컴포넌트에서 파일의 경로명을 절대 경로로 사용한다고 하면 /home/webapps/server/upload/b/c.txt와 같은 완전히 다른 값으로 값이 치환될 수 있습니다. 이러한 경우를 정규화라는 단어로 설명할 수 있습니다.

 

이렇게 컴포넌트에 사용할 입력 값을 지정된 형식으로 변환한 뒤, 안전하지 않은 값들은 걸러내는 작업인 입력 값에 필터링을 수행합니다. 예를 들어 SQL삽입 취약점을 방어하기 위해 입력 값 중 SQL삽입을 발생시킬 수 있는 의미 있는 문자들을 모두 삭제하거나, 브라우저에서 동적으로 실행될 수 있는 입력값에 포함된 스크립트 삭제를 합니다. 그다음 검증 과정에서 값의 범위를 확인하거나, null 여부를 판단하거나 비어있는 문자역과 같은 검증을 수행해야 합니다.

 

입력데이터 검증

 

4. SW 개발 보안이 필요한 이유

안전한 소프트웨어를 만들기 위해서는 소프트웨어를 개발하는 전 단계에서 적절한 보안활동을 수행해야 합니다. 이렇게 소프트웨어를 개발하는 프로세스의 각 단계별로 수행하는 보안활동을 정의하고 수행하도록 하는 개발 방법을 소프트웨어 개발보안 방법이라고 하며, 특히, 구현단계에서 소스코드에 존재할 수 있는 보안 약점을 제거하는 선제적인 보안활동을 시큐어코딩이라고 정의하고 있습니다. SW 개발 보안은 왜 해야 할까요?

 

첫 번째, COQ(Cost of Quality)의 절감

다음 표에서 알 수 있듯이 개발 초기 단계에 발견한 결함 수정 비용이 1이라면, 제품 출시 후 수정 비용은 약 30배에 달합니다. 따라서, 안전한 SW 개발을 위해 개발 초기 비용을 투자하더라도 전체적인 품질비용(COQ)은 절감하는 효과를 얻을 수 있습니다.

 

COQ(Cost of Quality)의 절감

 

두 번째, 기업에 미치는 영향

다음은, 기업에 미치는 영향을 살펴볼 수 있는데요. 안전한 소프트웨어 개발은 이제 선택이 아닌 필수입니다. 소프트웨어의 보안 문제가 발생하면 기업의 존폐에 영향을 미칠 정도의 법적인 문제가 발생할 뿐만 아니라, 기업 이용자의 대거 이탈 또한 발생될 수 있기 때문입니다.

 

기업에 미치는 영향

 

 

5. 소프트웨어 보안의 특징

애플리케이션 보안은 이슈 기반의 단기적 접근으로 위협모델링이나 코드 리뷰 등의 활동으로 유지할 수 있지만, 소프트웨어 보안은 개발 프로세스 개선과 인원들의 인식 변화 등 총체적이고 장기적인 접근이 필요하고, 근본 원인을 분석해야 하며 조직적 변화를 필요로 합니다. 시큐어 소프트웨어는 보안 관련 기능을 수행하는 소프트웨어가 아니라 신뢰성이 위협받는 상황에도 시스템이 신뢰할 수 있는 상태로 유지될 수 있도록 소프트웨어가 보안 약점을 가지지 않는 것을 말하는데요. 시큐어 소프트웨어는 다음과 같은 3가지 속성을 가집니다.

 

소프트웨어 보안 특징

 

5-1. 시큐어 소프트웨어 속성

첫 번째는 신뢰성입니다. 공격이 들어오거나 악의적인 호스트에서 동작하는 상황을 포함한 모든 조건에서 예측 가능한 실행을 하고 올바른 동작을 제공하는 것입니다.

 

두 번째는 신뢰가능성인데요. 신뢰가능성으로 간주되려면 소프트웨어는 악의적 방식으로 구동되는 원인인 악의적인 논리를 포함하지 않아야 합니다.

 

세 번째는 생존성 혹은 회복성입니다. 소프트웨어는 알려진 공격들과 추가로 가능한 많은 새로운 공격들에 대해 저항하고 견디기 충분해야 합니다. 혹여 저항하지 못하고 견디지 못한 공격들에 대해서는 가능한 빨리 회복하여 최대한 적은 손상을 얻을 정도의 회복력을 가져야 합니다.

 

B. 적절한 보안 활동

1. 요구사항 분석 단계

이러한 안전한 소프트웨어를 개발하기 위해 소프트웨어 개발 라이프 사이클에서 수행해야 하는 적절한 보안 활동에 대해 알아보겠습니다. 먼저, 요구사항을 분석하는 단계에서는 요구사항 중에서 보안항목을 식별하고, 보안요구사항 명세서를 작성합니다.

 

1-1. 보안항목 식별

보안항목 식별에서는 중요정보와 보안요구항목을 식별해야 합니다. 중요정보 식별은 법률이나 행정규칙, 사규, 위험도 계산을 통해 암호화되어 저장되거나 전송되어야 하는 정보와 인증이나 인가를 통해 접근해야 하는 정보를 식별하는 것입니다.

 

1-2. 보안요구항목 식별

개인정보보호 관련법규인 개인정보보호법이나, 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 신용정보의 이용 및 보호에 관한 법률 등 다양한 법률이나 법규에서 정의하고 있는 중요정보를 식별합니다. 보안요구항목 식별은 시스템을 구축할 때 반드시 고려해야 하는 입출력 데이터 검증, 인증관리, 권한관리, 세션관리, 자원관리, 중요정보 처리, 안전한 암호화, 감사 기록 및 에러 처리와 같은 보안요구항목들을 식별하는 것입니다.

 

1-3. 행정안전부가 정의한 보안요구항목

행정안전부의 소프트웨어 개발보안 가이드에서는 입력데이터 검증 및 표현, 보안기능, 에러처리, 세션통제, 이렇게 4개 범위의 20개의 보안요구항목을 정의해서 설계단계에 반영하도록 정의하고 있습니다.

 

입력데이터 검증 및 표현 보안요구사항에서는 외부에서 입력된 데이터에 대한 유효성 검증 체계를 갖추고, 실패했을 때 안전하게 처리되게 설계하도록 요구하고 있습니다.

 

보안기능에서는 인증, 접근통제, 권한관리, 비밀번호 등의 정책이 적절하게 반영될 수 있도록 요구하고 있습니다.

 

에러처리에서는 에러가 발생했을 때 안전하게 처리될 수 있도록 요구하고 있습니다.

 

세션통제에서는 HTTP와 같은 클라이언트의 상태를 관리하지 않는 통신의 경우 논리적으로 세션이 안전하게 유지하기 위한 요구사항을 정의하고 있습니다.

 

시큐어코딩 SW 행정안전부가 정의한 보안요구항목

 

2. 설계단계

다음, 설계단계에서는 구축하는 시스템에 발생가능한 위협원들을 미리 도출하는 위협모델링을 통해 안전하게 동작되는 시스템이 설계될 수 있도록 합니다. 또한 보안설계서를 작성하여 검토하며, 보안 통제 계획을 수립하는 활동들이 설계단계에 수행되어야 합니다.

 

2-1. 위협모델링

위협모델링은 대응해야 할 위협을 파악하고 어떻게 대응할 수 있는지를 결정하기 위한 체계적인 방법을 제공하기 위한 것입니다. 위협모델링 활동은 위협모델링을 수행할 팀을 구성하는 것으로 시작됩니다. 이 팀에는 보안전문가, 설계자, 개발자, 테스터 등 다양한 직무의 구성원이 참여하는 것을 권장하고 있습니다. 팀이 구성되면 먼저 애플리케이션을 분해합니다. 즉, 구축하고자 하는 시스템의 기능과 입출력되는 데이터를 파악하는 것입니다. 애플리케이션에 대한 분석이 끝나면 각각의 기능에 발생가능한 위협을 도출합니다.

 

2-2. 위협의 정의

위협은 시스템에 가해지는 공격이라고 볼 수 있습니다. 이렇게 위협이 결정되고 나면 결정된 위협에 대해 위험도를 계산하여 위험도가 높은 위협부터 어떻게 대응할 것인지 결정합니다. 일반적으로 위협에 대한 대응은 위험도에 따라 위협을 완화하거나, 제거하거나, 전가하거나, 수용하는 기법을 선택합니다. 위협에 대한 대응 방법이 정해지고 나면 위협을 완화하거나 제거하기 위해 사용될 기술들을 선정합니다. 이렇게 위협모델링을 통해 시스템이 가질 수 있는 위협원을 식별하고 설계단계에서 이러한 위협이 발생되지 않도록 지원합니다.

 

시큐어코딩 설계단계

 

3. 구현단계

다음으로 구현단계에서는 개발자들이 표준코딩 정의서나 SW 개발보안 가이드를 준수하여 프로그램을 작성하는 시큐어코딩을 적용하도록 하며, 이러한 규칙들이 준수되어 프로그램이 작성되었는지를 보안 약점 진단원이 진단하고 진단결과를 개선하는 보안 활동을 수행합니다. 표준 코딩 정의서나 소프트웨어 개발보안 가이드로 참고할 만한 사이트는 다음과 같습니다.

 

 

3-1. 표준 코딩 정의서 & 개발보안 가이드 참고 사이트

행안부에서는 47개 보안 약점 목록을 선정하여 행정 공공시스템 개발 시 소스코드에서 이러한 보안 약점 제거를 의무화하고 있습니다. SANS TOP 25는 소프트웨어가 가지는 가장 위험한 25개 에러 목록인데요. 애플리케이션 개발 시 최소한 이 25개 보안 약점을 제거할 수 있도록 개발자들은 노력해야 합니다. OWASP CLASP에서는 104개 취약점 목록을 제공하고 있으며, CWE는 1000여 개의 보안 약점 목록을 DB화 해서 해당 보안 약점에 대한 설명과 대응 방법을 제공하고 있습니다. 또한 CERT의 자바 시큐어코딩 표준과 C 시큐어코딩 표준은 각 개발 언어별 안전한 코딩 규칙을 제공하고 있습니다.

 

여기서는 SANS TOP 25 가장 위험한 소프트웨어 에러를 살펴보겠습니다. SANS TOP 25, 가장 위험한 25개의 소프트웨어 에러는 CWE DB의 1000개가 넘는 보안 약점들에 대한 위험도를 계산하여 그중 가장 위험한 25개의 소프트웨어 에러를 목록화한 것입니다. 구성요소 간 안전하지 않은 상호작용은 외부 입력값을 안전하게 검증하지 않고 사용하는 경우 보안위협으로 이어질 수 있는 보안 약점들입니다.

 

a. 행안부 47개 보안약점

https://www.kisa.or.kr/public/laws/laws3.jsp

b. SANS TOP 25 Most Dangerous Software Error

https://www.sans.org/top25-software-errors

c. OWASP CLASP 104개 취약점 목록

https://www.owasp.org/index.php/CLASP_Security_Principles

d. CWE Software Weakness List

https://cwe.mitre.org/

e. CERT Java Secure Coding Standard

https://wiki.sei.cmu.edu/confluence/display/java/Java+Coding+Guidelines

f. CERT C Secure CodingStandard

https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard

 

 

3-2. 보안 약점

그중 가장 위험도가 높은 1위는 SQL인젝션입니다. 외부 입력 값이 검증되지 않고 SQL문에 삽입되어서 쿼리문의 일부로 사용되는 경우입니다. 2위는 마찬가지로 외부 입력 값이 검증되지 않고 명령어의 일부에 삽입되어 실행되는 취약점입니다. 4위는 크로스 사이트 스크립트입니다. 특히 최근에 크립토재킹과 같은 블록체인 채굴을 위해 사용되는 악성코드들은 이 크로스사이트 스크립트 취약점을 많이 활용하고 있어 피해가 커지고 있습니다. 위험한 자원관리는 소프트웨어가 중요한 시스템 리소스에 대해 생성, 사용, 전송, 파괴를 관리하지 않아 발생되는 취약점들입니다.

순위를 보면, 3위의 버퍼오버플로우의 경우 그 위험도가 많이 알려져 있지만 아직도 C계열의 프로그램에서 빈번하게 침해사고의 원인이 되는 보안 약점입니다. 13위에 있는 금지된 디렉터리에 접근을 제한하지 않는 보안 약점도 경로를 조작할 수 있는 특수문자나 인코딩 등이 제대로 필터링되지 않아 허용되지 않은 파일이 노출되는 경우가 많습니다. 18위의 잠재적으로 위험한 함수 사용의 경우도 이미 침해사고의 원인으로 지목된 함수들이 위험한 함수로 분류되어 사용금지 정책을 적용하지 않았거나 또는 사용금지 되어있으나 개발자들이 습관적으로 사용하여 사고가 발생되는 경우가 많습니다.

 

허점이 많은 방어는 인증이나 인가, 암호화 정책 등이 안전하게 수립되어 있지 않아 침해사고의 원인이 되는 보안 약점들입니다. 5위의 핵심기능에 대한 인증누락, 6위의 인가 기능 누락 등은 많은 사고의 원인이 되고 있지만 아직도 완전한 대책이 수립되지 않아 침해사고가 발생되는 경우가 많습니다. 또한 8위와 19위, 25위에 있는 민감한 데이터를 암호화하지 않음, 안전하지 않은 암호화 알고리즘사용, 솔트 없이 일방향 해쉬 사용은 중요정보를 저장하거나 전송하는 경우 반드시 안전한 암호화를 적용하여 처리하도록 하고 있습니다.

 

보안 약점 순위 및 설명

 

 

3-3. 구현단계의 두 번째 보안활동

구현단계의 두 번째 보안활동은 소스 코드 보안 약점 진단 및 개선입니다. 소스 코드나 소프트웨어의 올바른 작성 또는 구현을 검증하는 도구를 이용하여 실행시점이 아닌 컴파일 시점 및 소스 코드 수준에서 검증 가능한 코딩 스타일, API 안전성, 메모리 누수, Null 체크, 보안 약점 항목들을 점검합니다. 국내에서는 CC인증을 받은 진단도구를 활용하여 소스 코드 보안 약점을 진단하고 개선하도록 행정안전부 고시로 규정하고 있습니다. 국내에서 CC 인증을 받은 진단도구로 다음과 같은 것들이 있습니다.

 

구현단계의 보안활동

4. 테스트 단계

구현단계 다음, 테스트 단계에서는 보안전문가들이 도구를 이용한 동적 테스트나 모의 침투테스트를 수행하여 보안 취약점을 진단하고 개선하는 보안활동을 수행합니다. 설계단계에 위협모델링을 수행해서 시스템에 발생가능한 위협들이 식별되어 있다고 한다면 해당 위협들로 인해 시스템이 위험해지지 않는지 검증하는 작업을 이 테스트 단계에서 수행할 수 있습니다.

 

4-1. 모의 침투테스트

테스트 단계에서 수행하는 모의 침투테스트는 합법적으로 허가를 받아 시스템의 보안 취약점이 악용될 수 있는지에 대해 침투 또는 공격을 시도하는 보안 테스트입니다. 프로그래머와 시스템 분석가가 참여하여 침투 테스트를 진행하며, 여기에는 웹 취약점 공격과 같은 외부 공격 가능성뿐만 아니라 비정상적인 접근 및 권한 등 내부의 보안 문제에 대한 시뮬레이션 테스트도 포함됩니다.

 

4-2. 동적 분석

한편, 동적 분석은 소프트웨어를 실행해서 분석하기 때문에 실행 과정 및 결과에 초점을 두고 진행됩니다. 정적 분석에서 발견되지 않는 사용상의 문제점을 발견할 수 있으며 구현된 컴포넌트 간 혹은 설계 및 구조 관점에서 발생 가능한 보안 약점의 검증이 가능하여 정적 분석 기법과 상호 보완적 기능을 수행합니다.

 

소프트웨어 개발보안 사례

5. 유지보수 단계

마지막, 유지보수단계에서는 보안 패치나 지속적인 개선작업이 수행되어야 합니다. 이와 같이 소프트웨어를 개발하는 전체 프로세스에서 각 단계에서 수행해야 하는 보안 활동을 강화하여 안전한 소프트웨어를 만들 수 있도록 해야 합니다.