企业形象 CISA 学习笔记某某某
0206 最新更新附个人考试心得
审计资源；
*信息系统审计师常常关注高风险的问题，如敏感和重要信息的机密性、可用性、完整性以
及生成、存储和处理这些信息的系统及流程等。在检查这类风险时，信息系统审计师常常对
组织所使用的风险管理过程的有效性进行评估。
*风险管理首要任务是识别出敏感或关键的信息资产；然后实施风险评估来识别威胁并确定
其发生频率、所导致的影响以及将风险降低至管理层可接受水平的相应安全措施；
*为保持其有效性，风险评估过程应当在组织中持续进行，以致力于及时发现和评估新出现
的风险。
*内部控制通常由能够降低组织风险的政策、规程、实务和组织结构组成；
*内部控制的设计是为管理层提供风险事件能够被预防、检测和纠正，业务目标能够达成的
合理保证。
*实施有效的 IS审计的第一步是审计计划；
*长期审计计划与企业的业务与发展有关，一般为 3到 5年的期间；
*每年都需要对长、短期审计计划进行分析；
*无论长期短期规划每年都必须分析、调整；在环境有重大变化时也必须分析调整
*证据的优先级：审计师自己收集>第三方提供>被审计方提供（银行函证例外）
*制定审计计划的步骤：
1、了解组织业务使命、目标、目的和流程的了解，包括信息和处理要求：对组织关键设施
现场巡视；收集阅读组织背景资料；检查长期战略计划；与管理人员会谈；审阅以前的饿审
计报告；
2、找出规定内容，如：政策、标准和作业指导书、程序和组织结构；
3、评价管理层实施的风险评估和隐私保护影响分析；
4、实施风险分析，找出高风险区域—重点检查对象；
5、执行内部控制检查（针对风险检查）；
6、确定审计范围和审计目标；
7、确定审计方法或审计战略；
8、为审计任务和其后勤支援分配人力资源
*需要遵守相关的法律法规：被审计方、审计师；
*法律法规的合规性：识别政府或相关外部要求的法律法规——记录相关法律法规——评估
被审计方在制定计划或设定策略时是否考虑相关的法律法规——制度的执行流程以及保障
（文档及程序）——执行结果
*信息系统审计是指审计内容中包含了对自动化信息处理系统、相关手工流程及两者间接口
进行全部或部分检查及评价的任何审计
*审计程序包括确定审计范围、说明审计目标、找出审计标准、执行审计步骤、检查和评估
证据、形成审计结论和意见、与关键流程所有人讨论后报告管理层
*审计方法是指：为实现预定的审计目标而设计的一系列书面审计程序，其内容包括审计范
围、审计目标和审计步骤；
*审计方法应当由审计管理层制定和批准并保持一致性。
*ISACA信息系统审计准则：
职业道德规范：必须遵守
信息系统审计标准：强制必须遵守，不可偏离
信息系统审计指南：在有合理解释的前提下可以调整和偏离
信息系统审计工具和技术：根据实际情况作出自己的职业判断
*审计计划步骤：
1、计划审计纲要；
2、以书面形式记录一份基于风险评估的审计方法；
3、以书面形式记录一份审计计划书，详述审计目标、性质、时间、范围以及所需相关资源；
4、以书面形式起草审计计划和审计程序
*信息系统审计人员应该得到监督，合理保证其审计目标的完成，并且符合审计职业标准；
*审计工作中收集证据的工作量最大；通过证据评估结论最困难；
*信息系统审计师必须拥有足够的、恰当的审计证据来解释报告中的审计结果；
*在报告审计发现和建议后，审计师必须持续跟进后续审计结果；
*审计最终目的：A&A(Audit&Assurance)审计及保证
*审计实质性（重要性）==阀值
*审计实质性（重要性）越低，需要投入的资源越大；审计实质性（重要性）越高，需要投
入的资源越小；
*ITAF（信息技术保证框架）包括：
1、一般准则：通用准则，所有审计都须遵守；
2、执行准则：在实施审计中的要求
3、报告准则（绩效准则）
4、指南
5、工具和技术
*目标->风险->控制->审计
*风险是特定的威胁，利用资产的脆弱性从而对组织造成的一种潜在的损害；它通过使用资
产和价值损失的概念把风险放在了组织的业务环境中。
*业务风险是指那些可能对资产、流程、具体业务或组织目标造成负面影响的威胁。
*风险的三个要素：威胁、脆弱性、资产（价值）；其中应该首先评估资产；
*以年为单位评估风险——基于成本效益原则（财务以年结算）
*风险评估：识别风险
*风险管理：消灭、控制风险
*风险评估首先识别敏感或关键信息资产；
*风险评估的最终目标：将风险降低至管理层可接受水平的相应安全措施；
*高风险==高发展、高收益
*风险控制（风险消减的措施）：
1、预防：避免或减少风险事件发生的可能性；
2、检查：发现不良事件的发生；
3、纠正：减小影响
向别的组织转移风险
*控制分为（书中）：
预防性：在问题发生前预防，监控运营和输入；职责分离、控制对物理设施的访问、良好设
计的文档、建立交易授权的适当流程、编辑检查、访问控制软件、加密软件
检测性：使用控制措施来检查和报告已发生的错误；哈希、检查点、通讯回显控制
纠正性：纠正问题引起的错误，把威胁影响降到最小；BCP、备份、DRP
*审计风险：审计过程中未发现信息可能存在的重大错误的风险；审计风险包括（固有风险、
控制风险、检测风险、整体审计风险）
*固有风险：审计过程中遇到的，在假定不存在相关补偿控制的情况下，当与其他错误相结
合时会导致重大错误的风险；也可以定义为：在不存在相关控制的情况下，易于导致重大错
误的风险；是由于业务性质所导致的，在审计中独立存在（复杂计算比简单计算更容易出错）
*所有审计项目的基本目标之一都是确定控制目标及针对这些目标的相关控制。并找出关键
控制点。
*控制风险：内部控制体系不能及时预防或检测出存在的重大错误的风险（手工检查计算机
日志的相关检查风险很高）
*检测风险：信息系统审计师由于采用了不恰当的测试程序，对实际存在的重大错误得出错
误结论的风险。（识别检测风险能更好的评价审计师的能力）
*整体审计风险：对每一个具体控制目标所评估出的各类审计风险的综合。
*统计抽样风险——指由选定样本得出错误的整体特征的风险
*风险分析——量化风险的系统方法
*风险评价——对比风险值与风险标准确定风险重要性的过程
*风险评估中所识别出的每一个风险都必须处置，处置方式包括：降低、避免、接受、转移
*风险分析的目标是理解和识别由实体及其环境引起的风险和相关的内部控制
*审计是典型的检测性控制；
*审计可定义为：由具备资质、胜任、独立的组织或人员，针对流程的预定结果，客观地搜
集并评价证据，以确定与既定标准的符合程度，形成意见并报告的系统过程。对特定经济实
体的可计量的信息证据进行客观的收集和评价，向利益相关者报告。可重现当时场景
*信息系统控制程序包括：战略和方针、全面的组织管理、IT 资源的访问（包括数据和程序）、
系统开发和变更控制、运行规程、系统编程及技术支持智能、质量保证（QA）流程、物理访
问控制、BCP、DRP、网络和通讯、数据库管理、对内外部攻击的检查和保护机制
*风险评估过程应当在组织中持续进行，以致力于及时发现和评估新出现的风险；
*内部控制：为减少风险所实施的各种政策、步骤、实践和组织结构；确保业务目标的有效
达成。提高经营效率
*风险控制另外分类方法：技术类控制、物理类控制以及管理类控制；
*COSO 内部控制框架：控制环境——风险分析——控制活动——内部沟通机制——监督和持
续改进
*COBIT通过域和流程框架来提供最佳实务，把 34个 IT流程组合到四个域中：
1、计划和组织（PO）；
2、获取与实施（AI）；
3、交付与支持（DS）；
4、监督与评价（ME）.
*COBIT 框架定义：IT 资源需要由自然归组的流程管理，为组织提供实现其目标所需要各种
类型的、符合质量、可用性以及安全要求的信息。（业务部门需要 IT部门提供满足一定要求
的信息）；
*管理：好的事情发生，产生价值、创造效益；
*控制：防止风险
*业务需求七要素：
种类 项目 解释
效果
符合业务部门的期望
质量
效率
成本效益
保密性
信息泄露
可用性
物理设备的丢失、信息被破坏；需要时能
用
安全
完整性
防止篡改、修改
符合性
合规性，法律法规
受信/受托
可靠性
数据准确
*IT资源：人员、信息、基础架构、应用系统；
*通过流程化管理 IT资源；
*通用控制：适用于组织的各个方面，包括：会计控制、运营控制、管理控制；
*应用控制：针对特定的流程；
*信息系统控制：战略指导、信息系统开发流程的控制、程序变更管理控制、计算机运行管
理控制、程序与数据访问控制、信息系统安全的控制、网络和通讯、数据库管理、IT计划；
*审计是指：有胜任能力的独立机构或人员（审计主体）接受委托或授权（审计关系），对特
定经济实体的可计量的信息（审计对象）证据进行客观的收集和评价证据（审计工作），以
确定这些信息与既定标准（审计依据）的符合程度，并向利益相关者报告（审计目标）的一
个系统的过程（审计过程）；审计的性质——独立、客观。
*位流映像——镜像之后再做哈希——防止篡改
*审计的实质：审计信息是否满足 7要素；
*制定信息系统审计计划的关键内容就是把宽泛的基本审计目标转化成具体的信息系统审计
目标；信息系统审计师必须明白如何把一般审计目标转换成特定的信息系统控制目标。确定
审计目标是信息系统审计计划的关键步骤。
*审计目标是指审计工作必须实现的特定目的；
*控制目标是指内部控制应当如何发挥作用
*信息系统审计人员从以下方面评估信息系统职能：
安全
质量
受托责任
服务和能力
*信息安全控制应当在系统和项目的需求说明及设计阶段予以考虑
*信息系统审计师应当对各类风险进行评价并选择高风险领域实施审计
*符合性测试（控制测试）——实质性测试：是否有控制—控制是否落实—控制是否有效—
控制是否持续
*舞弊检查：1、检查确认；2、与适当管理层沟通；3、与审计委员会沟通——向董事会沟通；
*审计师在接受客户审计时就应对审计风险进行评估，将评估风险与预计可接受的总审计风
险水平比较后，决定是否接受客户；
*审计风险分类：固有风险、控制风险、检查风险（审计风险）；总体审计风险。
*符合性测试是为测试组织对控制程序的符合性而收集证据，验证控制的执行是否符合管理
政策和规程（测试内控是否起作用）；
*实质性测试是为评价交易、数据或其他信息的完整性而收集证据，证实实际处理的完整性。
*需要进行实质性测试的数量与内部控制的水平直接相关
*符合性测试（控制测试）——简单、快速、资源消耗少
*实质性（重要性）：可容忍错报或漏报的最好界限，其运用的情形：1、在编制审计计划的
时候，进行初步估计；2、在做出审计结果时候，进行判断。
*审计风险与实质性（重要性）：实质性水平越高，审计工作风险就越低；实质性水平越低，
审计工作风险就越高；
*符合性测试（控制测试）：属性抽样
*实质性测试：判断控制是否完整
*充分性—数量上足够；适当性—审计证据有效且相关；
*统计抽样——采用统计推断技术的一种抽样方法，可以量化抽样风险
*非统计抽样——随机抽样
*属性抽样一般用于符合性测试中估计属性的有或无，结论是用比率表示发生率（属性抽样、
停—走抽样、发现抽样）；
*变量抽样一般用于实质性测试中估计总体的变化特征，结论是与正常值的偏差范围具体数
值（分层单位平均估计抽样、不分层单位平均估计抽样、差额估计）
*属性抽样：
1、固定样本抽样：100个里面抽 10个
2、停—走抽样：100个里面先抽 5个，如果没有问题就停止，如果有问题就再抽
3、发现抽样：100个里面一直抽，直到抽到一个有问题为止
*变量抽样：分层单位平均估计抽样、不分层单位平均估计抽样、差额估计抽样；
*置信系数越高，样本量越大；风险水平=1-置信系数；精度值越小样本量越大
*控制需求：发现高风险区域而又未控制的区域
*补偿性控制与重叠性控制：需要重点关注的是补偿性控制；
*补偿控制是强控制补偿弱控制，而重叠控制是指两个强控制；
*信息系统审计师在报告控制缺陷之前应当先检查补偿性控制
*判断控制是否有效率和效果；
*信息系统审计师在报告发布前，就重要发现及时和合适的人员进行交流，但前提是交流不
应该改变报告的内容；
*审计底稿是指在审计过程中产生的所有的记录和资料，应保存 7年；
*控制自我评估（CSA）三个基本特征：
1、关注业务的过程和控制的成效；
2、有管理部门和职员共同进行；
3、用结构化的方法开展自我评估。
*在控制自我评估（CSA）中，信息系统审计师作为控制专家和评估引导人，只是 CSA的推动
者；
*CSA把部门经理的监督职责分散到员工中
*审计师在 CSA中的目标：
增强审计职责
在控制责任和监控当中教育各级管理者
通过对在 CSA中注意到的高风险和非正常项目进行复核来确定审计工作目标
通过把纠错心动从所有者方面向雇员方面转移的办法来提高纠错行动的有效性
*一些组织在做 CSA评估时，可能还会包括客户、贸易伙伴等外部人员
*CSA 主要目标是通过把一些控制监督职责分散到职能部门来充分发挥内部审计职能的左右，
这并不是要替代审计的职责，而是一种加强
*审计师应该牢记他们只是 CSA的推动者，只有管理人员才是 CSA程序的具体实施者
*连续监控与连续审计区别：监控仅仅记录所有满足设定条件的事件；审计则一旦控制失效，
自动触发报警。
*持续审计的技术应该在系统开发和实施的早期阶段介入；
*持续审计的限制因素：成本问题
*持续审计是被审计事实的发生至证据收集和审计报告之间的时间间隔非常短
*持续审计应独立于持续控制或监控活动，当同时存在持续监控和持续审计时，就形成了持
续保证
*IT 系统通常是预防和检查性控制的第一道防线，综合审计的根本就在于合理评估它们的效
果及效率
*确定审计发现重要性的关键是评估这些审计发现对各级管理层的重要性，评估中需要判断
未针对审计发现采取纠正措施可能导致的潜在影响。
*审计证据可靠性的决定因素：
1、提供审计证据的人员的独立性
2、提供信息或证据的人员的资格
3、证据的客观性
4、证据的时效性
*应当由信息系统审计师来最终决定审计报告中包括或不包括哪些内容
*综合审计的一个关键步骤就是审计组集体讨论风险及其影响和发生的可能性
*详细审计工作关注已存在的管理这些风险的相关控制。
*进行实际取证时，只能对位流映像进行操作，目标驱动器应该封存
*对司法取证审计师而言，最重要的考虑就是做好目标驱动器的位流映像（镜像），并检查该
映像的时间戳和其他信息属性未被人为改变；
*位流映像做出来后应该对目标驱动器进行哈希，然后与位流映像的哈希进行对比，确保两
者的完全一致；
*除了位流映像以外还有内存信息转储到文件中也是司法取证的一种；
*信息系统审计师通常从许多不同的角度来评估 IT职能和系统：
安全——机密性、完整性、可用性
质量——效果、效率
委托责任——符合性、可靠性
服务和能力
第二章 IT治理与管理
*IT治理是组织中的一种安排。目的是为了提高 IT绩效，降低 IT风险，有效利用资源。
*信息系统的战略规划是获取、配置和管理信息资源及实现组织远景目标的总体规划，包括
软件、硬件、责任以及资源配置等，提供给组织相应的解决方案。
*IT治理有助于确保 IT和企业目标保持一致，IT治理的关键因素是 IT与业务保持一致，以
实现业务价值
*IT 治理采用最佳实践来确保组织信息及相关技术支持其业务目标（如战略一致）和价值交
付，确保资源得到合理使用、风险得到适当管理、绩效得到测评
*信息技术对企业非常重要，不能把职责放给 IT 管理人员或 IT 专家，而必须得到整个高级
管理层的关注
*IT治理在根本上关注以下两方面的问题：
IT如何向业务交付价值——由 IT与业务的战略一致推动
IT风险得到管理——向企业分配责任来推动
*IT如何有效率有效果的使用 IT资源；
*IT治理的关键因素是保持与业务战略的一致，引导业务价值的实现；
*IT 治理是董事会和最高管理层的责任，是企业整体治理的一部分，它由领导关系、组织结
构以及能确保 IT支撑和扩展组织战略及目标的流程组成
*关键的 IT治理实务有：IT战略委员会、风险管理和标准 IT平衡记分卡
*IT治理的关注领域：战略一致、价值支付、资源管理、风险管理、绩效测评
*IT治理实各种关系与流程结构，用于指导和控制组织达成增值目标，同时还要保证 IT及其
流程的风险与收益的平衡。
*在 IT治理中，信息系统审计师应当确认已明确以下内容：
1、工作范围，包括清晰定义所涵盖的职能领域和事务；
2、采用的报告路线，使查出的 IT治理问题能报告给组织的最高层
3、信息系统审计师对信息的访问权限，包括对组织内部和第三方服务提供商
*IT战略委员会是方向性的：由一个董事会成员加外部专家组成，战略层面
*IT指导委员会是技术执行层面的
*IT 平衡记分卡是协助 IT 战略委员会和管理层实现 IT 与业务保持一致的最有效的方法之一，
其目标是建立管理层向董事会的报告途径，就 IT 战略目标在关键利益相关方之间达成一致，
证实 IT的效果与价值，沟通 IT绩效、风险和能力。
*信息：具有特定意义和目标的数据
*信息安全的复杂性、相关性、危险性及其治理都要在组织的董事会层面予以考虑并提供支
持
*信息安全的忧虑：对信息及其处理系统的持续依赖和众多威胁所导致的复杂风险。
*有效的信息安全能为组织带来巨大价值：
1、在与贸易伙伴的交往中提供可靠的信赖；
2、提高客户的信任度；
3、保护组织信誉
4、促进采用更新更好的方式处理电子交易
*业务战略方针通过业务目的和目标来明确，信息安全必须能支持业务活动向企业交付价值；
*信息安全治理框架为制定一套有成本效益的、支持组织业务目标的信息安全程序提供了基
础。该程序的目标是建立一系列的活动以保证信息资产受到与其价值或给组织带来的潜在风
险相称的保护。
*IT治理是企业的一种制度安排，它通过为 IT提供必要的领导力、组织结构和相关过程，来
保证企业的 IT能支持企业战略和实现企业目标，同时控制风险、降低成本、提高绩效。
*IT治理是董事会和执行管理层的职责，是企业治理的重要组成部分；
*IT管理是公司的信息及信息系统的运营，确定 IT目标以及实现此目标所采取的行动；
*IT 治理是最高管理层（董事会）通过 IT 治理监督执行管理层在 IT 战略上的过程、结构和
联系，以确保这种运营处于正确的轨道上
*IT治理是董事会和高级管理层的责任
*IT治理框架主要流程：
1、IT资源管理，关注现有的全部 IT资源的维护并落实风险管理程序；
2、绩效衡量，关注确保所有 IT资源向业务交付既定价值，也在早期识别风险；
3、合规管理，关注满足法律、法规要求的流程的落实
*关键 IT治理实务：IT战略委员会（隶属董事会，由董事会成员+专家组成），风险管理和标
准 IT平衡记分卡
*COBIT 五个 IT 治理域都受利益相关者价值驱动，其中价值交付、风险管理是结果，战略一
致、绩效考评是驱动力，IT资源管理为治理提供支持。
*IT战略委员会负责宏观的指导性要求
*IT指导委员会负责具体事务，预算、架构以及项目进展，不讨论具体细节问题；
*信息系统审计师需要对 IT治理的各个方面进行评估：
1、信息系统审计的职能与组织的使命、愿景、价值、目标和战略一致；
2、信息系统的职能绩效目标应当由业务来决定（效率与效果）；
3、法律问题、环境问题、信息质量、信用和安全需求；
4、组织的控制环境；
5、信息系统环境的内在风险；
6、IT投资/费用
*IT平衡记分卡的四个视角（只是管理报告工具）：
财务视角：为了使股东满意
客户视角：为了实现财务目标，需要服务客户
过程视角：提高客户和利益相关者的满意度
学习视角：为了达成目标，组织应当如何学习与创新
*信息安全治理具有特定的价值驱动：信息安全的机密性（C）、完整性（I）和可用性（A），
持续服务和信息资产保护等，使信息安全治理成为一个重点关注领域；是董事会和高管的职
责。
*信息安全治理
1、价值交付：优化安全投资以支持业务目标；
2、绩效评测：衡量、监督和报告信息安全流程，以确保实现 SMART 目标（确定的、可度量
的、可实现的、相关的和符合时间要求的）
3、资源管理：有效利用信息安全知识与基础设施
4、流程整合：关注组织安全管理保证流程的整合，目标在改善整体安全及运营效率。
*信息安全治理的安全职责：
1、董事会——提出要求，听取汇报
2、执行管理层——制定具体的流程定义
3、指导委员会——具体事务的定义
4、信息安全管理层——具体流程的执行
5、审计员——对各个流程执行的评价
*审计员永远不提具体的改进活动，改进审计出来的缺陷，是被审计单位的管理层的职责；
*企业架构（EA）通过一种结构化的方式来反映组织 IT资产，并有效管理对 IT投资；
*企业架构通常应描述记录当前资产状态和最佳未来资产状态。
*IT治理目标要求 IT战略应当与整体业务保持一致
*AUP:可接受使用策略（AcceptableUsePolicy）是指这些网络能够被谁使用的约束策略（最
终用户如何使用信息资产的准则以及期望）。AUPs 的执行是随网络变化的。许多公共网络服
务有一个 AUP。这个 AUP 是一个正式的或非正式的文件，其定义了网络的应用意图、不接受
的使用和不服从的结果。一个人注册一个基于网络的服务或工作在一个社团内部网时经常会
遇到一个 AUP。一个好的 AUP 将包括网络礼节的规定，限制网络资源的使用和明确指出网络
应该尊敬的成员的隐私，最好的 AUPs 使"whatif"关一体化，其举例说明这个策略在现实世
界协商中的作用。
*IT投资财务指标关注：投资回报率（ROI）
*关注风险的同时也要关注投资回报；
*平衡记分卡决定项目投资与否，强调愿景；IT 投资组合，具体项目投资量，关注投资回报
最大化。
*IT平衡记分卡评估 IT功能和流程
*政策：永远都是高层政策决定低层政策。从集中到分散。
*政策最高管理层一定要签字确认，定期修订，重大变化时随时修订。
*最重要的一个方面是受程序控制的人员熟悉规程内容，如果使用程序人员不了解其内容，
该程序是无效
*风险：外在威胁利用资产本身（保护对象）的脆弱性（对象本身特点）造成损害的可能。
控制就是阻断威胁
*坏事已经发生了叫事件，可能发生叫风险；
*凡是高于风险可接受水平的，就要进入风险处置（降低、转移、回避、接受）；
*任何对企业有价值的资源都叫资产，所有资产有有脆弱性。
*一个未经保护的线路——脆弱性
*风险管理根据成本效益原则采取：
避免风险：选择不从事导致风险的特定活动或流程
降低风险：制定、实施并监督适当的控制降低风险发生的可能性
转移风险：购买保险或者保修服务
接受风险：经过评估后正视风险的存在，并监视
*风险管理的核心是：保护资产
*在攻击发生后，还没有造成损失叫事态，已经发生侵害损失叫事件
*风险管理首先需要识别信息资产（包括物理的、逻辑的和无形的）
*风险管理过程：识别信息资产、识别并评估威胁、识别并评估脆弱性
*IT风险管理在多种层面上进行综合分析：
运行层面：关注能影响 IT 系统及基础设施的效果及效率的风险，绕过系统控制的风险，关
键资源损失风险
项目层面：关注理解和管理项目复杂性的能力，项目不能有效完成、未实现项目目标的风险
战略层面：关注 IT能力与业务战略保持一致的程度
*风险分析方法：
定性方法：主观风险定级，采用问卷式的检查列表（CHECKLIST）
半定量分析法：还是定性法的一种。
定量分析法：使用数值描述风险发生的可能性及其影响
*应在公司的所有 IT职能领域内实施风险管理，风险管理是高层管理人员的职责，尽量使用
量化风险的管理办法
*信息安全治理的成果：
1、战略一致——使信息安全与业务战略保持一致以支持组织目标
2、风险管理——管理和实施适当的措施以降低风险并减少对信息资源的潜在影响至可接受
水平
3、价值交付——优化安全投资以支持业务目标
4、绩效衡量——衡量、监督和报告信息安全流程，以确保实现 SMART 目标（具体的、可度
量的、可实现的、切实的和有时限的）
5、资源管理——有效利用信息安全知识与基础设施
6、流程整合——关注组织安全管理保证流程的整合
*信息安全治理需要战略指导和推动力，需要委任、资源和为信息安全管理分配责任，也包
括董事会确定其目标是否已实现的方式。
*企业架购关注的内容是响应不断增加的 IT 复杂性，现代组织的复杂性，重点关注 IT 与业
务战略的一致性并确保 IT投资产生真实回报
*企业架构（EA）的参考模型：
绩效参考模型—衡量主要 IT投资绩效及其对业务流程绩效贡献度的框架
业务参考模型—功能驱动的框架，描述由政府、独立机构所执行的功能
服务组件参考模型—对支持业务和绩效目标的服务组件进行分类的功能性框架
技术参考模型—描述技术如何支持服务组件的交付、替换和构建的框架
数据参考模型—用在开发过程中，描述支持程序和业务生产线的数据信息
*对 XX的控制是最有效——找属于预防性控制
*强制休假——防止舞弊，发现问题加强控制
*信息系统职能的交付方式包括：
内包——由组织内员工实施
外包——全部由供应商实施（把公司无增值功能的事务转移出去）
混合方式——由组织员工和供应商混合实施
*信息系统职能实施方式：
现场——员工直接在信息系统现场工作
离场（近岸）——员工在同一地理区域内的不同地点远程工作
离岸——员工在不同的地理区域远程工作
*外包方式应该注意：数据的所有者、知识产权问题以及对外包方的审计权问题
*全球化外包需要注意事项：
法律、法规和税务方面的事务——不同国家和地区对 IT系统的相关规定
持续运行——可能无法提供测试 BCP和 DRP
网络通讯事务
跨国界和跨文化的事务
*云计算服务交付模型：SaaS（软件交付）、PaaS（平台交付）、laaS（架构交付）
*laaS（架构交付）需要关注：服务中断
*PaaS（平台交付）需要关注：隐私性，数据所有权
*SaaS（软件交付）需要关注：软件应用所处位置
*云计算注意的问题：服务商宕机、机密性如何保证、安全问题的法律责任、数据所有权
*私有云的安全性最好，但不容易扩展
*敏感数据的使用者需要关心数据安全性问题
*云治理要考虑使用云计算时主要考虑和 IT的战略方向
*采购实务中第三方服务的变更管理：变更服务条款，包括对现有的信息安全政策、规程和
控制的维护及改善，应考虑业务关系的关键性及其涉及流程进行管理，并重新评估风险。
*建立 IT用户计费机制可以提高应用水平，监督信息系统费用和可用资源
*软件开发，公司对内部使用软件的成本资本化（作为固定资产成本摊销）
*绩效优化：是在无须对信息技术基础设施追加额外投资的情况下，将信息系统的生产力尽
可能提高到最高水平
*管理指南的重要内容：关键成功要素（CSF）、关键目标指标（KGI）、关键绩效指标（KPI）、
成熟度模型
*信息系统部门组织结构职务：
最终用户服务台：与业务部门沟通的界面
运行部门计算机操作员：在主机环境的控制台上执行任务
技术支持部门的系统程序员：在主机环境中对操作系统进行修改
*职责分离（要理解）
安全管理员不可以是系统管理员
选项中业务案例最重要
*发现没有职责分离，找补偿性控制
*选择项中不选：多加人、停止工作、自动化检查系统
*审计师发现问题——找证据审计师确认问题——报告适当的管理层
*控制组负责收集、转换和控制输入，核对结果并向用户分发结果
*质量控制：负责执行测试或审查，以验证并确保软件不存在缺陷并满足用户预期，必须在
程序被迁移到生产环境之前进行。
*质量保证（QA）：帮助信息系统部门确保其人员遵守规定的质量程序。发布、制定、维护
质量标准。
*不能对自己的工作做 QA；用户、开发人员不能做 QA
*应用程序员负责开发和维护应用系统，只能在开发和测试环境中进行；
*在小型机构中，网络管理员可以负责局域网的安全管理，可以拥有系统程序员及最终用户
的职责，但不应拥有应用程序编程的职责；
QA
*从信息系统的角度来看，战略规划是组织为了利用信息技术来改善业务流程而确定的长期
发展方向。
*在制定业务战略过程中缺乏 IT的介入将导致 IT战略规划不能与业务战略保持一致的风险
*战略指导委员会的主要职责是对重要的信息系统项目进行审查，而不应当涉及日常运营。
*IT指导委员会监督重大项目的进度和资源分配
*项目管理委员会负责制定 IT项目策略
*采用自顶向下的方法来制定低层政策，确保了各级政策的一致性
*采用自底向上的方法来制定低层政策，基于风险评估的结果而制定的，可能更加实用，但
容易造成政策间的不一致和相互抵触。
*程序反映了业务流程及嵌入的控制。程序由流程所有人制定，是对政策的有效解释
*风险管理是组织用于识别信息资源的脆弱性及威胁，制定相应的对策（安全措施或控制），
以实现组织业务目标的过程。
*安全政策必须在控制水平与生产效率之间进行平衡，控制成本决不能超过控制所带来的预
期收益。
*信息安全政策指导整个组织来确定所需保护的内容、相应的保护职责以及保护工作应遵循
的策略。
*应当按照计划周期或当发生重大变化时对信息安全政策进行审查，以确保其适当性、充分
性和有效性。
*应当为信息安全政策指定所有人，来批准安全政策的制定、审查和评估等管理职责。
*信息系统职责分离的原则：
资产保管
授权
交易记录
*任何风险，都应当基于信息资源对组织的价值，将其降低至可接受水平。
*有效的风险管理始于清楚的理解组织的风险偏好。在 IT环境下，风险偏好推动所有的风险
管理工作，影响未来的技术投资，IT资产的保护程度及所需的保证水平。
*风险管理包括识别、分析、评估、处置和沟通 IT流程的风险影响
*风险的对应措施：避免风险、降低风险、转移风险、接受风险
*为制定风险管理程序，必须：
1、确定风险管理程序的目的
2、为风险管理计划分配职责
*风险管理过程
第一步是对信息资产或资源进行标识并分类；
第二步是评估与信息资产相关的威胁和脆弱性，及其发生的可能性；
*威胁的发生是由于信息资产存在脆弱性，脆弱性是信息资源的特性，可以被威胁利用并造
成损害
*发生任何威胁所造成的结果称为影响，它能导致这种或那种损失
*信息系统管理实务反映的是为各种信息系统相关管理活动所设计的政策与程序的实施情况
*CIA要求：机密性、完整性和可用性
*服务台应建立正式流程来分别记录已报告、已解决和升级的问题，并对问题和疑难进行分
析，以帮助监督用户和改善信息处理设施（IPF）的服务
*在计算机运行中，管理控制可以划分为物理安全控制、数据安全控制和处理控制三个类别
*控制组负责收集、转换和控制输入，核对结果并向用户分发输出结果
*数据录入人员由控制组管理，因此数据录入不一定是最终用户
*安全管理应首先得到管理层的支持，管理层必须了解并评估安全风险，制定书面政策清晰
地说明应遵循的标准和规程，并强制执行
*为保证充分的职责分离，安全管理员应当是全职员工，可以直接向基础设施主管报告
*质量保证人员通常执行两种不同任务：
质量保证（QA）—帮助信息系统部门确保其人员遵守规定的质量程序
质量控制（QC）—负责执行测试或审查，以验证并确保软件不存在缺陷并满足用户预期。
*质量控制（QC）可以在系统开发的各个阶段进行，但必须在程序被迁移到生产环境之前进
行
*在任何情况下都不应当让个人对自己所负责的工作执行质量审查
*针对数据库管理员（DBA）的严格控制：
1、职责分离
2、DBA活动需要得到管理层批准
3、由主管对访问日志和相关活动进行审查
4、对数据库工具的使用事实检查性控制
*必须确保应用程序员不能修改生产环境中的程序和应用数据，他们应当只能在测试环境下
工作，由另外的团队把程序和应用变更迁移到生产环境中。
*在小型机构中，网络管理员可以负责局域网的安全管理，拥有系统程序员及最终用户的职
责，但不应当拥有应用程序员编程的职责
*应当分离的职责包括：资产保管、授权、交易记录
*职责分离的目标是：通过识别补偿性控制来降低或消除业务风险
*访问控制决策应基于组织政策和两个普遍接受的实践标准：
职责分离
最小授权原则
*用户部门应提交授权单；信息系统部门根据授权单维护用户授权表
*审计痕迹的主要目的是建立交付处理的业务交易的职责（可追溯责任）。
*针对职责分离的补偿性控制：
1、审计轨迹—在缺乏职责分离时，详细的审计轨迹将是可接受的补偿性控制
2、核对—核对是用户的最终责任，还可以增加控制组使用控制总计和平衡表对应用系统执
行部分核对功能
3、例外报告—应当由主管层处理并且需要留下证据
4、交易日志—可以时电子也可以手工
5、监督性审核—可以通过现场观察、访谈或远程执行
6、独立性审核—执行独立审核是对错误或故意违反既定流程的补偿性控制，在职责不能恰
当分离的小型组织中尤其重要
*审计过程中应该审计的文档：
IT战略、规划和预算
安全政策文档
组织图或职能图
工作说明
指导委员会报告
系统开发和程序变更流程
操作流程
人力资源手册
质量保证程序
*信息系统审计师应当验证管理层在合同过程中的参与程度，确保按适当的周期对合同遵循
性进行审查。
*制定 IT服务外包决策应考虑的问题：服务质量、持续服务保证、控制程序、竞争优势和技
术知识
*外包实允许组织把服务交付转由第三方提供的机制。
*外包的基本原则是：虽然将服务交付转移，但其职责仍属于组织内管理层，他们必须确保
对风险的适当管理及供应商持续的价值交付。
*外包应注意：数据所有权，知识产权，审计权（或独立的第三方审计报告）
*IT 目标应当是改善用户满意度并实现业务目标。应当通过用户访谈和调查来监督用户满意
度
*质量管理是控制、衡量和改善 IS部门流程的一种方法
*信息系统部门制定并维护的书面流程是有效管理信息资源的证据，坚持遵守流程及相关流
程管理技术是信息系统部门有效运营的关键因素。
*绩效评价的主要阶段有：
1、制定和更新绩效指标
2、为绩效指标建立责任制
3、收集和分析绩效数据
4、报告和使用绩效信息
*绩效指标用途
1、衡量产品和服务
2、管理产品和服务
3、确保责任制
4、制定预算决策
5、优化绩效
*针对职责分离的补偿性控制：
审计踪迹、核对、例外报告、交易日志、监督性审核、独立性审核（在不能进行有效职责分
离的小型组织尤其重要，可以帮助发现错误或违规行为）
*业务连续性计划（BCP）——涉及组织内绝大多数部门；灾难恢复计划（DRP）——涉及 IT
及相关部门
*BCP责任属于高级管理层，高级管理层不能将责任分到下属
*业务连续性计划应当基于长期的 IT计划，并与组织总体业务连续性战略一致
*业务连续性计划和灾难恢复的目的是使组织在中断事件后可以持续提供关键服务并从灾难
中断中恢复其活动；
*灾难恢复（DRP）与业务连续性计划（BCP）是组织为避免关键业务功能因重大灾难而中断，
减少业务风险而建立的一个控制过程；是业务流程，不是一个项目。
*BCP主要是组织高级管理层的责任，因为高级管理层对组织的资产和生存负有最高责任；高
级管理层不能推托将责任委托给下级人员。
*BCP 计划不是所有的业务流程都要恢复（只恢复关键流程），也不是所有的服务都需要恢复，
关键的目标是满足客户的需求。
*BCP维护的一个重要步骤：组织内任何相关变化产生时都要进行 BCP的更新和演练
*业务连续性计划（BCP）是组织为避免业务功能/运作中断，减少业务风险而建立的一个控
制流程，包括对支持组织关键业务的人力、物力需求和关键业务所需的最小级别服务水平的
连续性保证。
*准备一个新的 BCP 的第一步师识别战略性的业务流程，这些关键流程是业务持续增长和实
现业务目标的保证
*风险管理在 BCP的准备阶段被关注。
*无论发生何种中断，关注的焦点永远是关键业务流程的可用和持续运行
*如果信息系统的 BCP与 DRP需要单独建立，必须与组织的总的 BCP计划保持一致。
*不存在单独的 DRP计划，一定先有 BCP才会有 DRP。
*一个整合的 BCP计划必须确保：
每个部分都被涵盖
承诺的资源被最有效的方式使用，并有充分证明通过它组织可以克服中断生存下去
*灾难：把发生概率极小，但冲击极大
*一个业务连续性计划应当识别出当发生灾难时，业务应当做什么
*保证恢复的成本永远不要超过所获得的利益
*流感大流行的到来具有很强的不确定性，对社会和经济的影响与威胁是确定的。
*流感大流行特点是系统、设备没有问题，但是人没有了。
*流感大流行的应对规划和传统的业务连续性规划不同，信息系统审计师应评价组织对流感
大流行的准备；流感大流行的影响由于范围和持续时间不同难以确定。
*危机沟通范围：
内部：股东、员工
外部：新闻媒体、政府
*危机沟通中，除发言人外，组织中的任何其他人不管官居何职，都不得发布任何公共言论
*BCP主要针对服务中断
*BCP是纠正性控制
*根据对业务危害程度的估计，对各种事件进行分类：可忽略事件、微小事件、重大事件、
危险事件，在事件被解决前，任何对它的分类都是临时性的
*BCP过程分为：
1、创建业务连续性方针/政策
2、风险分析 RA
3、BIA\运行分类及重要性分析
4、识别支持关键组织功能的信息系统流程
5、开发 BCP策略
6、开发业务连续性计划和 DRP步骤
7、开发重建程序
8、培训与意识教育程序
9、计划的演练与实施
10、监测
*BIA之后做策略供管理层选择，管理层批准后，制定计划
*执行 BIA的方法：
1、设计详细的调查问卷，分发给重要业务人员和 IT人员（用户多，分布广，问题标准化）
2、拜访关键用户，通过面谈收集信息（问题复杂）
3、把 IT和终端用户召集，讨论得到结论（跨部门）
*信息系统审计师应该分析过去的事务量以确定在系统不可用期间对业务的影响程度
*BIA目标：业务、利润；合规；合同约定、承诺
*对 BIA应用的重要性分类：
关键的——必须立即恢复（中断几小时到一天）
重要的——短时间人工替代（1~5天）
敏感的——长时间人工替代（一周以上）
不敏感——可完全手工替代
*BIA中关键业务流程由流程所有者确定，由高级管理层批准
*BIA之后先做恢复策略
*RPO越小，最低可接受损失就越少，就需要采用镜像或磁盘双工技术
*在制定 DRP计划时需要 RPO值
*RTO指业务恢复。
*HR的员工手册中必须有人员撤离计划
*RPO影响备份技术的选择
*RTO越小，对灾难容忍程度就越低，就只能选择“热站”
*完全不允许停机——双生产中心（冗灾中心、镜像站点）
*灾难恢复策略其他参数：
中断窗口：组织能够等待的自失效点时刻到关键服务应用恢复的时刻
服务交付目标（SDO）：直到正常的生产系统恢复运营，由替代流程实现的服务水平。这直
接与业务需求相关
最大可容忍中断：组织使用备用方式支持的生产处理的最长时间
*灾难必须由授权人员宣告
*管理层与员工积极参与是 BCP成功的重要因素
*如果组织中不存在统一的业务连续性计划，针对信息系统的 BCP 需要覆盖整个依赖信息系
统服务的部门和单位
*恢复策略的选择基于下列因素：
1、业务流程及支持此流程的应用系统的重要性；
2、成本；
3、组织要求的恢复时间；
4、安全。
*恢复成本不应大于停机成本
*最适合的恢复策略的选择，首先要通过业务影响分析确定风险和重要性级别，然后通过比
较恢复成本和停机成本来决定。
*热站的安全级别不是最高的，最高安全级别的应该是镜像冗余站点，或者是双生产中心
*热战：除应用程序、数据、文件以及操作人员外其他全部齐全
*温站：在热站基础上减少主机
*冷站：只有基本环境，电、空调、场地
*高级管理人员是 BCP关键决策制定者，具有决定启动计划的最终裁定权
*与业务连续性计划相关的部门有：服务支持部门、业务运行部门、信息处理支持部门
*BCP演练的各个阶段：预演练阶段、演练阶段、演练后续阶段
*演练类型：纸上推演、预备性演练、全面运行演练
*如果信息系统的 BCP和 DRP需要单独建立，必须与组织的总的 BCP计划保持一致。
*在管理层选择了适用的恢复策略后，下一步的目标就是制定详细的业务连续性计划和灾难
恢复计划，并在异地备份场所存放一份计划的拷贝，最好是纸质
*首先用户和管理层的参与是识别关键资源的基础，其次要由他们来决定关键的恢复时间和
定义所需的资源。
*应急管理小组通常由高级管理人员领导
*当 VOIP作为组织的唯一通信线路时，要考虑备份
*冷热温站合同事项：
1、配备—包括软件和硬件是否满足需要
2、灾难—对灾难的定义是否满足预期需要
3、启用速度—多长时间可以启用
4、每个站点的申请者—是否限制每个站点申请者的数量
5、每个区域的申请者
6、优先权
7、保险
8、站点使用期限
9、通讯能力
10、服务承诺
11、审计条款
12、测试权限
13、恢复站点的可靠性证明
*BCP演练目标：
1、验证 BCP的完全性或准确性；
2、评价 BCP演练中个人的绩效；
3、评价对非 BCP团队成员的其他员工的教育与培训；
4、评价 BCP团队与外部供应商之间的协调性；
5、通过实施预定的程序来演练备份站点的能力与容量；
6、评估重要记录的检索能力；
7、评价要转移到恢复站点的设备的状态、数量及供应情况；
8、评价与维护业务实体有关的运行活动和信息系统处理活动的绩效
*对备份存储位置的逻辑以及物理安全要求应该与生产中心的级别一致
*异地备份库管理员的责任：
1、维护一个永久的备份存储介质的库目录（可以手工或者自动）；
2、控制对这些存储介质的访问；
3、根据需要，控制存储介质在不同的库中循环流通；
4、维护一份 BCP拷贝。
*制定和维护一个 DRP与 BCP应该：
1、执行 BIA；
2、识别各类资源并分类；
3、选择策略恢复 IT设施，支持关键业务流程；
4、制定详细计划恢复 IT设施（DRP）；
5、制定详细计划保证关键业务运行（BCP）；
6、测试计划；
7、当业务和系统环境发生变化时，维护与更新计划。
*BCP计划更新日期都是 30天
*备份和介质的选择因素：
1、标准化——技术支持
2、容量——满足需求
3、速度——与业务要求一致
4、成本——包括设备和介质的成本
*备份的方法：全备(最慢)、增量（最快）、差分（一般）
*呼叫树清单每个月都需要核实
*计划演练目的：找出错误、不足，没有控制的点；个人绩效
*全面运行演练不能由演练变成真正的灾难
*审核 BCP计划：是否覆盖关键业务流程
*业务连续性计划中紧急逃生最重要，人的安全永远排在第一位
第三章信息系统与基础设施生命周期管理
*项目的定义：
1、项目是一项有待完成的任务，且有特定环境与要求
2、在一定的组织机构内，利用有限资源（人力、物力、财务等）在规定的时间内完成任务
3、任务要满足一定性能、质量、数量、技术指标等要求。
*项目一定有截至点,不能无限期延续；一定在有限的时间、有限的预算内。交付物是可以长
期保存的。
*软件项目一旦交付到生产环境后应立即交割给运维人员。
*项目的目标应该包括成果性目标和约束性目标，满足客户、管理层和供应商在时间、费用
和性能上的不同需求。
*项目群可以看成是由一系列项目和有时间边界的任务组成，这些项目和任务通过共同的目
标、共同的预算、相互交织的日程和策略等紧密的联系在一起。
*成功的实施项目群，需要对以下内容进行有效管理：
1、项目群的范围、财务、日程、目标及交付物；
2、项目群所处的环境；
3、项目群的沟通与文化；
4、项目群的组织。
*项目群中典型的沟通结构就是召开项目群所有者会议和项目群团队会议
*项目管理办公室是项目管理和项目群管理过程的所有者，它必须是永久性的组织结构，需
要配置充足的人员，以对当前的项目管理提供充分的支持，同时开发新的程序和标准。
*项目管理办公室只涉及项目管理程序中的活动和任务，并不涉及具体的项目内容。
*在一个给定的时间点上，组织中正在进行的所有的项目的集合称为项目组合。
*项目组合的管理目的：
1、优化项目组合的结果
2、对项目优先级排序，进行日程安排
3、协调对资源的使用
4、项目中的知识传递
*项目是短期的、战术性的
*项目群是长期的、战略性的
*项目组合具有管理周期（每季度或每年）
*应追求整体项目组合的收益最大化。
*规划 IT项目时首先需要进行业务利益分析（商业案例/BusinessCass），组织可以获得的业
务利益是实施 IT项目的源动力。
*组织可以获得的业务收益才是实施 IT项目的源动力
*规划 IT项目时，首先要考虑业务模式（商业模式、业务案例）
*可行性分析时业务模式分析的一种
*在可行性研究分析时就必须决定软件系统是自己开发还是购买。
*对项目进行充分详细的业务模式分析，作为启动和持续一个项目的验证条件，为项目的实
施提供一个合理的理由
*业务模式分析是项目生命周期中各个决策过程的关键因素，无论在项目的哪一个阶段，如
果业务模式分析表明由于成本增加或预期的利益不能实现使得项目不再有意义时，项目发起
人或指导委员会应当考虑是否要终止项目的执行。
*业务利益由谁来验证。
*项目管理的四个要素：环境、资源、目标、组织
*项目管理的方式是目标管理。
*在一个良好定义的项目中，通常建立了一些决策点，有时称为“阶段点”或“生死点”，在
这些点上进行业务模式分析后决定当前的项目是否依然有意义。
*如果 IT项目实施阶段中其业务模式发生变化，应当通过部门规划和审批流程对项目重新进
行评估和批准
*实施后评审：在项目实施后 6~18个月进行，评价利益实现程度，独立于项目实施的审计师
进行评审
*有关项目的所有治理决策应当由业务效益驱动，并进行周期性评审
*信息系统项目可以由组织的任何一部分启动，包括信息系统部门
*项目管理的一般过程：启动、计划、执行、控制、收尾（其中控制过程，贯穿整个项目实
施过程）
*业务过程的设计方法也同样适用于项目管理过程
*项目环境最关键就是一把手工程。
*项目管理的组织规划：
1、职能式组织形式：项目经理仅作为一个成员，没有正式管理权权限无
2、项目式组织形式：项目经理有正式授权负责项目权限高
3、矩阵式组织形式：项目经理与部门经理同时共同分担管理权限权限中
*用户管理部门拥有项目和最终系统的所有权，当系统被定义和完成时，用户管理部门应当
评价和批准系统的交付。
*安全主管评价安全测试计划并在实施之前进行报告
*项目发起人对项目指导委员会负责；
*项目经理负责项目的日常活动；
*关键用户在需求分析阶段、测试阶段需要积极参与；用户培训在测试阶段进行，主要培训
怎么使用软件。
*在测试阶段用户需要参与测试案例的开发。
*QA独立整个项目组，对整个项目的活动做独立的评价。
*项目沟通文化：各类会议
*项目分解结构：
1、先建立对象分解结构（OBS）
2、建立项目工作分解结构（WBS）
3、WBS不包括方案中基本元素，表示为工作包（WPS）
*永远不能靠忽视质量来满足工期、时间、资源的要求。也不能忽略测试；在特别的情况下，
只能减少功能。
*成功的项目计划的全面特征式项目基于风险的管理过程而且本身是互动的。
*项目中三个元素/纬度必须考虑
1、时间/持续时间需要花多少时间才能完成项目
2、成本/资源需要花费多少
3、交付品什么是必须做的
*软件规模评估：源代码行数、功能点分析（FPA）、FPA特征点
*源代码行数评估结构化程序语言（BASIC、COBOL）有用，其他不行，尤其业务功能不行
*功能点分析（FPA）广泛用于评估开发大型业务应用的复杂性。功能点分析的结果用于度量
基于输入、输出、文件、接口和查询系统的规模
*FPA特征点分析对于网站应用，能有效估算特征点、访问规则、页面链接和存储有关的应用
*项目评审技术（PERT）是一种网络管理技术，常用于充分计划的系统开发项目。
*甘特图的缺点：无法表现任务之间的逻辑关系
*PERT时间计算=（乐观完成时间+4X最可能完成的时间+悲观完成时间）/6
*先用 PERT算出每个工作的工期，然后再用关键路径法
*关键路径法中，有多条路的时候找最长的路。也就要确保整个路径图中所有任务能在计算
出的时间内完成。
*关键路径中的松弛时间为 0
*设计系统开发项目的 PERT 网络时，第一步是识别所有的任务、项目的相关事件/里程碑和
它们相对应次序
*时间盒管理是项目管理方法
*原型法的项目管理方法是时间盒管理
*时间盒管理中：时间、质量、资源不可变，只有功能可以变
*时间盒管理是在一个相对短的、绝对的和不许变更的时间以及有限资源的情况下，定义和
部署软件交付产品。
*时间盒方法主要优点是避免项目成本超支以及进度拖延
*时间盒方法由于最终用户的参与，测试用例的准备和测试需求很容易达到，系统测试和用
户接受测试通常可以一起执行。
*项目控制活动包括项目的范围管理，资源使用和风险管理。记录项目新的需求并在批准后
分配合适的资源。
*范围变更管理：
变更请求必须提交项目经理
项目经理提交项目咨询顾问委员会决定是否建议变更
项目出资人决定是否变更
*项目出资人有最后决定是否变更的决定权。
*项目过程的变更控制就是确保项目的完成时间，项目资金的使用和项目质量达到利益相关
方的预期
*系统开发生命周期（SDLC）一般具有开发、实施、维护和废止阶段
*项目资源利用采用 EVA挣值分析
*项目风险主要有：
1、对业务收益产生冲击（及对项目的存在性构成风险）——项目投资人
2、对项目本身产生风险的——项目经理
*V模型中：
用户需求——接受测试 UAT
功能需求——系统测试
概要设计——集成测试
详细设计——单元测试
编写代码
*V模型中：
1、单元测试用于验证详细设计的正确性；
2、集成测试是用于验证各单元集成后的正确性
3、系统测试用于验证系统总体功能与架构的正确性
4、用户接受测试是用户为了验证软件是否实现了用户需求
*开发的业务应用系统一般都可以归为两种类型：
组织中心计算型（采用 SDLC生命周期方法）
用户中心计算型
*SDLC 也被称为瀑布式开发技术，是一种系统的、顺序式的软件开发方法，从可行性研究开
始，通过需求定义、设计、开发、实施和实施后维护等阶段而逐步发展，建立了相应的责任、
预期的结果和完成目标的日期。
*SDLC 需求定义：描述系统应该做的，用户如何与系统交互，系统运行的条件，系统应满足
的信息标准；确保需求完整、连续、清楚、可验证、可修改、可跟踪
*审计师在 SDLC需求分析阶段需要关注：业务部门的人员积极参与到需求调研中；安全控制
是否提出（审计师作为用户，提出嵌入式在线审计模块是否提出）
*SDLC 方法适用于一个需求稳定、定义准确的项目，并且在开发工作早期建立总体的系统架
构
*软件购买阶段：
1、不修改，只配置
2、进行部分定制开发
3、完全重新开发（绝对不允许，ERP软件代表行业的最佳实践）
*迭代法：业务需求被迭代开发和测试直至整个应用系统被设计、建立和测试。适合于 WEB
应用开发
*需求定义阶段决定软件是自行开发还是购买软件包
*软件征求建议书中应该包括（重点）：
1、供应商的财务稳定性；
2、源代码的可用性
3、提供此类产品的时间；
4、先做 UAT测试
5、签订合同之前需要本公司法律顾问核准
*UAT测试后，实施前一定要求最后软件进行打包，不允许进行最后一分钟修改。
*自行开发的设计阶段==购买软件包的选择阶段
*自行开发的开发阶段==购买软件包的配置阶段
*实施阶段在最终用户验收测试完成、用户签署正式文件后进行
*组织应当按照ERP的要求首先要转变原有的管理理念、策略和实践方法，并按业务需求对ERP
进行定制，才能有效提高信息技术能力，以支持组织业务目标的实现。
*进行 ERP的风险评估是组织高级管理层的责任
*一旦决定推进一个项目，首先应该做一个分析来清晰地定义需求以及识别与这个需求相关
的备选方案，这个分析称为可行性研究
*信息资源包括：人员、应用系统、技术、设施和数据，通过一系列 IT过程加以管理
*可行性研究报告首先由项目负责人审查（审查内容是否可靠），再上报上级主管审阅（估价
项目的地位）。从可行性研究应当得出“行或不行”的决断
*与可行性报告联系紧密的是影响评估，研究当前项目对其他项目和资源的潜在影响。评估
结果需要列出一具体行动方案的好处和坏处。
*需求定义即在可行性研究后对选择的业务系统识别和明确业务需求。需求包括：描述系统
应该做的，用户如何与系统交互，系统运行的条件，系统应该满足的信息标准。
*信息标准包括：系统的效力、效率、机密性、可用性、合规性和可靠性。
*最终用户在这阶段详述他们对信息资源的要求
*在需求定义阶段，一个系统的初步设计呈交用户管理层审阅，修改，批准和支持。创建项
目计划用于开发、测试和实施系统。
*在需求分析阶段，所有相关的管理人员与用户都应积极参与到需求定义中来。
*实体关系图（ERD）描述的是系统数据和这些数据是如何交互的，可作为需求分析工具
*实体关系图（ERD）的基本元素是实体和关系
*信息系统审计师在需求分析阶段要确定：应用系统是否定义了充分的安全需求以保证系统
的机密性、完整性和可用性；是否定义了完备的审计踪迹作为系统的必要组成部分，审计踪
迹是审计师未来进行跟进的重要依据。
*如果决定购买现成的商品化软件包，那么用户也要积极参与到软件产品的评估和选择过程
中。
*组织应当建立一个由技术人员和主要业务人员组成的项目小组，由项目小组制定征求建议
书（RFP）或邀标书（ITT），并发送给软件供应商，让软件供应商根据组织的需求，在考虑
技术先进、成本最优的前提下，提供最佳解决方案。
*征求建议书（RFP）的内容：
产品与系统需求
客户参考资料（成功案例）
供应商的生存能力/财务稳定性
完整可靠的文档
供应商的服务支持
源代码的可用性
提供此类产品的年头
最近对产品的更新计划
当前使用改产品的用户数及列表
对产品的接受测试（在正式购买前必须要做）
*征求建议书（RFP）—需要供应商提供解决方案和相关的支持与维护服务
*邀标书（ITT）—已经知道需要购买什么样的产品和服务
*在正式的征求建议书（RFP）前，要先起草信息征求书（RFI）文件，送给软件供应商，请
其就组织的特定需求，提供产品与服务方面的初步咨询意见与建议。组织根据各个供应商提
供的信息，制定出正式的征求建议书。
*考察其他相同类型的组织使用这种软件包的情况，重点在于：
1、可靠性—供应商的产品递交是否可靠
2、承诺的服务—如果产品出现问题，供应商的服务响应是否及时
3、为产品提供文档及培训的承诺—客户满意度如何
*信息系统审计师要参与到软件获取过程中，保证组织与供应商达成任何协议前，已充分考
虑了安全控制的需要，否则很难保证系统要处理的信息的完整性；
*设计阶段必须制定计划：测试计划、数据转换计划
*商品化软件包相关的风险：不完备的审计踪迹、口令控制和应用系统的整体安全
*由系统分析师进行软件架构设计来描述系统蓝图，进而详细分解系统各个部分和要素
*在软件设计过程中，最好不要让用户参与；但是设计人员应当向用户解释软件结构是如何
满足用户的业务需要的
*信息系统审计师主要关注系统设计对控制的影响
*关键的设计阶段：
1、开发系统流程图和实体关系图模型，说明信息在系统中如何流动
2、确定是否使用结构化的设计方法，通过一系列数据或流程图自顶向下建立各种关系
3、描述输入输出（原型开发工具中，是最重要的设计内容）
4、确定软件的过程步骤和计算规则，满足功能需求
5、确定数据文件或数据库文件设计
6、为各种类型的需求或已定义的信息标准，建立程序规格说明书
7、制定各种类型的测试计划：单元测试（程序测试）、子系统测试（模块测试）、集成测试
（系统测试）、测试与其他程序的接口、测试系统装载和初始化文件、压力测试、安全测试、
数据备份与恢复测试
8、制定数据转化计划，把数据从老系统转换到新系统
*软件配置管理引入基线（Baseline）概念，软件设计阶段代表了软件基线管理过程中的一
个优化点，基线的概念意味着一个设计阶段的一个“冻结”点。一旦为软件开发过程建立了
基线，就要引入配置管理的过程来管理对软件的修改，以协调和控制整个系统。如果控制不
到位就会产生范围蔓延。
*基线标志软件开发过程的里程碑，任何一个软件配置项（如设计说明书、测试计划等），一
旦形成文档并审核通过，即为一个基线。
*基线标志开发过程中一个阶段的结束。对于已称为基线的软件配置项，虽然可以修改，但
必须按照特殊、正式的变更管理过程进行评估，在确认风险与成本的前提下，再进行修改。
*详细设计完成后，在得到用户同意和建立软件基线的情况下，就可以把设计方案交给系统
开发人员进行编程
*设计阶段，信息系统审计师应审核在系统规格说明书、测试计划中建立了完备的安全控制，
是否将连续在线审计功能集成到系统中
*在软件设计阶段的关键文档包括：系统规格说明书、子系统规格说明书、程序规格说明书、
数据库系统规格说明书、测试计划和正式的软件变更控制程序
*软件开发的目的是通过编程实现开发者在系统分析和系统设计中提出的管理方法和处理构
想
*开发阶段的编程责任主要在编程人员和设计系统的分析员身上
*需要开发数据迁移计划、用户迁移计划
*集成开发环境（IDE），容易受非授权访问出现错误以及版本无法控制；因此需通过访问控
制软件来控制风险
*编程标准是一项基本控制，是系统开发过程中编程团队成员之间、编程团队与用户之间交
流的方法
*联网的集成开发环境应当通过访问控制软件来控制非授权访问之类的风险
*调试工具就是协助编程人员在开发阶段发现错误、修改代码的软件，一般分为三种类型：
逻辑路径监测、内存转储、输出分析
*输出分析一般通过比较预期的结果与实际结果而实现检查程序运行的输出结果的精确性
*软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例
（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的
过程
*在测试过程种，信息系统审计师扮演的角色是预防性和发现性的
*软件测试方法（一般用自底向上）：
1、自底向上—在所有程序完成前就可以进行测试；对关键模块的错误可以较早发现
2、自顶向下—可以较早对主要功能和处理过程进行测试，接口错误可以较早测试出来，增
强用户对系统的信心
*测试分类：
1、单元测试：针对程序模块，进行正确性检验的测试
2、接口测试/集成测试：一种软件或硬件测试，评估两个或多个模块之间的连接，而这些模
块之间有信息传递。在系统之间传递数据时测试确认和验证单个系统系统的应用程序功能
3、系统测试：对整个软件进行测试；目的在于通过与系统需求定义作比较，发现软件与系
统定义不符合或与之矛盾的地方
4、最终接受测试：当开发与测试人员完成所有测试，准备交付软件产品时，就应该开始系
统的用户接受测试。
*系统测试的测试用例应根据需求分析规格说明来设计，并在实际使用环境下运行
*用户接受测试以用户为主，主要有两类人员：使用软件的最终用户、质量保证人员
*UAT测试主要测试业务功能。QAT需要测试运行功能
*用户接受测试（UAT）一般使用用户界面输入测试数据，分析测试的输出结果，一般使用生
产中的实际数据进行测试，以确保用户要求的功能得到实现
*质量保证测试（QAT）对软件的可移植性、兼容性、可维护性、错误的恢复功能进行技术性
确认
*系统测试包括：
1、恢复测试：检查系统从硬件或软件故障中恢复的能力
2、安全测试：确保新系统内置了充分的访问控制
3、压力测试/容量测试：对大量数据的处理，评估系统在处理高峰时的性能
4、性能测试：利用通用测试标准来比较系统性能
*UAT测试应该在单独的测试环境，不能与生产与开发环境在一起
*用户接受测试（UAT）应该在源代码和可执行代码都能得到很好保护的安全测试环境，有助
于避免非授权的版本或最后一分钟还在修改的系统没有经过标准的系统维护过程就直接引
入正式系统
*α测试是由一个用户在开发环境下进行的测试，是在受控环境下的测试。目的是评价软件
产品的 FURPS（功能、可使用性、可靠性、性能和支持）；在编码结束之时就可以开始
*β测试是由多个用户在一个或多个用户的实际环境下进行的测试，非受控环境下的测试，
主要目的是测试可支持性；是衡量产品的 FURPS（功能、可使用性、可靠性、性能和支持）
*β测试中所有的产品手册文本也应该完全定稿
*只有当α测试达到一定的可靠程序时，才能开始β测试
*模拟测试只是对系统进行有限评估的方法
*白盒测试：把测试对象看作打开的盒子，允许测试人员利用程序内部逻辑结构及有关信息，
设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实
际的状态是否与预期的状态一致
*黑盒测试：在软件接口处进行测试，证实每个实现的功能是否符合要求。必须在所有可能
的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出，一般用于 UAT
测试。
*功能/确认测试：验证软件的有效性，验证软件功能和性能及其它特性是否与用户的要求一
致
*回归测试：对测试计划或测试场景的某些内容重新进行测试，目的是为了保证最近对软件
所做的变更和修改没有引入新的错误。回归测试中所用的数据要与以前的测试数据一致
*平行测试：把一套测试数据同时输入到被测试系统（新系统）和对比系统（原系统）中去
运行，比较两个系统的输出结果，以判断被测试系统的正确性
*社交性测试：证实新系统在目标环境中运行时，不会给其他系统带来负面影响（包括平台、
接口、桌面以及操作系统等环境）
*新信息系统实施前：程序已经被测试优化、存在程序流程和生产计划、初始数据已经成功
的转换并导入到新的系统中、用户已经制定了运营流程并完成了全员培训、已经确定了系统
投入运营的日期和新旧系统切换的日期
*实施计划的阶段：
阶段一、制定所需的支持结构
差距分析——定义当前支持组织和未来所需组织之间的差距
角色定义——对项目的各个角色进行明确的定义
阶段二、建立支持功能
*一旦项目所交付的新系统完成，准备上线运行时，还需要建立有效的支持结构包括：工作
岗位、人员角色、职责、技能培训、工作分配。
*要对实施的各个阶段（从老系统到新系统的构建、集成、移植和转换）进行有效管理
*实施计划（知识转移计划）——应当按照渐变式或接力棒方式进行，这是知识转移和职责
转移的最佳方式
*培训计划——定义了角色与职责后，需要用矩阵图方式记录，便于相关人员清晰理解。制
定培训计划应明确：培训内容、日程、持续时间、培训方式（现场或网上）、先期对培训者
进行培训
*培训目标是保证终端用户在系统运行过程具有必要的使用能力
*终端用户培训中最重要因素就是确保在开发阶段的早期就考虑培训的问题
*数据转换的目标是将当前的数据转换成需要的格式、编码和结构，同时要保证数据的完整
性和可用性
*数据转换过程必须提供一些方法，如审计痕迹和日志，以允许对转换数据进行精确性和完
整性验证（可以手工也可以通过系统工具自动完成）
*数据转换步骤：
1、确认哪些数据需要程序进行转换，哪些数据使用手工转换；
2、转换前进行必要的数据清理
3、识别用于验证数据转换是否成功的方法（自动文件比较、比较记录数、控制总数、记帐
平衡数和抽样选择）
4、建立数据转换的接受标准
5、确定数据转换项目任务的先后顺序
6、设计用于记录转换的审计追踪报告
7、设计例外报告记录没有成功转换的数据项
8、明确确认，为每一个转换步骤签字和接受最终转换成功的责任人
9、开发和测试数据转换程序，包括功能和效率
10、进行一次或多次数据演练，让相关人员熟悉整个项目的各个步骤，各自的责任，并且使
用真实的数据测试转换流程
11、对外包流程，需要签署包括保密在内的合适的协议
12、在实际数据转换时，所有必要的人员要到场，或者至少能联系上
*成功的数据转换时系统按时、符合预算和按质上线的前提
*数据转换的备份：旧系统最后一个拷贝/新系统转换过来后的第一个拷贝，都需要永久保存
*数据转换的风险：
1、正常运行的中断
2、破坏数据安全和数据保密
3、在系统迁移过程中，数据不一致和不完整
*企业配置库可以对组织中的系统重组过程和数据移植过程提供一个全景图
*通过模块分析，界定项目实施过程中的功能模块与数据实体的范围，基于这些信息和对业
务需求的分析，对实施项目的计划进行精细调整
*分阶段部署应用系统，以最小化新系统实施对终端用户的影响，通过实施失败后的回退操
作减少负面影响，降低风险
*为新技术架构设计的数据重定向器要符合面向服务的架构要求，使新系统在运行过程中能
对遗留系统的数据进行访问
*数据转换组件把遗留数据模型转换到新数据模型，这些组件有三种：
1、下载组件——从遗留系统中下载数据
2、传输组件——从遗留系统向新系统传输数据
3、上载组件——向新系统上载数据
*组织一旦决定购买软件包，就要根据系统所需的数据库及供应商提供的转换工具，尽快设
计数据的转换方案。
*一旦新系统不能正常运行，移植失败后，需要把已转换得到的新数据结构，通过逆向转换
组件再恢复为遗留数据结构。
*数据回退应急计划：
1、下载组件从新数据结构执行数据下载，传输组件为数据转换传输数据，上载组件向遗留
数据结构上载数据
2、系统运行时，通过日志组件记录下新数据模型在服务层上对数据的修改，传输组件为数
据转换传输数据，上载组件向遗留数据结构上载数据
*基于以下标准，在每一个实施项目内作出是否需要回退的决策：
1、交易量大小
2、数据模型的变动程度
*程序员编写的数据转换脚本完成并通过验收后，应当先用生产数据库的副本进行测试。测
试数据值时需要包含在业务过程的测试中进行，直到完成对转换脚本的精确调整，用户和开
发人员才能完成测试周期。
*数据转换中的关键因素：
1、数据转换的完备性。源数据库记录总数与转换后的新数据库的记录总数保持一致；
2、数据的完整性。没有被任何方式替换或改写过，包括错误蔓延
3、转换过程中的机密性。非授权拷贝或者转换前数据备份没有有效管理
4、数据的一致性。新系统与旧系统调用的字段与记录应保持一致
5、连续性。新系统应能持续追加新记录，保持业务运行连续性
6、转换前在旧系统对数据进行最后一次备份（拷贝）；转换后，在新系统对数据进行第一次
备份（拷贝）。并分别进行管理与维护
*只有对新系统的程序与相关数据进行了充分的测试后，才能进行系统切换，也叫系统上线。
*系统切换技术有三种方式（并行转换风险最小，也有助于在新项目的初始阶段发现存在的
问题）：
1、并行转换：也叫平行切换，使新系统与老系统同时同步运行，通过一段时间的观察与评
估，在对新系统的运行获得充分信心后，才最终切换到新系统
2、分段转换：把老系统拆分成与新系统对应的可交付的各个模块，用新系统的模块逐步替
代老系统的对应模块，直到全部完成。这种切换可以是预先计划的，分阶段的方式来实现
3、直接转换：也叫快速切换，在一个选定的时间，快速从老系统切换到新系统，一旦切换
完成后，老系统就不再使用（考虑回退问题）
*分阶段切换的风险（现实中没有人这么干）：
1、资源挑战：IT 方面维护两个不同的软、硬件环境；运行方面维护用户手册、程序、流程、
政策及系统条款的定义
2、延长项目生命周期以覆盖两个系统
3、为持续维护旧系统而进行需求的变更管理和定制
*切换新系统的四个步骤：
1、对文件和程序进行转换，在试验台上进行测试
2、安装新硬件、操作系统、应用系统，并移植数据
3、对员工或用户进行分组培训
4、安排系统切换时间
*系统切换时可能存在的风险：
1、对信息资产的保护
2、数据完整性
3、系统效果
4、系统效率
5、变更管理带来的挑战
6、如果数据清理没有作好，可能存在重复或错误的记录
*新系统实施后评审，验证新系统是否达到了设计、开发要求，必要的控制措施是否已内置
到系统种（6~18月）
*实施后评审的目标：
1、评估系统的充分性（满足需求、定义控制）
2、评价项目成本效益或投资回报
3、针对系统缺陷，提出改进建议
4、为改进建议制定详细计划
5、对项目过程进行评估
*项目后评审可以由项目开发团队和合适的最终用户联合组成，评估与评判项目过程，评估
与测量项目所具有的业务价值
*在开发过程中曾为项目团队充当咨询顾问的审计师不应当涉入项目后评审
*由信息系统审计师实施的实施后评审主要是关注系统开发与实施过程中控制方面的问题
*在设计和开发软件系统的风险：
1、系统不符合用户的业务需要，不能达到用户的期望值
2、项目风险，设计和开发系统的项目活动超出了必要的财务资源限制，项目就会被推迟
*对系统功能的开发一般是以模块化的方式自顶向下进行的，有助于程序员用线性方式来对
模块进行系统化开发和测试
*传统的软件开发生命周期（SDLC）方法进行业务应用系统开发时候，审计师应当关心这种
结构化的过程是否被良好定义、记录和遵循
*软件的开发方法：
1、增量开发或渐进开发——系统内嵌到各阶段或版本中，而不是在开发完成后整体交付。
通常在第一个版本中交付基本系统结构，随后的版本在系统功能、用户范围和使用定位方面
不断扩充
2、迭代开发——使用迭代或增量来构建系统。当出现一个需求增量后，产生反馈以促进项
目计划和软件开发产品的重新调整。迭代开发被认为是一种最佳实践，是处理软件开发项目
中复杂性和相关风险的最恰当的方法
3、演化式开发——原型设计用于构建一个可工作的模型，确认需求和寻找设计中存在的问
题；最后，原型被“固化”，并实施到产品中去，或基于向原型的学习，对系统重新编码
4、螺旋式开发——对于复杂的大型软件，开发一个原型往往达不到要求，因此使用一系列
的原型来开发一个解决方案
5、敏捷开发——项目被分解成相对较短的时间段进行迭代开发（分割成小模块进行开发），
开发的重点是快速生产出可工作的功能性产品；以预定的开发方法和体系结构，先开发出一
系列具有基本功能的模块，然后对这些模块进行迭代，功能性从用户接口开始扩展，提高用
户和开发人员的信心
*当今系统复杂性包括：
1、系统开发的广度和深度在不断增加
2、业务变化的速度在增加，导致需求不稳定
3、针对不同的系统结构，需要制定多个决策方案（包括软硬件）
4、新系统都需要与遗留系统集成
*敏捷开发流程的特点：使用小规模基于时间盒的小项目或迭代，在每个迭代末端都对项目
重新计划，对需求优先级重新排列，严重依赖有效散布默认知识并促进团队工作的机制。
*在敏捷开发流程中，项目经理的角色是项目的促进者和协调人，计划和控制项目的责任移
交至项目成员
*敏捷开发只会详细计划下一个迭代开发，不会一次性计划之后的所有开发
*原型法——也叫启发式或演化式开发。用户首先提出要求，开发人员识别和归纳用户要求，
根据识别、归纳的结构，构造出一个原型，然后和用户一起评价原型，通过重新构造或者修
改，直到用户满意为止。通过控制错误来减小开发系统的风险
*原型法促使开发商和客户理解每个演化水平的风险并对这些风险做出反映（使用原型法作
为降低风险的机制）
*原型法的风险：
1、控制机制较弱，如备份和恢复、安全和审计轨迹等方面；
2、变更控制更加复杂。需求和设计变更很快，很少文档化，系统不易维护
*原型法的优点：省时、节约
*快速应用开发（RAD）是一种方法论，支持单个系统开发，不支持信息系统规划与分析。
*快速应用开发（RAD）过程如下：
1、概念定义，决定系统范围
2、功能设计，将系统数据和过程模型化，建立关键系统组件模型
3、开发阶段完成物理数据库和应用系统构建
4、安装系统，包括最终用户培训、数据转换，应用系统实施
*业务流程重组（BPR）是尽量改变当前的业务流程，而不是做出动态的改变
*面向数据的开发方法：把数据与处理数据的过程分离，只考虑数据，不考虑处理数据的过
程，必须与其他开发方法结合使用，才能有效开发适合业务的解决方案
*面向对象开发方法的主体是对象，特点是（支持代码复用，系统无须修改）：
封装性：将对象作为一个独立存在的实体，从外部可以了解其功能，但内部细节是隐蔽的，
不受外界干扰。对象之间相互依赖性小，可独立被其他各系统选用
继承性：对象和类之间的层次结构具有继承关系，子类继承父类属性
多态性：各种对象之间具有统一、方便、动态的消息传递机制
*面向对象的开发过程：
1、对系统进行调查，并进行需求分析
2、面向对象分析，抽象的识别出对象及其相关属性，建立系统的分析模型
3、面向对象设计，对分析模型进行归类整理，以范式的形式确定
4、系统的实现，用面向对象的程序设计语言将范式映射成应用程序软件
*面向对象开发的优点：
继承机制——提高开发效率
封装性——简化开发过程
多态性——增强系统对环境变化的适应
*逆向工程主要考虑：版权问题和编译器成本问题
*面向对象开发的技术：
WEB应用
电子商务
为软件开发提供的 CASE
办公自动化
人工智能
为生产和流程控制的计算机辅助建筑
*基于组件的开发方法
过程内客户端组件——组件必须在一个容器内运行，不能独自运行（浏览器）
独立客户端组件——将应用导出给其他软件的应用（如 OFFICE组件）
独立服务器端组件——运行在服务器上，以标准方式提供服务的过程当作组件（微软 DCOM）
过程内服务器组件——运行在服务器容器内
*组件开发的优点：
1、减少开发时间；
2、改善质量
3、允许开发商更加关注业务功能
4、加强模块性
5、重用性
6、减少开发成本
7、支持多用户开发环境
8、允许在构造和购买的选择之间进行协调
*基于 WEB的应用开发方法，主要用于在组织中进行更简单、更有效的代码集成。
*通用描述，发掘与整合（UDDI）是一项关于 WEB 服务与其资料信息如何在互联网上进行注
册的标准规范
*企业透过 UDDI规范将自己公司简介与提供的服务相关资料注册在白页、黄页以及绿页上。
*白页——包含各企业的一般信息（公司名称、联络资料）
*黄页——将各企业依照产业、产品、服务以及地区等条件整理成一套分类目录
*绿页——记载了如何取用某项特定服务的各种技术性细节
*软件重组——通过抽取、重用现存软件的设计与程序组件，对现有系统进行升级的过程，
用来支持组织业务运行方式的主要变更
*逆向工程法——分析已有的程序，寻求比源代码更高级的抽象表现形式
*逆向工程进行方式：
1、将对象和可执行文件拆编成源代码，分析程序；
2、采用逆向工程作为黑盒，采用数据测试揭示它的功能
*逆向工程优点：
1、快速开发降低软件开发生命周期 SDLC
2、改善代码质量
*逆向工程的风险：
1、软件许可协议通常包括限制软件逆向工程的声明；
2、反编译器的购买以及针对不同组件需要不同的反编译器
*IT 部门的一个关键任务就是：对当前物理架构进行分析，定义所需要的新系统，并规划从
现有系统向新系统转移的路径图
*利用率——系统不宕机时间
*物理架构分析的各项目阶段：
1、对现有架构的检查，列出基础设施各组件的列表以及所有能影响物理架构的限制条件（场
所、规模、重量、供应安全等）
2、分析与设计，对当前物理架构的现状进行分析，与行业最佳实践及业务需求进行对比
3、起草初步功能需求，初步确定未来的架构方向和业务需求
4、供应商与产品选择
5、功能需求的正式成文
6、概念验证，以证明所选择的硬件与软件能够满足所有的期望，包括安全方面的需求（考
虑以最小的费用达到验证目的）
7、基础设施的规划实施
8、采购阶段：对交付物建立一个量化的结构，并建立详细的需求陈述。
9、交付时间，制定交付计划
10、安装计划
11、安装测试计划，应包括：测试案例、基本需求规格说明书、过程定义、针对应用系统和
基础设施的各种测量信息
*基础设施实施规划的成功因素：
1、要吸收有一定技能的合适成员参加到工作组中来，并要全程参与项目实施，避免产生项
目延误；
2、完成工作所需的文档应当在项目开始时就准备好
3、决策制定者必须参与项目各个环节，确保所有必要的决策快速制定
4、为做好准备，必须完成物理架构的分析，并为所需的基础设施方案做出决策
*在信息系统的短期和长期计划中，都应当对操作系统升级加以规划。
*审计师不会参与到采购活动中，更不会对采购的价格进行任何评价或建议。
*实施系统软件时，需要先在一个非生产环境中对系统软件进行测试，在把系统软件安装到
生产现场前，还应当获得一定形式的认证与认可。
*设计系统软件变更控制程序是为了确保对系统软件的任何变动需要得到授权，而且以不影
响正常业务处理为前提，并且建立针对变更失败回退恢复程序，以最小化变更可能带来的负
面影响。
*信息系统维护实务主要是指管理应用系统变更的过程，目的是保证软件产品源代码与可执
行代码的完整性
*应用系统变更由用户管理部门批准正式实施
*系统软件实施一定要先测试再实施。
*操作系统打补丁一定要走变更流程。
*所有对生产环境的变更一定要通知用户（不论软/硬件）；
*所有变更记录必须永久保存。
*应根据系统开发时采用的相同规格，对变更程序进行测试与验证，确保程序变更实现了所
需的功能。如风险分析认为有必要的话，还需要进行额外的测试保证：现有功能没有受到变
更的影响；系统性能没有因为变更而受到影响；变更没有引入新的安全暴露风险
*开发人员不能进入生产环境。
*紧急情况下开发人员进入生产环境进行补救：采用 frieID，所有操作记录日志，所有正常
的变更程序及时补上。
*在评估对应用程序的变更过程是否充分时，信息系统审计师应当确保组织已建立了适当的
控制措施，能够防止对生产中的应用程序的非授权变更
*只有独立于计算机编程的成员才能将变更从测试环境迁移至生产环境中，如：控制组人员、
计算机维护人员，QA或者指定人员
*因为软件维护过程中的控制难度，组织使用配置管理系统。维护申请需要正式的保存并由
变更控制小组审批
*有效使用配置管理系统提供了一个重要证据，说明管理层承诺对维护流程实施谨慎的控制
*识别可能需要变更的项目叫做配置项（包括程序、文档和数据）。
*将配置项移入到受控环境中的流程称为录入。
*当变更需要时，配置项由配置经理录出。一旦变更完成，则需要分配另一个不同的版本号。
这个录出的流程也可以防止或管理对代码的同时编辑
*配置管理流程通过开发和遵循配置管理计划和流程来实现
*配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个系统过程
*系统开发工具和辅助工具：
1、代码产生器：代码生成器通常和 CASE工具结合在一起，根据系统分析定义的参数或 CASE
产品产生的数据（实体）流程图来生产程序代码。这个产品使得大多数开发者可以高效地生
产代码
2、计算机辅助软件工程：CASE 是辅助软件开发过程的自动化工具的使用，包括用于软件的
需求分析、软件设计、代码生成、测试、文件产生和其他软件开发活动的软件工具的应用
3、第四代编程语言（4GL）：非过程化语言、环境无关性（可移植）、软件功能强、支持程
序员工作台概念、使用简单语言子集
*CASE产品分成三类：
1、前端 CASE——描述和记录业务和应用需求的工具，包括数据对象的定义、实体关系和程
序的定义
2、中端 CASE——制定详细审计的工具
3、后端 CASE——生成程序代码和实施数据库定义的工具
*源代码比较：防止恶意代码，最好带时间戳
*CASE 技术是系统开发工具与方法的结合，强调的是解决整个系统开发过程的效率问题，跨
越了系统生命周期的各个阶段，而不仅仅是安装阶段。
*信息系统审计师应该获得以下保证：
1、适当的规格说明书得到了批准；
2、用户持续的参与到开发过程
3、在 CASE工具投资获得了质量和速度效益
*CASE 工具能够帮助应用系统设计过程，但是不能确保设计、程序和系统是正确无误或是满
足组织需要的，并且还需要一种有效的使用方法
*4GL分类：查询与报告生成器、嵌入式数据库 4GL、关系数据库、应用程序生成器
*流程是将输入转化为输出的一组相关的资源和活动。关键要素是：输入、活动、资源和角
色
*输入：规定了输出应满足的条件，是过程的起点
*活动：通常一个过程由很多个活动组成
*资源与角色：包括物质资源和人力资源
*组织在实施 ERP 过程中的业务过程重组一般是指实行套装软件促成的企业流程重组（PER）。
PER是整合 BPR与 ERP的一种方法，其主要原则是以 ERP为引发器来影响流程、人、组织的
BPR。当重组过程适合于业务需要时，组织就能从 BPR中获得最大利益。
*BPR流程中，一些关键控制可能会在业务重组过程中没有被采纳入新流程中去。信息系统审
计师的任务就是要确定组织中现存的关键控制，并评价撤消这些控制对组织的负面影响。如
果控制是关键的预防控制，信息系统审计师必须确认管理层已意识到控制被撤消，并愿意接
受没有这些控制所带来的潜在重要风险
*标杆管理主要是用于改善组织的业务流程，它被定义为评价组织的产品、服务和工作流程
的一个持续的、系统的过程，它是一种组织提高绩效的最佳实践。
*实行标杆管理采取的步骤
计划—在计划阶段，基准团队首先要在标杆管理实践中确定关键流程，理解它们如何被评价，
需要什么样的数据及如何收集需数据。
研究—团队应该收集流程的基准数据，随后是通过商业报纸、杂志、质量获奖者、行业杂志
等确定其他组织的相似流程作为标杆对象。
观察—收集资料并访问标杆对象，与标杆对象的组织之间应该有一个协议、一个资料收集计
划和一个便于观察的方法。
分析—总结和解释所收集的资料，并分析组织流程与标杆对象的流程之间的差异。把关键的
发现转换成新的操作目标是该阶段的目标。
调整—调整标杆比对的结果可能是最难的一步，在这个阶段中，团队需要把发现转换为一个
新的核心原则，并从原则逐步细化到战略再到行动计划。
改进—在标杆管理过程中，持续改进是一个关键因素。在一个组织中，标杆管理把组织中每
一个流程与组织目标、组织战略改进联系在一起。
*软件的质量通常可以从以下 6个方面去衡量(定义)：
功能性(Functionality)，即软件是否满足了客户功能要求；
可靠性(Reliability)，即软件是否能够一直在一个稳定的状态上满足可用性；
可用性(usability)，即衡量用户使用软件需要多大的努力；效率(Efficiency)，即衡量软
件正常运行需要耗费多少物理资源；
可维护性(Maintainability)，即衡量对已经完成的软件进行调整需要多大的努力；
可移植性(Portability)，即衡量软件是否能够方便地部署到不同的运行环境中。
*CMM的 5个级别
初始级、可重复级、己定义级、己管理级、优化级
*各级别要点：
第二级可重复级：关键之处是建立基本的项目管理控制。它们是需求管理、软件项目计划、
软件项目的跟踪和监督、软件外包管理、软件质量保证和软件状态管理。
第三级己定义级：关键之处是既关注项目问题，也关注组织问题，因为组织建立起了使高效
率软件工程制度化的基本架构和跨项目的管理过程。它们包括组织过程关注程度、组织过程
定义、培训项目、集成化的软件管理、软件产品化机制、项目组的内部协调和对出现错误的
复查。
第四级己管理级：关键之处是对软件开发过程和软件产品都有一个定量的理解。它强调的是
定量的过程管理和软件质量管理。
第五级优化级：关键点强调不论组织还是项目必须追求持续的、可度量的过程改进，包括缺
陷预防、技术更新管理和流程改造管理
*应用控制是存在于应用系统的事务和数据处理中，对每一个应用系统都是特定的，用于保
证记录的完整性和准确性及人工或自动数据录入的正确性的控制措施；是针对输入、处理和
输出功能的控制
*应用控制目的有以下内容：
在计算机系统中仅有完整的、准确的和有效的数据被输入和更新
处理过程完成了正确的任务
处理结果与预期目标相符合
输出数据得到了维护
*控制方法：编辑测试、总计、核对及对错误数据、丢失数据、例外数据的识别与报告等
*应用控制审计任务：
1、识别重要系统组件和贯穿系统的事务流，评价可得到的文档并与适当人员面谈；
2、分析积累的信息，开发适合的测试战略，确定应用控制强度，评价控制弱点的影响；
3、实施审计程序，测试控制以保证功能性和有效性
4、通过分析测试结果和其他审计证据，评价控制环境以确定控制目标是否可以达到
5、对照有效的编程标准和分析程序，并将其与系统的管理目标相比较，以确保应用系统运
行效率与效果的实现
*当一个系统输出可能是另一个系统的输入/源头时，必须对产生输出的系统的控制方式进行
审核（编辑检查、合法性确认和访问控制）
*输入控制确保每一笔需要被处理的事务能够被正确完整地接受、处理和记录，并确保只有
合法的、经授权的信息才能被输入，而且只对这些事务处理一次。
*控制类型
?输入授权
?原始凭证控制
?数据编码控制
?批控制和批平衡
?错误报告和错误处理方法
*输入授权验证所有的由管理层授权和批准的事务，输入授权有助于确保只有经授权的数据
才能进入计算机系统进行处理。
*授权的类型有：
?在批表格或源文件上签字
?在线访问控制
?唯一性口令
?终端或客户工作站的识别
?规范的源文件(输入后及时取消)
*原始凭证控制
?为防止在原始凭证上的舞弊，必须对原始凭证的来源实施控制
*控制方法：
?使用预先编号的原始凭证
?按顺序使用原始凭证
?定期对原始凭证进行审计
*数据编码控制
?常见错误：
?抄录错误(Transcriptionerrors)
?换位错误(Transpositionerrors)
?控制方法：
?检查数位(Checkdigit)
*批控制和批平衡
批控制
?对输入事务进行分组以提供控制总计。批控制可以基于总金额、总项目数、总文件数或杂
数总和等控制手段。
?批控制的类型
–总金额(Totalmonetaryamount)——确认被系统处理的项目总金额等于处理前批文件中项
目金额之和。
–总项目数(Totalitems)——确认在本批次中的每一个文件中的项目总数与被处理的项目总
数一致。
–总文件数(Totaldocuments)——确认一个批次中文件总数等于被处理的文件总数。
–杂数总和(Hashtotals)——确认一个批次中的所有文件中的数值类字段的总和与系统计算
出来的总和相等。
*批平衡——能够通过人工或自动的对帐(Reconciliation)来执行
?批平衡的类型
–批登记(Batchregisters)——通过登记对批总计进行人工记录，并与系统报告的总计进行
比较。
–控制账户(Controlaccounts)——使用控制账户是通过一个初始编辑文件来确定批总计。
数据被处理并先存入主文件，然后把主文件中的批总计与初始编辑文件中批总计进行比较。
–计算机一致（puteragreement）——批总计的计算机一致是通过输入记录批总计的批标题
细目来执行的，系统将其与计算出来的总计进行比较，再决定是接受或拒绝本批次。
*输入处理要求系统内部控制能够验证输入数据被系统正确地接受，输入错误会被识别和纠
正。
*输入错误的处理方法：
?仅拒绝有错误的事务—只有包含了错误的事务会被拒绝，该输入批次中的剩余部分事务都
会被处理。
?拒绝整批事务—包含错误的任何输入批次将会被拒绝，在下一次处理之前必须被纠正。
?暂停输入批次—任何包含错误的整次输入将不会被拒绝，但批次在被纠正以前将被挂起。
?整批接收并对错误事务做标志—任何包含错误的批次都会被处理，但包含错误的事务将会
被做上标记，将带有错误标记的记录从批处理文件移至一个临时建立的错误待处理中，以便
于后续的错误纠正操作。
*避免输入错误的控制技术有：
?事务日志—事务日志包含数据更新的详细清单，日志可以人工维护或者由计算机自动记录。
利用事务日志可以与系统已经接收的源文件数进行核对，以确认所有的事务已经被输入。
?数据对帐—验证所有接收到的数据是否被正确地记录和处理。
?文件——用户、数据录入和数据控制程序的书面证据。
?错误纠正程序—错误记录、及时纠正、向上再次提交、对纠正的批准、暂停文件、错误文
件、纠正确认
?预备—用户或控制小组准备数据的接收。
?传输日志—记录文件的传输或数据的接收。
?源文件取消—取消输入源文件的程序。例如：对己输入的表单通过用打孔或做标记的方法
以避免重复输入。
联机系统或数据库系统中的批输入完整性
?通过限制时段、终端及人员输入等方式来建立批控制。
?监督人应当先检查联机批输入，然后才提交给系统进行处理。
*处理控制用于保证应用程序处理的可靠性，信息系统审计师应当理解并评价这些程序与控
制能够涵盖经常出现在处理过程中的哪些暴露风险，还有哪些剩余风险。
*数据确认和编辑检查程序
建立程序以保证输入数据被确认，并且对数据的编辑要尽可能的接近于其原有格式。
如果输入程序允许监督人员可以绕开数据的确认和编辑控制，系统日志应当自动记录下这种
行为，而且日志应当由不能绕开确认和编辑控制的管理人员进行审核。
如果使用智能终端，就能够执行前端（front-end）数据的编辑与和确认。
*编辑控制是在应用程序中使用的预防性控制，发生在数据处理之前。
*数据确认与编辑控制的类型：
?顺序检查：通过自然序号进行控制记数的方式，任何失序或重复的控制将被拒绝或被记录
到例外报告中以备追踪调查。
?限制检查：数据不应当超过一个预定义的数量。（<4000）
?范围检查：数据应当在一个预定义的值的范围内。(100~200)
?有效性检查：按照预定义的标准进行的数据确认的一种程序化检查。(“M”or”S”)
?合理性检查：输入的数据与预定义的合理极限或发生率相匹配
?查表：输入的数据必须与存储在计算机中的数据预定义值相符合。
?存在性检查：数据被正确的输入并与有效的预定义的标准一致。
?击键校验：由不同的录入人员通过使用同一设备分别录入数据，通过计算机来记录并比较
录入人员击键顺序与次数的差异来发现录入过程的错误
?校验数位：一个经计算而附加到数据上的值，确保原始数据不被改变或者是被一个实际上
不正确但可能被计算机接受的值所替换
?完整性检查：一个字段应当总是包含非零和非空数据，要对该字段的每一个字节都要进行
检查，以检测数据是否满足非零和非空条件
?重复检查：对字段进行唯一性判断，防止重复输入
?逻辑关系检查：如果一个特定条件为真，那么，其他一个或多个附加条件或数据输入关系
也必须为真时，才能认为有效。
*处理控制程序
?保证数据在文件或数据库中的完整和准确，只有授权的处理或修改程序才能对数据进行更
改
*处理控制类型
1、人工重新计算（抽样）
2、编辑检查：用来测试数据的准确性、完整性和有效性
3、运行到运行的总计：在数据处理各阶段中验证数据值的能力
4、程序化控制：通过软件来检查和启动针对数据错误和处理错误的纠正行动
5、计算量的合理性检查：应用程序确认计算量的合理性，保证适合于预定义标准
6、计算量的极限检查
7、文件总数核对：应经常性运行此控制
8、例外报告
*对数据文件的控制类型：
1、处理前和处理后的数据映象报告
2、错误报告的维护和操作：错误报告应当由不涉及事务的人进行审核与授权
3、源文件保存期：保存期政策应该强制执行；源文件应当在一个安全、受控的环境中销毁
4、内部、外部标签：为可移动存储介质设定
5、版本使用
6、数据文件的安全：仅防止非授权访问
7、一对一检查
8、预录输入：例如日期录入，先期将当前日期显示在字段中
9、事务日志
10、文件更新和维护授权
11、奇偶校验检查
*系统控制参数—这些文件中内容将影响系统的正常工作和内部控制的执行。对这些文件的
任何改变都应当受到控制。
*应用系统以及操作系统的问题最大的就是参数控制
*常备数据—如供应商或客户的姓名和地址，这些数据不经常变动，在处理时可以参照。这
类数据在录入或维护之前应当经授权，输入控制包括对已经检查和批准的变动数据的出具报
告。审计踪迹会记录所有的变化。
*主数据或平衡数据—只有得到严格的批准和在完备的审核控制之下，才能根据事务更新操
作而产生的新的运行平衡和总计进行调整。当这种调整与变化对财务报告有影响时，审计踪
迹就很重要了。
*事务文件—通过使用确认检查、控制总计、例外报告措施进行控制。
*文件控制应当确保对于存储的数据只有授权的程序才能进行处理
*输出控制保证交付给用户的数据是符合格式要求的、可交付的，并以一致和安全的方式递
交给用户。
*输出控制主要有:
1、在安全的地方登记和存储重要表单
2、计算机生成可流通的通知、表单和签名：应当受到适当的控制，与物理表单对比，对例
外、拒绝和毁损情况应当进行适当解释
3、报告分发：按照已授权的分发范围进行交付，可以自动或人工，对整个打印过程也需要
控制
4、平衡和核对：数据处理应用程序的输出应当和控制总计平衡。建立审计踪迹
5、输出错误处理：错误报告应当及时交付给创建者进行检查，和错误纠正
6、输出报告保管
7、报告接收确认
*在集成的应用环境下，支持业务流程的应用系统中设计并内嵌了控制。
*对业务流程控制的鉴证需要在业务流程和业务活动这二个层次上对控制进行评价。
*这些控制可能是管理控制、自动程序实现的控制或人工控制
*控制包括：建立安全措施及职责分离机制，对访问权限进行阶段性的审核与批准，在业务
流程中建立应用控制等。
*业务流程控制鉴证中要考虑的特定因素：
1、流程图
2、流程控制
3、在流程中评估业务风险
4、对最佳实践进行标杆管理
5、角色与责任
6、活动与任务
7、数据限制
*信息系统审计师的任务是：
1、识别重要的应用程序组件和贯穿系统的事务流，通过评价可利用的文件和与适当的人员
面谈，获得对应用程序的详细理解
2、确定应用控制的强度，评价控制弱点的影响，通过积累的信息分析来开发测试策略
3、审核应用系统文件，加深对应用程序的理解。应当审核的文档：
系统开发方法文档：包括成本效益分析和用户需求分析
功能设计说明书：提供对程序的详细解释
程序变更：任何的变动都应当提供授权的证据并交叉索引到源代码
用户手册：可以寻找控制弱点
技术参考文档：应用系统的访问规则和访问逻辑常常包含在里面
*观察和测试用户操作程序
1、职责分离：确保没人具有执行多于一个下列处理过程的能力：启动、授权、验证或分发
2、输入授权：可以通过在输入文件上的书面授权或唯一口令的使用来获得证据
3、平衡：验证运行到运行的控制总计和其他应用总计得到及时核对
4、错误控制和纠正：以报告形式提供对错误进行适当的审核、调查、及时纠正和重新提交
的证据
5、报告的分发：应当在一个安全的地方产生并保存，并以授权方式分发
6、对访问授权及访问能力的检查和测试：访问控制列表提供了个人访问级别的信息
7、用户活动报告：提供用户详细的活动量和时间，应当进行审核，确保活动仅在授权时间
内
8、违例报告：描述任何不成功的访问，或未经授权的访问企图
*数据完整性测试：是一种实质性测试程序，检查保留在系统中的当前数据的准确性、完整
性、一致性和授权。
*关系完整性(Relationalintegritytests)：主键
*参照完整性(Referentialintegritytests)：外键
*联机事务处理数据完整性-ACID原则
1、原子性(Atomicity)：交易或事务处理要么执行完成，要么什么也不执行，如果发生错误，
所有变化返回原点
2、一致性(Consistency)：数据库从一个一致性状态转换到另一个一致性状态时，要遵守数
据的所有完整性约束
3、隔离性(Isolation)：每个事务与其他事务相互隔离，每个事务，只有访问数据是一个一
致性数据库状态的一部分
4、持久性(Durability)：如果给用户的事务报告是完整的，则对数据的任何变化都能恢复，
即使随后的软件或硬件出现故障
*测试应用控制的有效性包括：分析计算机应用程序、测试计算机应用程序控制、选择和监
控数据处理事务。
*测试应用系统技术：快照、映射、追踪和标识、测试数据（在真实的系统中的仿真交易）、
基于用例的系统评价、平行作业、整体测试、平行模拟（不需要准备测试数据）、事务选择
程序、嵌入式审计数据收集、扩充记录
*通用审计软件（GAS）在发现特定的应用程序控制弱点时特别有用
*连续在线审计为审计师提供了一个在正常的事务处理过程中收集可靠证据的方法，允许审
计师在持续的基础上对系统进行监控。降低了审计时间和成本，改善了系统安全性。
*连续在线审计技术：
1、系统控制审计检查文件和内嵌审计模型（SCARF/EAM）：非常复杂，适用于正常处理不能
被中断；通过在组织的主机应用系统中内嵌经特别编写的审计软件，使审计师以可以选择的
方式来监控应用系统的使用；
2、快照（Snapshots）：复杂性中等，需要审计踪迹时；记录一个事务从输入到输出各阶段
的处理轨迹。通过对输入数据使用标识符来对事务作标签，并跟踪该记录的处理轨迹，供信
息系统审计师后续检查
3、审计钩（Hooks）：复杂性低，只有所选择的事务或过程需要检查；在应用系统中内嵌程
序“钩”，像标识符那样起作用，在错误或不规范事务失去控制前，提醒信息系统审计师采
取行动
4、整体测试（ITF）：复杂性高，采用测试数据没有益处时；在审计对象应用系统的生产文
件中设置虚构的事务，通过与真实事务一起进入应用系统中运行，然后信息系统审计师经独
立计算的数据来比较虚构事务的处理输出，确认计算机处理数据的正确性（一定要隔离测试
数据和生产数据）
5、持续和间歇性模拟（CIS）：复杂性中等，符合某些标准的事务需要被检查时；在一个事
务的处理运行期间，计算机系统模拟应用程序指令的执行。在每一个事务输入时，模拟器就
确定该事务是否符合预定义的标准，符合就审计；不符合，模拟器就等待直到下一个符合标
准的事务出现。
*信息系统审计师应当审查项目管理活动的充分性：
1、项目指导委员会的监督级别；
2、项目中采用风险管理的方法；
3、项目问题管理；
4、项目成本管理；
5、项目计划管理的流程；
6、向管理层汇报的流程；
7、变更控制的流程；
8、利益相关者参与管理；
9、签字与审批流程
*项目管理各阶段需要的文档类型：
1、每个阶段要完成的目标定义文件；
2、每个阶段要交付的成果以及关键项目成员所需负责的任务；
3、着重指出关键成果交付期的项目进度表；
4、各阶段需要的资源及其成本预测分析。
*审计可行性研究工作包括：
合理性、成本收益真实性、系统需求的必要程度、是否能够现有系统解决问题，如不能，则
评估替代方案合理性、判断所选方案可行性
*信息系统审计师要确认系统变更程序中的：
1、变更需求应有授权、优先排序及跟踪机制；
2、日常工作手册中，明确指出紧急变更程序；
3、变更控制程序应同时为用户及项目开发组认可；
4、变更控制日志确认所记录的变更都完成；
5、对源代码和可执行代码模块的安全访问充分；
6、紧急程序变更流程合理；
7、紧急情况登陆 ID安全访问控制充分；
8、查阅变更控制日志；
9、确认变更需求被记录在适当的变更开发文件中，如：程序或操作系统文件；
10、确认是否有变更记录；
11、现存文件均以反映变更后的系统环境；
12、系统变更测试程序的适当性；
13、测试计划与测试结果等证据是依据组织相关标准制定的；
14、保证源代码与可执行代码完整性程序；
15、评审可执行模块，证实只有唯一与源代码对应的最新版本。
*出于安全缘故，永久性的消费者数据不应当存储在直接暴露于 Internet的 WEB服务器上。
*电子商务最重要的风险是：机密性、完整性、可用性、身份鉴别和不可否认性、选择权转
移到消费者手中
*采用电子数据交换 EDI的好处：
1、较少的书面工作；
2、较少的信息交换错误；
3、改善了数据库到数据库、公司到公司的信息流；
4、没有多余的数据重新键入；
5、较少的通讯延迟；
6、改善了计价和支付处理。
*EDI独有的风险中，最重要就是来自交易授权的风险。
*EDI的安全风险：
1、对电子交易的未授权访问；
2、在应用控制建立之前或之后对交易的删除和修改；
3、EDI传输的遗失或重复；
4、在第三方处理的过程中 EDI交易机密性的丧失和不适当的发送。
*EDI目的为了在组织不同的计算机系统之间以标准的、计算机可处理的格式传输业务交易数
据。
*EDI数据通过 EDI中心进行交换。
*EDI替代传统的纸质文件交换，所以适当的审核与编辑控制就有必要内建到交易双方的应用
程序系统中去，以允许这种 EDI数据交换的发生。
*一个 EDI系统需要通讯软件、转换软件和访问标准。EDI处理系统的组成部分包括 EDI系统
软件和业务应用系统。
*EDI的应用程序接口的回执功能可以作为 EDI交易的一个审计踪迹
*EDI的处理的最佳方法取决于被处理的交易的大小及数量的多少
*EDI过程需要具备检测及处理不符合标准格式的事务的能力，并防止与非授权团队之间发送
与接受 EDI信息。处理检测错误的措施有：要求重发或人工更改数据。
*EDI交易必须成功的从起点计算机应用程序发送到目的地组织，提供这些保证的方法有：内
部的批总计校验、运行到运行平衡、传输记录记数平衡、应用改善交易回执功能
*确保所有 EDI进站交易都被完全、正确的接收（通讯阶段）、转换（转换阶段）和准确地传
送到应用程序（应用程序接口段）中，所有进站 EDI交易都仅仅被处理一次。
*确保只有恰当授权的出站交易才能被处理，控制目的：
1、出站交易是基于授权而被启动；
2、出站交易包含了唯一的预先授权的交易类型；
3、出站交易只能被发送到合法的商业伙伴那里。
*EDI的审计，信息系统审计师必须评价：
1、Internet加密处理，保证交易的可靠性、完整性、机密性和交易无否定性；
2、更新应用前进行编辑检查，鉴别错误的、不寻常的或无效的交易；
3、执行附加的计算机化检查，评价交易的合理性和有效性
4、确保每个进站交易都被日志文件记录下来；
5、对接收交易使用控制总计校验交易数量和交易金额，在每个应用和贸易伙伴之间总计核
对；
6、发送者将分段总计内建到交易中以设置追踪器；
7、发送者将交易集合的计算总计内建到功能组的报头文件中；
8、发送者将批控制总计内建到功能组的报头文件中；
9、通过检查对照商业伙伴的详细信息判断发送人的有效性
*网关执行电子邮件格式转换
*电子邮件安全——加密
*大文件——对称加密
*不可否认——非对称
*哈希——完整性
*电子银行主要风险：战略、经营和声誉上的风险
*电子银行风险管理责任：
1、风险管理是董事会和高级管理层的责任
2、实施技术是信息技术高级管理层的责任
3、测量和监控风险是经营管理层的责任
*管理层需要在实施一个新的电子银行应用程序之前要进行适当的战略评估、风险分析和安
全审核，以降低实施电子银行的风险。
*在所有的支付系统中，涉及到两个当事人，即发行者和使用者。
*电子现金系统的目标是模拟真实的现金，发行者通过创建数字证书来实现这个过程。
*支付系统模式：
电子现金模式：支付者不必在线，无条件不可追溯性
电子支票模式：支付者不必在线，涉及个人隐私
电子转帐模式：收款人不必在线
*由于在电子资金转帐（EFT）中有大笔的货币进行交换，这些系统一般都被定义为高风险级
别，因此，EFT环境中的安全就变得特别重要。
*ATM逻辑安全：本地高强度算法加密
*图象处理中，应该有适当的程序来保证在良好的图象被获取之前，不能损坏原始文件，因
此需要对扫描人员进行充分的培训，访问控制也需要关注。
*业务流程自动化导致原有流程中控制点和控制措施消失。
*当需要访问其他系统获得数据时，应当基于“知必所需”（need-to-know）原则
*商业智能（BI）通过对信息的收集与分发来协助决策支持与评估组织绩效。
*一个合理建造的数据仓库应当支持下列三种基本的查询格式：
1、向上溯源和向下溯源——向上溯源是对数据进行总计；向下溯源是将数据进行细化；
2、交叉溯源——通过通用属性访问数据仓库中内容有交叉的信息
3、历史分析——数据仓库应当储存具有时间变量的数据，支持数据历史分析
*BI系统中数据的可信可靠需要重点关注
*在所有 BI治理中另一个较重要的是对数据的治理，包括建立标准数据定义，业务规则和测
量尺度，确定被认可的数据资源，为数据核对和平衡建立标准；
*决策支持系统 DSS 设计的基本原则是注重效果（正确的完成任务）而不是效率（快速完成，
节约成本）
*原型法是最流行的 DSS设计和开发方法
*对 DSS 的实际检验主要是看它是否改善了管理者的决策，没有直接降低成本的效果，没有
明确的开发日期
*运行 CRM考虑的是客户服务经验最大化使用；分析 CRM增加客户产品持有
*CRM系统：最终用户可能对公司发起法律诉讼，个人用户信息的隐私泄露问题
*SCM要求所有处于供应链中的企业都能以实时的模式协同工作，最大程度降低库存
*专家系统与人工智能(AI)：信息准确、访问控制、及时更新
第四章信息系统运行、维护和支持
*要使 IT真正为业务创造价值，就需要对组织所建立的信息技术基础设施有充分的了解，并
对 IT 所能提供的服务进行管理，提高信息系统的运行效率，才能使信息系统充分地支持组
织的业务目标
*服务水平预期是组织业务目标的实现
*IT服务包括：信息系统运行、IT服务和信息系统管理，以及负责支持的群体
*信息系统管理层对信息系统部门的全面运行负全部责任。涉及分配资源（计划和组织），符
合标准和程序（提供和支持）。和监控信息系统运行流程（监控和评估）。
*IT部门管理层对信息系统的运行负责
*信息系统运行管理功能包括：
1、资源分配——信息系统管理层负责为计划内的信息系统活动提供必要的资源；
2、标准和程序——信息系统管理层负责为所有运行建立必要的符合总体业务战略及政策的
标准和程序；
3、过程监控——信息系统管理人员要负责监控和测量信息系统运行过程的效率与效果，以
保证过程的持续完善。
*排班表，保证信息系统支持运维。变更也需要变更管理。
*IT服务管理目标：满足企业业务对 IT的要求。
*IT服务管理（ITMS）用于有效交付和支持各种 IT功能的流程和程序，目标是不断提高服务
质量，降低服务成本，满足企业不断变化的需求，实现对服务性能的持续监控和改善。
*IT 服务管理（ITMS）的重点是业务交付品并对支持和提供 IT 服务的 IT 应用的基础架构进
行管理。
*IT支持服务包括服务平台、事件管理、问题管理、配置管理、变更管理和版本管理
*IT交付服务包括水平管理、IT财务管理、能力管理、IT服务持续性管理和可用性管理
*服务水平协议（SLA）也被称为内部记帐系统
*SLA不存在最好的、先进、便宜，双方协商后确定的，满足双方需求的就可以。需要文档化
和管理 SLA文本。
*SLA可以作为未来度量和改善 IT服务的标准，保持和改善客户满意度。
*任何要求的变更，都必须经过问题变更管理。在变更被接受并得到批准前，要审核其成本
效益和可行性研究。如果涉及到配置选项，就会要调用配置管理流程。
*信息系统部门的成功体现为对最终用户处理和在服务水平协议规定的目标。在实施这些服
务时，应该考虑的特性包括准确性、完备性、及时性以及将输出结果适当的分发给相关的应
用处理部门
*监控信息系统人员所提供服务的效率和效果的工具：
1、例外报告：识别所有没有成功完成的或出了故障的应用
2、作业重运行报告：大多数异常终止作业都会导致重起
3、操作员问题报告：记录计算机运行问题及解决方式的手工报告（判断是否需要对操作员
进行额外培训）
4、输出分发报告：记录所有应用生成的报告及它们分发的地点
5、控制台日志：记录了计算机执行的大多数行为。由于报告的长度和复杂性，很难监控计
算机活动。通常信息系统管理层利用其它特定功能的日志。
6、操作员工作日程表：由信息系统管理层手工维护以辅助人力资源计划。日程安排应足够
灵活以允许适当的交叉培训或应付紧急人员需求。
*有许多程序可用来分析系统日志以报告特定的预制项目，信息系统审计师能够执行测试以
确保：
1、只有经批准的程序访问了敏感数据；
2、工具软件或服务助理能够修改数据文件和程序库的程序，仅被用于授权的用途；
3、经批准的程序仅在预定的时间内运行，非授权的运行不会发生；
4、为生产目的而使用正确的数据文件；
5、报告为“口令保护”的数据文件确实受到保护。
*计算机操作员负责计算机作业的准确和有效的执行
*信息系统控制环境的必要组成由：详细说明运行任务的指南和程序，以及适当的管理部门
的监督程序
*部分自动控制==半自动
*自动控制中以不依赖人的自动控制最好
*自动无人值守运行（LIGHTS-OUT）优势：
1、信息系统运行成本的遏制/减少；
2、持续运行（24/7）；
3、减少系统错误和中断次数。
*I/O控制人员负责保证：
1、批处理信息得到准确和完整的处理
2、与信息系统管理部门的意图和授权一致
3、输出文件正确，并被送给适当的人员；
4、作为下一个系统的输入的输出要及时、准确、完整
5、处理中使用了正确的文件
6、操作员操作正确
7、没有证据表明数据已被非授权修改
*作业记帐：监控和记录信息系统资源的使用，这些信息可被信息系统审计师用来执行：
1、将资源使用和相关用户挂钩以便实行计费；
2、通过改变系统软件的默认设置来最优化硬件性能
*作业调度：是信息系统部门的主要功能。调度表包括必须执行的作业、作业执行的顺序和
引起程序运行的条件，包括对低优先级作业的安排。调度表提供了一种将用户要求保持在一
个便于管理的级别上的手段，同时允许非预期的或临时请求的作业得到处理而不产生不必要
的延迟
*作业调度软件的优点：
1、作业信息仅需建立一次，减少错误发生概率；
2、可定义作业间的依赖关系，当某一项作业失败时，依赖于该作业的后续作业就不会被执
行；
3、所有成功或失败的作业均被记录；
4、对操作员的依赖程度降低；
5、能对生产数据的访问提供安全
*计算机资源包括硬件、软件、远程通讯和数据，对这些资源的控制也称为一般控制。
*事件管理时 IT 服务管理的关键流程之一。为了更好的定期服务客户，IT 需要持续的关注。
通过减少或消除 IT 服务的不利影响和干扰，事件管理保持服务的连续性，并且事件管理覆
盖了几乎所有的非标准的 IT服务
*任何不符合 SLA要求的称为事件==服务请求
*如事件未解决也没有升级，是最大的风险
*事件处理：负责解决事故并跟踪、监督、控制和协调解决过程
*任何事件处理流程都很关键的一点是：在确定事件的影响和紧急程度之后对各事件排定优
先级。
*信息系统管理层应该制定一些参数指标为这些事件分配优先级，同时也要考虑问题的紧急
程度和影响大小。
*事件处理在排定优先级后就要考虑人力、资源以及时间问题
*未解决事件的升级标准是信息系统管理层设置的
*事件管理是被动的，目的是快速反应和尽快解决问题
*事件管理不负责查找事件产生的原因，强调速度，目的是让受影响的业务流程尽快回到“正
常状态”减少对业务的影响。
*问题管理的目的是通过对重大事故进行调查和深入的分析后解决问题，或者通过调查和深
入分析类似问题后找出事故的根本原因。（用头脑风暴开发因果图/石川图）
*事件管理——问题管理——变更管理
*任何人都可以新开增日志，但是日志的修改和删除不能由被日志监控者执行，只能由其主
管或其他授权人操作
*问题管理和事故管理在目标和方法上不同
*问题管理的目的：降低事故发生的次数/严重性
*事故管理的目的：让受影响的业务流程能尽快回到正常，减小对业务的影响
*有效的问题管理可以使信息系统部门的服务质量产生重大的改进
*应该记录的日志错误有：
1、程序错误
2、系统错误
3、操作员错误
4、远程通讯错误
5、硬件错误
*追加错误日志应限制为授权人员
*职责分离要求：结束错误日志的人员不同于开始记载错误条目的人员
*不论什么理由，一个重要问题长期不能得到解决是不可接受的；对未解决问题缺乏关注的
风险是可能导致业务处理中断
*问题上报程序应明文规定，应将问题通告给适当的系统、编程、操作和用户人员，以保证
最及时的解决问题
*审计师通过检查尚未分配解决的重要问题的汇总报告，并通过跟踪例外情况来掌握问题是
否被通告给最适合解决该问题的人员
*发生事件首先报告——接报——记录——分级——分配资源——解决问题——问题监控
——超时升级——关闭
*帮助平台/服务台功能顺序：
1、记录问题，启动问题解决流程；
2、区分问题优先级，并移交给适当管理者
3、跟踪未解决的问题，启动问题升级程序；
5、关闭已解决问题，也表示用户授予了关闭问题的权限
*变更控制程序是内容更广的变更管理的组成部分
*信息系统审计师建立变更控制程序以控制应用（由作业或程序组成）从用于开发和维护的
测试环境，转移到进行全面测试的中试环境，并最终转移至生产环境。
*变更控制程序中关于作业和程序经过用户验收测试后，从中试环境移至生产环境的过程中，
信息系统运行人员应当执行的动作的描述部分通常称为正式的作业周转程序
*通过规范化变更过程，并对变更请求、变更授权、变更测试、变更实施过程及与用户的沟
通等过程都建立相应的文档
*程序库管理系统可增强数据中心软件库管理的效率，包括应用软件代码、系统软件代码、
作业控制语句和处理参数等的管理。
*程序库管理系统的能力：
1、完整性——每个源程序均有版本号，通过口令、加密、数据压缩及自动备份等手段，以
保证程序库、作业控制语句和参数文件的安全。
2、变更——对库内容的追加、修改、删除、重新排序和编辑进行管理
3、报告——为管理层和审计检查提供关于库内容、类别、追加和修改的列表
4、接口——提供与操作系统、作业调度系统和联机程序管理系统的接口
*不论何种环境下，都需要程序库控制软件来隔离测试和日常作业程序库，保证变更必须经
过授权才可以到日常作业程序库
*采用程序库管理软件实现：只要有源代码模块移入日常作业，就自动创建一个可执行代码
的模块
*保证可执行源代码的完整性是控制日常作业系统的关键，因为它提供了一种保证，使得错
误版本的程序不会被执行。源代码模块的时间戳不能晚于对应的可执行模块。
*信息系统审计师首先应该获得并保存所测源代码的副本，将该副本作为控制版本。之后，
信息系统审计师通过运行源代码比较软件，来追踪控制版本的源代码和目前版本的源代码之
间的区别。
*源代码比较软件允许信息系统审计师独立完成对源代码变更的审核，不需他人帮助，故不
会被误导或蒙骗
*删除或变更源代码不应从源代码中被物理删除，要删除的源代码或源代码线可以通过注释
实现逻辑删除。
*软件的发布管理就是把新增或修改后的软件提供给用户使用的过程，“发布”是用来描述一
系列的授权变更过程，由变更管理流程控制。
*软件发布的类型：
1、大型发布——包含重大修改，增加新的功能。一般包含了以前所做的许多小型发布。把
许多变更组合在一起有利于促进综合性的测试和对用户的培训；
2、小型发布——对软件的升级，包含一些小的改进和修补。一般包含了以前所做的许多紧
急发布
3、紧急修补——包含少量的错误修改。通常要求对存在问题的软件进行快速修改，以避免
造成用户系统停机和重要业务中断
*应当对发布管理中的主要角色与职责进行定义，以确保每一个都能理解自己角色特征、授
权级别及此过程涉及的其他人员
*所有的发布都应当有一个唯一的识别号，可用在配置管理中
*质量保证要验证系统变更在进入生产环境前已经在受控方式下得到授权、测试和实现。同
时，借助于库管软件，对程序版本、源目标代码一致性的适当维护进行监督
*介质处理：
不需要再用：物理毁坏，盐酸腐蚀，消磁器
需要重新再用：抹盘
*信息安全管理能保证 IT的持续运行和业务过程及数据的安全性。
*信息安全管理包含各种安全过程来保护信息资产，应当集成在 IT运行过程中
*超级计算机通常只运行少数几个专门的程序，大型机则需同时支持大量的各种类型的应用
*计算机多任务原理：
1、多任务
2、多处理
3、多用户
4、多线程
5、网格计算
*对于桌面安全（唯一）：带口令的屏幕保护，离座立即锁桌面
*所有存储在移动设备的敏感数据一定要加密（高强度算法），与 PC及时同步、备份。
*USB盘以及邮件最大的风险：病毒木马
*可引导的 USB设备可以绕过安全检查并使系统彻底暴露
*硬件维护计划应最大限度地满足供应商要求的规格(评估维护好的唯一标准)。
*硬件维护程序就是将硬件维护的执行过程形成文件
*对硬件维护程序进行审计时，信息系统审计师应该：
1、确定已形成正式的维护计划并得到管理层的批准；
2、标出超出预算的或额外的开销，超额开销意味着没有遵守维护程序或即将到来的硬件变
动，应及时调查并采取后续措施
*硬件监控的典型方法和报告：
1、可用性报告——指出系统工作正常的时间段（宕机时间）
2、硬件错误报告——标识出硬件故障
3、利用率报告——设备利用率，由系统自动形成
4、资产管理报告——连接网络设备的清单（包括：PC、服务器，网络设备）检查非法外接
设备
*能力管理（容量管理）是对计算机资源的计划和监控，其目标是根据总体业务的增长或减
少动态的增减资源，确保可用资源的有效利用。
*能力计划应由用户和信息系统管理部门共同参与完成，并至少每年进行审核和修改
*能力计划应包括被以往经验所证实的预测，并同时考虑现有业务的潜在增长和未来业务的
扩充
*能力管理根据业务需要，动态增减 IT资源
*为了确保数据的机密性，保险公司以及医疗机构数据不能放在 U盘中
*参数决定系统的行为，使一个标准的操作系统适合不同的环境
*VLAN只提供网络分割，不提供网络安全，提高网络管理灵活性
*软件控制参数涉及：
1、数据管理
2、资源管理
3、作业管理
4、优先级设置
*参数选择应适应组织的工作负载和控制环境结构
*判断一个操作系统的控制运行状况的最有效手段是检查其软件控制特征/参数
*在评估操作系统完整性时，信息系统审计师应检查系统控制选项及保存在系统目录中的参
数
*通讯软件的三要素：发送方、传输途径、接收方
*数据通讯系统仅关心两个节点间数据的正确传输，而与传输信息内容无关
*数据管理文件的方式：
1、顺序
2、直接随机存取
*数据库管理系统（DBMS）是帮助应用程序组织、控制和使用数据的系统软件。
*DBMS 提供了一种能建立和维护组织良好的数据的手段，主要功能包括减少数据冗余、缩短
访问时间和建立对敏感数据的基本安全措施（记录、字段和事务级）
*数据字典和目录系统（DD/DS）的好处：
1、增强文档编制
2、提供公共的合法性准则
3、减少程序设计的数据定义需求，使其更容易
4、规范程序设计方法
*三种常用数据库模型：层次、网状和关系
*关系数据库的一个关键特征使利用规范规则实现最少的表数据来满足对数据库的结构化或
非结构化查询
*正态化可以消除数据冗余；反正态化数据查询效率高，但数据冗余多了
*系统工具没有日志，一定要严格限制使用控制
*为了预防或检测对软件版权的侵权，信息系统审计师应该：
1、审核用于防范非授权使用和拷贝的策略和程序文件
2、获取所有软件合同的拷贝
3、审核所有标准的、已用的和许可的应用及系统软件列表（抽样或者全部检查）
4、使用专门的工具审阅已经安装的软件
*预防侵犯软件许可的选择：
1、对软件安装集中控制和自动分发（取消用户安装软件能力）
2、所有 PC采用无盘工作站
3、在 LAN中安装计量软件，采用并发许可
4、定期扫描 PC，确保 PC中没有安装非授权的软件拷贝
*数字权限管理 DRM主要目的在于从源头上防范数字内容盗取
*信息网络的发展源于信息资源的共享需求，资源共享可以使组织改进业务流程并极大提高
生产率
*网络互联线路分为：
专用电路：连接两个地点的对称通信线路，永久建立连接
交换电路：按需建立连接（电路交换和包交换）
*网络标准的优势是：兼容性、帮助组织设计一个集成、有效、可靠、可伸缩和安全的网络。
这样的网络应具备：互操作性、可用性、灵活性以及可维护性
*OSI参考模型每一层不仅能够和它的上下层进行通信，也能够和远程系统的同一层进行通信。
*OSI 参考模型七个层次分别是：应用层、表示层、会话层、传输层、网络层、数据链路层、
物理层
*表示层提供数据的转换和加密功能
*数据链路层检测和纠正错误的技术：
1、前向差错控制：与字符或帧一起发送附加的信息，使接受者确认错误已经发生，并能确
认错误位置甚至纠正错误；
2、后向差错控制：与字符或帧一起发送的附加信息，只能使接受者确认错误已经发生
*前向差错控制方法：
1、奇偶校验——发送器在发送前为每个字符追加一位，是字符中 1或 0的个数的函数
2、块总计校验——对奇偶校验的扩充
3、循环冗余校验——针对可能出现帧错误的情况，而奇偶校验和块总计校验均不能有效的
检测出帧错误
*星型拓扑当进行新的建设时可被用于任何大的扩展
*网状拓扑具有最好的可靠性
*以太网使用 MAC 地址来确定接受方，如果一个网卡被设置成混杂模式，那么它就能读取所
有通过网络的数据（包括 ID和口令）
*网桥的功能是在总线型网络隔离碰撞域（数据链路层，效率低），交换机在以太网络隔离碰
撞域和存储转发数据帧
*令牌介质访问方法被认为是可靠的，因为它拥有活跃监视、信标和可选的设备删除等特征
*WAN特征适用于 OSI参考模型的物理层、数据链路层和网络层
*确定何种网络资源可通过 VPN 来连结取决于系统的应用：决定网络连接的需求包括安全政
策、业务模型、内联服务器访问、应用需求、数据共享和应用服务器访问。
*VPN中的攻击病毒，IDS以及防病毒不能检测到。因为加密的数据不能被检测
*VPN类型：
远程访问 VPN
内部网 VPN
外部网 VPN：各自管理自己的 VPN
*E-Mail最大问题是明文传输，机密性
*生产环境中应禁止 TELNET应该使用 SSH
*无线通讯中 WEP加密不能为企业提供足够安全，应该采用 WPA加密
*无线访问的风险：敏感信息的截取、设备丢失或失窃、设备滥用、设备内含信息的遗失、
设备引起的分心、设备对人体健康的潜在影响、无线用户签证、文件安全、WEP 加密安全性
低、互操作性、无线子网的使用、转换点
*互联网由本地网络、区域网络及高速骨干线路构成
*加密在表示层/会话层负责控制/传输层所有发出去的数据都能够被对端的传输层收到，为
所有收到的数据发回执
*TELNET，，DNS，HTTP对应应用层
*TCP，UDP对应传输层
*IP，ARP，RARP，ICMP协议对应网络层
*跨界数据流指数据在不同国家间的传输，需要对数据的私密性、安全和完整性给予更多关
注
*CRC循环冗余校验在数据链路层进行，可以检测所有单字节和大多数多字节的错误
*可用于监视和修改网络的软件应限制为只有网络管理员才能使用
*反应时间和吞吐量是度量网络性能的关键参数
*反应时间是信息从源端到达目的端之间的延迟，主要由信息传输的距离，尤其是需要经过
的设备所引起
*吞吐量是单位时间内的工作量
*网络管理基本任务：
1、故障管理
2、配置管理
3、计帐资源
4、性能管理
5、安全管理
*网络管理工具：
1、响应时间报告——确定用户从终端输入命令至计算机给出回答所需的时间
2、故障时间报告——记录通讯终端
3、在线监视器——度量并判断通讯过程的准确性和完整性
4、网络监控——实时显示网络节点状态
5、协议分析仪——监视和记录数据包中的网络管理信息来分析网络活动（硬件）
6、简单网络管理协议 SNMP——监视和控制网络中的各种变量、管理配置和采集性能/安全相
关的统计信息
7、咨询台报告——记录信息系统支持人员日常处理运行过程中遇到的问题
*中间件使客户机和服务器之间的网络连接更加简便，并使客户机能访问远端的数据库和主
机文件
*硬件审核包括：
1、审核硬件的能力管理程序和性能评估程序以确定——能否保证对硬件和系统软件的性能
和能力进行连续的审核；信息系统管理层的硬件性能监控计划中使用的标准是否基于历史数
据和分析结果
2、审核硬件获取计划确定——硬件获取计划是否定期的与管理层的硬件计划进行比较；环
境是否足以适应当前安装的硬件以及根据已批准的硬件获取计划将要增加的硬件；是否与信
息系统计划同步；是否考虑了现有设备及新设备的技术退化；规格、安装要求及交货时间说
明的准确性；
3、审核 PC 获取标准以确定——信息系统管理层发布了关于 PC 获取及使用的书面政策性陈
述，并且已传达到用户；PC 获取标准建立，设计了程序和表格实现获取的批准流程；PC 获
取请求经过了成本效益分析；PC均由采购部门集中采购
4、审核变更管理控制以确定——正式的变更流程使有效的；及时通知调度人员关于硬件配
置的变更情况；强制实施变更日程表；变更实施前，信息系统部门内使用的操作员文档已经
进行了适当修订；及时提出变更计划；所有硬件变更情况已经通知系统程序员、应用程序员
和 IS职员；变更有效实施，没有干扰正常应用生产处理
*操作系统审核的方法：
1、会见技术服务和其他人员
2、审核系统软件选择程序
3、审核可行性研究和选择流程
4、审核系统软件程序的成本效益分析
5、审核对变更后系统软件的安装的控制
6、审核系统软件维护活动
7、审核系统软件变更控制
8、特别审核以下系统文档：安装控制语句、参数表、退出定义、活动日志/报告
9、审核和测试系统软件实施确定控制的充分性：变更程序、授权程序、访问安全特征、文
档要求、系统测试文档审计踪迹、对生产软件的访问控制
10、审核授权文档
11、审核系统软件安全
*数据库审核时，信息系统审计师应审核
1、设计——确认存在数据库模型
2、访问——对数据库以及存储过程、触发器的重要访问应进行分析
3、管理——所有用户的安全级别和角色应在数据库中标识
4、接口——为保证数据的完整性和私密性，应验证数据导入导出程序
5、可移植性——尽量使用结构化查询语言（SQL）
*信息系统审计师应审核对局域网的控制，保证设计和选择网络体系结构遵循了适当的标准，
保证获取和运行网络的成本不超过其效益
*分布式网络的安全政策：
1、高度分布的——IS安全由单独的用户管理部门控制
2、分布的——IS安全受用户部门指示，但遵循 IS管理层制定的指南
3、混合的——IS安全受用户部门指示，但 IS管理层全面负责
4、集中的——IS安全受 IS管理层指示，但和用户管理部门保持密切联系
5、高度集中的——IS安全由 IS管理层完全控制
*参观信息处理设施（IPF）通常可使 IS 审计师更好的了解其运行任务、程序控制和控制环
境
*计算机运行控制包括：
1、限制操作员访问能力
2、日程安排
3、使用例外处理程序获得应用业主的书面或电子的批准
4、执行再运行处理
*数据录入控制：
1、输入文档的授权
2、批总计的核对
3、录入人员和录入检查人员的职责分离
2012年 10月 28日
第五章信息资产的保护（信息安全）
*三分技术，七分管理
*安全管理，包括：政策、控制、流程
*管理：安排正确的人做正确的事
*信息是经过整理的，有意义的数据
*保护的内容：用于存储、检索、传输和处理信息资产的过程和流程进行评估，以确定信息
资产是否得到充分保护
*ISO27002告诉信息安全需要做什么
*ISO27001告诉信息安全怎么做，建立信息安全管理体系 ISMS
*因为有风险所以要建立控制
*PDCAPLAN计划、DO执行、CHECK检查、ACTION处理戴明环
*ISO27000等同于国家 GB/T22080标准
*信息安全管理的关键要素：
高层管理的承诺与支持
信息安全政策：组织纲领性的方向性文件，由高层发布
信息安全程序：具体制度、流程，由中层管理层发布
*5W1H 是对选定的项目、工序或操作，都要从原因（何因 why）、对象（何事 what）、
地点（何地 where）、时间（何时 when）、人员（何人 who）、方法（何法 how）等六个
方面提出问题进行思考。
*安全制度分层：
组织策略（文件，有法可依）
程序、流程（文件，有法可依）
操作手册（文件，有法可依）
记录（有据可查）
*制度一定要形成体系，通过 PDCA循环起来
*信息安全组织：明确组织中信息资产的保护责任和完成特定的安全流程的责任、员工的安
全意识、教育
*监督和审计：监督高层的，监控审计的过程。没有审计检查，制度就不可能落实；
*信息资产管理：识别与定义、对组织的相关价值、位置、安全或分类风险、所属资产组、
资产所有者、指定保管人员。首先必须识别与定义信息资产。
*生产数据导入测试环境需要进行托敏操作；
*信息资产分类：数据与文档、书面文件、软件资产、实物资产、人员、服务（计算、通讯、
制冷、照明、动力、空气等）
*首先找到全部资产，然后分类，然后分级。以此为根据定义访问控制，避免欠保护或者过
保护；
*信息资产分级由信息资产所有者定义；
*系统访问控制分为：
逻辑访问控制：网络、系统、数据库、应用
物理访问控制：控制人员进出敏感区域。
*访问控制的原则：
所有的访问都必须申请与授权
知所必需
最小授权：赋予的权限不能超出完成工作所需要的权限
职责分离
安全管理员实施安全控制
阶段性进行检查
*访问控制类型
强制性访问控制：强制实施组织中有关信息共享的安全政策或安全规则的机制。
自主性访问控制：由数据的所有者决定谁可以访问数据。
*信息安全管理的关键成功因素：
高级管理层的支持
方针制定
程序制定
意识培养
组织架构
人员教育
*为阻止非授权的拷贝，打印文档应该限制在现场使用；
*人员离职，系统账户应停用；
*应急处理响应步骤：
计划与准备——检测——启动——评价——限制——根除——响应——恢复——关闭处理
流程——事件后续检查——事件总结
*针对社会工程的攻击的方法：不断进行信息安全意识教育与培训
*网络钓鱼、DNS中毒，是社会工程学攻击的一种方法
*审计师需要审核 IT系统架构的各个安全层面，他们包括：网络层、操作系统层、数据库层
和应用系统层。
*访问控制过程（3A）：身份识别，发放 ID，提交 ID，识别，授权，记账日志；审计
*信息系统审计师在实施网络安全评估与访问控制审核时，应鉴证组织所有可能的访问路径
都已经被正确的识别出来，并采取了相应有效的控制措施；
*可审计性——记账日志
*操作系统的访问控制基于文件的权限，用户：人；
*数据库的访问控制基于各个层级：字段、表、库，用户是：人、应用；
*身份识别与验证（ID&Password）是多数系统的第一道防线；
*身份识别与验证技术分为三类：
单因素技术：口令
双因素技术：ID卡
生物测定技术：指纹
*一次性口令是双因素的身份验证技术
*生物测定的三个量化指标：
错误拒绝率（FRR）：合法用户被错误的拒绝
错误接受率（FAR）：非授权用户被错误的接受
平均错误率（EER）：当错误拒绝率与错误接受率相等时的比率。平均错误率越低，表示测
量设备越有效。
*Kerberos是单点登录的典型应用，用票据（特定的数据包）进行认证。
1、所有的通讯必须加密；
2、用户只要登录后，再访问其他服务器都不需要再次认证；
3、基于对称密钥加密。
*KDC，AS，TGS
*域信任也用 Kerberos
*用户权限：能访问什么资源，能做什么
*授权原则：决定什么人能访问什么资源
*访问控制：主体、客体、权限通过矩阵表来显示横轴—主体；纵轴—客体。
*访问控制的方式：
分布式：认证机制分布在各个结点上或者本地
集中式：所有的用户在一个点进行认证
*VPN缺点：被加密的流量能够隐藏非授权活动和恶意代码。解决办法：用 VPN集中器（VPN
服务器）终结所有 VPN流量到一个端点（DMZ区），在网络其他部分不接受 VPN流量
*对系统日志的控制措施：
严格限制安全管理员对系统日志的访问；
用数字签名和一次性写入入设备保存日志
认证、加密控制日志的机密性
每日打印与审批日志
阶段性检查日志
*对控制的主体与客体制定命名规则，便于管理以及查找相关资源；
*磁带应垂直存放，避免酸性环境；光盘应该避光存储。
*磁介质有剩磁性，一般格式化不能完全清除
*如果以后不用的话就退磁；如果要重复使用应该需要进行六次以上的全盘覆盖重写
*对硬盘进行物理毁坏（砸）是最彻底的也是最经济的；硫酸毁坏有污染。
*虚拟化管理终端可能在未授权的情况下访问虚拟机的用户信息；
*无线网的安全需求：真实性、防抵赖、可追踪性、网络可用性
*WPAN主要风险，容易受到中间人攻击
*网络攻击分为：主动攻击、被动攻击
*内部网络不允许直接拨号接入外部网
*虚拟化可以有效的控制数据信息的流动
*DDOS对虚拟化系统影响很大，管理终端将会是单点风险
*所有在有线网络中的风险，在无线网络中都存在
*防火墙种类
包过滤防火墙：缺乏审计的报警功能，IP地址欺骗/源路由定义/碎片攻击
状态检测防火墙：针对 TCP链路状态，配置非常复杂
应用层防火墙：完全隔离内外网，安全性能高，应用层安全性能差，支持服务少代理服务器
*防火墙类型
屏蔽主机防火墙：通过包过滤路由器到堡垒主机之后才是内网
双穴主机防火墙：双网卡堡垒主机
屏蔽子网防火墙/非军事区（DMZ）：安全性最高
*防火墙最大的风险是配置错误。
*IDS的分类（特征分析—准确率较高，统计分析，神经网络；以进程驻留后台方式运行）
基于网络入侵检测：安装在需要保护的网段中，监视网段中传输的各种数据包
基于主机的入侵检测：安装在被保护的主机上，检测网络实时连接以及系统审计日志；
*IDS的网卡设置成混杂模式，监听所有网络通讯
*IDS类型：
特征分析：对新入侵方法没办法
统计分析：较高的检出率
神经网络：自学习，入侵特征辨识高，误报率高
*IPS入侵防护——预防性控制
*IDS入侵防护——检查性控制
*IPS串行在网络中；IDS并行在网络中。
*IDS组件：传感器、控制台、分析模块、用户界面
*蜜罐：提前发现；分散攻击者注意
1、调查入侵者来源，调查入侵手段和方法；
2、考察用于防护的安全措施是否有效。
*把许多蜜罐串在一起叫蜜网
*加密实现：机密性、完整性、身份认证、不可抵赖
*加密无法解决可用性
*加密动作不一定为保密
*加密：密钥（最重要）、算法（可公开）
*加密系统的强度，取决于密钥的保密性强弱；
*好的密码算法必须能够经受选择明文破译
*密钥越长，安全性越好，密钥空间越大；
*加密破解：
唯密文破译（最常用）
以知明文破译（需要知道密文）
选择明文
*对称密钥算法比非对称密钥算法快 10倍到 100倍
*对称密钥：DES\3DES\SSF33\AES......
*DES算法 56比特密钥不安全，AES比较安全
*两两对发密钥 N*(N-1)/2
*非对称算法：公钥、私钥
*非对称算法：RSA大素数分解\ECC椭圆曲线\Diffie-Hellman
*ECC的特点：更强的加密能力、更小的计算能力，缩短长度
*加密技术应用（数字信封）
用对称加密算法进行大批量的数据加密
每次产生一个新的随机密钥
使用非对称加密算法传递随机产生的密钥
*常用哈希函数：
MD5：128位目前已经不安全，2004年已经被破解（中国山东大学）
SHA-1：160位安全
*数字签名：容易遭受中间人攻击
*单向哈希值
*哈希函数：输入一个长度不固定的字符串，返回一串定长度的字符串，即哈希值。单向哈
希函数用于产生信息摘要。如果输入的字符串发生任意改变，哈希值就一定会改变。信息摘
要可被视为一份长文件的数字指纹；
*数字签名的目的：数据的完整性、身份鉴别、不可抵赖性
*公钥基础设备 PKI，通过第三方信任机构认证中心
*数字证书格式
*CPS认证业务声明：游戏规则
*认证中心（CA）系统包括：安全服务器、注册机构 RA、CA服务器、LDAP目录服务器和数据
库服务器；
*注册机构 RA：证书注册管理与维护
*CA要对证书进行签名，发放和管理数字证书的权威机构；
*加密技术在 OSI 协议中，除了物理层，其他所有层均可实现加密，其中在应用层，加密最
容易实现；在网络层和传输层的加密对于大多数应用是透明的，加密成本相对较高，但影响
到所有应用系统间的通讯；在数据链路层的加密主要用于保护信息在局域网上的传输。
*IPSec特点（网络层）
机密性
完整性
真实性
抗重性
*IPSec有隧道模式（整个 IP数据包被加密，性能相对低，安全性高）和传输模式（在 IP包
头后面的加密包，性能相对高，安全性差）
*IPSec的 AH数据包头实现完整性、真实性但不加密，替换 IP数据包头；
IPSec的 ESP数据包头实现完整性、真实性并且加密，整个 IP数据包被 ESP加密；
*SSH安全通道协议：保护 Telnet和 FTP服务；
*SSL保证信息的真实性、完整性和保密性，提供交易的不可否认性：HTTPS
*应用系统对加密体系的使用（无法保证可用性）：
1、甲准备好明文；
2、对明文哈希，得到信息摘要；
3、甲用自己私钥对信息摘要加密得到甲的数字签名，并将其附在数字信息上；
4、甲随机产生一个机密密钥（对称密钥），并用此密钥对要发送的信息加密，形成密文；
5、甲用乙的公钥对机密密钥加密，将加密后的机密密钥以及密文发送给乙；
6、乙用自己的私钥对机密密钥解密；
7、乙用机密密钥对密文解密，得到明文及数字签名；
8、乙用甲的公钥对甲的数字签名解密，得到信息摘要；
9、乙对明文进行哈希，得到新的信息摘要；
10、乙用新的信息摘要与解密的信息摘要对比，如果一致，则收到的信息是安全的，没有被
修改过。
2012年 10月 29日
*审计师永远只是站在边上看、观察，不能插手企业事务；
*病毒必须依附于另外一个程序，蠕虫不需要寄生；木马是特洛伊
*防病毒软件是检查性控制
*被动攻击：窃听、流量、网络分析
*防毒墙针对 SMTPHTTPFTP端口
*30多威胁战争拨号、驾驶、漫步、粉迹
*坏事发生前是预防控制：移动设备进公司前扫描
*坏事发生时能控制检查：日志
*坏事发生后控制纠正：备份
*needtodo----needtoknow
*所有部门的主管，是本部门的数据的所有者；
*审计就是证明控制存在或者是证明控制不存在；
*防病毒软件即使特征库已经更新或者管理员申明及时更新，但仍然要与厂家的最新特征库
进行对比；
*VoIP 应对带宽能力进行基线管理，以确定数据流量的目前水平，并在必要的时候调整，或
定义服务质量（QOS）；
*某些国家禁止使用 VoIP：海湾国家、朝鲜等
*VoIP需要保护两种资产：数据和语音；SBC类似防火墙，基于 VoIP协议，可过滤
*PBX是一种复杂的基于计算机的电话交换设备，甚至连厂家都不能完全了解其风险；
*PBX 的风险：窃取服务（费用欺诈），信息泄露，数据修改，非授权使用，拒绝服务，流量
分析（被动攻击）
*PBX风险的防范：关闭远程访问功能，只在必须使用的时候临时开启
*审计的书面策略、流程与标准必须经高级管理层批准
*离职员工应立即撤消其所有权限，最好是冻结而不是删除（以备后续审计使用）
*利用恰当的审计技术，对访问路径的各种控制进行测试。首先必须将各种路径识别出来。
*要审计一个网络系统，首先应该查阅网络 TOP图；
*审计逻辑访问：
熟悉信息系统环境：查阅网络 TOP图；
记录访问路径：设备或 PC，网络通信软件，事务处理软件，应用软件，数据库管理系统，访
问控制软件
与系统人员会谈
审核访问控制软件的相关报告
审核应用系统操作手册
*系统口令文件应是加密为无意义内容，不可以是明文；
*特权用户的账户不能被锁死，可以采取改名（不可被猜出含义），并将日志导入另外一台特
权用户没有权限的日志服务器进行保存；
*服务器管理员账号是不能设置锁死的，否则一旦被暴力攻击，该服务器就无法维护了；
*日志问题：操作系统、数据库系统、网络系统、应用系统
*日志注意事项：
1、永远开启日志；
2、对于日志的保护；
3、日志修改绝对不能让被监控人员有权限查看、修改、删除；
4、日志中所记录的问题，一定要被分配给有能力解决问题的人去解决，并要跟踪是否已经
解决，如果不能解决的话，是否有问题升级程序。
*犯罪调查技术：
对于正在发生的事件：用户需要立即报告应急小组；应急小组应记录事件、分级事件、控制
现场
已发生没有正在进行的事件：保存证据（内存信息转储到文件、位流映像）
*破坏证据的操作：重新启动
*计算机司法取证四步骤：识别、保全、分析、呈现
*证据转移：保存完整的证据链收集——转移——保存
*审计师不是犯罪调查的主体，也不是最终负责人；
*拥有相应技能的信息系统审计师应在信息安全官的带领下实施调查；
*第三方 VPN账号，只能开临时一次性账号；并且，长久不用账号应关闭；
*渗透测试的类型：外部测试、内部测试、盲测、双盲测、针对性测试；效果最好的渗透测
试是双盲测
*网络渗透测试中，双盲测测试最真实，但要考虑管理层对渗透测试的接受程度；
*渗透测试必须有被测试方书面的经高级管理层授权的证书。
*渗透测试不能保证发现所有的系统弱点。
*在组织网络中，拨号访问是最大隐患，回拨机制，有可能发生呼叫转移，采用带加密验证
机制的 MODEM，最好的办法是禁止拨号访问。
*软件源代码比较工具是一种检测软件非授权变更的有效工具，但不能检测出临时将软件改
回原来版本的情况，因此需要对软件加上时间戳，来保证对软件的任何变更都会有时间戳印
记。
*环境风险的控制是需要高可用性来保证；
*电力完全中断需要采用两路市电来控制，且要采用来自两个不同方向的配电站；
*电压不稳需要采用浪涌保护器；
*机房设备散热靠通风，而不是空调；
*UPS短时间供电，电池组有辐射，还需要有氢探测器；
*发电机属于补偿性控制，而且柴油属于易燃物品，存在风险；柴油存储时间有局限。
*机房选址注意事项：
1、远离一切危险源：化工、车站、军事机构等
2、不能在岛屿上，地下或者顶层，最好处于建筑物的中间位置；
3、应该在河流上游；
4、外表面以及内部各处（接待处、电梯等）均不应有明显标识，机房不应该有明窗；
5、应该考虑建筑的承重；
6、机房高架地板应该防静电，耐火，足够的承重，四周墙体应该是实体墙也应该耐火；
*温度计应该设置在通风口附近；
*水只有在其他灭火措施都实效的情况下才考虑使用；
*七氟丙烷（FM-200）以及 Argonite（氩气）为无污染灭火剂；
*卤代烷（哈龙）破坏臭氧层有污染；
*灭火设施只能信赖防火部门的检测结果，但应该检查检测报告；审计过程中是不可能进行
测试的！
*自动释放的灭火系统只能用于无任值守的区域，并且门应该常闭；
*机房外部紧急断电开关应该有保护措施；
*紧急疏散计划应该有书面文件以及测试；
*机房静电地板的作用是防止线路被压坏，而不是防止静电；
*移动存储设备中的文件应该强加密——使用算法进行加密（RAR的加密压缩不算）
