1. SDLC(System Development Control)
1. SDLC 방법론
1.1 폭포수 모델(Waterfall Model)
- 특징
> 공정제품의 개발을 근본으로 한 모델
> 공정이 이미 정해져 있으며, 어떤 공정에서 문제가 생겨도 앞의 공정으로 되돌아가는 것이 곤란
> 시스템 개발을 단계별로 나누어 성과를 확인
- 장점
> 개념적으로 자연스럽게 표현
> 단계의 진척 관리가 쉽다
> 각 공정마다 성과물 출력
> 일정관리가 쉬움
> 유사한 시스템의 개발 경험이 있는 경우 효율, 품질 우수
- 단점
> 앞 공정으로 돌아갈수 없다
> 처음 단계에서 지나치게 강조할 경우 코딩, 테스트 작업 지연
> 사용자 요구를 만족하는지 최종 성과물이 완성되어야 판명
> 사용자와 개발자간 오해
1.2 수정 폭포수 모델(Modified Waterfall Model)
- 특징
> 바로 앞 단계로 돌아갈 수 있도록 수정된 폭포수 모델
> 실환경을 제대로 표현할 수 없다는 폭포수 모델 개선
> Validation : 확인(Real-world) / 요구사항 정의 / 올바르게 일을 하고 있는가
> Verification : 검증 / 명세서대로 되고 있는가 / 올바르게 잘 수행 되는가
1.3 원형 모델(Prototyping Model)
- 특징
> 고객이 모르는 경우 시제품(prototype)을 만들어 보여주는 것
> 폭포수 모델의 단점을 보완하기 위해 점진적으로 시스템을 개발함
> 고객의 요구사항을 식별하기 위해 만든 실제 실행되는 시스템
> 만들고자 하는 시스템 기능을 모두 구현할 필요가 없음
> 성능, 보안, 견고함 및 신뢰도와 같은 소프트웨어 특성을 무시
> 변경이 체계적으로 이루어지지 않아 유지보수 힘듦
> 요구사항 명세서를 추출하는 기반으로 사용
- 장점
> 개발자와 사용자의 오해가 규명됨
> 생각지 못하였던 기능과 서비스가 발견됨
> 완전하지 못하지만 작동하는 시스템을 만들어 가능성과 유용성을 관리자에게 보여줌
- 단점
> 재사용이 어려움(조금씩 만들어 보여주니깐)
> 변경관리의 어려움(회의록 작성을 하지 않아서)
1.4 나선형 모델(Spiral Model)
- 특징
> 업무를 개선하는데 사용되는 PDCA주기의 생각을 시스템 개발에 적용
- 장점
> 변경에 대하여 유연하게 대응(문제점을 보완해나감)
> 사용자 요구에 일치된 시스템이 개발될 수 있음
- 단점
> 같은 단계를 반복함으로 공정관리와 개발요원 배치가 복잡
> 프로젝트 관리가 어려워 리스크를 다룰 전문가 필요
> 시간과 비용이 많이 듦
1.5 CBD(Component-based Development)
- 특징
> 컴포넌트(클래스)를 사용 어플리케이션 구성
> 소프트웨어 재사용성을 이끔
1.6 RAD(Rapid Application Development) : 자동화 개발도구를 통한 빠른 개발
1.7 CASE(Computer Aided S/W Engineering) : 컴퓨터를 활용하여 자동화한 방법론
1.8 JAD(Joint Analysis Development) : 워크샵 / 사용자, 고객이 설계에 참가하는 개발 방법론
1.9 Cleanroom : 실수와 오류를 방지하기 위한 접근법 / 고품질의 중요한 어플리케이션
1.10 XP(Extreme Programming) : 단순성, 소통, 피드백 용기 / 실천적인 개발 방법론
2. 소프트웨어 개발 방법론
2.1 프로젝트 착수 및 계획 작성(Project Initiation)
- 프로젝트 개념정의 결정
- 보안의 필요조건 확인
- 초기 위험분석 수행
- 위협 및 대응책 분석
- 보안관리의 관여가 가장 효과적인 시기
2.2 기능적 설계 분석 및 계획(Design Analysis & Planning)
- 프로젝트 계힉 준비 : 보안관련 업무, 테스트 계획, 검증하는 체크포인트 포함
- 보안 요구사항 정의
- 기능관련 요구사항 정의 단계
2.3 시스템 설계 명세(System Design Specification)
- 시스템 상세 설계 개발 : 보안 명세 정의
> 보안 체크리스트
> 테스트 계획 업데이트 -> 변화시 업데이트 지속
> 소프트웨어 기준선(범위) 설정
> 고객과 함께 명세를 검토
2.4 소프트웨어 개발(Software Development)
- 코드개발 작업 시 보안관련 코드 작성 및 설치
- 단위 테스트의 수행 및 평가 : 개발자가 개발품 테스트
- 효율적인 프로그램 조건 : 높은 응집도(cohesion), 낮은 결합도(coupling)
- 재사용성, 유지보수성의 증가
2.5 인수테스트/구현(Acceptance test / Implementation)
- 단위 테스트 후 인수테스트 진행
- 인수 테스트 후 인증(certification)과 인정(accreditation) 과정 수행
> 인증 : 제품기능과 보안기능의 기술적 검토
> 인정 : 경영자의 공식적인 선언 -> 제품에 대해 책임 질것을 수락
- 제품의 문서화(사용자 설명서, 설치 안내서 등)
- 계약의 종류(SLA-서비스 수준계약, ESCROW-제3자 유지보수 계약)
> Escrow 계약시 필요한 것 : 소스코드, 설계문서, 개발 환경정보
=> SDLC의 마지막 단계? (폐기/소멸 단계 > 인정)
=> 변경관리 마지막 단계? 인정
2.6 운용/유지보수(Maintenance / Operation)
- 벤더가 SLA 체결 시 운용 및 유지보수 책임
- 주기적인 감사 : 패치의 실행 전 테스트, 취약성 검사
- 제품 변화가 발생할 경우 인증/인정 절차 수행
- 운영단계에서 발생하는 테스트
(1) 병행테스트 : 서로 다른 시스템간 기능 비교 테스트
(2) 파일럿테스트 : 특정부서 우선 도입 -> 전사확산
(3) 회귀테스트 : 일반적인 기능/패치 업데이트(이전 테스트 항목 포함)
(4) 사회성테스트 : 기존 시스템간 호환성 테스트
- 제품의 설치 및 운영 : Hardenning(경화) -> Simple(단순화) : 불필요한 기능은 제거
3. 소프트웨어 성숙도 모델(CMM)
- 특징
> 정보기술 프로세스 능력 평가 및 개선 모델
> 각 성숙도 단계별 이행하여야 할 핵심 프로세스 및 각 프로세스별 이행방법(수준)을 제시
- 필요성
> 프로세스 개선에 대한 로드맵 제공
> 국제 표준이 되고 있음
> 일부 프로젝트의 경우 CMM레벨을 요구
- 기대효과
> 프로세스 개선 소요비용, 훈련비용 절감
> 생산성 향상(시행착오 최소화), 품질 오차율 감소, 개발소요기간 감소, ROI 향상
- 성숙도 모델 단계
(1) 1단계(초기) : 작업자의 능력에 의한 성과, 프로세스, 예산, 기간 예측할 수 없음, 관리 빈약
(2) 2단계(반복) : 성공한 사례를 반복, 프로젝트 가이드 제시
(3) 3단계(정의) : 프로세스 정의, 정형화, 문서화, 프로젝트에 맞도록 수정
(4) 4단계(관리) : 수치로 나타나는 품질 목표가 설정, 평가
(5) 5단계(최적) : 프로세스 혁신에 초점, 지속적인 프로세스 리엔지니어링
4. 변화 제어 / 관리(Change Control & Management)
- 변화 제어 및 관리 보안 이슈
> 데이터의 무결성에 의존
> 변경은 보안 모델을 훼손
> 시스템 변경은 벤더가 제공하는 보증 수준을 훼손
> 보안관리자에 의하여 변화 요청이 시스템에 주는 영향에 대해 분석/평가 중요
> 모든 변경은 철처히 검토/승인되고, 테스트되며, 기록되어야 함
(Changes must be authorized, tested & recorded)
> 변경된 시스템은 인증 및 인가과정을 거쳐야 한다
> 변경통제에서 마지막 단계는 인정
'STUDY > CISSP' 카테고리의 다른 글
| [CISSP] Domain8_Software Development Security (3/4) (0) | 2019.04.01 |
|---|---|
| [CISSP] Domain8_Software Development Security (2/4) (0) | 2019.04.01 |
| [CISSP] Domain7_Security Operations (6/6) (0) | 2019.04.01 |
| [CISSP] Domain7_Security Operations (5/6) (0) | 2019.04.01 |
| [CISSP] Domain7_Security Operations (4/6) (0) | 2019.04.01 |
