본문 바로가기

카테고리 없음

cisa 정리

Domain 1. IT 감사 프로세스
Domain 1. IT 감사 프로세스
Domain 2. IT 거버넌스 및 관리
Domain 3. 정보시스템 구입, 개발 및 구현
Domain 4. 정보시스템 운영, 유지보수 및 지원
Domain 5. 정보자산의 보호​
* 문서 종류
IS 감사헌장 : 감사 기능의 역할과 책임에 대해 포괄적으로 정의한 문서. (책임, 권한, 해명의무 포함​) - 재정/개정 후에는 반드시 이사회나 감사위원회의 승인을 받야야 함. 
- 감사를 계획하고 수행하는 과정을 기록하는 문서 2가지
IS 감사 수임 용역 약정서 : 개별적인 감사 과제 진행에 있어서 감사인의 책임, 권한 및 해명 의무 등의 내용이 기술 (암행어사 마패)
IS ​감사 프로그램 : 세부 감사 계획서로서 현장 감사 절차를 기술. 어떠한 도구와 기법을 사용하여 어떻게 감사 활동을 수행할 것인지, 감사 일정
IS ​감사 조서 : 감사 수행 중에서 적용한 모든 감사 절차와 기법, 의사소통한 대상자와 내용, 수집한 증거 및 발견사항, 분석 결과 등. 감사 조서는 감사 보고서의 내용을 뒷받침해야한다.
- 감사 결과
IS ​감사 보고서 : IS 감사 결과를 전달하는 공식적인 수단. 감사 의견 및 이를 뒷받침하는 판단 근거를 포함
   단계                                                      문서
개별 감사 계획                                       -    감사 프로그램
현장 감사(통제평가,통제테스트,실증테스트)       -    감사 조서
보고                                                    -   감사 보고서
후속 조치                                              -   후속조치 보고서
후속검토 : IS 감사인이 제시한 발견사항 및 권고사항에 대응하여 경영진이 조치한 교정 조치가 적절하였는지를 검증. ​
*  감사의견
적정 (Unqualified) : 감사가 독립적이고 적정하게 수행. 
한정 (Qualified) : 감사인과 피감사 조직의 경영진 사이에 의견 불일치가 있거나 독립적 감사 수행이 상당히 방해받았지만 부정적 의견이나 의견 거절을 할 정도는 아님
부적정 (Adverse) : 감사인과 피감사 조직의 경영진 사이에 심각한 의견불일치
의견거절 (Disclaimer) : 독립적인 감사 수행이 상당한 방해를 받아 충분한 감사 증거와 판단 근거를 확보하지 못함
* 감사 증거
관련성 : 감사와 관련있어야함
신뢰성 : 원천(독립성, 조직내부보다는 외부(제3자)의 증거), 객관성(내용이 분명하고 판단이나 해석이 불필요한 증거), 증거제공자의 자격(전문성, 중립성, 권위가 있는 제공자로부터 받은 증거), 수집 시점(관련 사건의 발생 시기와 근접한 시기에 수집한 증거)
유용성 : 감사 목적 달성에 기여해야 하는 증거. 아니면 가치가 없다. 
충분성 : 다른 감사인도 동일한 감사 결론을 형성하게 할 만큼 완전하고, 적합하며, 설득력 있어야 한다.
* 증거의 유형
물리적 증거 : 감사인의 직접적 관찰 및 검사 (현장 사진, 재고자산 실사, 감사인의 검사, 참관 등)
문서 증거 - 일상 업무의 거래처리에서 발생되는 산출물 (거래 기록, 프로그램 목록, 활동 로그 등)
진술 - 질의 또는 질문에 대해 제시한 서면 또는 문서의 설명. 진술만으로는 결정적인 정보가 되기 어려우므로 다른 정보에 의해 뒷받침되어야 한다.
분석 - 데이터간 상호관계에 대한 파악을 통해 얻어지는 유의미한 자료.
* 위험
고유 위험 : 원천적으로 존재하는 위험. 보완통제를 통해 감소. 감사인이 통제하기 힘듬.
통제 위험 : 내부 통제 시스템에 의해 적절히 예방, 적발 및 교정되지 않을 가능성. 감사인이 단기적으로 통제할 수 없으나, 권고를 통해 장기적으로는 개선에 일정 부분 기여 가능.
적발 위험 : 감사인의 감사 절차상의 약점과 샘플링 위험으로 구성
=샘플링위험(샘플이 모집단을 적절히 대표하지 못할 위험)+비샘플링위험(감사인의 판단 미숙이나 부적절하나 감사 절차로 인하여 적발 실패가 발생할 위험. 자료의 측정과 수집과정, 처리 과정에서 주로 발생) => 적절한 교육과 훈련, 감사의 강도를 통해 조절이 가능하다.
감사 위험(AR) : 감사인이 적발하지 못한 채 보고서를 발행할 위험. 주로 2종 오류가 발생할 가능성.
=고유위험 x 통제위험 x 적발위험 => 감사인은 적발위험을 낮춰 감사위험을 낮춰야 한다.
사업 위험
AAR(Acceptable Audit Risk) 용인 가능한 감사 위험
=> 목표 감사 위험 수준. 고유위험과 통제위험을 평가한다. 
감사위험(AR)이 AAR보다 낮아질 수 있는 수준까지 실증테스트를 수행한다.
AR = IR(고유위험) x CR(통제위험) x DR(적발위험) <= AAR
ALR(Acceptable Level of Risk) 과 헷갈리지 않기.
* IS 감사 절차
1. 연간 감사 계획
2. 개별 감사 계획
3. 현장 감사
 - 통제 평가 : 설계의 적합성 - 통제와 통제의 목적을 파악하고 적합한지
 - 통제 테스트(준거성 테스트) : 운영의 효과성 - 통제가 잘 이루어지고 있는지
 - 실증 테스트 : 성과 품질 - 잘 지켜지지 않고 있는 통제를 증명, 실제 처리상의 무결성을 입증. 성과의 품질을 테스트. 
4. 보고 : 피감사인과 협의: 발견사항에 대한 이해와 교정 조치 협의 목적으로 수행. 경영진과의 종료회의. 감사보고서 배포
5. 후속 조치 : 권고사항에 대해 경영진이 취한 교정 조치가 목적을 달성하였는지 검토. 경영진이 위험을 감수하기로 한 경우 IS 감사인은 이를 문서화화되, 후속 조치를 수행할 책임은 없다.
* 감사인의 자격
 - 독립성
 - 전문가로서의 정당한 주의
 - 전문가로서의 판단
 - 적격성 : 지속적인 직무 교육(CPE) 등의 방법으로 적격성을 획득
 - 중요성
* 감사위원회 - 이사회 산하에 설립되며 경영에 참여하지 않는 사외 이사들로 구성. 독립성 제공. 경영자의 부정에 대한 감사기구로서 경영자의 재무보고과정 전체에 대한 감시기능을 이사회로부터 위임받은 기구.
* 통제
예방통제 : 문제 발생 전에 이를 예방하고 예측하여 조정하기 위한 통제. ex) 업무 기능 분리, 물리적 접근 통제, 거래 승인 절차 등
교정통제 : 위협의 영향을 최소화하고, 문제의 원인을 식별하여 조치함으로써 오류를 사후적으로 정정하기 위한 통제. ex) 재해복구계획, 백업 및 복구 절차, 교정을 통한 위험 감소
적발통제 : 이미 발생한 문제를 적발하고 보고하는 통제. ex) 해시 합계, 체크 포인트, 에코 체크, 감사, 접근 로그
보완(=보충)통제 : 기존의 통제 약점 혹은 잠재적인 통제 약점의 위험을 감소. 보완통제를 통해 고유위험을 감소. ex)자동화된 통제에 약점이 있어 추가로 수작업으로 검토하는 것.
일반통제 : IS 관련 활동 전반에 영향을 미치는 통제
응용통제 : 특정 응용 시스템에 대한 통제, 개별 거래 처리의 무결성을 확보하기 위한 통제
* COBIT 5.0
거버넌스 책임은 이사회, 관리 책임은 최고경영자와 임원
자체보증 또는 자기확신 : 업무 수행자 스스로에 의한 보증
독립적보증 : 제3자에 의한 보중
절대적보증 : 비용을 고려하지 않고 제공되는 최고 수준의 보증
합리적보증 : 비용이 효과를 초과하지 않는 수준
적극적보증 : 보증 기준에 적절히 부합한다는 것까지 보증
소극적보증 : 보증 기준에 부합하지 않다고 말할 수 없음만 보증
- IS 감사는 일반적으로 독립적, 합리적, 소극적 보증이다.
  회계감사는            독립적, 합리적, 적극적 보증
* 계획 수립 절차
1. 환경 이해 및 문서 검토 : 업무현장 실사, 전기 감사보고서 보기, 경쟁회사 자료 분석 등
2. 분석적 검토 절차 (ARP, Analytical Review Procedure)
- 기대치와 정보를 비교함으로써 예외사항이나 비정상적인 거래를 식별.
- 비정상적인 항목에 중점적으로 감사를 수행함으로써 효율적인 감사수행 가능
- 하지만 상황적인 증거만을 제공하는 것이며 만약 기준 자체가 합리적이지 못하면 잘못된 결론에 도달하는 한계를 지님
3. 설문조사
4. 착수 회의, 예비 회의
* 감사 테스트
- 통제 테스트 (준거성 테스트 (Test of Controls)) : 통제 절차가 사전에 규정된 통제 절차와 일치하여 준수되었는지를 판단하는 절차. 통제 운영환경이 효과적인지 테스트. 통제 테스트
  1. 조사 : 관찰(주로 활동에 대한 조사), 검사(물리적 자산에 대한 조사)
  2. 질의
  3. 재수행
  4. 추적조사 (Walkthrough) : 비즈니스의 전반적인 프로세스를 추적해보며 이해와 통제활동을 평가​
  5. 속성 샘플링 : 모집단에서 표본을 추출한 후, 표본의 규정 위반율을 근거로 모집단의 규정 위반율을 추정.
- 실증 테스트 (Substantive test) : 실제 테스트의 무결성을 확증. 재고실사를 위한 통계적 샘플링. 물리적인 조사. 
  1. 검열 : 감사인의 경험과 식견으로 식별
  2. 재계산 : GAS를 사용하여 감사인이 재계산하여 시스템이 처리한 결과를 검증
  3. 조회 : 거래의 유무를 서신으로 검증
  4. 변량 샘플링 : 보고서에 포함된 정보의 허위 정도를 가늠하기 위해 수행. 
  5. 추적방법 : Vouching(역추적, 실재성 검증), Tracing(순추적, 완전성 검증)

* 감사 샘플링
1. 추출, 2. 관찰, 그리고 관찰 결과로부터 모집단의 특성을 3. 추론
표본설계(샘플링)에 앞서, 모집단의 완전성을 우선 확인해야함!
통계적 샘플링 : 오류의 확률을 객관적으로 계량화 가능. 목표 신뢰수준을 충족시킬 수 있는 표본의 크기를 객관적으로 결정가능. 충분한 감사 증거에 대한 객관적인 기준을 가짐.
  - 임의 샘플링(Random sampling) : 난수를 이용하여 표본 추출. 모든 표본단위의 선택확률이 동일하므로 전체 모집단을 대표할 가능성이 제일 높다.
  - 체계적 샘플링(Systematic sampling) : 첫번째 샘플은 무작위 추출. 이후부터는 일정한 추출 구간만큼 일련번호를 증가시키면서 추출.
      ex) 모집단의 크기: 10,000,  표본의 크기: 200, 표본 항목에 일련번호를 붙인 후, 난수 생성 결과: 5
      4번째 추출되는 표본 항목의 일련번호는?
      샘플링구간: 10,000/200= 50 즉, 50씩 증가시키면서 표본추출.
      난수 생성 결과 5이므로 최초로 추출된 항목의 일련번호는 5, 55, 105, 155 즉 4번째는 155.1​
