0. 개요
Secure Software Development 란 무엇인가?
일반적으로 SW개발은 "Penetrate and Patch" 방식으로 개발됨
: 빠르게 배포, 어느정도 테스팅 해보고 릴리즈
특히, 게임의 경우 릴리즈 날짜를 정해놓고, 그 날에 죽이되든 밥이되든 릴리즈 하는게 일반적이며, 버그는 사용자들이 리포트(피드백)해줄 것으로 기대
=> 이상적이지 않으나 현실적으로 대부분 이런 방식을 사용
1. Secure SW Development
1) Why Penetrate and Patch?
- 시장 선점이 핵심임 (>버그로 인한 불편함)
- 어려우니깐 (안전한 SW를 개발하는 과정은 Costly하므로)
(기능 구현을 우선으로 하는 현실) - P&P로 해도 economic disincentive는 없다
2) Fallacy of P&P
: Patch하다보면 완벽해 질 것이라는 막연한 생각
=> 이 patch라는 것은 변화가 생기는 것
=> 멀쩡한 부분에 결함이 생길 수도 있다
=> 즉 점진적으로 100%로를 채워나간다고 보는 것과는 거리가 있다
3) Open source vs Closed
어느게 더 안전할까?
e.g.
- linux (open source)
- windows (closed sw)
=> 별 차이가 없다.
ⓘ Open Source
- 더 많은 사람이 지켜보므로, 더 안전할 수도 있긴함
- 얼마나 많은 전문가들이 이 오픈소스의 보안성을 책임질건가. 그 중 공격자도 있을 수 있고.... 여러 concerns
② closed
- 공격자들이 소스코드를 못봄 (은폐에 의한 보안 only)
- but. 소스코드 없어도 뚫을 수 있음(SRE)
※ 도찐개찐! : 둘다 장단점이 존재
※ open/closed 보다 어떤 프로세스로 개발되느냐가 핵심
※ 왜 Microsoft가 자주 target? : big target (사용자 다수)
2. Software Development
※ open, closed 보다 중요한 것은 어떤 프로세스로 개발되었냐가 보안을 확보하는데 핵심
(goal) go away from P&P
S/W Development
- specify
- design
- implement
- test
- review
- document
- manage
- maintain
각 개발 단계마다 security 향상시킬 수 있는 부분이 존재
1) Design
: 최대한 design단계 서부터 critical issue를 찾아내기 위해 노력
정형 혹은 비정형 검증을 통해 검증을 수행
① 정형 검증 (Formal Verification)
: 수학적인 증명과 논리적 추론을 사용하여 S/W의 검증을 수행. 오류를 찾아내기 위해 가능한 모든 실행 경로를 탐색하고, 수학적 증명을 통해 S/W의 명세를 만족하도록
② 비정형 검증 (Informal Verification)
: 테스트 케이스, 시나리오, 사용자 경험, 지식을 기반으로 한 경험적인 S/W 검증 방법
=> 참고로, 아키텍쳐 검증은 매우 어렵다.. (상당한 경험과 지식을 필요로함)
2) Hazard Analysis
: 위험 분석, 위험 모델링
best case와 worst case를 고려해서 위험 list를 미리 작성 및 파악
인지를 한 후 개발을 해라
- 다양한 정형 접근 방식이 존재
3) Peer Review (상호 검토) ★
- informal 검토 : 비정형적, 옆 사람에게 봐달라고
- walk-through(semi-formal) : 팀 단위 리뷰(팀장님or관계자)
- inspection : 개발 회의 소집하여 검토
4) Testing
: Testing이 사실 핵심
① Levels of Testing
- module
- component
- unit
- integration
=> 주관적 단위이므로 프로젝트 규모를 고려하여 Testing 계획을 수립할 것
② Purpose of Testing ★
- Function testing
- Performance testing
- acceptance testing : 고객이 참여한 테스팅
- Installation testing
- Regression testing
- strength testing : 맥시멈 리소스를 쓰고 서버의 부하 정도를 체크
=> 결론은 다양한 testing을 수행
③ 기타 테스팅 이슈
- Active fault detection : 결함 발생을 기다리지 말고 적극적으로 찾을 것
- Fault Injection : 비정상적인 input과 같은 결함 주입
- Bug Injection : 겉으로는 정상적으로 보이나 버그 발생 여지가 있는 코드 주입
※ 참고
약 20만줄의 loc를 가진 system의 결함 발생 빈도를 조사한 결과
대다수의 결함이 integration testing 단계에서 발생
④ Security Testing
: Security Testing은 Non-Security Testing보다 더 많은 것을 검증해야함
-
Security Testing : does system so what it is supposed to do and nothings more?
-
Non-Seuciryt Testing : does system so what it is supposed to do?
※ 결론
: 가능한 많은 다양한 testing을 수행해야함
5) Configuration
: 여러가지 change가 존재 > 이후에 보안적 문제 발생 가능성
6) Postmortem (사후분석)
: 문제 발생 시 실패로부터 배운다
※ 결론
시장선점을 간과할 수 없다. 그래서 일반적으로 P&P방식을 사용
BUT 개발 과정에서 줄일 수 있는 요소들은 최대한 제거하면서 개발을 잘 할수 있다.
결국 목적은 보안적 이슈와 결함을 100%없애는 것이 아니라 minimize하려는 노력
- 이런걸 chatgpt가 해줄 순 없다!! (고급 인력의 개발자가 되어야하는 이유라고도 할 수 있다)
