• 1부. 감사 개요
  
• 1장. 내부IT감사기능의 효율적 구축
• 내부감사부서의 임무(우리가 여기에 있는 이유?)
  • 독립성: 위대한 신화
  • 공식감사 이외의 가치 추가
  • 경영자문감사
  • 경영자문감사를 위한 4가지 방법
  • 조기참여
  • 비공식감사
  • 지식 공유
  • 자체평가
  • 계속감사
  • 공식감사 이외의 가치 창출에 대한 최종 생각
  • 관계의 구축: 협력 파트너가 될 것인가? 치안 경찰이 될 것인가?
  • 협력 파트너십 구축을 위한 학습
  • IT감사팀의 역할
  • 애플리케이션 감사인(또는 통합 감사인)
  • 데이터 추출과 분석 전문가
  • IT감사인
  • 효과적인 IT감사팀의 구성과 유지
  • 경력직 IT감사인
  • IT전문가
  • 경력 IT감사인과 IT전문가: 최종 생각
  • 공동 소싱
  • 전문지식의 유지
  • 학습의 원천
  • 외부감사인과 내부인증기능의 관계
  • 요약
    
    
• 2장. 감사업무의 진행과정
  • 내부통제
  • 내부통제의 유형
  • 내부통제의 예
  • 감사대상의 결정
  • 감사 모집단의 정의
  • 감사 모집단의 순위 정하기
  • 감사대상의 결정: 최종 생각
  • 감사의 진행 단계
  • 계획수립
  • 감사 현장업무의 실시와 문서화
  • 문제점의 발견과 타당성 검증
  • 해법의 개발
  • 보고서 초안 작성과 발행
  • 문제점의 추적
  • 기준
  • 요약
    
    
• 2부. 감사 기법
  
• 3장. 전사적 수준 통제
  • 배경지식
  • 전사적 수준 통제 감사를 위한 테스트 단계
  • 지식 베이스
  • 종합 체크리스트
    
    
• 4장. 사이버보안 프로그램
  • 배경지식
  • 사이버보안 프로그램 감사단계
  • 지식 베이스
  • 종합 체크리스트
    
    
    
• 5장. 데이터센터와 재해복구
  • 배경지식
  • 데이터센터 감사의 기본사항
  • 물리적 보안과 환경관리
  • 시스템과 사이트 복구
  • 데이터센터 운영
  • 재해대비
  • 데이터센터 감사를 위한 테스트 단계
  • 주변과 외부의 위험 요소
  • 물리적 접근통제
  • 환경관리
  • 전력과 전기
  • 화재진압
  • 데이터센터 운영
  • 시스템 복원력
  • 데이터 백업과 복원
  • 재해복구계획
  • 지식 베이스
  • 종합 체크리스트
    
    
• 6장. 네트워킹 장치
  • 배경지식
  • 네트워크 감사의 요점
  • 프로토콜
  • OSI 모델
  • 라우터와 스위치
  • LAN, VLAN, WAN, WLAN
  • 방화벽
  • 스위치, 라우터, 방화벽의 감사
  • 네트워크 장비에 대한 일반적 감사단계
  • 추가 스위치 통제: 계층 2
  • 추가 라우터 통제: 계층 3
  • 추가 방화벽 통제
  • 무선 네트워크 장비에 대한 추가 통제
  • 도구와 기술
  • 지식 베이스
  • 종합 체크리스트
    
    
• 7장. 윈도우 서버
  • 배경지식
  • 윈도우 감사 기본 사항
  • 커맨드라인
  • 기본적인 커맨드라인 도구
  • 공통적인 명령
  • 서버 관리 도구
  • 감사의 실시
  • 윈도우 감사를 위한 테스트 단계
  • 초기 단계
  • 계정관리
  • 사용 권한관리
  • 네트워크 보안과 통제
  • 보안 모니터링과 기타의 일반통제
  • 도구와 기술
  • 지식 베이스
  • 종합 체크리스트
    
    
• 8장. 유닉스와 리눅스 운영체제
  • 배경지식
  • 유닉스와 리눅스 감사 기본 사항
  • 주요 개념
  • 파일 시스템 레이아웃과 내비게이션
  • 파일 시스템의 사용 권한
  • 사용자와 인증
  • 네트워크 서비스
  • 유닉스와 리눅스 감사를 위한 테스트 단계
  • 계정관리
  • 사용 권한관리
  • 네트워크 보안과 통제
  • 보안 모니터링과 기타 일반통제
  • 도구와 기술
  • 네트워크 취약점 스캐너
  • NMAP
  • 악성코드 탐지 도구
  • 패스워드 강도의 유효성 검증 도구
  • 호스트 기반 취약점 스캐너
  • Shell/Awk/etc
  • 지식 베이스
  • 종합 체크리스트
    
    
• 9장. 웹 서버와 웹 애플리케이션
  • 배경지식
  • 웹 감사의 기본 사항
  • 다중 구성 요소에 대한 일회 감사
  • 1부: 호스트 운영체제 감사를 위한 테스트 단계
  • 2부: 웹 서버 감사를 위한 테스트 단계
  • 3부: 웹 애플리케이션 감사를 위한 테스트 단계
  • 웹 애플리케이션에 대한 추가적 감사단계
  • 도구와 기술
  • 지식 베이스
  • 종합 체크리스트
    
    
• 10장.데이터베이스
  • 배경지식
  • 데이터베이스 감사의 기본 사항
  • 일반적인 데이터베이스 공급업체
  • 데이터베이스 구성 요소
  • NoSQL 데이터베이스 시스템
  • 데이터베이스 감사를 위한 테스트 단계
  • 초기 단계
  • 운영체제 보안
  • 계정관리
  • 사용 권한관리
  • 데이터 암호화
  • 보안 로그 모니터링과 관리
  • 도구와 기술
  • 감사 도구
  • 모니터링 도구
  • 암호화 도구
  • 지식 베이스
  • 종합 체크리스트
    
    
• 11장. 빅데이터와 데이터 리포지터리
  • 배경지식
  • 빅데이터와 데이터 리포지터리 감사의 기본 사항
  • 빅데이터와 데이터 리포지터리 감사를 위한 테스트 단계
  • 지식 베이스
  • 종합 체크리스트
    
    
• 12장. 스토리지
  • 배경지식
  • 스토리지 감사 기본 사항
  • 주요 스토리지 구성 요소
  • 스토리지 핵심 개념
  • 스토리지 감사를 위한 테스트 단계
  • 초기 단계
  • 계정관리
  • 스토리지 관리
  • 암호화와 권한관리
  • 보안 모니터링과 기타의 일반통제
  • 지식 베이스
  • 종합 체크리스트
    
    
• 13장. 가상화 환경
  • 배경지식
  • 상용과 오픈소스 프로젝트
  • 가상화 감사 기본 사항
  • 가상화 감사를 위한 테스트 단계
  • 초기 단계
  • 계정관리와 자원의 설치/제거
  • 가상 환경의 관리
  • 보안 모니터링과 추가적인 보안통제
  • 지식 베이스
  • 하이퍼바이저
  • 도구
  • 종합 체크리스트
    
    
