소프트웨어 보안 사고의 약 75%는 소프트웨어 취약점으로 인해 발생한다. 또한, 제품 출시 후 결함 수정 비용은 설계 단계의 수정 비용보다 30배 이상 많다. 이러한 배경에서, 시큐어 코딩은 유지 보수 문제를 해결하는 방법 중 하나로 제안되었다. 다양한 연구 기관에서는 소프트 웨어 보안 약점의 표준 양식을 제시하고 있다. 새로운 한글 프로그래밍 언어 새싹은 언어 수준에서 보안 약점 해결 방법을 제안하였다. 그러나 이전 연구의 새싹은 API에 관한 보안 약점을 해결하지 못하였다. 본 논문에서는 API에 의한 보안 약점을 해결하는 방법을 제안한다. 이 논문에서 제안하는 방법은 새싹에 위험한 메소드를 검사하는 정적 분석기를 적용하는 것이다. 위험한 메소드는 오염된 데이터 유입 메소드와 오염된 데이터 사용 메소드로 분류한다. 분석기는 위험한 메소드 탐색, 호출 그래프 구성, 호출 그래프를 바탕으로 유입 메소드와 사용 메소드간의 경로 탐색, 검출된 보안 약점 분석 순으로 4단계에 걸쳐 보안 약점을 분석한다. 이 방법의 효율성을 측정하기 위해 정적 분석기를 적용한 새로운 새싹을 이용하여 두 가지 실험을 실행하였다. 첫 번째 실험으로서 이전 연구의 새싹과 개선된 새싹을 Java 시큐어 코딩 가이드를 기준으로 비교하였다. 두 번째 실험으로써 개선된 새싹과 Java 취약점 분석 도구인 FindBugs와 비교하였다. 결과에 따르면, 개선된 새싹은 이전 버전의 새싹보다 15% 더 안전하고 개선된 새싹의 F-measure는 68%로써 FindBugs의 59%인 F-measure와 비교해 9% 포인트 증가하였다.
소프트웨어 보안 사고의 약 75%는 소프트웨어 취약점으로 인해 발생한다. 또한, 제품 출시 후 결함 수정 비용은 설계 단계의 수정 비용보다 30배 이상 많다. 이러한 배경에서, 시큐어 코딩은 유지 보수 문제를 해결하는 방법 중 하나로 제안되었다. 다양한 연구 기관에서는 소프트 웨어 보안 약점의 표준 양식을 제시하고 있다. 새로운 한글 프로그래밍 언어 새싹은 언어 수준에서 보안 약점 해결 방법을 제안하였다. 그러나 이전 연구의 새싹은 API에 관한 보안 약점을 해결하지 못하였다. 본 논문에서는 API에 의한 보안 약점을 해결하는 방법을 제안한다. 이 논문에서 제안하는 방법은 새싹에 위험한 메소드를 검사하는 정적 분석기를 적용하는 것이다. 위험한 메소드는 오염된 데이터 유입 메소드와 오염된 데이터 사용 메소드로 분류한다. 분석기는 위험한 메소드 탐색, 호출 그래프 구성, 호출 그래프를 바탕으로 유입 메소드와 사용 메소드간의 경로 탐색, 검출된 보안 약점 분석 순으로 4단계에 걸쳐 보안 약점을 분석한다. 이 방법의 효율성을 측정하기 위해 정적 분석기를 적용한 새로운 새싹을 이용하여 두 가지 실험을 실행하였다. 첫 번째 실험으로서 이전 연구의 새싹과 개선된 새싹을 Java 시큐어 코딩 가이드를 기준으로 비교하였다. 두 번째 실험으로써 개선된 새싹과 Java 취약점 분석 도구인 FindBugs와 비교하였다. 결과에 따르면, 개선된 새싹은 이전 버전의 새싹보다 15% 더 안전하고 개선된 새싹의 F-measure는 68%로써 FindBugs의 59%인 F-measure와 비교해 9% 포인트 증가하였다.
About 75% of software security incidents are caused by software vulnerability. In addition, the after-market repairing cost of the software is higher by more than 30 times than that in the design stage. In this background, the secure coding has been proposed as one of the ways to solve this kind of ...
About 75% of software security incidents are caused by software vulnerability. In addition, the after-market repairing cost of the software is higher by more than 30 times than that in the design stage. In this background, the secure coding has been proposed as one of the ways to solve this kind of maintenance problems. Various institutions have addressed the weakness patterns of the standard software. A new Korean programming language Saesark has been proposed to resolve the security weakness on the language level. However, the previous study on Saesark can not resolve the security weakness caused by the API. This paper proposes a way to resolve the security weakness due to the API. It adopts a static analyzer inspecting dangerous methods. It classifies the dangerous methods of the API into two groups: the methods of using tainted data and those accepting in-flowing tainted data. It analyses the security weakness in four steps: searching for the dangerous methods, configuring a call graph, navigating a path between the method for in-flowing tainted data and that uses tainted data on the call graph, and reporting the security weakness detected. To measure the effectiveness of this method, two experiments have been performed on the new version of Saesark adopting the static analysis. The first experiment is the comparison of it with the previous version of Saesark according to the Java Secure Coding Guide. The second experiment is the comparison of the improved Saesark with FindBugs, a Java program vulnerability analysis tool. According to the result, the improved Saesark is 15% more safe than the previous version of Saesark and the F-measure of it 68%, which shows the improvement of 9% point compared to 59%, that of FindBugs.
About 75% of software security incidents are caused by software vulnerability. In addition, the after-market repairing cost of the software is higher by more than 30 times than that in the design stage. In this background, the secure coding has been proposed as one of the ways to solve this kind of maintenance problems. Various institutions have addressed the weakness patterns of the standard software. A new Korean programming language Saesark has been proposed to resolve the security weakness on the language level. However, the previous study on Saesark can not resolve the security weakness caused by the API. This paper proposes a way to resolve the security weakness due to the API. It adopts a static analyzer inspecting dangerous methods. It classifies the dangerous methods of the API into two groups: the methods of using tainted data and those accepting in-flowing tainted data. It analyses the security weakness in four steps: searching for the dangerous methods, configuring a call graph, navigating a path between the method for in-flowing tainted data and that uses tainted data on the call graph, and reporting the security weakness detected. To measure the effectiveness of this method, two experiments have been performed on the new version of Saesark adopting the static analysis. The first experiment is the comparison of it with the previous version of Saesark according to the Java Secure Coding Guide. The second experiment is the comparison of the improved Saesark with FindBugs, a Java program vulnerability analysis tool. According to the result, the improved Saesark is 15% more safe than the previous version of Saesark and the F-measure of it 68%, which shows the improvement of 9% point compared to 59%, that of FindBugs.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
본 논문에서는 해결하지 못한 보안 약점 중 API를 사용하여 발생하는 보안 약점을 해결하는 방안을 제안한다. API에 의한 보안 약점은 API의 메소드 형식이 정해져 있기 때문에 프로그래밍 언어 차원에서는 해결하기 어렵다.
소프트웨어를 구성하는 모든 클래스에서 오염된 데이터 유입 메소드와 오염된 데이터 사용 메소드가 있는지 탐색한다. 각각의 메소드 코드가 위험한 메소드에 대한 호출을 포함하는지 탐색한다.
그러므로 새싹의 보안 약점을 분석하기 위해서는 새싹용 취약점 분석기가 필요하다. 이에 본 논문에서는 정적 분석 방법을 사용하여 새싹의 보안 약점을 분석하는 취약점 분석기를 개발한다.
제안 방법
소프트웨어를 구성하는 모든 클래스에서 오염된 데이터 유입 메소드와 오염된 데이터 사용 메소드가 있는지 탐색한다. 각각의 메소드 코드가 위험한 메소드에 대한 호출을 포함하는지 탐색한다. Fig.
개발한 개선된 새싹의 안전성을 평가하기 위해 두 번의 실험을 시행하였다. 처음에는 이전 연구의 새싹과 비교를 하고 두 번째는 FindBugs와 비교하였다.
그러므로 본 논문에서는 보안 약점이 발생할 수 있는 Java API를 조사하여 위험한 메소드 목록을 구성하고 오염 분석[26]을 통해 보안 약점을 분석한다. 구체적으로 위험한 메소드 호출 탐색, 호출 그래프 구성, 유입 메소드와 사용 메소드 간 경로 탐색, 보안 약점 분석 순으로 4단계 분석 과정을 수행한다.
API는 사용하는 형식이 정해져 있고 API의 코드 내부를 확인하기 어려우므로 프로그래밍 언어 수준에서 문법적으로 API에 의한 보안 약점을 해결하기 어렵다. 그러므로 본 논문에서는 보안 약점이 발생할 수 있는 Java API를 조사하여 위험한 메소드 목록을 구성하고 오염 분석[26]을 통해 보안 약점을 분석한다. 구체적으로 위험한 메소드 호출 탐색, 호출 그래프 구성, 유입 메소드와 사용 메소드 간 경로 탐색, 보안 약점 분석 순으로 4단계 분석 과정을 수행한다.
예를 들면, 데이터 통신에서 수신한 데이터를 검증 없이 사용하면 사용한 기능에 따라 사용자가 원치 않는 동작을 할 수 있다. 그러므로 우리는 보안 약점이 발생할 수 있는 API의 메소드를 조사하고 오염된 데이터를 유입하는 API와 오염된 데이터 사용하는 API로 분류한다. 오염된 데이터 유입 API는 Table 1과 같이 데이터 통신의 수신, 파일 읽기 등과 같이 외부에서 데이터를 가져오는 API다.
먼저, 위험한 API를 조사해 유입 메소드와 사용 메소드로 분류한다. 그리고 4단계에 걸쳐 분석한다. 먼저, 위험한 메소드를 탐색하고 저장한다.
이전 연구에서 우리는 한글 프로그래밍 언어 새싹을 개발하였다[12]. 그리고 행정자치부에서 제시한 Java 시큐어 코딩 가이드의 보안 약점을 재분류하고 프로그래밍 언어 수준에서 보안 약점을 해결하기 위해 예약어를 제공하였다[13]. 그리고 새싹은 행정자치부에서 제시한 Java 시큐어 코딩 가이드의 보안 약점 83개 중 33개를 해결하였다.
처음에는 이전 연구에서 프로그래밍 언어 수준에서 보안 약점을 해결한 새싹과 개선된 새싹을 비교한다. 두 번째는 취약점 정적 분석기인 FindBugs와 개선된 새싹을 비교한다.
보안 약점 검출은 코드 배열을 바탕으로 분석한다. 분석기는 애플리케이션 코드 내에 존재하는 유출 가능한 경로에 대해 병렬적으로 보안 약점 분석을 실행한다. 보안 약점 검출은 메소드에 따라 단계별로 진행되고 코드 배열 내의 모든 메소드를 실행했을 때 마지막에 오염 데이터 사용 메소드에 오염된 데이터가 전달되는지 확인한다.
그리고 FindBugs는 새싹과 같이 JVM에서 동작하기 때문이다. 비교에 사용할 테스트 코드로는 CWE/SANS Top 25[13]의 항목별로 Juliet(Ver. 1.2)[29, 30]과 CWE에서 제공하는 예제 코드를 참고하여 Java와 새싹으로 각각 보안 약점 코드 2개와 정상 코드 1개를 직접 작성하였다. 단, CWE/SANS Top 25의 항목 중 3, 20, 23번은 C, C++에서만 발생하는 보안 약점으로 새싹과 Java에서는 발생하지 않기 때문에 제외하였다.
그리고 새싹 테스트 코드 66개를 새싹에서 분석을 수행한다. 수행 결과를 재현율(recall)과 정밀도(precision), F-measure를 비교한다. 비교 결과는 Table 5와 같다.
오염된 데이터 유입 API를 네트워크, 파일, 시스템으로 분류한다. 그리고 오염된 데이터 사용 API는 네트워크, DB, 파일, 시스템으로 분류한다.
API에 의한 보안 약점은 API의 메소드 형식이 정해져 있기 때문에 프로그래밍 언어 차원에서는 해결하기 어렵다. 이에 우리는 보안 약점이 발생할 수 있는 API를 조사하고, 정적 분석 방법을 통해 조사한 API를 사용하여 데이터를 조작하거나 사용한 경우 보안 약점으로 판단한다. 제안한 방식의 성능 평가를 위해 보안 약점 분석기 FindBugs와 비교 실험하였다.
이전 연구의 새싹과 개선된 새싹의 안전성을 비교하기 위해 이전 연구에서 제안한 시큐어 코딩 가이드[25]를 바탕으로 해결한 보안 약점의 수를 비교한다. 제안한 시큐어 코딩 가이드의 보안 약점은 행안부에서 제안한 Java 시큐어 코딩 가이드를 바탕으로 구성하였다.
이전 연구의 새싹과 개선된 새싹의 안전성을 비교하기 위해 이전 연구에서 제안한 시큐어 코딩 가이드[25]를 바탕으로 해결한 보안 약점의 수를 비교한다. 제안한 시큐어 코딩 가이드의 보안 약점은 행안부에서 제안한 Java 시큐어 코딩 가이드를 바탕으로 구성하였다.
개발한 개선된 새싹의 안전성을 평가하기 위해 두 번의 실험을 시행하였다. 처음에는 이전 연구의 새싹과 비교를 하고 두 번째는 FindBugs와 비교하였다. 첫 번째 실험의 결과, 이전 연구의 새싹은 83개의 보안 약점 중 33개를 해결한데 비해 개선된 새싹은 46개를 해결하였다.
호출 그래프를 바탕으로 오염된 데이터 유입 메소드 노드와 오염된 데이터 사용 메소드 노드를 잇는 경로를 탐색한다. 경로 탐색 알고리즘은 Dijkstra의 최단 경로 탐색 알고리즘을 사용한다.
그리고 저장한 메소드를 바탕으로 호출 그래프를 구성한다. 호출 그래프의 경로를 탐색하고 보안 약점 분석을 통해 보안 약점을 탐지한다.
대상 데이터
단, CWE/SANS Top 25의 항목 중 3, 20, 23번은 C, C++에서만 발생하는 보안 약점으로 새싹과 Java에서는 발생하지 않기 때문에 제외하였다. 그러 므로 테스트 코드는 보안 약점 코드 44개와 정상 코드 22개로 총 66개다.
비교 실험은 작성한 Java 테스트 코드 66개를 FindBugs에서 분석을 수행한다. 그리고 새싹 테스트 코드 66개를 새싹에서 분석을 수행한다. 수행 결과를 재현율(recall)과 정밀도(precision), F-measure를 비교한다.
개선된 새싹은 이전 연구의 새싹보다 위험 코드 검출률이 15% 포인트 증가하였다. 두 번째 실험으로는 결함 코드 44개를 포함한 테스트 코드 66개를 FindBugs와 새싹에서 수행하였다. 그 결과 FindBugs의 F-measure는 59%이고 새싹의 F-measure는 68%다.
데이터처리
비교 실험은 작성한 Java 테스트 코드 66개를 FindBugs에서 분석을 수행한다. 그리고 새싹 테스트 코드 66개를 새싹에서 분석을 수행한다.
이에 우리는 보안 약점이 발생할 수 있는 API를 조사하고, 정적 분석 방법을 통해 조사한 API를 사용하여 데이터를 조작하거나 사용한 경우 보안 약점으로 판단한다. 제안한 방식의 성능 평가를 위해 보안 약점 분석기 FindBugs와 비교 실험하였다.
이론/모형
CWE/SANS Top 25는 일반적인 수행 환경을 위한 주요 보안 약점 목록으로서 2009년부터 25개의 주요 보안 약점을 선발하여 발표하고 있으며, 2011년에 가장 최근 버전이 발표되었다[15]. 2011년에는 중요 보안 약점의 선별을 위하여 중요도 정량평가 방법인 CWSS(Common Weakness Scoring System)가 사용되었다.
호출 그래프를 바탕으로 오염된 데이터 유입 메소드 노드와 오염된 데이터 사용 메소드 노드를 잇는 경로를 탐색한다. 경로 탐색 알고리즘은 Dijkstra의 최단 경로 탐색 알고리즘을 사용한다. 경로를 찾으면 코드 배열을 구성한다.
성능/효과
첫 번째 실험의 결과, 이전 연구의 새싹은 83개의 보안 약점 중 33개를 해결한데 비해 개선된 새싹은 46개를 해결하였다. 개선된 새싹은 이전 연구의 새싹보다 위험 코드 검출률이 15% 포인트 증가하였다. 두 번째 실험으로는 결함 코드 44개를 포함한 테스트 코드 66개를 FindBugs와 새싹에서 수행하였다.
두 번째 실험으로는 결함 코드 44개를 포함한 테스트 코드 66개를 FindBugs와 새싹에서 수행하였다. 그 결과 FindBugs의 F-measure는 59%이고 새싹의 F-measure는 68%다. 즉, 새싹의 위험 코드 검출률이 9% 포인트 증가했다고 볼 수 있다.
그러나 이는 보안 측면에서는 더 강화된 경고를 주는 것으로 생각할 수 있다. 재현율과 정밀도의 조화평균인 F-measure는 FindBugs가 59%, 새싹이 68%로 나타났다.
즉 개선된 새싹은 해결 취약점 개선 측면에서 이전 연구의 새싹보다 15% 안전하다고 볼 수 있다. 전체적으로 시큐어 코딩 가이드에 따라 점검해야 하는 취약점 수가 55%나 줄어들었다.
Table 5에서 볼 수 있는 것처럼 보안 약점 코드 44개 중 FindBugs에서는 20개를 검출한 데 비해, 새싹은 24개를 검출하였다. 즉, FindBugs의 재현율은 45%인데 비해 새싹의 재현율은 59%인 것을 확인하였다. 새싹이 FindBugs보다 재현율이 높은 이유는 프로그래밍 언어 수준에서 보안 약점을 해결하였기 때문으로 보인다.
처음에는 이전 연구의 새싹과 비교를 하고 두 번째는 FindBugs와 비교하였다. 첫 번째 실험의 결과, 이전 연구의 새싹은 83개의 보안 약점 중 33개를 해결한데 비해 개선된 새싹은 46개를 해결하였다. 개선된 새싹은 이전 연구의 새싹보다 위험 코드 검출률이 15% 포인트 증가하였다.
후속연구
향후 연구로는 FindBugs보다 정밀도를 높이기 위한 연구를 생각해 볼 수 있다. 새싹은 CWE/SANS Top 25의 항목에서 위험한 종류의 파일 업로드, 무결성 검사 없이 코드 내려받기와 같이 파일의 위험성과 관련된 보안 약점을 해결 하지 못하였다.
질의응답
핵심어
질문
논문에서 추출한 답변
분석기는 어떤 순서로 보안 약점을 분석하는가?
위험한 메소드는 오염된 데이터 유입 메소드와 오염된 데이터 사용 메소드로 분류한다. 분석기는 위험한 메소드 탐색, 호출 그래프 구성, 호출 그래프를 바탕으로 유입 메소드와 사용 메소드간의 경로 탐색, 검출된 보안 약점 분석 순으로 4단계에 걸쳐 보안 약점을 분석한다. 이 방법의 효율성을 측정하기 위해 정적 분석기를 적용한 새로운 새싹을 이용하여 두 가지 실험을 실행하였다.
FindBugs는 무엇인가?
첫 번째 실험으로서 이전 연구의 새싹과 개선된 새싹을 Java 시큐어 코딩 가이드를 기준으로 비교하였다. 두 번째 실험으로써 개선된 새싹과 Java 취약점 분석 도구인 FindBugs와 비교하였다. 결과에 따르면, 개선된 새싹은 이전 버전의 새싹보다 15% 더 안전하고 개선된 새싹의 F-measure는 68%로써 FindBugs의 59%인 F-measure와 비교해 9% 포인트 증가하였다.
정적 분석기를 적용한 새로운 새싹을 이용하여 수행한 두가지 실험은 무엇인가?
이 방법의 효율성을 측정하기 위해 정적 분석기를 적용한 새로운 새싹을 이용하여 두 가지 실험을 실행하였다. 첫 번째 실험으로서 이전 연구의 새싹과 개선된 새싹을 Java 시큐어 코딩 가이드를 기준으로 비교하였다. 두 번째 실험으로써 개선된 새싹과 Java 취약점 분석 도구인 FindBugs와 비교하였다. 결과에 따르면, 개선된 새싹은 이전 버전의 새싹보다 15% 더 안전하고 개선된 새싹의 F-measure는 68%로써 FindBugs의 59%인 F-measure와 비교해 9% 포인트 증가하였다.
참고문헌 (30)
MSIP, SPRI, Software Industry Annual Report, 2014.
I. H. Kim, Facebook users private information leaked six million people [Internet], http://news.inews24.com/php/news-_view.php?g_serial754079&g_menu020600.
A. Buncombe, "Sony Pictures hack: US intelligence chief says North Korea cyberattack was 'most serious' ever against US interests," The Independent, 2015.
S. W. Lee, "Study on the information system aduit check list for enhanced privacy," MS. dissertation, Konkuk University, Seoul, ROK, 2015.
T. Lanowitz, "Now is the time for security at the application level," Gartner, 2005.
G. Tassey, "The economic impacts of inadequate infrastructure for software testing," National Institute of Standards and Technology, RTI Project 7007, 2002.
J. McManus and D. Mohindra, The CERT Sun Microsystems Secure Coding Standard for java [Internet], http://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId34669015.
OWASP, Welcome to OWASP [Internet], https://www.owasp.org/index.php/Main_Page.
CWE, A community Developed Dictionary of Software Weakness Types [Internet], http://cwe.mitre.or/.
JSF, The F-35 Lightning II Program [Internet], http://www.jsf.mil/.
MISRA, The Motor Industry Software Reliability Association [Internet], http://www.misra.org.uk/.
J. S. Cheon, D. H. Kang, and G. Woo, "A Concise Korean Programming Language Sprout," Journal of KIISE, Vol.42, No.4, pp.496-503, 2015.
D. H. Kang, Y. E. Kim, and G. Woo, "A Study on Improving Runtime Safety of a Sprout through Analysis of Java Secure Coding Guide," Proc. of the KIISE Korea Computer Congress 2015, pp.1751-1753, 2015.
OWASP, "OWASP Top 10-2013," The Ten Most Critical Web Application Security Risks, 2013.
B. Martin, M. Brown, A. Paller, and D. Kirby. "2011 CWE/SANS top 25 most dangerous software errors," Common Weakness Enumeration, 2011.
HP, IT Security in the Idea Economy [Internet], https://www.hpe.com/us/en/solutions/security.html.
IBM, IBM Security AppScan [Internet], http://www-03.ibm.com/software/products/en/appscan.
FindBugs, FindBugs because it's easy [internet], http://findbugs.sourceforge.net/findbugs2.html.
N. Ayewah, W. Pugh, J. D. Morgenthaler, J. Penix, and Y. Q. Zhou, "Evaluating static analysis defect warnings on production software," Proceedings of the 7th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, ACM, pp.1-8, 2007.
Evenstar, BigLook is the financial and enterprise security weaknesses SW diagnostic system optimized for enterprise environments [Internet], http://www.evenstar.co.kr/index-.php.
Trinitysoft, The Trinitysoft is committed to providing the best Web application security solutions [Internet], http://www.trinitysoft.co.kr/page/solution_04.
GTONE, SecurityPrism is secure coding solution to ensure safe application since the early stages of development [Internet], http://www.gtone.co.kr/main/ag/sp.php.
Fasoo, SPARROW is a source code analysis tool, using static analysis [internet], http://www.fasoo.com/site/fasoo/sourcecodeanalysis/sparrow.do.
Y. E. Kim, J. W. Song, and G. Woo, "A Design of a Korean Programming Language Ensuring Run-Time Safety through Categorizing C Secure Coding Rules," Journal of KIISE, Vol.42, No.4, pp.487-495, 2015.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.