비통계적 샘플링 : 확률이론을 적용하지 않고 주관적인 판단에 의한 표본추출방법
  - 우발 샘플링=자의적 샘플링 : 그냥 막 우발적으로 추출하는것.
  - 판단 샘플링 : 감사 목적에 부합되는 대상을 선정하여 감사인의 판단에 따라 주관적으로 결정
속성 샘플링 : 통제테스트, 준거성테스트, 일반통제
  - 단속적 샘플링 (Stop or Go) : 기대오류가 매우 낮을 때, 비교적 작은 크기의 샘플로 기대에 부합되는 샘플링 결과가 나오면 추가적인 샘플링x, 그렇지 않으면 계속 샘플 추출.
  - 색출 샘플링 (Discovery) : 부정이나 사기 발견을 위한 샘플링. 아주 적거나 없을 것이라 기대하는 경우에 적용. 
변량 샘플링 (Variable sampling) : 실증 테스트의 일환으로 재무 보고서에 포함된 허위 주장이 용인 가능한 수준 이하인지를 판단하기 위하여 수행​
층화 샘플링 : 모집단을 특정한 기준에 따라 나눔. 추출 대상 모집단이 한정되므로 샘플의 크기도 작아진다.
x화폐 단위 샘플링 : 과대계산된 표본 항목일수록 추출될 확률↑
* 샘플 크기의 결정
모집단의 크기 : 크면 샘플의 크기도 ↑​
신뢰수준 : 크면 샘플의 크기도 ↑​​
모집단의 다양성(=분산) : 크면 샘플의 크기도 ↑​. 
도(허용가능오류) : 허용오차의 한계. 정도가 커지면 허용되는 오차의 범위가 ↑​, 샘플크기↓, 통제테스트에서만 적용됨​​
기대오류 : 클수록 오류가 크므로, 샘플크기↑. 통제테스트에서만 적용됨​
표준편차 : 크면 샘플이 모집단을 대표하기가 힘드므로 샘플크기↑ -> 변량 샘플링에서만 고려됨

* CAATs (Computer Assisted Audit Techniques)
 - GAS (General Audit Software) 다양한 형태의 계산, 샘플링 및 데이터 분석에 사용되는 범용 감사 소프트웨어
   - 파일접근, 파일재구성, 데이터추출, 통계적기능, 연산기능
 - SAS (Special Audit Software) 특정 목적으로 사용되는 감사 소프트웨어
- 화이트박스
스냅샷
EAM (Embeded Audit Module, 내장 감사 모듈​)
Tracing and mapping
Tagging

- 블랙박스
Test Data​
ITF 통합설비테스트​
병행 시뮬레이션
병행 테스트

* CSA (Control Self Assessment) 자가통제평가. 자체감사
- 활용 : 업무에 대한 세부지식이 필요한 고위험 분야
코칭역할은 감사인이 하지만 평가 수행자는 실무진에게 넘김. 현업관리자들이 CSA프로세스의 주체임.
설문조사. 촉진된 워크샵
검토 대상 분야를 잘 알고 있으며 통제 수행에 필수적인 사람들(=프로젝트 소유자)을 모아 워크샵 형태로 진행. 감사인은 촉진자 역할을 한다. 책임을 약간 전가시켜 내부 직원들을 참여시켜 그들이 가지고 있는 실무 지식을 활용하며 세부 검토가 필요한 고위험 분야를 식별할 수 있다. 워크샵 진행 과정에서 업무의 약점을 알고 통제를 인식하고 직원들의 동기 부여, 경영진은 직원들로부터 피드백을 받고 추가 검토가 필요한 고위험 분야 식별 가능.
* IS 직무윤리 규정

① ISACA는 협회 회원 및 자격증 소지자의 직무 및 개인 행위에 관한 지침을 제시하고자 본 직무 윤리 규정을 제정한다.

② ISACA 회원 및 자격증 소지자는 다음 규정을 준수해야 한다.


1) 기업의 정보 시스템과 기술에 대한 효과적인 거버넌스와 관리 그리고 감사, 통제, 보안, 위험 관리 등에 적용되는 적절한 기준과 절차의 구현을 지원하고 준수를 촉진해야 한다

2) 직무 기준에 따라 객관성, 정당한 근면성, 전문가적 주의로 임무를 수행해야 한다

3) 높은 행위 기준과 품격을 유지하고, 자신의 직업 또는 협회의 신뢰를 떨어뜨리지 않으며, 합법적인 방법으로 이해관계자들에 이익에 기여한다.

4) 사법 당국이 공개를 요구하는 경우가 아니라면 업무 수행 중에 습득한 정보의 프라이버시와 기밀을 유지해야 한다. 해당 정보를 사적 목적으로 사용하거나 부적절한 대상에게 제공해서는 안 된다.

5) 자신의 전문 분야에서 숙련성을 유지하고 필요한 기술, 지식 및 능력을 사용하여 업무를 완수할 수 있을 때만 해당 업무 수행을 동의해야 한다.

6) 공개하지 않을 경우 결과 보고를 왜곡할 수 있는 모든 중요 사실을 공개하고 수행 작업의 결과를 적절한 대상에게 전달해야 한다.

7) 기업의 정보 시스템과 기술의 거버넌스와 관리 그리고 감사, 통제, 보안, 위험 관리 등에 관한 이해관계자들의 이해를 증진함으로 그들의 직무 교육을 지원한다.


③ 본 직무 윤리 규정을 위반할 경우 해당 회원 및 자격증 소지자의 행위에 대한 조사는 물론 결과적으로 징계 조치가 취해질 수 있다.​


Domain 2. IT 거버넌스 및 관리
Domain 1. IT 감사 프로세스
Domain 2. IT 거버넌스 및 관리
Domain 3. 정보시스템 구입, 개발 및 구현
Domain 4. 정보시스템 운영, 유지보수 및 지원
Domain 5. 정보자산의 보호​​
1. IT 거버넌스와 관리 개요
- 10개의 과업과 17개의 지식설명
2. 기업 거버넌스
IT전략위원회 - 3에서 다룸
* 기업 거버넌스
- 규제 요건 및 사회적 책임이라는 제약 하에서 조직이 운영되도록 하면서
- 이해관계자의 가치를 증대시키기 위한 기회를 활용
* IT 거버넌스 (이사회와 고위 경영진의 책임)
- 기업 거버넌스의 한 영역으로, 기업 내에서 IT를 어떻게 적용할 것인지를 고려하는 현안들의 집합체로 구성
- 비즈니스와 IT간의 연계를 통해 비즈니스 가치를 달성. 위험 관리.
- 목적 : 가치창출 (효과실현 + 위험 최적화 + 자원 최적화)
- 거버넌스(평가,지휘,모니터링) + 매니지먼트(=관리)(기획,구축,운영,모니터링)
- 효익 : 조직이 정보를 최대한 활용하여, 최대의 이익을 얻고, 기회를 이용하여 경쟁우위를 얻도록 함.
- 5가지 중점 영역 (중요)
1. 전략적 연계 : 경영계획과 IT계획의 상호 연계, 운영 연계
2. 가치 제공 : IT가 전략상 약속한 효익 제공, 비용 최적화, IT 고유의 가치 제공에 집중
3. 자원 관리 : 핵심 IT자원(정보,응용,인프라,인력)에 최적 투자와 적절한 관리
4. 위험 관리 : 고위 경영진의 위험 인식, 위험에 대한 명확한 이해, 준수 요구사항의 이해 등
5. 성과 측정 : BSC를 이용하여 추적하고 모니터링하여 성과 측정
* 정보보호 거버넌스 : CISO(정보보호 최고책임자)에게 정보보호의 권한 위임, (책임은 이사회와 고위경영진)
- 통합(Integration)의 정의 : 프로세스가 의도한 대로 운영됨을 보증하기 위해 괸련된 모든 보증 요소들을 함치는 개념
- 기업의 가치 창출에 도움이 되는 비즈니스 활동을 지원
- 6가지 산출
1. 전략적 연계
2. 위험관리
3. 가치 창출(전달)
4. 성과 측정
5. 자원 관리
6. 프로세스 통합 : 전반적인 보호와 운영 효율성 개선
- 이사회/고위경영진 : 정책/모니터링/측정지표 승인, 리더십, 솔선수범, 전파
- 고위 경영진 : 리더십과 지속적인 지원 제공. 비용효과적인지, 비즈니스 목표와 연계되어있는지 결정
- 운영위원회 : 기업 내에 확산. 우선순위와 합의 도출. 의사소통채널 역할.
- 정보보호 최고책임자 CISO(Chief Information Security Officer) : 최고 경영진의 수준으로 확대. 법적 책임과 연결
* 사업 연속성과 재해복구계획
- DRP(Disaster Recovery Plan, 재해복구계획)
- BCP(Business Continuity Plan, 기업연속성계획)​
- BIA(Business Impact Analysis, 비즈니스 영향분석)
 => BIA를 통해 중단비용과 지속적인 업무기능 유지를 고려하여 핵심적인 것이 무엇인지 이해하는 절차 수행​
 => 복구 순서와 시간대를 결정하고 기술과 방법을 결정
- RTO(Recovery Time Objective, 복구목표시간) : 운영이 중단된 상황에서 허용할 수 있는 중단시간에 기반을 두고 결정
- RPO(Recovery Point Objective, 복구목표시점) : 운영이 중단된 상황에서 허용할 수 있는 손실데이터 양에 기반을 두고 결정
- CSR(Corporate Social Responsibility, 기업의 사회적 책임)
3. 엔터프라이즈 IT 거버넌스
* IT 거버넌스 감사의 역할
- 컴플라이언스(법규 및 규정 준수)를 모니터 하는 주체로서
- 수행된 IT 거버넌스 추진과제의 품질과 효과성을 개선하는데 도움을 주기 위해 선도적이 사례를 경영진에게 추천
- IT 거버넌스 추진과제의 결과를 준수하도록 도움
- 이를 위한 정성적인 평가에서의 독립적이고 균형적인 시각이 필요
* IT전략위원회 (이사회 레벨) 현재/미래 전략적 IT문제에 초점
비즈니스 측면에서의 IT개발 타당성
비즈니스 목표와 IT연계, 전략적 IT 목표 성취
전략 관련 관리 방향 제시
* IT운영위원회 (경영자 수준) - 구현에 초점
비용지출 수준, 프로젝트 기획/예산 승인, 적절한 자원 할당 검토 및 승인
기업의 고위경영진이 정보시스템 조직의 기능과 관련 활동을 감독
구성원: IT 관련 위험과 이슈를 이해하고 있는 이사회의 멤버가 위원회의 의장
=> 두 위원회의 모든 활동과 결정사항은 공식적인 의사록이 유지 관리 되어야 한다.
=> IS 감사인의 관점: IT 운영위원회는 각 부서로부터 적절한 관리 정보를 받고 있는가?
=> 이 정보로 자원을 효과적으로 조정/모니터링 하는가?
=> 위원회는 정기적인 회의 소집과 고위 경영진에게 보고를 수행하는가?
=> 회의록 유지 관리는 잘되는가?
* 정보 전략 기획(ISP, Information Strategic Planning)
비즈니스 프로세스를 개선하기 위해 정보기술(정보시스템)에 투자하는 장기적인 방향성
하드웨어, 소프트웨어, 네트워크
* IT BSC(IT Balanced ScoreCard, IT 균형성과표)
 1. 경영진의 이사회 보고 수단 정립
 2. 핵심 이해 당사자 간 IT 전략적 목표에 대한 합의 촉진
 3. IT의 효과성과 IT가 추가로 창출한 가치를 증명
 4. IT 성과 / 위험 / 역량 등에 대한 의사소통 제공
