1. 소프트웨어 요구사항
- 기능적 요구사항 : 시스템이 수행해야 하는 구체적인 기능이나 동작을 명시 ("무엇을 하는가")
- 비기능적 요구사항 : 시스템의 품질과 제약 사항 등을 명시 ("어떻게 하는가")
- 1) Security(안전) : 시스템의 데이터 및 기능을 보호하기 위한 정의
- 2) Capacity(용량) : 처리 가능한 성능 및 데이터 작업량 정의
- 3) Compatibility(호환성) : 시스템, 플랫폼, 환경의 확장성 정의
- 4) Reliability (신뢰성) : 정해진 조건하에 안정적인 기능 수행 정의
- 5) Maintainability (유지 보수성) : 시스템 운영 중 수선, 개선 용이성 정의
- 6) Scalability (확장성) : 시스템 부하 증가시 효율적인 처리 정의
- 7) Usability (사용성) : 사용자가 효율적으로 시스템 사용 정의
2. 보안 개발 방법론
-
소프트웨어 개발 전 단계에 걸쳐 보안을 고려 => 안전한 소프트웨어를 개발하기 위한 체계적인 방법론
-
소프트웨어 개발 생명 주기 (SDLC) 각 단계별로 보안 활동을 통합한 프로세스
-
비기능 요구사항으로서의 보안 : 기능의 정상적인 동작을 보장하면서 추가적으로 고려해야하는 품질 요소
-
설계단계에서 보안 개발 필요한 이유 : 설계 단계에서 보안 항목을 반영하지 않으면 이후 구현 단계에서 소프트웨어 일관성이 떨어지거나, 단순 수정을 통해 보안 항목을 만족 시킬 수 없는 경우 발생
-
소프트웨어 생명 주기 각 단계별 보안 활동
-
개발 단계 핵심 보안 활동 요구사항 분석 보안 요구사항 식별 및 정보 보안 등급 결정 설계 위협 모델링 수행 및 설계 반영 구현 보안 코딩 가이드 준수 및 코드 리뷰 수행 테스트 동적 분석 및 모의 침투 테스트 수행 유지보수 취약점 모니터링 및 보안 사고 대응 수행
3. 위협 모델링
- 시스템 설계 단계에서 잠재적인 보안 위협을 예측 및 분석하고 효과적인 통제를 구현
- 위협 모델링 프로세스 : 자산 식별 => 위협 식별 => 취약점 분석 => 위험 평가 => 대응 방안 수립
- 자산 식별 : 보호가 필요한 시스템 내의 자산을 식별
- 위협 식별 : 자산에 위해를 가할 수 있는 잠재적인 위협을 찾기 위해 공격 표면, 신뢰 경계 및 그 외의 다양한 접근 방식을 통해 위협을 식별
- 취약점 분석 : 식별된 위협이 발편될 수 있는 취약점을 분석
- 위험 평가 : 식별된 위협과 취약점이 조직에 미치는 영향과 발생 가능성을 정량적, 정성적으로 평가
- DREAD 모델 : Damage(손해정도), Reproducibility(재현성), Exploitability (악용 용이성), Affected users (영향받는 사용자 수), Discoverability
- 대응방안 수립 : 평가된 위험에 대해 수용 가능한 수준으로 통제하기 위해 기술적, 관리적, 물리적 대책을 수립
4. 보안 개발 방법론 적용 사례 MS-SDL
- 마이크로소프트가 제품 개발에 보안 원칙을 체계적으로 통합하기 위해 만든 보안 개발 프로세스
- SDLC에 Tranining(교육)단계, Response(대응)이 추가됨
- 교육 -> 요구사항 -> 설계 -> 구현 -> 검증 -> 배포 -> 대응
5. 개발 보안 방법론 - 구조적 완화 전략
- 1) 공격 표면 최소화 : 시스템이 외부로 노출되어 공격자가 접근할 수 있는 모든 진입점(인터페이스, 서비스, 포트, API, 파일 업로드 등)의 총합을 줄이는 것
- SDP (Software Defined Perimeter) : 네트워크 자원을 외부에서 볼 수 없게 숨기고 인증된 사용자만이 접근할 수 있도록 제공하는 제로 트러스트 기반의 보안 아키텍처
- 2) Narrow Vulnerability Window : 소프트웨어나 시스템이 취약 상태 (취약점 존재 => 패치가 적용되기 전)로 열려 있는 기간을 최대한 짧게 유지하는 전략.
6. 개발 보안 방법론 - 망분리
-
업무망(사내 시스템)과 인터넷망(외부망)을 물리적·논리적으로 분리하여 내부 자산 노출과 외부 침해 위험을 줄이는 보안 방법.
-
장점
• 외부 인터넷으로부터의 직접 침해 경로 차단 → 공격 표면 감소
• 내부 중요 시스템에 대한 접근 통제 강화 -
단점
• 시스템 운영/ 관리 부담 증가 - 최신 보안 패치 어려움
• 업무 불편성 증가
• 우회경로 발생 가능성
• 내부자 공격 취약 -
경계기반 모델 (Perimeter-based)
• 내부는 신뢰, 외부는 불신으로 가정
• 내부 위협(권한 남용, 내부자 공격)에 취약
• 클라우드·원격근무·BYOD 환경에 적합하지 않음 -
ZTA (Zero Trust Architecture)
• “Never trust, always verify” 원칙
• 모든 요청에 대해 강력한 인증·인가 수행
• 마이크로세그멘테이션, 최소권한 접근, 소프트웨어 정의 경계 적용
• 망분리의 문제(내부 신뢰 가정)를 보완 가능
7. SBOM (Software Bill of Materials)
- 소프트웨어가 포함하는 구성요소(오픈소스 라이브러리, 서드파티 모듈 등)를 목록화한 문서
— 공급망 취약점 관리에 사용. - 단점
- 추적의 한계 존재
- SBOM 표준 및 도구 부족
- 추가적인 전문 인력 및 추가 리소스가 필요하여 중소 기업 등에 적용이 어려움