• 14장.최종 사용자 컴퓨팅 기기
  • 배경지식
  • 1부: 윈도우와 맥 클라이언트 시스템 감사
  • 윈도우와 맥 감사 기본 사항
  • 윈도우와 맥 클라이언트 시스템 감사를 위한 테스트 단계
  • 도구와 기술
  • 지식 베이스
  • 2부: 모바일 장치 감사
  • 모바일 장치 감사 기본 사항
  • 모바일 장치 감사를 위한 테스트 단계
  • 추가 고려 사항
  • 도구와 기술
  • 지식 베이스
  • 종합 체크리스트
    
    
• 15장. 애플리케이션
  • 배경지식
  • 애플리케이션 감사의 기본 사항
  • 애플리케이션 감사를 위한 테스트 단계
  • 입력통제
  • 인터페이스 통제
  • 감사증적과 보안 모니터링
  • 계정관리
  • 사용 권한관리
  • 소프트웨어 변경통제
  • 백업과 복구
  • 데이터 보존, 분류, 사용자 참여
  • 운영체제, 데이터베이스, 기타 인프라 통제
  • 종합 체크리스트
    
• 16장. 클라우드 컴퓨팅과 아웃소싱 운영
  • 배경지식
  • 클라우드 컴퓨팅, 아웃소싱 운영 감사의 기본 사항
  • IT 시스템, 소프트웨어, 인프라 아웃소싱
  • IT 서비스 아웃소싱
  • IT 서비스 아웃소싱의 기타 고려 사항
  • 제3자 보고서와 증명
  • 아웃소싱 운영, 클라우드 컴퓨팅 감사를 위한 테스트 단계
  • 초기 단계
  • 공급업체의 선정과 계약
  • 계정관리와 데이터보안
  • 운영과 거버넌스
  • 법적 고려 사항과 법규 준수
  • 도구와 기술
  • 지식 베이스
  • 종합 체크리스트
    
    
• 17장. 회사 프로젝트
  • 배경지식
  • 프로젝트 감사의 기본 사항
  • 높은 수준의 프로젝트 감사목표
  • 프로젝트 감사의 기본 접근법
  • 워터폴과 애자일 소프트웨어 개발 방법론
  • 프로젝트 감사의 7가지 주요 부분
  • 회사 프로젝트 감사를 위한 테스트 단계
  • 프로젝트 전반 관리
  • 프로젝트 시작, 요구사항의 수집과 초기 설계
  • 상세 설계와 시스템 개발
  • 테스트
  • 구현 활동
  • 교육훈련
  • 프로젝트 마무리
  • 지식 베이스
  • 종합 체크리스트
    
    
• 18장. 신기술과 기타 기술
  • 배경지식
  • 신기술과 기타 기술 감사의 기본 사항
  • 범용 프레임워크
  • 모범 실무
  • 신기술과 기타 기술 감사를 위한 테스트 단계
  • 초기 단계
  • 계정관리
  • 사용 권한관리
  • 네트워크 보안과 통제
  • 보안 모니터링, 기타 일반통제
  • 종합 체크리스트
    
    
    
• 3부 프레임워크, 표준, 규제 법규, 위험관리
  
• 19장. 프레임워크와 표준
  • 내부IT통제, 프레임워크, 표준의 소개
  • COSO
  • COSO의 내부통제 정의
  • 내부통제의 주요 개념
  • 내부통제 통합 프레임워크
  • 전사적 위험관리 통합 프레임워크
  • 내부통제와 기업 위험관리 간행물 사이의 관계
  • IT지배구조
  • IT지배구조 성숙도 모델
  • COBIT
  • ITIL
  • ITIL 개념
  • ISO 27001
  • ISO 27001 개념
  • NIST 사이버보안 프레임워크
  • NSA INFOSEC 평가 방법론
  • NSA INFOSEC 평가 방법론 개념
  • 사전 평가 국면
  • 현장 활동 국면
  • 평가 후 국면
  • 프레임워크와 표준의 동향
  • 지식 베이스
    
    
• 20장. 규제 법규
  • 내부통제 관련 입법 소개
  • 법규의 IT감사에 대한 영향
  • 기업재무 규제의 역사
  • 2002년 제정된 사베인스-옥슬리법
  • 사베인스-옥슬리법이 상장기업에 미치는 영향
  • SOX법의 핵심 포인트
  • IT부서에 대한 SOX법의 영향
  • 여러 위치에 있는 회사의 SOX법 고려 사항
  • SOX법 규정 준수에 대한 제3자 서비스의 영향
  • SOX법 규정 준수에 필요한 특정 IT통제
  • SOX법 준거가 회사에 미치는 재무적 영향
  • 그램-리치-브라일리법
  • GLBA 요구사항
  • 연방금융기관검사협의회
  • 일반데이터보호규정
  • 기타 프라이버시 규정
  • 캘리포니아 보안침해 정보법(SB 1386)
  • 캘리포니아 소비자 프라이버시법
  • 캐나다 개인정보보호 및 전자문서법
  • 프라이버시 법규의 동향
  • 병원 진료기록정보 보호법
  • HIPAA 개인정보보호와 보안 규칙
  • 하이테크법
  • 적용 대상에 대한 HIPAA의 영향
  • EU와 바젤 II
  • 바젤 II 자본협약
  • 결제 카드업계 데이터보안 표준
  • 결제 카드 산업에 대한 PCI의 영향
  • 기타 규제 법규의 동향
  • 지식 베이스
    
    
• 21장. 위험관리
  • 위험관리의 이익
  • 경영진의 시각에서 본 위험관리
  • 정량적 위험분석과 정성적 위험분석
  • 정량적 위험분석
  • 위험의 구성 요소
  • 실제 적용 예
  • 위험에 대한 대책
  • 부정확성의 일반적 원인
  • 정량적 위험분석의 실무
  • 정성적 위험분석
  • IT 위험관리 순환 사이클
  • 국면 1: 정보자산의 식별
  • 국면 2: 위협의 정량화와 정성화
  • 국면 3: 취약점 평가
  • 국면 4: 통제 결함의 개선
  • 국면 5: 잔여위험관리
  • 제3자 위험
  • 위험의 식별
  • 위험평가
  • 개선책
  • 모니터링과 보고
  • 수식의 요약
  • 지식 베이스
    
    
    
    

[p.12 : 3문단 1행]
맥그우힐 출판사
->
맥그로우힐 출판사

[p.49 : 아래에서 4행]
감사인은 문제점을 감추라는 부당한 압력에 굴복하지 말고,‘일을 바로 처리하게’ 허락받았다고 믿어야 한다.
->
감사인은 부당한 압력에 굴복해 문제점을 덮어서는 안 되며, 주어진 업무를 올바르게 처리해야 한다.

[p.52 : 아래서 12행]
IT 부서 직원들과
->
IT 사람들과

[p.52 : 아래서 9행]
IT 부서 직원들이
->
IT 사람들이

[p.52 : 아래서 7행]
IT부서 직원들이
->
IT 사람들이

[p.53 : 아래서 5행]
감사인은 팀과 내부통제 운용 방식에 대한 브레인스토밍을 두려워 해서는 안 된다.
->
(삭제)

[p.72 : 4행]
IT부서의
->
IT조직의

[p.72 : 아래서 4행]
비즈니스 애플리케이션
->
업무용 애플리케이션

[p.76 : 아래서 3행]
기본적인 비즈니스 기능
->
기본적인 업무 기능

[p.77 : 그림 1-2]
비즈니스 프로세스
->
업무 프로세스

데이터센터 설비
->
데이터센터 시설

[p.77 : 1행]
비즈니스 프로세스를
->
업무 프로세스를