- 조직의 전략을 1.재무 2.고객 3.내부프로세스 4.학습과성장 등의 4가지 관점의 측정 가능한 핵심성과지표(KPI)로 전환하여 관리함으로써 균형성과관리(성과측정 영역)를 실현
- 전사수준에서 구축된 전략 및 성과지표를 부문,부서,팀,개인수준으로 하향전개.
- 조직의 전략을 공유하기 위해 수단화/구체화한 것.
- 학습과 성장 -> 비즈니스 프로세스 향상 -> 고객만족 증대 -> 재무적 결과 증가
* 정보보호 거버넌스 - 2에서 다룸
* EA(Enterprise Architecture, 전사적 아키텍처)
- 조직의 IT자산을 구조적인 방법으로 문서화하여 IT 투자에 대한 이해, 관리, 계획을 촉진
- 현재 상태와 최적화된 미래 상태를 표현 (로드맵)
- 가치를 창출하는 핵심 프로세스와 이를 지원하는 프로세스 관점에서 조직을 이해하려는 속성
- 점차 증가하는 IT와 기업 조직의 복잡성에 대응하며, IT와 비즈니스 전략과의 연계(전략전 연계)하며 IT 투자가 실직적인 이익을 제공하도록 노력(가치 제공)
- EA 도입 목적
1. CEO/CIO 관점: 투자전략지원, IT 비용절감, IT 기반 혁신 지원
2. IT 기획자 입장: 신기술 및 표준 동향을 파악하여 정보화 요구사항 파악 및 IT 계획 수립. IT 장비도입 기준수립
3. 현업 관리자 입장 : 비즈니스 프로세스 개선, 업무 변경에 따른 신속한 IT 지원
4. IT 운영 및 개발 인력 입장: 통합시스템 아키텍처 확보, 관리 지원

4. 정보시스템 전략
* 경영전략(BS, Business Strategy)와 기업전략기획(BSP, Business Strategy Planning)
5. 성숙도와 프로세스 개선 모델
* CMM(Capability Maturity Model)
성숙 수준 5단계
Initial 초기 - 개발만 하는 수준. 프로세스 없음
Repeatable 반복 - 반복 수행. 비용, 일정, 기능성에 대한 추적이 이루어짐. 일정과 개발기간이 감소됨. 프로젝트를위한 프로세스가 존재
Defined 정의  - 프로세스 작업이 정의되고 데이터에 의한 프로젝트 관리가 실행되며 프로세스가 계속적으로 진보하는 기초가 정립된 상태. 비용, 기능, 품질, 생산성. 조직을 위한 표준 프로세스가 존재
Managed 관리 - 프로세스의 데이터 수집이 자동화되고 데이터로 프로세스를 분석하고 수정함으로써 실질적인 품질개선, 포괄적인 프로세스 개선이 가능한 상태. 예측능력, 재사용, 품질관리
Optimizing 최적화 - 질적, 양적으로 큰 개선이 계속되는 상태에 도달하고 있는 수준. 비즈니스 통제, 변화 관리. 지속적인 프로세스 최적화
6. IT 투자와 자원배분 실무
투자수익률 ROI(Return On Investment)
가치는 비용 대비 큰 효익일수록 가치가 증대됨.
* Val IT v2.0
1. 가치 거버넌스
2. 포트폴리오 관리
3. 투자 관리
- 핵심용어 : 프로젝트, 프로그램, 포트폴리오
7. IT 정책 및 절차
* 정책의 구체화
정책-표준-절차-지침-실무 (순서 기억하기)
8. 위험관리
위험 = 자산의가치 x 취약성 x 위협
* 위험 관리 프로세스
1. 정보자산 식별/분류
2. 분석/평가
3. 조치(=대책, 대응, 통제)
4. 모니터링
5. 보고
위험식별을 위해서는 자산 재고조사가 선행되어야 한다.
회피: 위험을 발생시킬 수 있는 프로세스나 활동을 하지 않음(원인을 아예 제거를 해버려 위험을 없앤다)
경감(완화): 적절한 통제의 정의/구현/모니터링으로 위험의 발생 가능성과 영향을 줄임
전가: 보험, 아웃소싱
수용(감수): 위험의 존재를 인식하고 모니터링만 수행
무시(거부)
**
**
**
* 위험분석기법
- 정성적 분석 기법 : 단어 또는 서술형의 위험등급 (상/중/하). 주관적, 개인의 판단/경험/직관이 좌우.
 + 델파이 기법
 + 질문서 법
 + 시나리오 법
- 준 정량적 분석 기법 : 서술적 위험등급(정성적분석) + 수리적 척도(정량적분석)
- 정량적 분석 기법 : 수치로 표현. 객관적. 다양한 데이터와 통계 기법이 사용됨. 주로 사업영향분석(BIA, Business Impact Assessment) 에 사용. 
 + 문제점: 동일자산에 다른 가치가 계산될 가능성.
* 연간 손실 기대값 (ALE, Annual Loss Expectancy)
ALE = SLE(=AV x EF) x ARO
SLE(단위 손실 기대값, Single Loss Expectancy) = AV(자산가치, Asset Value) X EF(노출계수, Exposure Factor)
SLE = AV x EF
ARO(연간 빈도수, Annual Rate of Occurrence)
* 통제대책(보호대책) 가치. (Safeguard value)
ex) Safeguard value 구해보기
DB value : 10억
해커에 의한 정보 유출 위협으로 인한 ALE : 5억
보안대책 수립 후 예상되는 ALE : 2억
해커에 대한 대비책으로 백신과 DB Security Program 설치/운영 비용: 1억/년
답: (5-2-1)=2억
* 정리
위험관리는 고위경영진 책임
정량적 위험관리 > 정성적 위험관리
연간 발생률이 낮더라도 위험영향이 큰 사건을 다룰때는 각별한 주의가 필요
9. 정보시스템 관리 실무
* 인적 자원 관리
- 교차훈련: 운영의 연속성 유지에 도움. 본업무를 하면서 다른 업무 훈련. 교차훈련과 직무순환을 통해 전체 시스템에 대해 모두 알게 될 경우 통제 우회 위험과 통제 취약점이 증가할 수 있음
- 직무순환: 아예 다른 업무로 주업무를 바꿈(교차훈련과의 차이). 변칙이나 부정을 발견할수 있는 기회 제공. 공모 사슬 제거 목적
- 강제휴가: 최소한 1년에 한번 해당 업무를 다른 사람이 수행. 부적절 행위를 발견할 수 있는 기회 제공. 
- 퇴사 직원의 계정은 퇴사 결정이 이루어지면 바로 삭제한다. 퇴사한 후가 아니다.
* 직무기술서
* 직무명세서: 직무기술서의 내용 중 직무 수행 요건만을 상술한 문서.
* 성과측정지표
1. 핵심 성공 요소 (CSFs, Critical Success Factors)
2. 핵심 목표 지표 (KGI, Key Goal Indicatro)
3. 핵심 성과 지표 (KPI, Key Performance Indicator) : 목표를 달성하는데 있어서 성과를 내고 있는지를 판단하는 척도​
4. 성숙도 모델 (MM, Maturity Model)
 - 부재 - 초기(프로세스X) - 반복(유사한 절차 따름) - 정의(절차존재. 개인역량에 의존) - 관리(부단한 개선중.좋은 실무) 최적(지속적 개선. 최선의 실무. 신속대응)
* 6 시그마 (Six Sigma)
- IT에 적합한 개선방법론
- 프로세스 개선과 불량감소에 초점을 둔 측정지향적 전략의 구현
- 6 시그마에서 불량이란 고객의 요구사항을 벗어나는 것
* IT BSC (Balanced Score Card, 균형성과표) : IT 기능이나 프로세스를 평가할 때 적용하는 프로세스 관리 평가 기법
* Benchmarking : 최선의 방법을 알아내기 위해 동종업체 및 경쟁사와 성과를 비교하는 체계적인 방법
10. 정보시스템 조직 구조와 책임
* 정보 처리 설비 (IPF, Information Process Facility)
- 컴퓨터 주 전산기, 주변 기기, 자기 매체 및 매체에 수록된 데이터 등
- IPF 내에서 분리형 매체에서 유지 관리되는 모든 데이터와 프로그램들을 기록, 반출, 회수하고 안전하게 보관
* DBA(Database Administration)
- DBA에 대한 통제: 모든 데이터에 접근할 수 있는 권한이 있기 때문에
 1. 직무의 분리
 2. DBA 작업내역에 대한 경영진의 승인
 3. 모든 활동은 로깅하고, 접근 기록 및 활동들에 대한 감독자의 검토 - 적발통제
 4. 갱신 및 동시성 통제. 무결성 손상 예방
* 라이브러리안
- 라이브러리 통제 소프트웨어를 사용하면 프로그램 버전 통제 및 프로그램 구성 관리에 도움이 됨
- 컴퓨터 테이프 및 디스크로 관리되는 모든 프로그램과 데이터 파일의 사용과 회수 및 보관 및 기록을 책임짐
11. IT 거버넌스 구조와 이행에 대한 감사
* IS 감사사의 주안점 -- 문제의 징후
- 비호의적인 최종 사용자의 태도
- 과도한 원가
- 예산 초과
- 프로젝트의 지연
- 직원의 높은 이직률
- 경험이 없는 직원들
- 하드웨어나 소프트웨어의 빈번한 오류
- 사용자의 과다한 요청
- 느린 컴퓨터 반응시간
- 개발 프로젝트 중 중도에서 중단되거나 연기된 것이 많음
- 지원되지 않거나 승인받지 않은 하드웨어나 소프트웨어의 구매
- 하드웨어나 소프트웨어의 빈번한 업그레이드
- 비정상적으로 많은 예외사항 보고서
- 예외 사항 보고서가 사후관리 되지 않음
- 낮은 동기부여
- 미흡한 승계계획 (Succession plan)
- 한 두명의 핵심 요원에게 의존
- 적절한 교육훈련의 부족
* IS 감사사의 문서 검토
1. IT 전략, 계획 및 예산
2. 보안정책문서
3. 조직도/기능도: 보고계통과 책임의 분담 파악. 기능의 분리 정도 판단
4. 직무 기술서
5. 운영위원회 보고서
6. 시스템 개발 및 프로그램 변경 절차
7. 운영 절차
8. 인사관리 메뉴얼
9. 품질 보증 절차
10. 시스템 개발 방법론 문서
11. 기능설계 사양서: 응용시스템에 대한 상세설명, 핵심 통제 포인트 이해/기록
12. 프로그램 변경 문서: 모든 변경에 대한 승인 받은 증거 제시. 소스코드와 교차비교
13. 사용자 메뉴얼
14. 기술참조 문서: 벤더로부터 구입한 응용시스템에 대한 기술 메뉴얼.
* 업체 선정 과정
- 벤치마크나 RFI를 통하여 정보를 수집하고, 각종 계약 요구사항을 확인하여 RFP를 작성하며, 서비스제공자가 작성한 제안서 평가를 통하여 업체를 선정
1.  RFI (Request for Information)
  - RFP 작성 전에 일반적인 기술흐름이나 제품정보를 취합 목적
  - 각종 기술에 대한 이해력 제고
  - 프로젝트에 부적합한 공급업체를 일차적으로 선별할 수 있는 근거
2. RFP (Request for Proposal)
  - 아웃소싱의 범위, 서비스 수준, 서비스 조건, 평가항목 등을 명시
  - 제안서의 내용이 계약서에 포함됨을 명시: 제안서의 충실도 향상
  - 제안 요청 설명회 : 벤더를 초청하여 제안 요청서의 내용에 대해 설명 및 질의답변을 통하여 제안 요청서를 검토하고 보완
  - 구현 후 지원 및 유지보수를 위한 요구사항을 기술
