Secure Software Development
안전한 소프트웨어 개발
- 기한을 맞춰 급급히 Development하고, 충분한 테스팅 없이 Release하는 현업에서는
Penetrate and Patch 전략을 사용한다.
Penetrate and Patch Strategy (침략 후 패치 전략; 소잃고 외양간 고치는 전략)
- 빠른 Development와 Release후, 공격이 발생하면, 그 때 보완하는 방식이다.
- 시장 선점이 매우 중요한 소프트웨어 업계에서 어쩔 수 없이 택해지는 전략이다.
- 또한, 안전한 소프트웨어 개발과 테스팅에는 많은 비용이 들어 더더욱 Penetrate and Patch 전략이 빈번히 사용된다.
- 무수히 많은 Patch가 거듭되면 더욱 완전한 소프트웨어가 만들어질 것이라는 착각이 만연하지만,
오히려 Patch로 인한 Flaw가 발생되어 소프트웨어가 더욱 엉망이 되는 경우가 빈번하다.
Open Source vs Closed Source on Secury (보안 측면에서의 오픈소스와 클로즈소스)
- Open Source와 Closed Source 모델간의 보안적 우위는 존재하지 않으며,
아래와 같은 각각의 옹호자(?)들의 주장이 있을 뿐이다:
| Open Source | Closed Source | |
| Claim | - 더 많은 사람들이 지켜보고 있기 때문에 Flaw가 더욱 많이 개선될 것이다. - Kerchoffs' Principle의 일종 |
- 보안 결함이 노출되지 않는다. - Security by Obscurity의 일종 |
| Counter Question |
- 보안을 신경쓰는 사람이 얼마나 있을 것인가. - 유의깊게 보는 사람이 얼마나 될 것인가. - 보안 전문가가 얼마나 될 것인가. - 공격자 또한 Flaw을 발견할 수 있다. - 공격자가 Evil Code를 삽입할 수 있다. |
- 대부분의 공격은 어차피 Source Code 없이 이루어진다. - SRE등의 분석 기법을 통해 Break될 여지가 있다. - Security by Obscurity가 보안이라 할 수 있는가. |
Example. Open Source: \(\texttt{wu-ftp}\)
- Wasington Univ.에서 개발한 Linux 특정 버전에서 동작하는 8,000 Lines 가량의 FTP Server 프로그램이다.
(FTP 프로그램은 File을 주고받는 Security-Sensitive한 S/W이다.)
- 10년 가량 사용된 이후에야 Flaw가 발견되었다.
(이 사건은 Open Source가 보안 결함을 보완하는데 중요한 역할을 하지 않음을 시사한다.)
Testing on Security (보안 측면에서의 테스팅)
\(E = {K \over t}\)
\(MTBF = {t \over K}\)
| Legend | Description |
| \(E\) | - 테스팅 이후 Security Failure가 발생될 확률 |
| MTBF | - Mean Time between Failure (오류가 발견되기 까지의 평균 시간) |
| \(K\) | - S/W 보안 특성에 따른 상수 |
| \(t\) | - 테스팅 횟수 |
- 즉, 테스팅 횟수(t)가 증가함에 따라 Security가 "선형"으로 증가됨을 알 수 있다.
(많은 테스트가 수행되어야 한다.)
- 개발자는 모든 Flaw를 찾기 위해 노력하지만,
공격자는 단 하나의 Flaw를 찾으려 하기 때문에
근본적으로 공격자가 유리한 위치에 있다.
Example. Calculate \(t\)
- 어떤 S/W에 Security Flaw가 \(10^6\)개가 존재하고, MTBF가 \(10^9\) 시간이라 가정한다면,
하나의 Flaw를 발견하는데 소요되는 테스팅(\(t\)) 시간은 \(10^3\) 시간이다.
- 개발자가 테스팅(\(t\))에 \(10^7\) 시간을 투자한다 가정하면,
개발자는 \(10^7\) / \(10^3\) = \(10^4\) 개의 Flaw를 찾게 되는데, 이는 전체 Flaw(\(10^6\))의 1%밖에 되지 않는 수치이다.
- 공격자는 \(10^3\) 시간만 소요하여 하나의 Flaw를 발견할 수 있다.
Development on Security (보안 측면에서의 개발)
- 보안 측면에서의 개발 과정에서는 궁극적으로, Penetrate and Patch Strategy를 벗어나는 것을 목표로 한다.
- Design
- 초기 설계 단계에서부터 보안에 신중을 기하는 것이 중요하며
High-Level Error는 추후 수정이 불가하거나 비용이 많이 들 수 있어 미연에 방지하는 것이 중요하다.
- IPv4 and IPv6\
(IPv4에는 아무런 Security Mechanism이 Built-In되지 않았으나,
추후 IPv6에서는 IPSec이 Mandatory로 채택되었다.)
- Hazard Analysis
- 발생 가능한 위협을 사전에 파악하여 리스트업하는 방법이다.
(Develop Hazard List, What If List)
- Schneier's Atttack Tree (가능한 공격들을 트리 구조로 구조화해놓은 모델)
- HAZOP (Hazard and Operability Studies)
- FMEA (Failure Modes and Effective Analysis)
- FTA (Fault Tree Analysis)
- Peer Review
- Peer Review는 아래와 같은 Level로 나눌 수 있다:
- Review(Informal)
- Walk-Through(Semi-Formal)
- Inspection(Formal)
- Testing
- Testing은 아래와 같이 테스트 대상에 따라 나눌 수 있다:
- Module Testing (Code의 Small Section)
- Component Testing (몇몇 Module의 Combination)
- Unit Testing (몇몇 Component의 Combination)
- Integration Testing (Everything)
- Testing을 아래와 같이 목적에 따라 나눌 수 있다:
- Function Testing (기능 테스트)
- Performance Testing (성능 테스트)
- Acceptance Testing (고객 참여 테스트)
- Installation Testing (설치 테스트)
- Regressiong Testing (회귀 테스트; 업데이트 이후 수행하는 테스트)
- Active Fault Detection
- 결함이 발생되기 까지 기다리는것이 아닌, 공격자의 자세로 적극적으로 결함 탐지에 임한다.
- Fault Injection
- 의도적으로 결함을 발생시켜 오동작을 유발하여 다른 결함을 찾아낸다.
- Bug Injection
- 버그를 의도적으로 주입하고 버그가 발견되는 수를 파악하여 내재된 버그의 수를 파악한다.
- Non-Security Testing
- 시스템이 해야할 일을 하는가에 대한 테스팅이다.
- Security Testing
- 시스템이 해야할 일을 하고 그 이상의 예상치 못한 일을 하진 않는가에 대한 테스팅이다.
- Configuration
- Flaw는 모든 레벨에서의 변경에서 발생할 수 있음을 견지해야 한다.
- Minor Changes (Maintain Daily Functioning)
- Adaptive Changes (Modifications)
- Perfective Changes (Improvements)
- Preventive Changes (No Loss of Performance)
- Postmortem (사후 분석)
- 공격을 당한 이후, 같은 공격으로 또 같은 피해를 입지 않기 위한 작업이다.
Reference: Information Security: Principles and Practice 2nd Edition
(Mark Stamp 저, Pearson, 2011)
Reference: Computer Security: Principles and Practice 3rd Edition
(William Stallings, Lawrie Brown, Pearson, 2014)
Reference: 2022학년도 1학기 홍익대학교 네트워크 보안 강의, 이윤규 교수님