[p.77 : 아래서 1행]
비즈니스 애플리케이션 시스템
->
업무용 애플리케이션 시스템

[p.77 : 아래서 1행]
비즈니스 또는 재무 분야의
->
사업부서나 재무부서의

[p.78 : 5행]
비즈니스 배경을 가진 또는 애플리케이션의 지원을 받는 비즈니스 프로세스를 잘 이해하고 있는 감사인들은 IT감사부서에서 강력한 구성원이 될 수 있다. IT감사인들은 시스템 내에 설정된 비즈니스 통제기능의 실행을 평가하는 데 필요한 지식을 갖추고 있기 때문이다.
->
애플리케이션의 지원을 받는 업무 프로세스를 잘 이해하고 있거나 사업부서에 근무한 적이 있는 IT감사인들은 감사부서의 든든한 구성원이 될 수 있다. IT감사인들은 시스템 내에 설정된 업무 연관 통제의 실행을 평가하는 데 필요한 지식을 갖추고 있기 때문이다.

[p.78 : 아래서 12행]
응용시스템의 가용성이
->
애플리케이션 시스템의 가용성이

[p.80-81 : 아래서 9행부터]
응용시스템의 사용 방법을 이해하는 비즈니스 사람들과는 반대로 이러한 감사팀은 일반적으로 IT전문가로 구성된다. 데이터베이스 계층과 그 하부는 이들 IT감사인의 영역을 구성한다. 애플리케이션 감사는 필요에 따라 IT감사인의 지원하에 통합 감사인이나 재무감사인이 진행한다. 예를 들어 IT감사인은 특정 애플리케이션에 의뢰하면서 데이터베이스 계층과 그 하부를 살펴볼 것이다(IT환경에 대한 대규모 감사에서 그러한 항목들이 사전에 다뤄지지 않았다고 가정한다). IT감사인은 전반 시스템 접근관리 및 변경통제와 같은 일부 일반통제와 응용통제에 대한 검토를 도울 수 있다. 그러나 통합 감사인이나 재무감사인은 특정한 비즈니스 응용에 어떤 종류의 업무분장과 데이터 무결성 통제가 필요한지를 이해하기에 보다 나은 위치에 있으므로 그에 대한 지식을 갖추고 있어야 한다.
->
애플리케이션 시스템의 사용법을 이해하는 사업부서 사람들과는 반대로 이들 감사팀은 일반적으로 IT전문가로 구성된다. 데이터베이스 계층과 그 하부는 이들 IT감사인의 영역을 구성한다. 애플리케이션 감사는 필요에 따라 IT감사인의 지원 하에 통합감사인이나 재무감사인이 진행한다. 예를 들어 데이터베이스 계층과 그 하부는 특정 애플리케이션에 적합하므로, IT감사인은 이들을 자세히 살펴볼 수 있을 것이다(IT환경에 대한 대규모 감사에서 그러한 항목들이 사전에 다뤄지지 않았다고 가정함). IT감사인은 전반 시스템 접근관리 및 변경통제 등, 일반적인 애플리케이션 통제에 대한 검토도 일부 도울 수 있다. 그렇지만, 통합감사인이나 재무감사인은 특정 업무용 애플리케이션에 어떤 유형의 업무분장과 데이터 무결성 통제가 필요한지에 대한 지식을 당연히 갖추고 있을 것이다. 그것을 이해하기에 보다 좋은 위치에 있기 때문이다.
한편, 이들 감사인은 해당 업무에 대한 지식을 갖추지 못한 ‘기술두뇌’에 불과한 자가 아니라는 점이 중요하다. 기업가치의 실질적인 증대와 내부통제의 효율적 증진을 위해, 감사인들은 자신의 노력을 업무전반의 프로세스 및 우선순위에 연계시킬 수 있어야 한다. 심지어 핵심 기술 관련 구성부문을 살펴볼 때도 그렇다. 비즈니스 업무 맥락을 고려하지 않은 감사인은 자신의 역량을 위험평가에 국한시키는 꼴이 될 것이다.

[p.82 : 2행]
그러나 이 논의의 초점을 IT감사인에 게 맞추고자 한다. 이들은 스택의 모든 계층에서 작업하지만 비즈니스 응용통제의 좀 더 세부적인 사항 검토에 대해서는 재무 또는 통합 감사인에 의존한다.
->
여기서는, 이 논의의 초점을 스택의 모든 계층에서 업무를 수행하지만 업무용 애플리케이션 통제(응용통제)application controls의 좀 더 세부적인 사항 검토에 대해서는 재무감사인 또는 통합감사인에 의존하는, 말하자면 IT감사인에 두도록 한다.

[p.87 : 11행]
지식‘과함께
->
지식‘과 함께

[p.88 : 8행]
세부사항을 잃지 않고 기술적 세부사항을 파헤칠 수 있다.
->
큰 그림(숲)을 놓치지 않으면서 기술적 세부사항(나무)을 파악할 수 있다.

[p.88 : 아래서 3행]
매일 특정 기술에 영향을 다루지 않을 의지다.
->
어떠한 특정 기술을 매일 직접적으로 다루지는 않는다.

[p.92 : 아래서 1행]
도움을 제공하는
->
도움을 제공할

[p.93 : 3행]
IT부서의
->
IT조직의

[p.105 : 8행]
서버의 배치, 관리를 위해 중앙집중식 유닉스와 리눅스 관리 부문에서 사용하는 프로세스를 검토하는 일이 또 하나의 예가 된다.
->
중앙집중형 유닉스・리눅스 관리부서에서 서버의 설치, 관리에 적용하는 프로세스도 감사인의 검토 대상이 될 수 있다.

[p.105 : 6행]
이에는 계정관리 변경관리 문제점 , 관리 패치, patch 관리 보안 모니터링 환경 전반에 적용되는 기타 프로세스 등 관리적 성격의 프로세스들이 있다.
->
이러한 환경관리에는 계정관리, 변경관리, 문제점 관리, 패치 patch 관리, 보안 모니터링 환경 전반에 적용되는 기타 프로세스 등 관리적 성격의 프로세스들이 포함된다.

[p.105 : 아래서 6행]
이러한 감사는 전체 유닉스와 리눅스 서버 환경에 적용되는 모든 프로세스(예 , 패치 관리와 접속 검토) 와 새 서버 배포에 사용된 표준적인 구성(환경설정configuration)에 대한 보안 검토를 그 범위로 다룰 수 있다. 따라서 재무감사계획서가 유닉스 서버에 존재하는 특정 애플리케이션의 감사를 요구하는 경우 해당 감사에 참여한 담당자는 해당 서버를 관리하기 위한 프로세스의 이해에 시간을 소비하지 않고(이미 중앙집중식감사에서 이해했음) 특정106서버의 보안과 환경설정만을 전적으로 감사할 수 있을 것이다.
->
이러한 감사는 새 서버 설치에 적용된 구성(환경설정configuration)표준에 대한 보안 검토 및 유닉스・리눅스 서버 환경 전체에 적용되는 모든 프로세스(예, 패치 관리와 액세스 관찰)를 포괄할 수 있다. 여기서, 재무감사인들이 유닉스 서버에 상주하는 특정 재무 애플리케이션의 감사를 계획한다고 가정해보자. 이 감사에 참여할 당신은 해당 서버 관리에 대한 프로세스를 이해하는데 시간을 소비하지 않고(이미 중앙집중식 감사에서 파악했으므로) 해당 서버의 보안 및 환경설정의 감사에만 집중할 수 있다.