3. Proposal (제안서) 평가, 업체 선정
  - 제안서 접수 전에 RFP 평가항목에 대한 사전 검토/합의를 끝낸다.
=> 한 기업에 아웃소싱 하는 것이 최선이 아님. 다수 기업에 의뢰하고 한 기업을 주사업자로 선정할 수도 있음. 동시계약도 가능.
12. 비즈니스 연속성 계획(BSP)
도메인4 뒷부분과 일부 중복
BCP/DRP/BIA
- BIA : BCP 전략수립의 가장 중요한 단계. 이후 위험대응책과 BCP 수립.
- BCP : 예방통제, 적발통제, 교정통제 등
- DRP : 재해 복구 계획. BCP 안에 DRP가 존재.
=> 책임은 고위경영진에게. 일관성이 중요.
* 테스트 비교표

종류

정보 처리

1차 사이트

2차 사이트

체크리스트

X

문서테스트

구조적 워크스루

모의실험

O

X

병행 테스트

O

O

완전 중단 테스트

X

O​

* 준비도 테스트 (Preparedness Test) - 완전중단 테스트의 종류
- 전체 테스트의 일부만 테스트.
- 지사별/부서별 완전중단 테스트
- 계획이 얼마나 좋은지에 대한 증거를 점차적으로 입수하는 비용대비 효과적인 방법. 계획을 점진적으로 향상시킬 수 있는 수단을 제공
* 결과는 관찰을 근거로 하기 보다는 계량적으로 측정.
- 경과시간, 백업사이트에서 수행한 작업의 양, 요청 대비 실제 수량, 1,2차 사이트에서의 정확성 등
13. 비즈니스 연속성에 대한 감사
* IS 감사사의 감사 수행 내용
1.비즈니스 연속성 전략과 비즈니스 목적과의 연계성 이해/평가
2.비즈니스의 우선순위와 통제가 반영된 BIA의 발견사항 검토
3.BCP 검토와 BIA에서 정의된 RPO, RTO 등으 기준과 계획의 적절성과 현재성 평가
4.테스트 결과 검토/효과성 검증
5.오프사이트 저장소 검토하고 적절성 확인
6.보안 요구사항을 만족하는 백업 미디어 전송 방법
7.수립된 유지관리가 주기적으로 개정되는지 확인
8.BC메뉴얼, 절차가 간단/쉬운 설명인지를 확인/이를 위해 관련자 인터뷰
9.중요한 비즈니스 활동을 지원하는 정보시스템의 아웃소싱 시에는 BCP/DRP에 아웃소싱을 반드시 포함시켜야함.
14. 사례 연구
Domain 3. 정보시스템 구입, 개발 및 구현
Domain 1. IT 감사 프로세스
Domain 2. IT 거버넌스 및 관리
Domain 3. 정보시스템 구입, 개발 및 구현
Domain 4. 정보시스템 운영, 유지보수 및 지원
Domain 5. 정보자산의 보호​
1. 프로젝트 지배 및 관리
* ISP(Information Strategy Planning, 정보화 전략 계획)
* 프로젝트: 고유한 제품, 서비스 또는 결과를 창출하기 위하여 일시적으로 기울이는 노력. 프로젝트 조직은 목적이 달성되면 해체된다. 불확실성 높음
* 운영: 반복적인 제품, 서비스 또는 결과를 창출하고 제공하는 항구적인 노력의 과정. 운영 조직은 특정 목적이 달성되더라도 존속한다. 불확실성 낮음
* 프로그램 (프로젝트를 묶어놓은 개념)
- 공통의 목적과 예산 그리고 상호 연계된 일정과 전략을 통해 서로 밀접하게 연결된 프로젝트 및 시간 제약이 존재하는 태스크.
- 통합 관리 시 더 큰 성과를 거둘 수 있다.
- 프로젝트에 비해 더 복잡하고, 더 오랜 기간 지속되고, 더 많은 예산이 투입되며, 더 큰 전략적 중요성을 갖고 있음.
* 서브 프로젝트 (프로젝트 밑에 서브프로젝트들이 있다.)
- 프로젝트를 관리 가능한 단위로 분할한 것.외부 기관이나 하청을 맡기는 경우가 많음.
* 단계: 프로젝트 활동들의 집합, 납품한 주요 인도물(산출물)들을 고객이 검수한 후 이를 인수하면 완결됨. 단계말에는 '다음 단계를 착수할 것인지의 여부'에 대한 결정이 내려진다. (단계말 검토)
* 전략적 연계(Strategic Alignment): 비즈니스와 IT의 연계.
* 프로젝트 지배(Project Governance)
- 프로젝트가 조직의 전략적 목적을 지원하는 것을 보증하기 위한 리더십, 조직 구조 및 프로세스
- IT 프로젝트 지배는 IT 지배의 일환으로 볼 수 있다.
1. 프로젝트 정관(헌장)(Project Charter)
- 프로젝트의 존재를 공식적으로 승인하고 프로젝트 관리자에게 프로젝트 활동을 위한 자원 사용 권한을 부여한 문서.
- 조직의 고위 경영진 및 후원자가 승인한다.
- '프로젝트 수행명령서' 라고도 불린다.
- 포함내용: 프로젝트명, 설명, 목적, 프로젝트 관리자 및 권한 수준, 사업사례(Business Case), 제품 설명/인도물, (고위경영진의)승인 서명
2. 사업 사례(Business Case)
- 전략적 목적 또는 사업 쟁점을 해소하기 위해 제안된 특정 대안의 필요성(needs), 정당성(justification) 및 기대효과(expectation)에 대한 설명
- 프로젝트 정관에 포함되어야 한다.
- 초기의 사업 사례는 타당성 조사 단계에서 작성되어야 하며 이사회 및 고위 경영진의 검토와 승인을 받아야 한다.
- 사업 사례는 프로젝트의 주요한 이정표마다 또는 단계말에서 주기적으로 재검토되어야한다.
- 이러한 재검토 과정에서 사업 사례가 변경될 수 있으며, 사업 사례에 대한 모든 변경은 반드시 이사회 및 고위 경영진의 재승인을 받아야 한다.
+ 프로젝트 목적은 '무엇' 인데 사업 사례는 'why' 이다.
* 프로젝트 포트폴리오
- 특정 시점에서 조직 내 수행되고 있는 모든 프로젝트의 집합
- 전사적으로 비용 대비 효과를 극대화하는 것이 관건이다.
- 우선순위 부여, 일정수립, 자원조정, 지식전수, 결과최적화
=> 프로젝트 포트폴리오 데이터베이스, 보고서
* 프로젝트 관리 사무국
- 프로젝트 관리와 프로그램 관리의 소유자, (영구)조직
- 품질을 개선하고 프로젝트 성공을 확보하는 것이 목적
* 프로젝트 운영 위원회(고위 경영진, 프로젝트 후원자, 사용자 경영진, 프로젝트 관리자)
- 고위 대표자들로 구성된 협의체
- 위원회 의장: 프로젝트 후원자(프로젝트의 총괄적 소유권과 해명 의무를 가짐)
- 이해 상충을 조정하고 우선순위를 결정
- 프로젝트의 전략적 방향을 제시하고, 이해관계자들의 의사를 대변하며, 인도물/원가/일정에 대한 궁극적 책임을 진다.
- 교정조치와 프로젝트 중단을 결정 가능
* 위윈회
- 감사 위원회: 경영에 참여하지 않는 사외 이사들로 구성됨. 가사 기능의 독립성과 권한을 보증
- IT 전략 위원회: 이사회 임원 및 전문가들로 구성. 기업 전략과 정보 전략의 연계를 위한 방향을 제시하고 조언
- IS 운영 위원회: 핵심 경영진 및 핵심 전문가들로 구성. IS 프로젝트 및 정보 처리 활동이 정보 전략과 연계되게 하기 위한 방향을 제시하고 조언
- IS 보안 위원회
- 업무 연속성 기획 위원회
* 구현 후 검토
- 시스템 구현 후 6~18개월 후 수행평가
* 프로젝트 사후 검토와는 다름.
* 회수 기간법
- 프로젝트의 회수 기간 < 목표 회수 기간 => 채택
- 프로젝트의 회수 기간 > 목표 회수 기간 => 기각
- 단점: 결정기준이 경제적 지표가 아닌 시간. 화폐의 시간 가치를 고려X. 회수 기간 이후 현금 흐름 생각 X. 목표 회수 기간 선정 기준이 주관적.
* 회계적 이익률법 (ARR, Accounting Rate of Returm)
- 연평균 세후 순이익을 연평균 투자액으로 나눈것.
- ARR의 일종으로 ROI가 있음.
ARR = 연평균 세후 순이익 / 연평균 투자액
ROI(Return of Investment) = 연평균 세후 순이익 / 총 투자액
- 단점: 화폐의 시간 가치를 고려 X. 
* 순 현재 가치법 (NPV, Net Present Value)
- 프로젝트로 인한 현금의 유입의 현재 가치에서 현금 유출의 현재 가치를 차감한 액수
- 시장 이자율: 5%라면
NPV = 14,959-10,000 = 4,959
0 < 프로젝트의 NPV => 채택
0 > 프로젝트의 NPV => 기각
- 복수의 프로젝트의 경우 NPV가 가장 큰 것부터 선택
- 단점: 소요 금액이 다를 경우 수익성 비교가 어렵. 그래서 PI(Profitability Index)를 사용하기도 함.
* 내부 수익률법 (IRR, Internal Rate of Return)
- 프로젝트로 인한 현금의 유입의 현재 가치와 현금 유출의 현재 가치를 같아지게 하는 이자율
- 내부 수익률 계산(IRR=23.28%)
목표 IRR < 프로젝트의 IRR => 채택
목표 IRR > 프로젝트의 IRR => 기각​
- 복수의 프로젝트일 경우 IRR이 가장 큰 것부터.
- 이자율이 높아질수록 NPV는 낮아짐.반비례 관계
IRR은 NPV=0 으로 만드는 이자율이다.
* 프로젝트 평가 기법의 장점
- 회수 기간법: 회수 기간을 근거로 한 유동성 위험 평가가 가능
- 회계적 이익률법: 이해하기 쉬우며, 회계 자료를 그대로 활용 가능
- 순 현재 가치법: 할인율로 재투자한다는 현실적인 가정을 사용
- 내부 수익률법: IRR 계산은 어렵지만 투자 평가는 간단
* 프로젝트 평가 기법의 비교
- 프로젝트 평가 기법이 갖추어야 할 조건들
조건1. 현금 흐릅이 고려되어야 함
조건2. 화폐의 현재 가치를 고려해야 함
조건3. 가치의 가산 원칙이 적용될 수 있어야 함
조건4. 평가 모형을 일관성 있게 사용했을 경우 프로젝트 포트폴리오의 가치를 극대화하는 결과를 산출해야 함

