[CISSP] SDLC, 소프트웨어 개발 방법론 단계별, 성숙도 모델(CMM), 변경통제

cissp 자격증 취득 및 보안 전반 study note로, 무단 복제 및 배포를 금함

Domain8 Software Development Security 8-2

 

 

II. 소프트웨어 개발 방법론

 **전 과정에서 고려해야 하는 요소: 보안

 

1. Project Initiation and planning

>개념적 정의

2. Functional requirements definition

>기능요구사항 정의

>시스템 환경 사양 정의

3. System Desing Specification

>시스템 기능 설계

>상세한 기능 분할

>사전 설계

>코드 설계

4. Development and implementation

>프로그래밍 & 문서화

5. Documentation and common program controls

>프로그래밍 & 문서화

6. Testing and Evaluation Controls

>Test Data

>Data Validation

>Bounds Checkings

7. Certification and Accreditaion

>인증

>인정/인가

8. Transition to Production

>운영 이관

9. Revision/Replacement/Destruction

>개정/대치/폐기

 

 

 

 

---

**출제 비율이 굉장히 높으므로, 단계별로 세세하게 파악해야 함

1. 프로젝트 착수 및 계획 작성(Project Initiation and planning) >개념적 정의

-프로젝트의 개념 정의 결정: 1st 비즈니스의 목적 이해

-보안의 필요조건 확인: ex)인증강화, 통신구간 암호화 등 

-초기 위험분석 수행

-위협 및 대응책 분석: ex) 단말기 분실(위협) ——> 원격 초기화(대응책: 분실 단말기를 무력화 시킴)

-보안관리의 관여가 가장 효과적인 시기: 초기 단계에서 관리 시, 비용대비 효과 극대화

 

 

2. 기능적 요구사항 정의(Functional requirements definition) >기능요구사항 정의 >시스템 환경 사양 정의

-프로젝트 계획 준비: 보안 관련 업무 및 테스트 계획 등

-보안 요구사항 정의

-기능관련 요구사항 정의 단계

 

 

3. 시스템 설계 명세(System Desing Specification) >시스템 기능 설계 >상세한 기능 분할 >사전 설계 >코드 설계

-시스템 상세 설계 개발 - 보안 명세 정의

-보안 체크리스트

-테스트 계획의 업데이트: 프로젝트 진척에 따라 테스트 계획은 그에 맞추어 업데이트 되어야 함

-소프트웨어의 기준선(baseline) 설정 = 범위

             >보안의 수준=baseline : Acceptable Risk Level에 맞춘 기준선 설정 필요

-제품이 필요한 보안수준을 제공할 것이라는 명세를 고객과 함께 검토

 

 

4. 소프트웨어 개발(Development and implementation) >프로그래밍 & 문서화

 4.1 소프트웨어 개발(Software Development): 코드 개발 작업 시에 보안 관련 코드가 작성/설치 됨

-단위 테스트의 수행 및 평가: 개발자가 직접 수행

-효율적인 프로그램의 조건: 높은 응집도(Cohesion), 낮은 결합도(Coupling=의존도), 재사용성, 유지보수성의 증가

-기존 secure coding에서 Security Design Architecture으로, 즉 설계 단계에서 보안이 들어가야 한다는 추세**

 

 

5. 제품의 문서화(Documentation and common program controls) >프로그래밍 & 문서화

 제품의 문서화(사용자 설명서, 설치 안내서, 참고자료 등): 운영절차, 재시작/복구 절차, 로그정책, 변경관리 등

 5.1 계약의 종류

-SLA(Service Level Aggrement): 벤더가 고객과 SLA를 체결 할 경우, 운용 및 유지보수의 책임

-ESCROW

  SW구매 계약은 '현 시점'에서 일어남 ------> S/W 유지보수 계약은 '미래시점' 기준으로 유지보수 미이행 위협이 존재함

**대응책: 소스코드 설계문서, OS 정보, 컴파일러 버전 등 개발 환경에 대한 정보를 제 3자 기업에 위탁 보관하는 제도

 

 