[p.105 : 아래서 7행]
다른 예로, 서버의 배포와 관리를 위해 중앙집중식 유닉스와 리눅스 관리 기능에서 사용되는 프로세스가 검토 대상이 될 수 있다.
->
(삭제)

[p.106 : 6행]
예를 들어 각 사이트에서 환경을 감사하지만 네트워크의 구성과 지원은 중앙 집중화돼 IT있다고 가정해보자. 전원 빠짐없이 각 사이트를 감사하는 동안에 네트워크 그룹과 대화하는 것은 비효율적이다. 그렇게 하는 대신 네트워크의 구성과 지원의 프로세스들을 담당해주는 한곳에 대한 감사를 수행한 다음 사이트들에 대한 감사에서 그 지역을 해당 영역의 범위로 규정한다.
->
예건대, 당신이 각 사이트에서 IT환경을 감사한다고 가정해보자. 그런대, 네트워크의 구성과 지원은 중앙 집중화돼있다. 이 경우 사이트 각각 및 전체를 감사할 때 마다, 네트워크 그룹과 해당 프로세스를 논의하는 것은 비효율적이다. 사이트 감사와는 별개로 해당 프로세스를 다루는 감사를 일회 실시하여 그 분야를 자세히 살펴보는 것이 바람직하다.

[p.106 : 참고 1행]
잠재적 감사를
->
잠재적 감사영역을

[p.107 : 1행]
비즈니스 응용과 프로세스
->
업무용 앱과 업무 프로세스

[p.107 : 2행]
비즈니스 애플리케이션이나 업무 프로세스
->
업무용 앱이나 업무 프로세스

[p.107 : 2행]
감사인은 각 비즈니스 애플리케이션이나 업무 프로세스5에 대한 잠재적 감사를 계획할 수 있을 것이다. IT감사 영역에서 또는 재무감사 영역 중 어느 쪽에서 이러한 감사를 수행하는 것이 더 효과적인지 여부를 정해야 한다. 여러 가지 면에서 볼 때 재무감사인이 이러한 감사를 수행하는 것이 가장 합리적이다. 재무감사인은 조달( 취득) 프로세스 감사의 적절한 수행 시기를 정하는 데 가장 적합하다. 재무감사인들이 그 결정을 내린다면 조달 감사에 포함돼야 할 관련 시스템 측면(예를 들어 조달 애플리케이션이 상주하는 서버 시스템의 소프트웨어 변경통제 시스템의 재해복구계획 등에 대한 검토)을 정해 달라고 요구할 수 있다.
->
당신(IT감사인)은 각 업무용 애플리케이션이나 업무 프로세스5 별 잠정적 감사계획도 세울 수 있을 것이다. IT감사 영역 또는 재무(재무제표)감사 영역 중 어느 쪽에서 이 감사를 수행하는 것이 더 효과적인지 여부를 판단해야 한다. 여러 측면에서, 재무감사인이 수행하는 것이 가장 합리적이다. 아무래도 조달(취득) 프로세스 감사의 수행 시기를 정하는 데 가장 적합한 위치에 있을 것이기 때문이다. 만약 재무감사인이 수행 시기에 대한 결정을 실제로 내리는 경우, 조달 감사에 포함돼야 할 관련 시스템 측면(예; 조달 애플리케이션이 상주하는 해당 서버, 시스템소프트웨어 변경통제, 시스템의 재해복구계획 등에 대한 검토)의 결정은 당신에게 요청할 수 있다.

[p.107 : 아래서 10행]
비즈니스가 제공하는 서비스나 상품에 따라 특정 규정에 대한 책임이 수반된다.
->
기업은 공급하는 재화나 용역에 따라, 특정 규정에 대한 준수 책임을 지기도 한다.

[p.128 : 아래서 3행]
생산코드
->
프러덕션 코드

[p.128 : 아래서 1행]
생산코드
->
프러덕션 코드

[p.140 : 아래서 7행]
‘권한 허용 관리’절에
->
‘사용 권한관리’ 절에

[p.154 : 2행]
중요한 데이터센터와 시스템에 대한 공식적인 위협과 위험평가의 수행
->
중요 데이터센터와 시스템이 직면한 위협, 위험에 대한 공식적인 평가

[p.154 : 3행]
해당 계획달성에 대한 위험의 평가
->
해당 계획의 달성이 저해될 위험의 평가

[p.158 : 5행]
12.직원이 아니 사람
->
12. 직원이 아닌 사람

[p.159 : 아래서 5행]
있다는 설명할 수 없게 돼
->
있다는 설명을 할 수 없게 돼

[p.168 : 아래서 9행]
새로운 윈도우 시스템 배포에
->
윈도우 신 시스템 배치에

[p.168 : 아래서 5행]
새로운 유닉스와 리눅스 시스템 배포에
->
닉스와 리눅스 신 시스템 배치에

[p.179 : 아래서 11행]
대신 일종의 비즈니스적 결정이어야 한다.
->
그것은 일종의 경영 의사결정이어야 한다.

[p.179 : 아래서 9행]
비즈니스 (IT와 반대됨) 관리가
->
경영(IT와 대비되는) 관리가

[p.184 아래서 2,3행]
배포
->
배치

[p.188 : 아래서 8행]
비즈니스 애플리케이션
->
업무용 애플리케이션

[p.168 : 아래서 2행]
비즈니스 팀
->
업무팀

[p.190 : 8행]
프레임워크framework가
->
틀framework이

[p.191 : 11행]
다양한 비즈니스 직무,
->
조직내 여러 부서들이,

[p.196 : 아래서 4행]
격차에 대한 가시성을
->
눈에 띄는 통제 결함들을

[p.197 : 6행]
이상적인 경우 내부감사와 외부감사는 동일한 통제와 잠재적 차이를 찾는다.
->
이상적인 경우, 내부감사인과 외부감사인이 발견한 통제와 잠재적 통제결함은 다르지 않을 것이다.

[p.197 : 아래서 4행]
(특정 고부가가치 응용 평가)
->
(고가의 특정한 애플리케이션 평가)

[p.204 : 12행]
유일한 영역은 통제센터 운영과 테이프 작업이 될 수 있을 것이다.
->
유일한 영역은 대체로 통제센터와 테이프 작업이다.

[p.206 : ５행]
데이터센터의 운영 센터로
->
데이터센터의 운영 본부로

[p.206 : 아래서 9행]
비즈니스 기능을 자동화하는 데 활용되므로 비즈니스 운영 시
->
업무 기능을 자동화하는 데 활용되므로 업무 처리 시

[p.206 : 아래서 8행]
중요한 비즈니스 운영을 수행하려면
->
중요한 업무를 처리하려면

[p.206 : 아래서 6행]
유형의 통제기능을
->
통제 유형을

[p.206 : 아래서 6행]
이러한 통제기능들은 전력, 컴퓨팅 환경, 광역 통신망 WAN, Wide Area Network을 보호하게 설계된다.
->
다양한 통제유형들을 설계 시 반영해 전력, 컴퓨팅 환경, 광역 통신망 WAN, Wide Area Network을 보호하도록 한다.

[p.208 : ４행]
정전, 긴급 상황과 경보 조건에 대한
->
정전, 긴급 상황 및 경보 발생 시의

[p.208 : 9행]
식별하고 측정
->
식별, 측정

[p.210 : 아래서 10행]
가능성이 줄어든다.
->
가능성을 줄일 수 있다.