* 프로젝트 관리
- 목적: 계획된 (시간=기간)내에, 배정된 (예산=비용)을 사용하여, 합의한 업무 (범위=산출물)를 완수함으로 고객 만족을 극대화
- 요건: SMART(Smart(구체적), Measurable(측정가능), Attainable(달성가능), Realistic(현실적), Timely(적시적))
* 프로젝트 관리 조직
- 고위 경영진: 비용/인력, 프로젝트 개시 등을 승인. 자원 확보
- 사용자 부서 관리자: 프로젝트와 최종 시스템의 소유자. 요구사항 정의, 인도물 검토 및 승인, 인수 테스트 및 사용자 교육 등
- 프로젝트 운영 위원회: 프로젝트를 위한 모든 비용과 일정표에 대한 궁극적인 책임을 가진다.
- 프로젝트 후원자: 자금을 제공하며 소유권을 가짐. 프로젝트 관리자와 밀접히 공조. 프로젝트가 완료되면 사용자가 소유자가 됨.
- 시스템 개발 경영진: 시스템 환경에 대한 기술적 지원. 
- 프로젝트 관리자: 매일매일의 관리를 제공. 일상적 프로젝트 관리와 리더십 제공
- 시스템 개발 프로젝트 팀: 개발팀
- 사용자 프로젝트 팀: 개발팀
- 보안 관리자: 시스템 설계가 기업의 보안 정책과 일치하는지 검토. 시스템에 포함해야할 보안 대책 상담
- 품질 보증 담당자: 각 단계 내 및 단계 말에 작업 결과 및 산출물 검토. 요구사항 준수 확인
* 프로젝트 의사소통
- 일대일 회의: 쌍방향. 비공식적
- 착수회의: 공식적. 일방향성. 프로젝트 관리자가 프로젝트 팀원들에게 수행해야 할 일을 알림.
- 프로젝트 착수워크숍: 개방적. 공식적. 쌍방향 의사소통. 제일 좋은 방법
* 원가 산정 기법
- SLOC(Source Lines of Code) 또는 KLOC(Kilo Lines of Code): 소스라인 수를 기준으로 규모 산정.
- FPA(Function Point Analysis, 기능점수분석): 각 기능에 대한 크기를 측정하여 점수 측정. 가장 과학적이고 합리적. 가장 좋은 기법
- 델파이기법: 전문가에게 서신을 보내 익명으로 돌려보도록 하는 기법
- 회귀분석: 과거의 데이터를 활용하는 기법
* 일정
* 간트차트
횡축에는 시간을 종축에는 프로젝트 활동을 표시. 막대형태로 표현.
* PERT(Program Evaluation Review Technique)

프로젝트를 서로 관련 있는 활동으로 구분. 활동들간의 관계를 네트워크 형태로 정의

프로젝트를 수행하는데 필요한 모든 활동과 각 활동간의 선후관계.

경로: 순환고리(루프) 없이 연결한 선
핵심 경로: 가장 긴 경로. 프로젝트 완료에 필요한 최소한의 기간.
* CPM(Critical Path Methodology)
개별 활동의 지속 시간은 평균 시간을 사용.
여유 시간: 예상했던 최단 완료 시간과 최장 완료 시간 사이의 차이. 음의 값을 가질 수도 있음.
CP(Critical Path)상의 활동에 추가 자원을 투입하여 일정을 단축한다.
* Time Boxing 기법
제한된 자원으로 주어진 시간 내에 납기할 소프트웨어를 정의
*마일스톤(milestone)이란 프로젝트 진행 과정에서 특기할 만한 사건이나 이정표를 말한다. 예를 들어, 프로젝트 계약, 착수, 인력투입, 선금 수령, 중간보고, 감리, 종료, 잔금 수령 등 프로젝트 성공을 위해 반드시 거쳐야 하는 중요한 지점을 말한다.[1]

마일스톤은 프로젝트 일정관리를 위해 반드시 필요한 지점을 체크하기 위해 사용한다. 프로젝트 성공을 위해 필수적인 사항들을 각 단계별로 체크함으로써 전체적인 일정이 늦춰지지 않고 제 시간 안에 과업이 종료될 수 있도록 관리하는데 도움을 준다. 다만, 마일스톤은 프로젝트 진행 과정에서 결정적으로 중요한 핵심적인 사항들만 체크하기 때문에, 그다지 중요하지는 않더라도 프로젝트 진행에 꼭 필요한 다양한 요소들을 상세하게 파악하기 힘들다는 단점이 있다.​

* Fast Tracking: 병행작업(다음 단계의 착수 승인받기 전에 진행하여 일정 단축). 위험 증가
* Crashing:추가 자원을 투입하여 일정을 단축(비용 증가 가능)
* Leveling: 프로젝트 자원 사용이 특정 기간에 집중되어 가용성이 제약되는 것을 해결
2. 응용 시스템 개발 및 구입 수명주기
폭포수모형: 순차적으로 수행. 역행은 허용X. 엄격한 프로젝트 관리 및 표준화를 강조
프로토타이핑 모형: 사용자와의 의사소통을 증진을 위해사용자 요구사항을 임시로 형상화한 시스템의 모형
 - 실험적 프로타타이핑: 사용자와의 의사소통에만 사용되고 폐기
 - 진화적 프로토타이핑: 의사소통 + 초기버전을 형성. 이후 발전시켜 최종으로 완성시킴.
나선형모형: 진화적 프로토타이핑에 (위험관리) 개념이 추가됨. (계획수립-위험분석-개발-고객평가 를 나선형으로 무한 반복하며 위험관리 중심으로 개발한 수명주기모형)
반복적모형: 폭포수, 프로토타이핑, 나선형 모형을 결합. 모든 단계가 반복적으로 등장
* 모형화
* V-다이어그램
모형의 일관성을 보증하기 위한 활동. 확인-검증 으로 구성
확인: 이전 단계의 요구사항이 후속 단계의 산출물에 반영됨을 보증. 외적 일관성을 보증
검증: 후속 단계의 산출물이 이전 단계에서 정의한 요구사항과 일치하는지 보증. 내적 일관성을 보증
* 전통적 수명주기 방법론
1)타당성 조사 2)분석 3)설계 4)개발 5)테스트 6)구현
* 에스크로 계약
* 타당성 조사
기술적 타당성: 만들 수준이 되는지?
경제적 타당성: 사서 쓸것인지 만들어서 쓸것인지
법적 타당성
* 요구사항 정의(=기본 설계)
시스템 요구사항을 공식적으로 문서화.
경영자+사용자 실질적 참여가 중요
- DFD(Data Flow Diagram): 특정 업무 프로세스를 수행하는데 필요한 하위 업무 프로세스들, 각 프로세스 사이의 정보흐름 및 연관 관계를 보여줌
- ERD(Entity Relationship Diagram): 개체 관계도. 데이터 객체와 관계로 구성.
* RFP(Request For Proposal)
* 바닐라솔루션: 신규 시스템을 조정 없이 그대로 사용하는것
* 설계
구조 설계
데이터 설계
절차 설계
* 기준선 설정(Baseline): 범위변경(Scope Creep) 문제를 완화할 수 있다.
논리 경로 감시기: 프로그램에 의해 달성되는 사건 순서를 보고. 논리상의 오류를 찾는 단서를 제공 => 비주얼스튜디오에서 디버깅 라인별로 보는것.
메모리 덤프: 프로그램이 멈췄을때 특정 시점의 내부 메모리 내용(카운터, 레지스터)을 보여줌
출력 분석기: 예측 결과의 실제 결과를 비교하여 프로그램 실행의 정확성을 체크하는데 도움 => 시뮬레이션
* 테스트 접근법
드라이버: 테스트 사례를 받아들이고 구성요소로 각 데이터를 보내며 관련 결과를 인쇄하는 프로그램
스텁: 테스트된 모듈 하위에 두어진 모듈들을 대체하며, 하위 모듈의 인터페이스를 사용하고, 입력 검증을 인쇄하고, 테스트받는 모듈의 제어를 돌려준다.​
상향식: 프로그램, 모듈 등 가장 작은 단위부터 시작하여 전체 시스템에 대한 테스트가 수행. 스텁과 드라이브가 필요 X. 주요 모듈에 있는 오류가 초기에 발견됨
하향식: 깊이 우선 접근법과 너비 우선 접근법이 있음. 스텁과 드라이버를 사용.
           주요 기능과 처리에 대한 테스트가 초기에 가능. 인터페이스 오류가 상대적으로 일찍 발견됨.
           수행되는 시스템을 봄으로써 프로그래머, 사용자에게 시스템에 대한 신뢰감이 부여됨.
- 단위테스트, 모듈테스트: 개별 프로그램 또는 모듈을 테스트. 프로그램 내부 기능이 사양서대로 수행되는 것을 확인. 디버깅되고 분석자가 제공한 사양서에 기술적으로 부합됨을 의미
- 인터페이스 및 통합 테스트: 둘 이상의 컴포넌트 간의 연결상태를 평가. 단위 테스트틀 거친 모듈들을 가지고 설계에 따라 통합된 구조를 구축하는 것
- 시스템 테스트: 모든 모듈들은 하나의 시스템으로 테스트. 사용자의 요구를 하나의 시스템으로 완벽하게 수행하는지 확인하는 다양한 테스트가 필요
 - 복구테스트: 장애 후 시스템의 복구 능력 테스트
 - 보안테스트: 적절한 접근 통제가 구현되었는지, 타 시스템을 손상시킬 수 있는 보안상의 허점이 있는지 확인
 - 스트레스 및 볼륨 테스트: 최고의 부하 시점에서의 성능을 평가.(접속수와 트래픽을 증가시켜 테스트)
 - 성능 테스트: 응답속도, 처리량, 처리속도 등 효율성 진단
- 인수테스트: 사용자가 검증. 요구한대로 개발되었는지. 테스트 완료 후 인수증에 서명. QAT(품질보증테스트), UAT(사용자승인테스트)
- 기타테스트
 - 알파테스트: 조직 내 사용자 팀에 의한 테스트
 - 베타테스트: 조직 외부의 제한된 수의 사용자에 의한 일종의 사용자 인수 테스트
 - 화이트박스테스트: 시스템 로직에 대한 검토를 수반
 - 블랙박스테스트: 시스템의 외부 기능만 테스트
 - 파일럿테스트: 한 부서 또는 본부에 국한
 - 병행테스트: 동일 거래를 신규 및 기존 시스템으로 처리하여 결과를 비교
 - 회귀테스트: 변경 또는 교정이 새로운 오류를 가져오지 않는다는 것을 검증
 - 사교성테스트: 시스템이 기존 시스템에 부정정인 영향을 미치지 않으면서 목표 환경에서 운영될 수 있는지 확인
=> 여기서 감사는? 테스트 계획읜 완전성 검토. 테스트 시나리오 개발 과정에서의 사용자 참여를 검토. 테스트 과정/겱롸/이의 문서화가 적절한지 검토. 오류보고서 검토 후 해결되었는지 검토
* 구현
* 구현 후 검토
- 프로젝트 개발팀과 최종 사용자 협조 수행. 평가와 비판. 적합성 평가
=> 여기서 IS감사인에 의해 수행되는 구현 후 검토는 절차의 통제라는 측면에 초점
* 타당성 검토 - 요구분석 - 선정 - 설계 - 개발 - 테스트 - 구현(인수테스트, 데이터변환, 강사육성 및 사용자교육 등) - 구현 후
* 구조적 프로그래밍: 하향식 설계. 개발유지 쉬움. 설계모듈은 독립적. 모듈단위설계(유지보수성 증가)
3. 대안적 방법론
* 객체지향: 데이터와 절차가 하나의 객체로 결합
속성; 객체의 데이터
메소드: 객체의 기능
- 객체: 개체간의 경계가 명확하고, 개체를 표현하기 위해 상태와 행위를 캡슐화한 것
- 상태: 속성과 관계로 표현
- 행위: 기능, 방법 및 상태 기계로 표현됨
- 고유한 식별자를 가진다.
- 상태를 가진다
- 클래스: 공통된 구조와 행위를 갖는 객체들의 집합
- 인스턴스: 클래스에 특정 값이 채워져서 만들어진 고유한 객체. 실제 데이터값을 의미
- 상속: 클래스가 하나 이상의 클래스들의 구조와 습성을 공유하는 것. 서브 클래스는 수퍼 클래스의 구조와 습성을 상속받는다.
  => 장점: 설계와 인터페이스를 재사용하기가 쉬워짐. 클래스들간의 일관성 향상