6. Testing and Evaluation Controls  >Test Data >Data Validation >Bounds Checkings

 

7. Certification and Accreditaion

>인증(certification): 제공자의 주장-기술적으로 인증기관에서 검토하는 것=인증

>인정/인가(accreditation): 경영자의 공시적인 선언-제품에 대한 책임을 수락함

         Q)SDLC의 마지막 단계는? a.인정(1st)  b.인증  c.폐기/소멸(2nd)

         Q)변경관리(Change Management)의 마지막 단계는?   a.인정 b.인증 c.폐기/소멸

 

8. Transition to Production >운용/유지보수(Maintenance/Operation)

>운영 이관

-주기적인 감사/테스트

.병행테스트: 서로 다른 시스템 간 기능 비교 테스트

.파일럿 테스트: 시범 도입, 우선 도입

.회귀 테스: 업그레이드, 이전 테스트 항목 포함

.사회성 테스트: 호환성 테스트

>제품의 설치 및 운영: Hardening(경화) == Simple: 꼭 필요한 기능만 있게 하여 단단하게 만드는 기술

 

 

9. Revision/Replacement/Destruction

>개정/대치/폐기

 

---

III. 소프트웨어 성숙도 모델 

 **조직/프로세스를 봄: 정보기술 프로세스 능력 평가 및 개선모델

 

각 성숙도 단계별 이행하여야 할 핵심 프로세스 및 각 프로세스 별 이행방법을 제시:조직 수준에 맞는 프로세스별 이행 방법을 제시하기 위해 단계를 제시하는 것으로, 좋은 조직이 좋은 서비스와 소프트웨어를 만들 가능성이 높다는 전제하에 제시된 모델

 

1. CMM의 필요성

-각 조직에 맞는 프로세스 개선에 대한 로드맵을 제공

 

2. 기대효과

-시행착오 최소화, 효율적 운영이 가능함(훈련비용 절감)

-생산성 향상, 품질 오차율 감소, ROI 향상 등

 

3. CMM 모델 각 단계

-1단계(Initial): 프로세스를 예측할 수 없고 관리가 빈약하며, 작업자의 능력에 의한 성과 단계 = 혼돈, 성공사례 없음 = 전형적인 스타트업 

-2단계(반복=Repeatable): 조직의 정책에 따라 가이드라인 제시, 성공 사례들이 반복되는 단계 = 시행착오 감소, 신규 입사 시 사수가 교육하는 형태로, 필요성이 확립되고 문서화되고 준수되는 단계

-3단계(정의됨=Defined): 조직차원의 프로세스가 정의되고 문서화 됨 = 프로세스의 특징이 정의되고 상당히 잘 이해되는 단계

-4단계(관리됨=Managed): 수치로 나타나는 품질 목표가 설정됨 = 관리, 수치, 평가 = 프로세스가 측정되고 통제되는 단계

-5단계(최적화/고도화=Optimizing): 지속적인 프로세스 리엔지니어링 = 고도화 = 프로세스 혁신에 초점을 맞추는 단계

 

 

 

---

IV. 변경통제

 

변화 제어/관리(Change Control & Management)

      무결성 훼손 > 변경관리 동반 필수 > 사전검토 > 변경승인 > test 기록 관리 필수

 

 1. 변화 제어 및 관리가 보안의 이슈가 되는 이유

-데이터의 무결성에 의존하는 비즈니스 생존원리

-변경은 보안 모델의 무결성을 훼손할 수 있음 —————>변경관리 동반이 필수적**

 

 2. 변화 제어/관리의 주요 사항

모든 변경을 철저히 검토/승인되고, 테스트되며, 기록되어야 함

-변경된 시스템은 인가 과정을 거쳐야 함

-벤더가 제공한 변경사항도 모두 검토

-경영자에게 변화내용을 반드시 보고해야함 = 경영진의 공식적인 승인 = 인정

 

                    Q)변경 통제의 마지막 단계는? a.인정 b.인증 c.폐기/소멸