[p.211 : 9행]
가장 결정적인
->
욕구가 아주 강한

[p.212 : 7행]
비즈니스 위험
->
사업위험

[p.218 : 9행]
‘최소한의 필요한 접근 ‘ minimumnecessary access’ 이라는 철학이
->
접근권한 최소화 ‘ minimumnecessary access’ 원칙이

[p.225 : 아래서 9행]
전력이 조절하는지 확인한다.
->
전력을 조절하는지 확인한다.

[p.230 : 7행]
26단계를
->
단계26을

[p.231 : 10행]
화재 연장 지역의
->
화재 확산 지역의

[p.232 : 11행]
산소를 대체할 수 있으므로
->
산소를 추방할 수 있으므로

[p.236 : 아래서 8행]
접근권한과 같은
->
접근허가 등의

[p.239 : 6행]
배포 지연이
->
배치 지연이

[p.242 : 2행]
중단 시간으로 인해 상당한 비용이나 비즈니스 손실이 발생하고 시스템 가동 중단 시간을 견딜 수 없다면
->
중단으로 인해 비용발생이나 매출손실이 상당하고 시스템 가동중단 동안을 견딜 수 없다면,

[p.243 : 8행]
(종종 목표복구시점RPO 이라고도 함)
->
(종종 목표복구지점RPO 이라고도 함)

[p.246 : 6행]
(종종 복구시간 목표 또는 PTO 이라고도 함)
->
(종종 목표복구시간 또는 PTO 이라고도 함)

[p.242 : 아래서 4행]
데이터센터에 있는 시스템 샘플의 경우 시스템 중복성의 적절한 수준이 요구되는 시스템 가용성 수준에 사용되고 있는지 확인한다.
->
데이터센터에 있는 시스템 중 샘플 하나를 선택해, 필요한 시스템 가용성 수준에 대비해서 적절한 시스템 중복성 수준이 사용되고 있는지 확인한다.

[p.248 : 5행]
41. 비즈니스팀이
->
41. 업무 팀들이

[p.248 : 8행]
해당 비즈니스에 정통
->
해당 업무에 정통

[p.248 : 10행]
비즈니스 요구와
->
업무상의 요구와

[p.248 : 11행]
전체 비즈니스에
->
업무 전체에

[p.248 : 아래서 11행]
비즈니스에 대한 프로세스와
->
업무 프로세스와