- 다형성: 두개 이상의 클래스에 속한 오퍼레이션들을 하나의 연산자처럼 보이도록 하는 것.
  => 예를 들어 Animal이라는 클래스는 draw라는 오퍼레이션이 있다. 이 오퍼레이션은 실제로 두개의 다른 메소드들로 구현된다. Lion을 draw하는 멤소드와 Tiger를 draw하는 메소드로 나누어지지만 논리적으로는 같은 작업을 수행하는 것 처럼 보인다. 메소드를 참조할 때에도 draw라는 이름으로 참조한다. 그러나 각 메소드는 다른 코드로 구현됨
- 캡슐화: 데이터와 데이터를 조작하는 연산을 하나로 묶는 것.
  => 장점은 '정보은닉'
  => 모듈이 그 기능을 구현하는 방법은 다른 모듈로부터 숨기고, 그 모듈의 인터페이스를 통해서만 접근할 수 있도록 하는것.
* 컴포넌트 기반 개발 (CDB, Conponent-Based Development)
- 정의된 인터페이스를 통해서 자신들이 제공하는 서비스를 가용하도록 하는 실행 가능한 SW들을 조립하는 것.
- 컴포넌트는 일정한 기능을 수행하는 SW로, 정형화된 인터페이스를 통하여 다른 컴포넌트와 상호 동작이 가능.
- 부품을 조립해서 제품을 만들어 내는 것처럼 부품화된 컴포넌트를 조립하여 시스템을 구현한다.
- 소프트웨어의 Plug and Play 기술의 발전으로 SW 부품 조립 기술 등장
=> 개발시간 단축, 품질개선, 모듈화촉진, 재사용의 용이성, 개발비용절감, 개발과구입의 적절한 절충가능
* 웹기반 어플리케이션
- 시스템 구조의 유연성
- 사용자 편리성.
- 기존 시스템 통합환경 제공
- 비용효율성
- 플랫폼 독립적. 표준화된 비즈니스 로직 구현
- 동작과정: 1) 서비스 정의 및 등록 2) 웹서비스 검색 3) 웹서비스 위치 4) 웹서비스 요청 5) 웹서비스 수행
- SOAP(Simple Object Access Protocol): xml, http를 사용. 서버의 객체를 호출하는 rpc규격을 표준화한 것.
- WSDL(Web Service Description Language): xml, http를 사용. 인터페이스를 정의하는 IDL에 해당. 서비스가 어떤 메소드, 속성, 어떤 인수를 호출하고 어떤 방식으로 리턴 값을 제공하는지 알려줌.
- UDDI(Universal Description Discovery and Integration): 서비스를 사용하는 측에서 어디에 어떤 서비스가 있는지를 지정하는 프로토콜을 이용하여 쉽게 찾을 수 있음.
* 프로토타입 방식 개발
- 시스템 전체 또는 일부분(시스템의 주요 기능과 외부 인터페이스)에 대해서 먼저 개발하여 사용자의 요구사항을 충분히 반영하는 과정을 되풀이하면서 최종적으로 실제로 운용하게 될 모형을 구성하는 수명주기 모형
- 수평 프로토타입: 구현될 시스템의 모습을 수명 주기 초기에 고객에게 보여줌으로써 요구사항의 정확한 추출을 돕는다.
- 수직 프로토타입: 시스템의 핵심 기능을 시뮬레이션하여 의사소통의 수단으로 역할.
- 고려사항: 위험이 증가할 수 있으나 시간과 비용 절감의 효익이 있음.
             통제가 어렵다. 사용자의 관점에 초점을 맞추다 보면 개발 관련 통제들을 빠뜨릴 수 있음
             통제의 변경이 다른 방식보다 더 복잡. 디자인과 요구사항의 변화가 너무 급히 이루어질 경우 문서화나 승인절차가 생략되고 유지관리가 힘들어질 수 있음
* 속성 어플리케이션 개발(RAD, Rapid Application Development)
- 빠르게 개발하면서도 개발 비용을 줄이고 품질을 유지할 수 있게 해주는 방법론
- 작고 잘 개발된 훈련팀. 진화적 프로토타입 및 자동화 개발도구, 통합도구(IDE), 중앙저장소, 쌍방향 대화방식의 요구사항 도출(JAD), 개발기간 기준의 엄격한 제한(Timeboxing기법)
* 애자일 개발
- Agility: 급변하는 비즈니스 환경에서 보다 많은 이익을 얻기 위해 스스로 변화하고 또 주위의 변화에 대응하는 능력
4. 인프라 개발/획득 실무
5. 정보시스템 유지 보수 실무
6. 시스템 개발 및 생산서어 향상 도구
7. 업무 프로세스 재설계(BPR)
8. 응용 통제
9. 업무 응용 시스템
Domain 4. 정보시스템 운영, 유지보수 및 지원
Domain 1. IT 감사 프로세스
Domain 2. IT 거버넌스 및 관리
Domain 3. 정보시스템 구입, 개발 및 구현
Domain 4. 정보시스템 운영, 유지보수 및 지원
Domain 5. 정보자산의 보호​​
* ITSM (IT Service Management)
PDCA (Plan Do Check Act)
* SLA (Service Level Agreement)
SLA Cycle : SLR(Requirement), SLA(Accept), SLM(Management), SIP(Implement Plan, 향상 계획)가 반복되며 이는 (지속적 개선)을 위함이다.
SLO(Objcet, 목표치)
* ITIL(IT Infrastructure Library) : 비즈니스의 요구사항을 IT Service와 연계하며, 방법론이 아닌 Best Practices(좋은 사례들의 모음)이다.
1. 서비스 지원
2. 서비스 전달
* 인프라 운영
1. 운영자의 임무
2. 소등 운영(무인 자동 운영)
3. 작업 스케줄링 소프트웨어
* 배포(Release) 관리
모든 릴리즈에는 고유한 식별자/번호 가 부여된다.
- 배포 관리 유형
1. 메이저 릴리즈: 상당한 큰 변경
2. 마이너 소프트웨어 릴리즈: 사소한 성능/기능 문제 해결에 활용. 설치와 준비과정은 전체 릴리즈 프로세스 준수
3. 긴급 소프트웨어 릴리즈: 심각한 영향이 있는 경우 가용성만 고려하고 릴리즈 절차를 무시.
* 품질 보증(Quality Assurance)
- 라이브러리언 소프트웨어로 프로그램 버전의 적절한 유지와 소스 코드에 대한 목적코드의 무결성을 모니터링
* IT 자산 관리
- 보호할 만한 가치가 있는 모든 것에 대한 보호 (사람, 정보, 인프라, 자산, 평판)
* 하드웨어 도입 및 유지보수 계획
사양서(Specification) 및 업체 평가기준은 RFP(Reqeuest For Proposal, 제안요청서) 또는 ITT(Invitation to Tender, 입찰 권유서)의 형태로 Vendor 및 공급자에게 전달되며, 이를 제안서 작성시 참조하게 됨.
업체 선정 기준은 입찰에 참여하는 업체들 중에서 최종 수주자를 어떤 조건으로 평가할 것인지를 조달문서(RFP)와 함께 작성되어 입찰참가자들에게 제공됨.
# RFP에 벤더가 정확하게 답하게 하려면? RFP로 제출하는 내용이 계약서에 포함됨을 명기한다.
​​
고객                   제공자(벤더)
   ------RFI------>
   <----제품소개----​
   ------RFP------>​
   <-----제안-------
   <-----계약------->​
RFP 포함사항
- 고객의 요구사항
- 부가사항
- 평가기준
RFP에 포함되면 안되는 항목
- 상세구성
- 보안사항
- 예산
* 하드웨어 자원 이용도는 85%~95%이다. 95%초과이면 증설권고, 85%이하이면 과다구매
* DBMS
외부 스키마
- 사용자, 응용프로그래머가 접근할 수 있는 데이터베이스
- 뷰(View) : 전체 데이터베이스의 한 논리적인 부분, 서브스키마 또는 뷰라고 함. 보안성을 제공하며 예방통제. 원본 데이터의 손상을 예방
외부스키마 - 개념스키마 - 내부스키마
user->App --> DBMS -----> file
* 데이터베이스 통제
- 정규화 (Normalization) : 무결성을 강조. 관계형 데이터베이스는 구조적/비구조적 질의를 만족시키기 위하여 필요한 테이블 정보의 양을 최소화하기 위하여 정규화 사용

                              관계형 데이터베이스(테이블간에 관계를 맺을 수 있는 상황)에서 중복을 최소화 하기 위해서 데이터를 구조화 하는 작업. 효율성은 감소

- 역정규화 : 효율성을 강조
- 체크포인트 : 저장시점. 복구에 사용됨. 자료 손실과 복구 노력을 최소화할 수 있는 시점에 재개를 위한 DB Check Point 선택. 체크포인트=스냅샷이라고 생각하면 편할듯.
- 락킹 메커니즘 (동시성 통제) : 두 프로세스가 서로 먼저 lock을 풀어주기를 기다리는 Deadlock 문제를 일으킬 수 있음. Deadlock은 관리자의 개입이 필요.
- 데이터베이스 재조직 (디스크 조각모음과 비슷) : DB파일 내에 빈 공간들이 발생하고 속도 저하 발생. 이러한 쓰레기 공간을 제거
- 데이터 무결성
 1. 개체 무결성 : 기본키로 구현
 2. 참조 무결성 : 외래키로 구현. 특정 테이블에서 레코드를 삭제하려는데 다른 테이블에서 이 레코드를 참조 시, 삭제 불가.
 3. 의미상의 무결성(도메인 무결설) : 범위의 적절성

* TMS(Tape Management System, DMS(Disk Management System)
* Open Source : GPL(General Public License), 소스코드 및 SW 배포가능
* Freeware : SW만 가능. 소스코드는 재배포 불가. ex) Adobe Acrobat Reader
* Shareware : 기능제한, 사용시기 제한. ex)체험판
-> 감사인은 소프트웨어 라이센스 위반 예방/탐지를 위해 감사해야 함
* VCS(Version Control System). RCS(Revision Control System)
- 장점: 접근통제, 변경내용 추적, 공동(동시) 개발, 이전버전으로의 롤백 가능, 분리 기능(branch)
* 최종 사용자 컴퓨팅(EUC, End-User Computing)
- 컴퓨터 소프트웨어 제품을 활용하여 최종 사용자가 자신의 정보 시스템으르 설계/구현 하는 것을 의미한다.
- 빠른 구축은 장점이지만 에러와 부정확한 결과가 산출될 수 있음. 보안성 결여. 변경/배포 관리를 벗어난 다른 버전의 소프트웨어가 생산됨
* 에스크로 계약

프로그램의 임치제도란 이른바 에스크로 제도의 하나로서 프로그램의 이용 허락 계약 등을 함에 있어서 프로그램의 소스코드를 신뢰할 수 있는 제3자에게 맡겨뒀다가, 개발자가 파산·폐업 등으로 인해 사업을 중단하거나 소스코드 멸실로 인해 개발자의 유지·보수가 불가능해지는 등의 경우에 이용계약의 상대방이 그 소스코드를 그 제3자로부터 제공받게끔 하는 제도를 말한다.

