Secure Coding Guidelines in Korea 10.6.22( 화 ) 정보화전략실 정보보호정책과
목차 1. 프롤로그 2. 소프트웨어오류 결함사례 3. 소프트웨어안전성을위한보안정책 4. 맺음말 2
전자신문 10.2.1 CIO Biz 6 면 3
소프트웨어보안취약점사전검사 4
소프트웨어사고 5
사이버위협동향 애플리케이션취약점을이용한공격 Security is many things to many people Network Layer ID Theft Physical Administrative Patches Infrastructure Denial-of-Service Attacks Hacks Worms and Viruses Terrorism (Cyber or Physical) Network Application Database Server Web Server Application Server Operating System 75 % of hacks occur at the application level * 출처 : Gartner, Now is the time for security at Application Level, 2006.12 6
사이버위협동향 웹애플리케이션해킹 - 홈페이지대중화로대응에한계 기존알려진공격에대해서는효과적으로차단가능 (Black List 기반 ) Black List 의신속한업데이트가관건이고필수 1 세대웹공격 ( 단순도구를이용한웹공격 ) 에는효과적이나 2 세대공격 ( 웹지식및도구이용 ) 에는무력 Hacker 웹브라우저 Web Client Telnet, FTP, NETBIOS, RPC * SQL Injection ID:Admin PWD: or 1=1 -- IDS (Intrusion Detection System) Web Server Web app. Web app. Web app. Web app. 방화벽웹서버웹애플리케이션데이터베이스 DB DB 7
가장위험한프로그래밍에러 Top 25 09.1.12 SANS, MITRE, CWE, CERT, 美국가안보국, Microsoft, 시만텍등 30개이상의단체가함께가장위험한프로그래밍에러 25개를선정 SANS와 MITRE Corp. 가주관한프로젝트 The Top 25 Errors 는보안버그로이어지며사이버스파이행위및사이버범죄를가능케하는프로그래밍에러를선정해벤더들이소프트웨어가판매되거나설치되기전에에러를제거하고자하는목적으로진행 3 파트로구분 구성의불안전한상호작용 9개 위험한리소스관리 9개 Porous Defenses( 통기성방어 ) 7개 SANS 소장 Mason Brown 이제 ( 프로그래밍에러들을 ) 수정할때가왔다 우선, 모든프로그래머들이에러탑 25에서벗어난코드를작성하는법을알아야만하며, 모든프로그래밍팀은문제를발견하고수정, 또는피할수있는프로세스를갖추고이러한에러들로부터벗어난그들의코드를인증하기위한툴을갖춰야만한다 http://www.sans.org/top25errors/ 8
가장위험한프로그래밍에러 Top 25 Insecure Interaction Between Components These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems. CWE-20: Improper Input Validation CWE-116: Improper Encoding or Escaping of Output CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection') CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting') CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection') CWE-319: Cleartext Transmission of Sensitive Information CWE-352: Cross-Site Request Forgery (CSRF) CWE-362: Race Condition CWE-209: Error Message Information Leak Risky Resource Management The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources. CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer CWE-642: External Control of Critical State Data CWE-73: External Control of File Name or Path CWE-426: Untrusted Search Path CWE-94: Failure to Control Generation of Code (aka 'Code Injection') CWE-494: Download of Code Without Integrity Check CWE-404: Improper Resource Shutdown or Release CWE-665: Improper Initialization CWE-682: Incorrect Calculation Porous Defenses The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored. CWE-285: Improper Access Control (Authorization) CWE-327: Use of a Broken or Risky Cryptographic Algorithm CWE-259: Hard-Coded Password CWE-732: Insecure Permission Assignment for Critical Resource CWE-330: Use of Insufficiently Random Values CWE-250: Execution with Unnecessary Privileges CWE-602: Client-Side Enforcement of Server-Side Security 9
소프트웨어오류 결함사고
S/W 품질을떨어뜨리는요인 개발환경으로인한문제점 이기종환경에서개발 다양한 Platform 과빠른변화 Short Time-to-Market 버그발견의어려움 더욱더복잡해지는시스템으로인한버그 점점더새로운기능의추가 복잡한코딩기법으로인해가독성이떨어짐 Legacy Code의사용으로인한버그 개발자로인한문제점 버그잡는것을 QA의문제라는인식 (Coding단계에서접근필요 ) 여러명의 S/W Develop engineer 가함께개발 S/W Develop engineer 간의편차 다양한언어와많은코드량으로인한 Code Inspection의어려움 11
소프트웨어복잡도 소프트웨어문제발생요소 현대의소프트웨어는매우복잡하게얽혀있다. 소프트웨어에서결함과의관계는 LOC (Lines Of Code) KLOC(Kilo Lines Of Code) 당 5에서 15개정도의버그발견 복잡도는보안의적이다 Paul Kocher (Cryptography Research, Inc.) 새로개발되는자동차는아폴로우주선을달에착륙시키는데필요한것보다더많은 LOC 를가지고있음. System LOC Year Windows 2000 < 29,000,000 2000 Windows XP 40,000,000 2001 Windows Server 2003 50,000,000 2003 Debian 4.0 283,000,000 2005 Mac OS X 10.4 86,000,000 Linux Kernel 2.6.0 5,200,000 Linux Kernel 2.6.29 11,000,000 NetScape 17,000,000 우주왕복선 10,000,000 보잉 777 7,000,000 [ 자료출처 : http://en.wikipedia.org/wiki/source_lines_of_code ] 12
Software related Accidents 1996년 6월 4일 Ariane 5 Rocket 64 16 bit 변환시 overflow 발생발사 40초만에폭발총손실액 8억 6천만달러 13
Software related Accidents 1994 년인텔펜티엄 CPU 부동소숫점연산오류 1995 년미덴버공항수하물 시스템오류 - 개항지연 1996 년타이탄로켓발사실패 $170 million 2005 년미 FBI VCF 프로젝트실패 14
오류 (Bug) 버그의원인과결과 프로그램수행중발생한에러는우리가예상하지못한곳에서발생할수도있다. S S X S X S 버그발생 증식 S X S S X S X 버그발생자료계속수행 R R R Unhandled Exception Segmentation Fault Access Violation Undefined Behavior 왜여기서죽는지알수가없다! ( 당연하다, 버그는여기없으므로 ) 15
프로그램개발오류 설계단계에서부터취약점을고려하지않고구축된웹어플리케이션에대한취약점수정은신규개발보다더욱막대한비용과시간소요 Source Code 1000 라인당 5 ~ 15 개의취약성존재 US Dept. of Defense, Software Engineering Institute 41 개의취약성을찾는데평균 75 분이소요되고, 1 개의취약성을제거하는데 2~9 시간소요 5 Year Pentagon Study 한사람의개발자가하나의취약성을찾는데 10 분이소요되며, 4200 개의취약성을찾는데 700 시간 (17.5 주 ) 이소요 Intel White paper, CERT, ICSA Labs 1000 개의서버를보유한기관에서 1 주동안취약성을테스트하고패치하는데소요되는비용이 $300,000 비즈니스어플리케이션은평균 150,000 ~ 250,000 라인의코드로구성 Software Magazine 200,000 라인 /1000 라인 x 15 개취약점 x 5 시간 = 15,000 시간 / 어플리케이션 16
소프트웨어오류문제점 프로그래머가작성한 ( 코딩한 ) 프로그램 ( 코드 ) 에는많은오류가있다 이러한오류는테스팅에의해발견이되지만, 발견이안된오류가많이있고, 이러한기능성오류는프로그램사용중에발견이되고, 수정에많은시간 / 비용이소모된다. 더욱중요한것은사용중인프로그램에내재된오류는기능성의문제를야기시킬뿐만이아니라, 보안성에중요한문제인프로그램취약성 (= 보안취약성 ) 을야기한다. 이러한취약성에의한비용은기능성오류비용보다훨씬더막대하고심각한위협을초래할것으로예측된다. 17
에러의의한비용 설치단계발견 코딩단계발견 통합단계발견 베타제품에서발견 개발완료 / 제품출시후발견 설계과정에러 1x 5x 10x 15x 30x 코딩과정에러 1x 10x 20x 30x 통합과정에러 1x 10x 20x 미상무성산하국립기술표준연구소 (NIST) 조사자료 (2002. May) 설계과정에서만들어지는에러가개발완료후에발견된다면, 설계단계에서에러를수정하는비용보다 30배추가지출발생통합과정에서만들어지는에러가개발완료후에발견된다면, 통합과정에서수정하는비용보다 20배추가지출발생. 출처 : http://www.nist.gov/director/prog-ofc/report02-3.pdf The Economic Impacts of Inadequate Infrastructure for Software Testing 18
정보보호취약성수정비용 IBM 사연구결과 운영단계에서보안취약성을제거하기위해서는설계단계에서제거하는것보다 60~100 배추가비용소요. 초기에보안원칙을고려하지않고설계함에따라운영단계에서는각요소별파급효과로조치가어려운상황이되기도함 출처 : IBM System Sciences Institute, Implementing Software Inspections, 1981 19
소프트웨어취약점 8500 8000 8,064 7500 7,236 7000 6500 6000 5500 5000 알려진소프트웨어총취약점개수 (1995~2008) : 44,074 5,990 6,058 4500 4000 4,129 3,784 3,780 3500 3000 2500 2,437 2000 1500 1000 500 171 345 311 262 417 1,090 0 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 CERT/CC 에보고된소프트웨어취약점 (1995~2008) [ 자료출처 :http://www.secunia.com - Vulnerability Information 1995~ 08] 20
Software Test Timing Requirement 요구사항분석 Architecture Design 개발필요사항분석 Modeling 이단계부터계획하면금상첨화 S/W Test 의필요성을느끼는시기 늦었다 System Test Acceptance Test 시제품테스트 Design 소프트웨어디자인 Coding 코드작성 S/W Test 가필요한시기 주기적점검필요 Integration Test 소프트웨어통합테스트 Unit Test 지정된 Unit 단위의테스트 SW 결함을발견하는시점이빠르면빠를수록결함수정비용이줄어듦 21
Remarks by Bill Gates 17th Annual ACM Conference on Object-Oriented Programming, Seattle, Washington, November 8, 2002 When you look at a big commercial software company like Microsoft, there's actually as much testing that goes in as development. We have as many testers as we have developers. Testers basically test all the time, and developers basically are involved in the testing process about half the time We've probably changed the industry we're in. We're not in the software industry; we're in the testing industry, and writing the software is the thing that keeps us busy doing all that testing. The test cases are unbelievably expensive; in fact, there's more lines of code in the test harness than there is in the program itself. Often that's a ratio of about three to one. 22
개발단계에서오류사전검사이점 23
소프트웨어안전성을위한 보안정책
소프트퉤어안전성향상 25
소프트웨어보안정책 26
코딩규칙 27
세계적으로통용되는코딩규칙 28
취약한코드의예 Authorization Bypass boolean authenticated = false; String query = SELECT Username FROM Users WHERE Username = + strusername + AND Password = + strpassword + ; if (getqueryresult(query) == ) authenticated = false; else authenticated = true; Attack: Login: OR = Password: OR = Resulting query: SELECT Username FROM Users WHERE Username = OR = AND Password = OR = The attacker is validated as if she is the legitimate first user in the DB table. 29
취약점제거한 Secure Coding Boolean authenticated = false; String query = SELECT Username FROM Users WHERE Username = + addslash(strusername) + AND Password = + addslash(strpassword) + ; if (getqueryresult(query) == ) authenticated = false; else authenticated = true; Attack: Login: OR = Password: OR = Resulting query: SELECT Username FROM Users WHERE Username = \ OR \ \ =\ AND Password = \ OR \ \ =\ This query is now gives an error message, There is no such user. 30
Secure Coding Standard NDV.nist.gov CWE.mitre.org Secure Coding (Standard) CVE.mitre.org www.first.org/cvss www.securecoding.cert.org 31 CAPEC.mitre.org
Secure Coding Standard CERT/CC Secure Coding Standard C Secure Coding Standard JAVA Secure Coding Standard C++ Secure Coding Standard ( 개발중 ) 32
전자정부서비스소프트웨어취약성자동진단정책 소프트웨어취약성 DB 구축 국내외 S/W 개발모델분석 언어별자동진단도구개발 정보시스템 취약성 자동진단체계 정보화사업용보안개발모델 자동진단도구적용 교육 홍보 소프트웨어취약성자동진단시스템 S/W 보안개발모델 기획 / 계획 수립 사업자선정 / 계약개발 / 구축감리검사 / 종료 법 제도개선 정보화사업및정보보호관련제도 정책분석 정보화사업에시범적용방안마련 선진국정보시스템구축및관리체계제도분석 33
소프트웨어취약성자동진단시스템 소스파일 (Java, C...) 소스코드 JAVA, JSP, PHP, C, C++... 소스코드취약점검사 (Data Flow, Control Flow, Semantic, Configuration, X-Tier Tracking) 안전한코딩규칙, 패턴, 언어별취약점 DB 진단결과보고서 Buffer Overflows SQL Injection Cross-Site Scripting Access Control Process Control No Null Termination Setting Manipulation Resource Injection Passwords in Config Files Unreleased Resource Unreleased Resource Format String Issues Privacy Violations Native Callout Unsafe Memory Operation Unchecked Return Value Always Unsafe Functions Race Conditions Uninitialized Variable 34
소프트웨어취약성 DB 구축 소프트웨어개발단계별결함검출활동으로수집된결함데이터를 DB 화하여조직의통합 DB 로구축관리하여이를분석하고개선하는활동을수행함 M&S 동료검토 Code Inspection 정적 Testing 동적 Testing 결함검출활동 A Status Defect Density 30.00 25.00 프로젝트별결함밀도 9.77 6.48 R&D 전체 Defect DB A Pjt 4.01 B pjt 20.00 15.00 10.00 5.00 0.00 1 2 3 4 5 6 7 8 9 Total 코드소나결함밀도 5.83 3.56 2.70 7.67 8.21 6.25 5.78 8.70 2.12 5.65 QAC/C++ 결함밀도 23.10 3.78 6.50 2.12 8.88 전체결함밀도 5.83 26.66 6.48 7.67 14.72 6.25 5.78 8.70 5.82 9.77 Defect DB < 프로젝트별결함 DB> 효과검증 및개선점식별 35
소프트웨어취약성 DB 구축 국내 외취약성목록사례 OWASP 입력 소프트웨어취약성 DB 언어별소스코드취약점조사 / 분류 우선순위선정을위한취약점정도계량화 취약점종류별검출기술및난이도구분 언어별 / 구현별안전한코딩규칙 패턴정의 36
소프트웨어취약성자동진단도구 자동진단도구 소스코드검사 ( 서버 ) 관리 ( 클라이언트 ) 소스코드 (Java, C ) 소프트웨어취약점 DB 입력 소스코드검사엔진 Java, JSP, C, C++ Parser 취약점분석엔진 검사결과평가 설정관리 검사결과통계 결과조회 Weakness Analysis Security Knowledge Pattern Analysis 보고서 저장소 설정정보 검사결과 37
단계별보안관리 신규개발사이트에대한관리 설계 (Design) 개발 (Coding) 평가 (Testing) 적용 (Deploying) White Box White-Box 테스트는개발자들이지켜야할개발상의함수처리등의규정에대한검증으로개발가이드라인에해당하는점검임 개발단계에서개발자가자신이추가한코드에대해점검하여논리적취약점을제거 Black-Box 테스트는실제웹사이트의보여지는모습에대한점검으로해커의공격과같은형태 개발모듈점검시실질적으로발생하는취약점에대해해커의관점에서점검 Black Box 실환경적용상태에서의보안취약점을점검 구분설계단계개발단계테스트단계운영단계 대응책보안요구리스트보안프로그램가이드프로그램검사침해사고대응및모의해킹 38
단계별보안관리 운영중인사이트에대한관리 개발된사이트는운영중지속적으로변경됨 운영자에의한서버설정변경 사용자요청 ( 업무변경 ) 에의한페이지수정 오류페이지에대한지속적수정 사이트가지속적으로변경됨에따라일정주기단위로감사를수행해야함 웹보안스캐너 소스코드분석도구 웹보안스캐너 감사 (Audit) 코드수정 (Coding) 평가 (Testing) 갱신 (Updating) 보안담당자에의해주기적인감사를수행최초 Deployment 에서변경된사항들에대한취약점점검수행 발견된취약점에대한코드수정 개발자가직접수정된페이지에대해보안취약점평가수행 전체사이트의보안취약점을재평가하여적절한수정이이루어졌는지평가 (Optional) 39
Question & Answer 정보화전략실정보기반정책관정보보호정책과 02-2100-3628 keunhee@mopas.go.kr