[p.248 : 아래서 2행]
(또는 비즈니스 영역별로
->
(또는 업무 영역별로

[p.249 : 2행]
비즈니스가 잃을 수 있는
->
회사가 잃을 수 있는

[p.252 : 아래서 2행]
41. 비즈니스팀이
->
41. 업무 팀들이

[p.297 : 1행]
고유한 식별자를 주소의 일부분이다.
->
고유한 식별자를 주소의 일부로 포함하고 있다.

[p.306 : 아래서 3행]
약어나 서비스 명칭들이다.
->
약어나 서비스 명칭들이 있다.

[p.316 : 1행]
시스인너털 도구
->
시스인너털스 도구

[p.316 : 1행]
,공격자와 캐기 좋아하는
->
공격자, 캐기 좋아하는

[p.319 : 아래서 12행]
정당한 비즈니스 요구에 대해서만
->
업무상 정당한 필요가 있는 경우에만

[p.323 : 표 7-2 아래서 3행]
계정 잠금 기간
->
계정잠금 지속시간

[p.324 : 2행]
사용자 권한user rights과
->
사용자 권리user rights와

[p.325 : 10행]
거절(주의한다)
->
거절(주의깊게 보자!)

[p.326 : 7행]
사용 권한이
->
사용 권한permissions(사용자에게 허용된 권한)이

[p.327 : 3행]
사업상의
->
업무상의

[p.328 : 6행]
정당한 비즈니스 요구가
->
업무상 정당한 필요가

[p.339 : 윈도우 서버 감사용 체크리스트 6번]
6 ----정당한 비즈니스 요구에 대해서만
->
6 ---- 업무상 정당한 필요가 있는 경우에만

[p.342 : 아래서 8행]
호환되는 V Release 4SVR4를
->
호환되는 SystemV Release 4SVR4를

[p.349 그림8-1 좌측 아래]
게산된 결과
->
누적의 결과

[p.349 그림8-1 좌측 아래]
결과 사용권한 ->
사용권한의 귀착

[p.351 : 아래 코드 1행]
account:password:UID:GID:GECOS:directory:shell
->
account:password::lastchange:min:max:warn:inactive:expired:reserved

[p.355 : 아래서 3행]
적합한 업무상 필요한 경우에만
->
업무상 정당한 필요가 있는 경우에만

[p.363 : 아래서 11행]
(따라서 사용자가 자신이 먼저 로그인한 다음 공유 계정에 접근하려면 su나 sudo를 사용하게 요구되고 감사증적의 생성이다).
->
(그래서 사용자에게 우선 본인 자격으로 로그인하게 한 다음 su나 sudo를 통해 공유 계정에 액세스하도록 해, 감사증적이 생성되도록 한다).

[p.371 : 4행]
그러나 대부분의 사용자 경로를
->
그러나 대부분의 사용자는 경로를

[p.371 : 아래서 7행]
패스워드 파일에서 자신의 항목entry을 보고 사용자의 홈 디렉터리를 확인할 수 있다.
->
패스워드 파일상의 사용자 앤트리 명령어entry를 보면, 그의 홈 디렉터리를 확인할 수 있다.

[p.371 : 아래서 3행]
사용자와 시스템 계정만
->
해당 사용자와 시스템 계정만

[p.373 : 1행]
16.---일반적으로 소유자만
->
16.---일반적으로 당해 소유자만

[p.374 : 주석 1행]
10. 판단표본(judmental sample)은 비통계적 표본이나 주관적 표본이라고 한다.
->
10. 판단표본(judmental sample)은 비통계적 표본이나 주관적 표본의 의미로 사용된다.

[p.377 : 2행]
상4 상8]
공격자가 이 복사된 셸을 실행하면 마치 그 SUID 파일의 소유자인 것처럼 실행될 것이다.
->
공격자가 이 복사된 셸을 실행시키면, 그것은 마치 그 SUID 파일의 소유자인 것처럼 움직일 것이다.

[p.377 : 4행]
어느 명령이든 실행할 수 있다.
->
어느 명령이든 실행시킬 수 있다.

[p.377 : 8행]
사람이 실행하지 않으면 완료되지 않는다.
->
사람이 그것을 돌려보지 않으면 완료되지 않는다.

[p.379 : 아래서 5행]
셸 위치를
->
당신의 셸 위치를

[p.379 : 아래서 3행]
셸 파일의
->
당신 셸 파일의

[p.379 : 아래서 1행]
새 셸 파일을
->
당신의 새 셸 파일을

[p.380 : 2행]
패스워드 파일에서 다른 사용자를 선택해 소유권을 가급적 동료 감사인에게 이전한다.
->
소유권을 이전시켜줄 다른 사용자를 패스워드 파일에서 선택한다. 가급적 동료 감사인이 바람직하다.

[p.380 : 아래서 11행]
8. whoami 명령을 실행한다. 명령 실행자는 이제 다른 사용자고 타인의 계정을 인계했다는 것을 알게 될 것이다.
->
8. whoami 명령을 실행시켜보니, 당신은 이제 다른 사용자이며 그의 계정을 인수했음을 알게 될 것이다.

[p.380 : 아래서 5행]
언마스크의
-> umask의

[p.384 : 3행]
해석하는 데도
->
해석할 경우에도

[p.384 : 9행]
합당한 업무상 필요가
->
업무상 정당한 필요가

[p.386 : 7행]
네트워크 서비스 관점에서 시스템의 현재 보안 수준에 대한 스냅샷snapshot을 제공한다.
->
이런 검사를 통해 현행 시스템 보안 수준에 대한 일종의 스냅사진(네트워크 서비스 관점에서)을 볼 수 있을 것이다.

[p.403 : 9행]
적어도 3∼6게월
->
적어도 3∼6개월

[p.412 : 계정관리 감사용 체크리스트 3행]
16.---일반적으로 소유자만
->
16.---일반적으로 당해 소유자만

[p.418 : 아래서 6행]
감사 애플리케이션을
->
애플리케이션 감사를

[p.423 : 4행]
특성에 따라 봇들의 회사 사이트 크롤crawl을 원치 않을 것이다.
->
특성에 따라, 귀사는 봇들에 의한 회사 내 특정 사이트의 크롤crawl을 원치 않을 수도 있다.

[p.425 : 아래서 4행]
최소한의 정보를 제공하도록 설정된다.
->
최소한의 정보를 제공한다.

[p.433 : 3행]
보안 사이트를 탐색하는 동안 사용자가 메시지를 팝업하게 사용자를 둔감화시키기 시작하는 점이다.
->
보안 사이트를 탐색 중인 사용자가 팝업 메시지에 둔감해지기 시작한다는 점이다.

[p.434 : 아래서 6행]
유지보수하고 있다.
->
제공하고 있다.

[p.435 :3행]
이는
->
이것은

[p.437 : 1행]
다시 강조하지만 확실한 유효성 검증법을 채용한다.
->
다시 말하지만, 적극적인 유효성 검사법을 채택해보자.

[p.438 : 아래서 12행]
개발팀과 웹
->
개발팀 및 웹

[p.439 : 11행]
웹 개발팀과의 정책준수를 알아본다.
->
웹 개발팀과 정책준거compliance에 대한 논의를 해보자.

[p.441 : 3행]
이해하는
->
파악해보는

[p.442 : 2행]
잘못 관리된 오류조건은
->
오류발생 요건에 대한 부실한 관리는

[p.443 : 아래서 4행]
유지보수하고 있다.
->
제공하고 있다.

[p.446 :４행]
유지보수한다.
->
제공하고 있다.

[p.450 : 2행]
세트(collection)이라고 할 수 있다.
->
세트(collection)라는 의미로 사용될 수 있다.

[p.470 : 3행]
5.--합당한 비즈니스 요구가 있을 때만
->
5.--업무상 정당한 필요가 있는 경우에만

[p.477 : 2행]
제한하게 한다. ----또한 ---- 기록되고 있는지 확인한다.
->
제한해보자. SQL. 또한 --- 기록되고 있는지 확인해보자.

[p.478 : 아래서 10행]
PUBLIC에 부여된 권한을 강조 표시한 모든 권한 목록을 수집해 시작한다. 필요한 권한이 있는 DBA와 알아본다.
->
모든 사용권한의 목록을 수집한 다음, PUBLIC에 부여된 사용권한은 강조 표시하면서 시작해보자. 어떤 사용권한이 필요한지를 DBA와 논의해보자.

[p.479 : 5행]
현재 사용 중인 데이터는 접근과 변경에 도움이 되는 방식으로 쉽게 암호화하고 암호 해독되지 않는다.
->
현재 사용 중인 데이터는 액세스와 변경에 도움이 되도록, 쉽게 암호화 및 암호 해독이 되는 건 아니다.

[p.486상 : 6행]
이는 인간으로 감사인이 도구 사용을 통해 가져오는 부가가치다.
->
이는 인간 감사인이 도구 사용을 통해 얻은 부가가치다.

[p.491 : 데이터 베이스 감사용 체크리스트 6행]
5.--합당한 비즈니스 요구가 있을 때만
->
5.-- 업무상 정당한 필요가 있는 경우에만

[p.493 : 10행]
• 데이터 리포지터리repository 감사방법
->
•데이터 리포지터리data repository(데이터 저장소) 감사방법

[p.494 : 4행]
• 데이터베이스는 10장에서 자세히 설명했다.
->
• 데이터베이스(10장에서 자세히 설명했다.)

[p.494 : 5행]
• 파일 서버 사람이나 시스템의 파일에 대한 접근을 제공하는 데 사용된다.
->
• 파일 서버( 사람이나 시스템이 파일에 접근할 수 있도록 해준다.)

[p.494 : 6행]
• Wikis, 웹 기반 콘텐츠 편집, 공유 플랫폼
->
• 위키백과Wikis(웹 기반 콘텐츠의 편집 및 공유 플랫폼)

[p.494 : 7행]
• SharePoint, 마이크로소프트 웹 협업 플랫폼
->
• 셰어포인트SharePoint(마이크로소프트의 웹 협업 플랫폼)

[p.494 : 8행]
• Bitbucket, 웹 기반 버전 제어 시스템
->
• 빗버킷Bitbucket(웹 기반 버전 제어 시스템)

[p.494 : 9행]
• 하둡Hadoop이나Splunk, 빅데이터 저장소
->
•빅데이터 리포지터리(예컨대, 하둡Hadoop이나 스플렁크Splunk)

[p.495 : 주석 1번 1행]
1987년까지도
->
1887년까지도

[p.497 : 3행]
시스템 관리 애플리케이션 관리 담당자와의
->
시스템 관리자 혹은 애플리케이션 관리자와의

[p.499 : 5행]
대규모의 데이터 세트로 작업하는 조직은 다른 소프트웨어나 커맨드라인 스크립트를 사용해 데이터로 작업할 수 있다.
->
큰 데이터 세트를 다루는 조직은 별개의 소프트웨어나 커맨드라인 스크립트를 사용해 당해 데이터에 대한 작업을 할 수 있다.

[p.501 :　7행]
5. --- 정당한 업무상 요구가
->
5. --- 업무상 정당한 필요가

[p.501 : 12행]
최소 특권의 접근
->
접근권한의 최소화

[p.506 : 아래서 7행]
데이터 추가의 영향을 이해한다.
->
데이터 추가의 영향을 파악해야 한다.

[p.509 : 빅테이터와 데이터 리포지터리 감사용 체크리스트 3행]
5. --- 정당한 업무상 요구가
->
5.--- 업무상 정당한 필요가

[p.514 :　４행]
RAID-1: Mirroring:
->
RAID-1: 미러링Mirroring:

[p.514 : 아래서 3행]
RAID-5: 패리티를 가진 안정성
->
RAID-5: 패리티를 통한 안정성

[p.515 : 그림 12-4 설명]
RAID-5: 패리티 추가 형태의 신뢰성
->
RAID-5: 패리티를 통한 안정성

[p.515 : 아래서 8행]
RAID-10: 고성능 스트라이핑 미러링된 세그먼트
->
RAID-10: 미러링된 세그먼트의 고성능 스트라이핑

[p.516 : 그림 12-5]
미러링된 세그먼트가 있는 고성능 스트라이핑
->
미러링된 세그먼트의 고성능 스트라이핑

[p.517 :２행]
DASDirect Attached Storage는
->
DASDirect Attached Storage 직접부착형 스토리지는

[p.517 : 9행]
NASNetwork Attached Storagee 네트워크 부착 스토리지 장치는
->
NASNetwork Attached Storagee 네트워크 부착형 스토리지 장치는

[p.518 : 아래서 2행]
CASContent Addressed Storage는
->
CASContent Addressed Storage 컨텐츠 지정형 스토리지는

[p.519 : 9행]
RPO(목표복구시점)는
->
RPO(목표복구지점)는

[p.524 : 아래서 6행]
4. --- 합당한 업무 요구가
->
4. --- 정당한 업무 요건이

[525 : 10행]
계정 샘플을 확보해 활동 중인 직원이 해당 계정을 소유하고 있으며 각 직원이 관리상의 접근을 위해 합당한 업무 요구사항을 제시하는지 검증한다.
->
계정 몇 개를 표본 추출해 계정의 귀속은 활성직원에 있으며, 각 직원들은 관리적 액세스에 필요한 정당한 업무 요건을 갖고 있는지 검증한다.

[p.525 : 12행]
합당한 업무 요구사항을 제시하는지
->
소정의 업무 요건을 갖추고 있는지

[p.526 : 2행]
6.--- 업무상 요구를
->
6.--- 업무 요구사항을

[p.526 : 아래서 4행]
• 고성능 비즈니스 요구사항을
->
• 고성능 업무 요구사항을

[p.527 : 2행]
7.-- 업무상 요구를
->
7.-- 업무 요구사항을

[p.532 : 11행]
∙자산의 재고
->
∙자산목록

[p.533 : 스토리지 감사용 체크리스트 5행]
4. --- 합당한 업무 요구가
->
4. --- 정당한 업무 요건이

[p.533 : 스토리지 감사용 체크리스트 7행]
6.---업무상 요구를
->
6--- 업무 요구사항을

[p.533 : 스토리지 감사용 체크리스트 8행]
7.-- 업무상 요구를
->
7.--업무 요구사항을

[p.539 : 3행]
이러한 회사 중 일부는 시트릭스의 Xen과 오라클의 VirtualBox를 비롯한 오픈소스 프로젝트를 유지보수한다.
->
시트릭스의 Xen과 오라클의 VirtualBox를 비롯한, 일부회사는 오픈소스 프로젝트를 지속하고 있다.

[p.539 : 아래서 8행]
동일한 비즈니스 요구사항과
->
동일한 업무 요구사항과

[p.541 : 5행]
운영과 관리팀이 감사 노력에 대한 지원을 위해
->
운영팀과 관리팀이 감사업무에 대한 지원을 위해

[p.541 : 7행]
참고 하이퍼바이저 설치의
->
참고 이 감사는 하이퍼바이저 설치의

[p.543 : 아래서 13행]
4. --- 업무상 합당한 필요성이 식별된 경우에만
->
4. --- 업무상 정당한 필요성이 식별된 경우에만

[p.543 : 아래서 6행]
사용자의 타당한 액세스 필요성을 검증하기 위한
->
사용자의 액세스 요구가 타당한지 검증하기 위한

[p.546 : 아래서 10행]
비즈니스는 중요 비즈니스 애플리케이션에 대한 액세스를
->
조직은 중요 업무용 애플리케이션에 액세스를

[p.547 : 아래서 1행]
목표복구시점RPO
->
목표복구지점RPO

[p.557 : 가상화 감사용 체크리스트 5행]
4. --- 업무상 합당한 필요성이 식별된 경우에만
->
4. --- 업무상 정당한 필요성이 식별된 경우에만

[p.559 :　3행]
모바일 장치(안드로이드, iOS폰, 태블릿 등)를
->
모바일 장치(안드로이드Android(구글의 OS)폰, 아이iOS(애플의 OS)폰, 태블릿 등)를

[p.562 : 4행]
2010년대까지 보안, 감사 법률 팀은
->
2010년대까지 보안팀, 감사팀, 법률팀은

[p.572 : 9행]
9.클라이언트 시스템에서 패스워드의 사용 기간, 길이 ,복잡성, 내력, 잠금 정책과 같은 패스워드의 강도와 패스워드 통제기능의 사용을
->
9.클라이언트 시스템을 대상으로, 패스워드의 강도와 패스워드 통제기능(패스워드의 사용기간, 길이, 복잡성, 내력, 잠금정책과 같은)의 사용을

[p.578 : 1행]
기업은 종종 인도우와
->
기업은 종종 윈도우와

[p.587 : 아래서 9행]
조직은 장치 인벤토리를 추적하고
->
조직은 장치목록을 추적하고

[p.589 : 6행]
14장의 3단계와
->
14장의 단계3과

[p.593 : 아래서 2행]
이 단계는 모바일 장치에 대한 추가 데이터보호 고려 사항을 전형적인 비즈니스 배치에서 다룬다.
->
이 단계는 전형적인 업무의 배치 시 고려해야 할 모바일 장치에 대한 추가적 데이터보호 요건들을 포함하고 있다.

[p.595 : 9행]
비즈니스용으로
->
업무용으로

[p.595 : 11행]
비즈니스용이나
->
업무용이나

[p.595 : 아래서 3행]
일반적인 비즈니스 설정에
->
일반적인 기업 환경에

[p.598 : 윈도우와 맥 클라이언트 시스템 감사용 체크리스트 10행]
9.클라이언트 시스템에서 패스워드의 사용 기간, 길이 ,복잡성, 내력, 잠금 정책과 같은 패스워드의 강도와 패스워드 통제기능의 사용을
->
9.클라이언트 시스템을 대상으로, 패스워드의 강도와 패스워드 통제기능( 패스워드의 사용 기간, 길이, 복잡성, 내력, 잠금 정책과 같은)의 사용을

[p.560 : 1행]
참고
노트북과 유사 형태의 요인들은 휴대용이라는 의미에서 ‘모바일’이긴하다. 그렇지만 이 책의 목적상, ‘모바일 기기(mobile device)’라는 용어는 스마트폰-운영체제 처럼 구동하는 스마트폰과 태블릿을 지칭한다. ‘클라이언트'와 ‘클라이언트 장치’라는 용어는 윈도우 또는 맥OS 운영체제를 구동하는 노트북,데스크톱을 지칭한다.
->
참고
이동성(portable) 면에서 노트북이나 이와 유사 형태도 ‘모바일(mobile) 기기’라고 말할 수 있겠지만, 이 책에서 ‘모바일 기기’라는 용어는 스마트폰과 태블릿(스마트폰에 탑재된 것과 같은 유형의 운영체제로 작동하는 기기)을 지칭한다. 또한 클라이언트’와 ‘클라이언트 기기’라는 용어는 윈도우(Windows, 마이크로소프트)운영체제나 macOS(애플)운영체제가 탑재된 노트북과 데스크톱을 지칭한다.

[p. 561 : 5행]
2008년에 최초의 안드로이드Android 기반 장치를 출시한, 구글은 이에 그다지 뒤지지 않았다. 이제 구글의 안드로이드 운영체제는 모바일 환경을 지배하여 모든 스마트폰과 태블릿의 85% 이상을 지원한다. 애플의 iOS는 한 발작 뒤에 있었지만 나머지 시장 점유율을 거의 모두 차지하고 있다. 삼성, 블랙베리, 마이크로소프트 등 기타의 OS 제공처들은 이제 거의 몇 퍼센트에 불과하다.
->
안드로이드(Android) 기반 기기들이 2008년부터 출시되기 시작하자, 구글은 애플에 그다지 뒤지지 않게 됐다. 현재는 구글의 안드로이드 운영체제(OS, Operating System)가 모바일 생태계를 거의 장악해 모든 스마트폰과 태블릿의 85% 이상을 지원하고 있다. 애플의 iOS 운영체제는 한 발작 뒤에 있지만 나머지 시장 점유율을 거의 모두 차지했다. 삼성, 블랙베리, 마이크로소프트 등 기타 OS 제공업체들의 비중은 현재 극히 미미하다.

[p.607 : 2행]
1단계
->
단계1

[p.611 : 1행]
이해한다.
->
파악한다.

[p.614 : 2행]
최소권한접근
->
접근권한의 최소화

[p.622 : 4행]
복구시간 목표)와
->
목표복구시간)와

