secure coding guidelines in koreac7%d1%b1... · 2012-03-20 · secure coding guidelines in korea...
TRANSCRIPT
Secure Coding Guidelines in Korea
’10.6.22(화)
정보화전략실정보보호정책과
韓 根熙
2韓根熙
1. 프롤로그
2. 소프트웨어 오류·결함 사례
3. 소프트웨어 안전성을 위한 보안정책
4. 맺음말
목 차
3韓根熙
전자신문 ’10.2.1 CIO Biz 6면
4韓根熙
소프트웨어 보안취약점 사전검사
소프트웨어 사고
5韓根熙
6韓根熙
Application
Network
Database Server
Web Server
Application Server
Operating System
75 % of hacks occur at the application level
애플리케이션 취약점을 이용한 공격
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)
* 출처 : Gartner, “Now is the time for security at Application Level”, 2006.12
사이버 위협 동향
7韓根熙
웹 애플리케이션 해킹 - 홈페이지 대중화로 대응에 한계
기존 알려진 공격에 대해서는 효과적으로 차단 가능(Black List 기반) Black List의 신속한 업데이트가 관건이고 필수 1세대 웹 공격(단순 도구를 이용한 웹 공격)에는 효과적이나 2세대 공격(웹 지식 및 도구 이용)에는
무력
DB
DB
Web app.
Hacker
Web app.
Web app.
Web app.
Web Server
Web Client
방화벽 웹 서버 웹 애플리케이션 데이터베이스
웹 브라우저IDS (Intrusion Detection System)
Telnet, FTP, NETBIOS, RPC…
* SQL InjectionID:AdminPWD: ‘ or 1=1 --
사이버위협 동향
8韓根熙
가장 위험한 프로그래밍 에러 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/
9韓根熙
가장 위험한 프로그래밍 에러 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
소프트웨어 오류·결함 사고
11韓根熙
S/W 품질을 떨어뜨리는 요인
개발 환경으로 인한 문제점 이 기종 환경에서 개발
다양한 Platform 과 빠른 변화
Short Time-to-Market 버그 발견의 어려움
더욱더 복잡해지는 시스템으로 인한 버그 점점 더 새로운 기능의 추가
복잡한 코딩 기법으로 인해 가독성이 떨어짐
Legacy Code의 사용으로 인한 버그
개발자로 인한 문제점 버그잡는 것을 QA의 문제라는 인식 (Coding단계에서 접근 필요)
여러명의 S/W Develop engineer 가 함께 개발
S/W Develop engineer 간의 편차
다양한 언어와 많은 코드량으로 인한 Code Inspection의 어려움
12韓根熙
소프트웨어 문제 발생 요소 소프트웨어 복잡도
현대의 소프트웨어는 매우 복잡하게 얽혀 있다. 소프트웨어에서 결함과의 관계는 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 ]
13韓根熙
Software related Accidents
1996년 6월 4일
Ariane 5 Rocket
64 → 16 bit 변환시 overflow 발생
발사 40초 만에 폭발
총 손실액 8억 6천만 달러
14韓根熙
1994년 인텔 펜티엄 CPU
부동소숫점 연산 오류
1995년 미 덴버공항 수하물
시스템 오류 -개항지연
2005년 미 FBI VCF 프로젝트 실패$170 million
1996년 타이탄 로켓 발사실패
Software related Accidents
15韓根熙
버그의 원인과 결과
프로그램 수행 중 발생한 에러는 우리가 예상하지 못한 곳에서 발생할 수도 있다.
왜 여기서 죽는지알 수가 없다!(당연하다,버그는 여기 없으므로)
SSS
SSS SS
RR R
X
RRXX
XXS
S
버그발생
버그 발생 자료 계속 수행
Unhandled ExceptionSegmentation FaultAccess ViolationUndefined Behavior
증식
오류 (Bug)
16韓根熙
프로그램 개발 오류
설계 단계에서부터 취약점을 고려하지 않고 구축된 웹 어플리케이션에대한 취약점 수정은 신규 개발보다 더욱 막대한 비용과 시간 소요
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시간/어플리케이션
17韓根熙
소프트웨어 오류 문제점
프로그래머가 작성한(코딩한) 프로그램(코드)에는 많은 오류가 있다
이러한 오류는 테스팅에 의해 발견이 되지만, 발견이 안된 오류가 많이 있고,
이러한 기능성 오류는 프로그램 사용 중에 발견이 되고,
수정에 많은 시간/비용이 소모된다.
더욱 중요한 것은 사용중인 프로그램에 내재된 오류는 기능성의 문제를 야기시킬 뿐만이 아니라, 보안성에 중요한 문제인 프로그램 취약성(=보안 취약성)을 야기한다. 이러한 취약성에 의한 비용은 기능성 오류비용보다 훨씬 더 막대하고
심각한 위협을 초래할 것으로 예측된다.
18韓根熙
에러의 의한 비용
미 상무성 산하 국립기술표준연구소(NIST) 조사 자료(2002. May)
설계과정에서 만들어지는 에러가 개발완료 후에 발견된다면, 설계단계에서 에러를 수
정하는 비용보다 30배 추가지출 발생
통합과정에서 만들어지는 에러가 개발완료 후에 발견된다면, 통합과정에서 수정하는
비용보다 20배 추가지출 발생.
− ※출처 : http://www.nist.gov/director/prog-ofc/report02-3.pdf
• The Economic Impacts of Inadequate Infrastructure for Software Testing
설치 단계 발견
코딩 단계발견
통합 단계 발견
베타제품에서 발견
개발완료/제품출시 후 발견
설계과정 에러 1x 5x 10x 15x 30x
코딩과정 에러 1x 10x 20x 30x
통합과정 에러 1x 10x 20x
19韓根熙
정보보호 취약성 수정 비용
IBM사 연구결과
운영단계에서 보안 취약성을 제거하기 위해서는 설계 단계에서 제거하는 것보다 60~100배 추가비용 소요.
초기에 보안 원칙을 고려하지 않고 설계함에 따라 운영 단계에서는 각 요소별 파급효과로 조치가 어려운 상황이 되기도 함
※ 출처: IBM System Sciences Institute, Implementing Software Inspections, 1981
20韓根熙
171 345 311 262 417
1,090
2,437
4,1293,784 3,780
5,990
8,064
7,236
6,058
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
5500
6000
6500
7000
7500
8000
8500
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
알려진 소프트웨어 총 취약점 개수(1995~2008) : 44,074
CERT/CC에 보고된 소프트웨어 취약점(1995~2008)[자료출처 :http://www.Secunia.com - Vulnerability Information ‘1995~’08]
소프트웨어 취약점
21韓根熙
Software Test Timing
Requirement요구사항 분석
ArchitectureDesign
개발 필요사항분석
Design소프트웨어
디자인
Coding코드 작성
Acceptance Test시제품 테스트
System Test
Integration Test소프트웨어 통합
테스트
Unit Test지정된
Unit 단위의테스트
Modeling
이 단계부터계획하면금상첨화
S/W Test의필요성을느끼는 시기
늦었다
S/W Test가필요한 시기
주기적 점검필요
SW 결함을 발견하는 시점이 빠르면 빠를 수록 결함 수정 비용이 줄어듦
22韓根熙
Remarks by Bill Gates17th 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.”
23韓根熙
개발단계에서 오류 사전검사 이점
소프트웨어 안전성을 위한보안 정책
25韓根熙
소프트퉤어 안전성 향상
26韓根熙
소프트웨어 보안정책
27韓根熙
코딩 규칙
28韓根熙
세계적으로 통용되는 코딩규칙
29韓根熙
취약한 코드의 예 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.
30韓根熙
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”.
취약점 제거한 Secure Coding
31
CVE.mitre.org
NDV.nist.gov
www.first.org/CVSS
CAPEC.mitre.org
CWE.mitre.org
Secure
Coding
(Standard)
www.securecoding.cert.org
Secure Coding Standard
32
CERT/CC Secure Coding Standard
– C Secure Coding Standard
– JAVA Secure Coding Standard
– C++ Secure Coding Standard (개발중)
Secure Coding Standard
33韓根熙
• 정보화사업 및 정보보호 관련 제도∙정책 분석
• 선진국 정보시스템 구축 및 관리 체계 제도 분석
•정보화사업에 시범적용 방안 마련
법·제도 개선
기획/계획
수립
사업자
선정/계약 개발/구축 감리 검사 /종료
정보시스템
취약성
자동진단체계
소프트웨어 취약성 DB구축
언어별 자동진단도구 개발
자동진단도구 적용
국내외 S/W 개발모델 분석
정보화사업용 보안개발 모델
교육 · 홍보
S/W 보안개발 모델소프트웨어 취약성 자동진단시스템
전자정부서비스 소프트웨어 취약성 자동진단 정책
34韓根熙
소스 파일(Java, C ...)
소스코드 취약점 검사(Data Flow, Control Flow, Semantic, Configuration,
X-Tier Tracking)
Buffer OverflowsSQL InjectionCross-Site ScriptingAccess ControlProcess ControlNo Null TerminationSetting ManipulationResource InjectionPasswords in Config FilesUnreleased Resource
안전한 코딩 규칙, 패턴,언어별 취약점 DB
Unreleased ResourceFormat String IssuesPrivacy ViolationsNative CalloutUnsafe Memory OperationUnchecked Return ValueAlways Unsafe FunctionsRace ConditionsUninitialized Variable
소스코드
JAVA, JSP, PHP, C, C++ ...
소프트웨어 취약성 자동진단시스템
진단 결과 보고서
35韓根熙
프로젝트 별 결함 밀도
0.00
5.00
10.00
15.00
20.00
25.00
30.00
코드소나 결함 밀도 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
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ Total
결함 검출 활동
소프트웨어 개발단계 별 결함 검출활동으로 수집된 결함 데이터를 DB화하여 조직의 통합 DB
로 구축 관리하여 이를 분석하고 개선하는 활동을 수행함
동료검토M&SCode
Inspection
정적Testing
동적Testing
<프로젝트 별 결함 DB>
효과 검증
및 개선점 식별
6.489.77
A Pjt
A Status Defect Density
4.01
B pjtR&D 전체
Defect DB
Defect DB
소프트웨어 취약성 DB 구축
36韓根熙
언어별소스코드
취약점 조사/분류
OWASP
국내·외 취약성 목록 사례
우선순위 선정을위한 취약점정도 계량화
언어별/구현별안전한 코딩
규칙·패턴 정의
···
취약점 종류별검출 기술 및난이도 구분
입력
소프트웨어 취약성 DB
소프트웨어 취약성 DB 구축
37韓根熙
입력
소스코드 검사(서버)
결과 조회
설정관리
보고서
검사 결과 통계
검사 결과 평가소스코드 검사 엔진
Java, JSP, C, C++ … Parser
취약점 분석 엔진
Security Knowledge
Pattern Analysis
설정정보 검사결과
저장소
관리 (클라이언트)
소프트웨어취약점 DB
소스코드(Java, C …)
Weakness Analysis
자동진단도구
소프트웨어 취약성 자동진단도구
38韓根熙
설계(Design)
개발(Coding)
평가(Testing)
적용(Deploying)
개발 단계에서 개발자가자신이 추가한 코드에 대해점검하여 논리적 취약점을
제거
개발 모듈 점검 시실질적으로 발생하는취약점에 대해 해커의
관점에서 점검
실 환경 적용 상태에서의보안 취약점을 점검
Black-Box 테스트는 실제 웹 사이트의 보여지는모습에 대한 점검으로 해커의 공격과 같은 형태
White-Box 테스트는 개발자들이 지켜야 할개발상의 함수 처리 등의 규정에 대한 검증으로개발 가이드라인에 해당하는 점검임
구분 설계단계 개발단계 테스트 단계 운영단계
대응책 보안요구 리스트 보안 프로그램 가이드 프로그램 검사 침해사고 대응 및 모의해킹
White BoxBlack Box
단계별 보안관리
신규개발 사이트에 대한 관리
39韓根熙
웹 보안 스캐너
코드 수정(Coding)
평가(Testing)
갱신(Updating)
소스코드 분석도구웹 보안 스캐너
감사(Audit)
개발된 사이트는 운영 중 지속적으로 변경됨
운영자에 의한 서버 설정 변경
사용자 요청(업무 변경)에 의한 페이지 수정
오류 페이지에 대한 지속적 수정
사이트가 지속적으로 변경됨에 따라 일정 주기 단위로 감사를 수행해야 함
발견된 취약점에 대한코드 수정
개발자가 직접수정된 페이지에 대해보안 취약점 평가 수행
전체 사이트의보안 취약점을 재평가하여
적절한 수정이이루어졌는지 평가
(Optional)
보안 담당자에 의해주기적인 감사를 수행최초 Deployment에서변경된 사항들에 대한
취약점 점검 수행
운영 중인 사이트에 대한 관리
단계별 보안관리