이 제도로 인해 개발자는 컴퓨터프로그램 저작물을 양도하지 않아도 되기 때문에 그 저작권을 보다 두텁게 보호받을 수 있고, 이용자는 그 저작물을 양도받지 않고 이용만 하기 때문에 저렴하게 프로그램을 사용하면서도 유지·보수에 대한 보장을 받을 수 있게 된다.​
* 네트워크의 종류
- PAN(프린터, 카메라, 스캐너, 전화 등의 개인이 컴퓨터 장치들을 연결하는 마이크로 네트워크. 10m이내), LAN, WAN, MAN(WAN보다 넓음), SAN(Storage)
* OSI 7 Layer
7계층 Application : 게이트웨이 L7스위치, UI 제공. 파일저장, 출력 데이터 수신 등. Telnet, HTTP, SMTP, FTP, DNS, Emaiil
6계층 Presentation : 게이트웨이 L7스위치, 데이터 표현방식 제공. 압축 암호화 등
5계층 Session : 게이트웨이 L7스위치, 임의의 에러를 검출하고 다룸. 보안 기능의 최초 적용 계층 (인증기능: ID/PW)
4계층 Transport : L4스위치(부하분산), TCP, UDP, 종점간 오류 복구, 흐름통제, 패킷 분할, 메시지 재조합, 
3계층 Network : 라우터, IP 주소 host간 연결과 데이터 전송기능. 상위계층과 연결설정 및 관리.
2계층 Data Link : 스위치, MAC주소. 물리적 연결을 통한 데이터 전송 기능. crc 에러탐지
1계층 Physical : 리피터, 허브, 비트 스트림 전송. 전기적 기계적인 특성
* 패리티 검사
- 데이터 비트의 1의 개수를 항상 짝수나 홀수가 되도록 유지하여 오류를 검사
- 동시에 2개 이상의 에러 발생 시 검출 불가능
- 오류 탐지만 가능.
* 블록 총합 검사
- 수평 패리티와 수직 패리티 검사를 병행. 좀 더 엄격하고 정확한 에러 검출 가능
* 순환적 중복성 검사(Cyclic Redundancy Check)
- 해시를 이용. 강력하면서 쉬운 구현. 프레임 단위의 에러검출 수단. 복수 bit 에러 검출 가능.
* 에러처리기술
- 전위 에러통제 : 수신측에서 에러 검출 및 수정 가능. 자체교정 가능. (전송비용이 비싸거나 전송 지연이 긴 경우 주로 사용. ex)위성통신)
- 후위 에러통제 : 수신측에서 에러 검출만 가능. 에러 검출 시 재전송.
* LAN 네트워크 위상
 1. Star 형 : 관리 용이. Hub 장애 시 시스템 마비
 2. Ring 형 : 네트워크 균등 분배. Ring 결함 시 전체 마비
 3. Bus 형 : 선로 상태 체크 후 가능 시 데이터 전송. 케이블 비용 최소. 확장 용이. 노드 증가 시 속도 저하
 4. Mesh 형 : 모든 경로 연결. 가용성 극대화. 구축 비용 비싸고 확장 어려움
* WAN 기술
1. X.25 : 에러에 대한 재전송 요구 기능을 가지며 손상된 데이터가 재전송될때까지 다음 데이터는 대기. 높은 부하. 낮은 성능
2. Frame Relay : 프레임이라는 가변 길이의 데이터 단위 사용. 유연성 제공. 에러 교정 기능은 종단다 장치에 맡김. 전체적인 데이터 전송 능력 증가. 가변길이라서 데이터 및 이미지 전송은 좋으나 음성이나 비디오 전송에는적합하지 않음
* CIR(Committed Information Rate) : 
3. ATM : Cell이라 불리는 53바이트의 고정된 크기의 패킷. 비동기 방식. 
4. PPP
5. DSL
6. ISDN
7. VPN
* DRP(Disaster Recovery Plan. 재해복구계획)
* BCP(Business Continuity Plan 비즈니스 연속성 계획)
- 목적 : 사업 중단으로 인한 손실의 최소화, 시기 적절한 정보서비스의 재개.
* BCP/DRP 공통점
- 위험 수용
- 가용성 확보가 우선
- 잔여 위험이 대상
- 대외비
* COOP (Continuity of Operation Plan, 운영 연속성 계획)
- 최대 30일동안 대체 사이트에서 조직의 핵심적이고 전략적인 기능을 유지하기 위한 절차 및 방법을 제공. 본부레벨에서 작성. IT에 초점을 두지 않음
* OEP (Occupant Emergency Plan, 거주자 비상계획)
- 3.재산의 손실방지, 1.인명 최소화를 위한 절차 제공, 2.확산방지
- 특정 시설에 대한 인력과 자산에 초점. IT에 초점을 두지 않음
* RPO(Recovery Point Objective, 복구목표시점) : 백업. 데이터를 복구하는데 수용할 수 있는 가장 빠른 시점. 운영중단이 발생할 경우 허용할 수 있는 데이터 손실량에 근거.
  - 백업 주기 산정 시 RPO를 반드시 고려하여야함. (백업주기<RPO)​
* RTP(Recovery Time Objective, 복구목표시간) : 2차사이트. 비즈니스 운영이 재개되는 가장 빠른 시점. 운영중단이 발생할 경우 허용할 수 있는 데이터 복구시간에 근거.
- RPO=RTO 인 경우는 업무가 매우 중요한 경우이다.
* 2차 사이트 구분
* 가용속도에 따른 구분
- 미러: HVAC, 네트워크, 컴퓨터, 데이터 - 수 분. 일차 사이트와 동일. 데이터 동기화
- 핫: HVAC, 네트워크, 컴퓨터 - 수 시간. 미러사이트에 비해 데이터 복구 필요
- 웜: HVAC, 네트워크 - 수 일. 
- 콜드: HVA - 수 주. 
* 소유방식에 따른 구분
- 자체 이중화 : 독자적으로 백업 사이트 구축
- 공동 투자 : 여러 업체가 공동으로 출차하여 백업 사이트 구축. 모든 업체 동시 수용 곤란 및 사용 순위 결정 곤란
- 상용 서비스 : 전문업체에 위탁. 보안과 신뢰성 문제
- 상호 협약 : 유사한 환경에 있는 조직들이 재해 시 상호 도움을 주기로 약정.
  상호협약의 단점 : 계약 이행의 강제성 결여, 호환성 문제, 용량 문제, 시간적 제약(근무외 시간), 공유 기간 중 보안 유지의 복잡성
* 구축 시 고려사항
- 1차 사이트와 동일한 자연 재해의 노출 환경이면 안됨
- 합리적 수준의 하드웨어 및 소프트웨어의 (호환성 확보)가 보장
- 자원 가용성에 대한 보증을 얻기 위하여 작업 부하에 대한 감시 수행
- 복구 대상 응용의 우선순위에 대한 합의
- 주기적 테스트가 필요

비상조치팀: 초기 대응(인명구조, 피해확산 방지)
(피해)평가팀: 원인조사 -> 1차 피해평가 -> 재해선언
구호팀: 상세피해평가 -> 1차사이트로 이관지휘 -> 재해 종료 선언
위 2개는 꼭 나온데
* 2차사이트 업무 처리 용량
- Normal Level - 전체 업무를 처리하는데 필요한 정상적 수준
- SDO(Service Delivery Objective) - 대체 사이트에서 확보하고자 하는 최소한의 처리 능력 수준
- RML(Required Minimum Level) : 핵심 업무를 수행하는데 필요한 최소한의 처리 능력 수준
* BCP/DRP에서의 IS 감사인의 역할
- 정부 정책과 비교 : 계획의 (적절성), (최신성) 판단
- TEST 참여/미참여시의 역할 : 계획의 (효과성) 판단
- 오프사이트 스토리지 평가 : 계획의 (적절성), (최신성) 판단
- IS 및 사용자 부서 평가 : 직원들의 비상 대처 능력 평가
RTO 복구 목표 시간은 중단 비용과 함께 고려하여 총 비용이 적당한 때로 복구비용을 정한다.
백업 주기 산정 시 RPO를 반드시 고려하여야함. (백업주기<RPO)
* 오프사이트 저장소
- 일차 사이트와 동일한 재해에 노출되지 않는 안전한 장소에 데이터를 주기적으로 백업
* RAID
- 물리적으로 독립된 디스크에 데이터를 중복해서 저장하여 시스템 성능, 데이터 복구 및 무결성 보증 등에 사용
- Striping : 여러 디스크에 (분산)저장. 성능 향상. Level 0
- Mirroring : 동일 데이터를 동시에 여러 디스크에 동시 저장. 복구기능. Level 1
- Parity : 데이터가 누락되거나 덮어 쓰여졌는지의 여부 검증. 무결성 검증
* Application 복구 - 서버의 이중화
- Fail-Safe or Fail-Secure 장애 안전/보호. 장애로 인한 시스템 손상 예방을 위해 모든 기능이 정지
- Fail-Soft or Fail-Resilient 장애 완화/흡수. 장애시 비핵심 기능 정지. 핵심 기능만 작동 ex)방화벽의 bypass
- Fail-Over (Active-Passive) 장애 극복. 중복서버는 Active-Standby. 장애시 중복 설비나 대체 설비에서 서비스를 제공
- Fail-Tolerant 장애감내. Active-Active. 평상시에도 1차/2차 서버가 동시에 기능 제공. 로드 밸런싱 기능. 장애시에도 대부분 인식 못함.
​문제풀이 정리
도메인1​
감사 수임 용역 약정서(특정 감사 과제 수준) -> 감사헌장(IS 감사 기능의 수준)을 참조
준거성테스트(통제테스트)
- 통제 절차가 준수되었는지 판단. 통제 운영 환경이 효과적인지 테스트하는 것. 
* 통제시스템이 적절히 설계되었는지 평가하는 것은 준거성 테스트가 아닌, 준거성 테스트 이전 단계에서 이루어진다.
* 식별된 시스템 변경 사항들이 모두 승인을 받았다는 것을 보증하기 위한 올바른 테스트 방향은?
- 변경된 전체 목록에서부터 처음 변경 요청서가 작성되었을 시점까지 추적 (이렇게 해야 모든 변경에 대해서 승인이 이루어지지 않은 사례를 찾을 수 있음)
관련성 : 감사와 관련있어야함
신뢰성 : 원천(독립성, 조직내부보다는 외부(제3자)의 증거), 객관성(내용이 분명하고 판단이나 해석이 불필요한 증거), 증거제공자의 자격(전문성, 중립성, 권위가 있는 제공자로부터 받은 증거), 수집 시점(관련 사건의 발생 시기와 근접한 시기에 수집한 증거)
유용성 : 감사 목적 달성에 기여해야 하는 증거. 아니면 가치가 없다. 
충분성 : 다른 감사인도 동일한 감사 결론을 형성하게 할 만큼 완전하고, 적합하며, 설득력 있어야 한다.​
자의적 샘플링(=우발샘플링): 어떤 체계적인 기법을 따르지 않으면서 우발적인 기준에 따라 표본을 추출하는 기법
샘플의 크기가 작아지는 경우: 신뢰수준이 낮으면
정도: 허용되는 오차의 범위. 정도가 작으면 허용되는 오차의 범위가 작다는 것이므로 샘플 크기를 크게 해야함
도메인2​
위험에 비례하여 기준선 보안 요건을 수립하는 실무를 통해 달성할 수 있는 정보보호 거버넌스의 산출 결과는?  일련의 표준 보안 실무 절차를 개발하는 것은 투입 대비 가치에 근거한 정보보안을 제공하므로 가치 제공이다.
- 이사회 : 사업 우선순위 조정
- IS 운영위원회 : 프로젝트 우선순위 조정. 기업 내에 확산. 우선순위와 합의 도출. 의사소통채널 역할. IT부서와 사용자 부서 사시의 중재.
- 프로젝트 운영위원회 : 신규시스템으로 인해 영향을 받게 될 부서의 고위 대표자들로 구성. 따라서 응용시스템 구입을 위한 RFP를 승인하는 가장 적합한 주체
- 업무 프로세스 소유자 : 보안정책을 수립하고 그 과정을 감독해야 할 책임이 있음.
최고경영자-궁극적책임. 보안정책 수립과 유지.
보안관리자-보안 정책의 적합성을 주기적으로 평가.
IS감사인: 벤더의 "재무적 안정성, 운영 연속성"을 고려해야 함
IT관리자: 아웃소싱 환경에서 벤더의 성과를 감시해야함.
사용자부서: 거래의 승인, 데이터의 조정, 자산의 보관
기술 지원 관리자: 시스템 소프트웨어를 유지관리하는 시스템 프로그래머에 대한 책임이 있음​
시스템분석가: 응용 시스템 프로그램을 위한 사용자 요구사항 결정
정보시스템 설계와 프로그래밍 투입순서: 기능분석가->기술분석가->프로그래머
RFP: 구매 가격보다 제품 사양에 대한 고려가 더 중요한 경우
ITT: 제품 사양이 어느정도 표준화되어 있고 여러 경쟁 업체들이 유사한 제품을 공급하는 경우
상향식 접근법 : 부서의 실무를 가장 잘 반영. 위험 평가 결과를 잘 반영
하향식 접근법 : 전사적 정책과 충돌하지 않음. 일관성 보증. 
조직의 IT 기반구조를 보호하기 위한 최소한의 보안 표준: 보안 아키텍처
교차훈련
직무순화
직원 공모: 직무순환으로 이미 형성된 공모 관계를 끊을 수 있다.