[p.622 : 5행]
복구 지점 목표)에
->
목표복구지점)에

[p.636 : 2행]
코드 체의
->
코드 자체의

[p.636 : 5행]
공유 책임 개념은 클라우드 제공자의 노력이 끝나는 위치와 비즈니스 책임이 시작되는 위치를 비즈니스 주체들이 이해하는 데 도움이 된다.
->
서비스 이용 주체는 공유 책임 개념을 통해 클라우드 제공자의 노력이 끝나는 위치와 이용자의 책임이 시작되는 위치에 대한 이해를 높일 수 있다.

[p.639 : 1행]
서비스의 측정이다(자원 사용이 자동으로 제어되고 최적화되지 않을 수도 있다)
->
사용된 서비스의 측정(자원의 사용이 자동으로 제어되고 최적화되는 것은 아닐 것이다.)

[p.640 : 11행]
컴퓨팅을 배치한다면
->
컴퓨팅 서비스를 이용한다면

[p.654 : 아래서 9행]

모든 단계(8단계 제외)에서
->
모든 단계(단계8 제외)에서

[p.657 : 9행]
‘필요한 최소 접근’ 개념을
->
‘필요 한도 내의 최소 접근’개념을

[p.666 : 아래서 13행]
복구시간 목표
->
목표복구시간

[p.666 : 아래서 12행]
복구시점 목표
->
목표복구지점

[p.674 : 6행]
작동(예를 들어 ‘가용 영역’)을
->
작동(예컨대 ‘가용 영역에서’)을

[p.674 : 8행]
모든 데이터 전송은 법규와 회사 정책에 준거되는지
->
모든 데이터 전송이 법규와 회사 정책에 따라 이루어지는지

[p.680 : 아래서 4행]
소프트웨어, 시스템과 프로세스를
->
소프트웨어, 시스템, 프로세스를

[p.681 : 2행]
기본 요소와 접근방식을 정의한다.
->
기본 요소와 접근법을 설명한다.

[p.683 : 7행]
발견된 프로젝트에 새로운 위험을 전달하고
->
프로젝트에서 발견된 새 위험을 전달하고

[p.689　: ２행]
문서편람이 허가 없이 부정확하거나 쓸데없이 변경될 수 있다.
->
문서편람이 승인 없이, 부정확하게, 또는 불필요하게 변경될 수 있다.

[p.70１　:　１１행]
프로젝트 출력이
->
당해 프로젝트의 산출물output이

[p.702 ： 아래서 2행]
15단계에서
->
단계15에서

[p.708 : 4행]
제반 문제점의 데이터베이스, 문제점 스프레드시트, 또는 구현 후 문제를 기록, 추적하고자 설정된 다른 방법이 있다면 이를 검토한다.
->
데이터베이스의 제반 문제점, 스프레드시트 문제점, 또는 구현 후 발생한 문제점에 대해서는 기록, 추적하고자 설정된 방법이 무엇이든 간에 이를 검토해보자.

[p.708 : 6행]
각 문제에 대한 적절한 정보를 기록하는지 확인한다.
->
각 문제 별 정보를 적절하게 기록하는지 확인한다.

[p.732 : 8행]
스냅샷snapshot을
->
스냅사진snapshot을

[p.741 : 3행]
18장에서는
->
19장에서는

[p.756 그림 19-3]
정의된
->
지정가능

[p.757그림 19-4 3열 3행]
존재하는 갭을
->
존재하는 통제결함을

[p.757그림 19-4 3열 4행]
갭의 근본 원인과
->
통제결함의 근본 원인과

[p.768 : 아래서 6행]
결정해야 한다.
->
알아내야 한다.

[p.770 : 11행]
결정해보자.
->
정해보자.

[p.770 : 아래서 8행]
계층 수준의 결정에 따르는 것은 아니다.
->
계층 수준을 정해야 하는 것은 아니다.

[p. 779 : 3행]
특히 19장에서는
->
특히 20장에서는

[p.781 : 3행]
사업 프로세스와
->
업무 프로세스와

[p.781 : 6행]
사업 프로세스를
->
업무 프로세스를

[p.781 : 8행]
사업 프로세스에
->
업무 프로세스에

[p.781 : 아래서 3행]
비즈니스의
->
기업활동의

[p.787 :　３행]
‘ 비작동’으로 판단되는 주요 새 재무나 운영 애플리케이션을 공시해야 할 수도 있다.
->
심지어 주요 신 재무 및 운영 애플리케이션을 ‘가동’시키지 않기로 한 경우도 공시가 필요할 수 있다.

[p.787 : 아래서 4행]
CEO와 CFO는 IS 부서를 잘 보살펴서 모든 애플리케이션 ---일반적 구체적 내부통제가 문서화되고 효과적이 되도록 유의한다.
->
CEO와 CFO는 IS 부서에서 모든 애플리케이션 ---내부 일반통제 및 응용통제의 문서화와 그 효과성을 확인해주길 기대한다.

[p.788 : 5행]
통제책임이 사용자그룹, IS기능, 제3자공급업체간에 어떻게 흩어져있는가?
->
통제책임이 사용자그룹, IS부서, 제3자 공급업체 사이에 어떻게 분산돼 있는가?

[p.788 : 6행]
개발, 문서화, 관리 애플리케이션, 인프라 모두에 대한 IS전략은?
->
IS전략(애플리케이션과 인프라 양쪽에 대한)의 개발, 문서화 및 관리는 어떻게 하고 있는가?

[p.788 : 11행]
비즈니스 목적에
->
사업 목적에

[p.790 : 아래서 13행]
여러 회계와 비즈니스 운영체제가 제공하는 데이터 웨어하우스에서 재무보고서를 생성할 때 특히 그렇다.
->
많은 회계 시스템과 경영활동 시스템에 연동된 데이터 웨어하우스로부터 재무보고서가 생성되는 경우 특히 그렇다.

[p.792 : 아래서 1행]
특히 재무 처리
->
특히 재무데이터의 처리

[p.803 : 10행]
비즈니스 프로세스의
->
업무 프로세스의

[p.823 : 아래서 9행]
사이버보안부서는 일반적으로 IT부서에 묻혀 있다는
->
사이버보안 영역은 일반적으로 IT영역에 묻혀 있다는

[p.823 : 아래서 7행]
영역 밖에서 별도로 관리되고 있으며 또한 회사에는 혼돈 상황에 대한 나름대로의 해결 방안도 있기 때문이다.
->
활동 범위 밖에서 별도로 관리되고 있으며, 회사에는 혼란 상태에 대한 처방전도 나름대로 있기는 하다.