* 겸임 가능한것.
변경/문제 관리자 - 품질 관리 담당자
보안관리자 - 품질보증
보안관리자 - DBA
응용프로그래머 - 시스템분석가
* 위험한 것
응용시스템프로그래머 - 테이프 관리자
시스템 개발자가 프로덕션 데이터에 접근하는것
프로덕션 환경으로 프로그램 이관을 수행할 책임을 수행하기에 가장 적합한 기능은? 품질보증, 보안관리자, DBA 등
=> 프로그램 개발 조직과 무관한 기능에서 이관업무를 수행.
=> 안되는것: 응용프로그래머, 시스템프로그래머, 시스템분석가
IPF 정보처리설비
통제그룹(IS감사인)은 오류의 원인을 파악하고 오류를 교정할 것을 요청한다. 직접적으로 교정의 주체가 되어서는 안됨. 독립성이 손상됨.
데이터 접근 권한은 데이터 소유자가 직접 부여. 소유자는 정보 자산에 대한 보안 대책을 유지할 궁극적 책임을 가지고 있다.
아웃소싱으로 인해서 기업은 전문분야에 몰입하여 사내 전문성 강화한다. 
아웃소싱 실패에 대한 책임은 고객사 경영진의 책임이지, 결코 아웃소서의 책임이 아니다. 
신뢰하던 통제 프레임이 벤더에게 적용되는 과정에서 약해지거나 간과될 수 있다.
재난: 하루이상의 긴 기간 동안 전체 처리 설비가 작동되지 않음으로 발생하는 서비스 중단 상황
재앙: 처리시설 파괴로 인해 발생하는 중단. 대체처리시설의 사용은 물론 원 상태로의 복귀 전략이 필요
BCP 개발 시 가장 먼저 풀요한 것은 복구 우선순위(위험 기반 시스템 등급 분류). 이것을 위해서 자산에 대한 목록이 필요한데 '모든'이 아닌, '핵심'적인 것을 대상으로.
효과적인 BIA를 위해서는 사용자 참여가 중요하다. BIA 에서 핵심복구시간과 복구우선순위는 이미 결정됨. 이후 복구전략 수립(이때 복구 대안의 효과 대비 비용 평가)-상세복구절차개발
구조적 워크스루 테스트(문서테스트): 담당자들이 모여서 자체적으로 직접 발표하며 수행하는것. 
=> BCP 테스트에서 주로 사용
BCP/DRP에서 가장 중요한 것은 인간생명의 보호이다.
도메인3​
- 사업사례(Business Case) - 프로젝트의 궁극적 동기와 기대 효과를 포괄적으로 정의한것. 
IS감사인은 컴퓨터 시스템 구입 제안에 대한 감사에서 명확한 사업사례에 의해 수립되었는지 확인해야함
프로젝트 시작 전에 사업사례가 명확히 수립되어야 한다. 프로젝트가 진행됨에 따라 변경이 생길 경우 반드시 승인이 필요함.
도메인4
- 프로그램 변경통제 절차: 운영자가 아닌, IS관리자와 감사인에 의해 변경 사항에 대한 검토가 이루어져야 함.
- 하드웨어 통제는 장비의 명령어들이 정확히 실행되는 것을 보증
- 패리티 체크 : 하나의 매체에서 다른 매체로 이전된 데이터의 정확성 검증

데이터베이스 아키텍쳐:
- 계층형 : 포인터가 하위 수준의 노드들로만 설정
- 네트워크형 : 안정적인 환경. 복잡한 상호관계X
- 관계형 : 다른 모델보다 구조의 변형이 용이 
  o 인덱싱 : 관계형 DB에서 성능개선. 레코드들을 각가의 키를 기준으로 목차를 만드는 것. 키 목록만을 검색하여 해당 레코드를 신속하게 찾음.
  o 정규화 (Normalization) : 무결성을 강조. 관계형 데이터베이스는 구조적/비구조적 질의를 만족시키기 위하여 필요한 테이블 정보의 양을 최소화하기 위하여 정규화 사용

                              관계형 데이터베이스(테이블간에 관계를 맺을 수 있는 상황)에서 중복을 최소화 하기 위해서 데이터를 구조화 하는 작업. 효율성은 감소.

                              정규화를 무조건 권고해서는 안되며 정당성 유무를 먼저 검토해야 한다.

참조 무결성 제한: 트리거를 통한 데이터 갱신(어떤 테이블의 프라이머리키에 변경이 일어나면 다른 테이블에 대응되는 외래키가 자동적으로 갱신되는것을 보장)
FEP(Front-End Processor): CPU의 반복적인 통신 업무를 덜어준다. 
다중화기(멀티플렉서): 다수의 인풋을 하나의 아웃풋으로
도메인5​
- 데이터소유자: 접근권한은 문서로 승인하며, 보안관리자에게 직접 전달해야함. 그리고 보안관리자가 제시한 분류체계에 따라 데이터 보안등급을 결정한다.
- 보안관리자: 데이터소유자의 도움을 받아 데이터접근권한 승인에 대한 검토를 정기적으로 수행해야함. 물리적, 기술적 보안을 제공
- 데이터관리인: 응용 내에서 보안을 실행
브루트포스 공격에는 '사용자이름 추측 어렵게'가 '패스워드 길이를 길게 하는것' 보다 더 효율적. 

전사적 보안정책을 경영진이 직접 수립하진 않는다. 승인하고 지원하고 리더십을 보여줄뿐. 적절한 직급의 고위 관리자들이 보안정책을 수립한다.

- 해당사업부서: 개발 감독

- 이사회: 궁극적책임​

- 보안관리자: 보안정책구현, 강제, 정기적보안정책 검토. 그러나 직접 개발하진 않는다.

* 보안사고의 원인

재연재해<외부인<내부인<오류,누락

- Data diddling: 원시 서류 자체를 변조, 위조해 끼워 넣거나 바꿔치기 하는 수법으로 자기 테이프나 디스크 속에 엑스트라 바이트를 만들어 두었다가 데이터를 추가하는 수법입니다. 자료를 코드로 바꾸면서 다른 것으로 바꿔치기하는 수법인데 원시자료 준비자, 자료 운반자 ,자료 용역처리자 그리고 데이터와 접근이 가능한 내부 인이 주로 저지릅니다. 예방법은 원시서류와 입력 데이터를 대조해 보고 셈틀 처리 결과가 예상 결과와 같은지 검토 하며 시스템 로그인파일과 수작업으로 작성된 관련 일지를 서로 비교 검토하는 작업을 정기적으로 실시하여야 합니다. 아주 직접적이며 초보적인 형태의 해킹이라고 할 수 있습니다. 예를 들어 은행원이 자신이 직접 단말기를 조작해 원하는 계좌로 돈을 빼내는 경우가 이에 해당 됩니다

​​

- 응용소프트웨어 패키지 구현시 파라미터가 올바로 설정되지 않는 것이 가장 큰 위험이다.

- 살라미기법: 436.75 금액에서 소수점 전체를 날리는것. 0.75를 횡령

- 트랩도어(백도어랑 비슷)란 시스템 보안이 제거된 비밀 통로로, 서비스 기술자나 유지ㆍ보수 프로그램 작성자의 접근 편의를 위해 시스템 설계자가 일부러 만들어 놓은 시스템의 보안 구멍을 의미합니다. 백도어(Backdoor)라고도 합니다. 대규모의 응용 프로그램이나 운영체제 개발에서는 코드 도중에 트랩도어라는 중단 부분을 설정해 쉽게 보수할 수 있도록 하고 있습니다.
최종 단계에서 삭제돼야 하는 트랩도어가 남아 있으면 컴퓨터 범죄에 악용되기도 합니다. ​
네트워크관리자: 주기적인 로그 분석과 리포팅
CERT: 사고처리를 다룰 때 로그 데이터를 이용
보안관리자: 로그의 모니터링과 관리
- 효과적인 DAC가 되려면 MAC과 결합하는 것이 좋다. MAC은 기본적으로 deny-all 정책이기 때문. 
토큰: 사용자의 소유물에 근거한 인증기법에서 사용자의 정당한 권리를 증명하는 객체
생일공격: 해시 값이 동일하지만 애용은 서로 다른 메시지를 발견하고자 할 때 사용
긍정적인증: 본인만이 제시할 수 있음 => 바이오/생체 정보, 신체적 특성에 근거한 인증
부정적인증(소극적인증): 본인이 아니라도 제시할 수 있음 => 패스워드나 토큰 등.
잘못된승인: 본인이 아닌데도 인증됨
잘못된기각: 본인이 맞는데도 인증이 안됨
재생(Replay)공격: 기계에 묻어서 남아있는 지문 등 잔여 생체 특성들을 이용한 공격
모방(Mimic)공격: 서면 위조, 음성 모사 등
싱글사인온: 한번 로그인으로 (하나의 계정으로) 전부 인증 => 패스워드 문법에 더 잘 부합하는 패스워드의 사용을 촉진 => 사용자 인증이 향상
=> 접근목록유지와 접근관리정책은 단순해짐.
=> IS 감사인의 가장 관심사항: 시스템 사인온 절차의 강도가 인증 절차의 강도를 결정하므로
다이얼-업(전화선, 모뎀, 공중전화망 등)​ 접근통제
=> 다이얼-백 회선의 사용
=> 로그온ID와 패스워드의 요구
=> 접근통제 소프트웨어
(X) => 전용회선의 사용
다이얼-백 통제 우회기법: 자동 착신 전환 
Sensitive(민감): 무결성이 더욱 요구되며 승인받지 않은 변경과 삭제로부터의 보호가 필요한 데이터 등급
Confidential(대외비): 조직 외부로 유출되면 심각한 위협과 손상이 유발될 수 있음
Private
Public
프라이버시 영향평가 (Privacy Impact Analysis): 관련 법규와 쟁점 식별 => 프라이버시 흐름 식별 => 법규 준수 방안 수립
소트프웨어 형상관리: 목적은 소프트웨어의 모듈 구성 및 기능과 관련하여 발생한 모든 변경 사항을 문서화=> 변경 이후에도 보안 요구사항을 지속적으로 충족함을 보증하는 근거.
DES와 MD5는 이미 크랙된 해시알고리즘
(가장단순)패킷필터링라우터: 처리속도빠름, 비용저렴, 보안성능 떨어짐, 패킷에 대한 로그 관리 어렵. 감사 증적 유지 X
프락시
=>서킷수준 게이트웨이​(모든 응용들을 중재하는 단일의 프락시 하나)
=>응용수준 게이트웨이(응용별로 따로 존재)=>더 강력
베스천호스트: 프락시가 설치되는 호스트. 그 자체가 방화벽은 아님
(가장강력)스크린트 서브넷 방화벽