The CISA Prep Guide Mastering the Certified Information Systems Auditor Exam phần 7 docx

16. What is the primary advantage of a hot site over a cold site for recovery planning? A. There is less work to do at the time of disaster because the site management will prepare it for you. B. Communications have already been tested, thus providing for a higher probability of success. C. Testing has occurred at this location in the past, so recovery teams are more familiar with the facilities and how to go about affecting a recovery. D. Downtime is minimized because equipment does not have to be configured and installed. 17. When reviewing the plans for business operation recovery, an IS auditor would be most concerned to find which of the following unaddressed by the plan? A. That there is adequate space for accommodating the business staff in an alternate site B. That computer workstations are available with the latest technol- ogy on them with which to perform the business processes C. That a desktop appropriate for the processing of the recovered business can be made available D. That connectivity to the EOC is provided for the business desk- tops for communication 18. When observing the testing of recovery in a dual-site, operational, recovery plan configurations, what should an IS auditor expect to see? A. Business continues as it normally would with no downtime or disruption B. Additional equipment being quickly turned on and added to the configuration at the surviving site to accommodate full process- ing with minimal disruption C. Two identical sets of processing equipment set up for hot fail over from one site to the other with no impact on the users D. A procedure that sheds some testing, reporting, and lesser essen- tial functions, allowing for the concentration of the surviving site on the critical business processing to be performed 342 Chapter 5 19. When reviewing the recovery testing reports to management, an IS auditor will be most concerned if the following is not part of the report: A. An assessment of the time it takes to recover compared to the management expectations for recovery and a gap analysis of the potential impact that any shortfall may have on management’s risk or loss expectations B. A comprehensive list of all of the problems and the resultant assigned action items C. A description of the process used to test the recovery, depicting the assumptions made about the recovery situation that was being tested D. A list of planned goals or milestones with an analysis of the ones that were achieved and those that were not successfully tested Disaster Recovery and Business Continuity 343 345 This chapter and the associated CISA exam content area cover the evalua- tion and assessment of building and maintaining those applications that businesses use to perform their work. Knowledge of this subject matter creates 16 percent of the exam content. We have covered many of these items previously in a slightly different context, but the concepts are worth revisiting here—not only because they are equally applicable but because they are universal concepts that need to be mastered by the information sys- tems (IS) auditor, and the review and repetition will begin to solidify your required understanding of these principles for continuous use as part of your auditing toolkit. Under the hood, the more seasoned and experienced IS auditors normally perform detailed business application auditing. This situation occurs because you must first understand the general concepts that we covered in previous content areas in order to apply those same principles to the development disciplines required in application develop- ment. The new concepts that are unique to these user interface systems will have these principles applied to them, as well. Developers’ methodologies must also be well known to the IS auditor in order for them to adequately and effectively compare the work they are reviewing to those models. Business Application Systems Development, Acquisition, Implementation, and Maintenance C H A P T E R 6 The processes by which application systems are developed or acquired will follow many familiar workflows and testing techniques that the IS auditor uses. They will ensure that proper diligence was applied to each of these steps so that the resulting application will meet the needs and objec- tives of the business organization while protecting the data and integrity of the business throughout the design and implementation phases. By the end of this chapter, you should be able to: ■■ Understand the applicability of the various development method- ologies and tools, such as prototyping, rapid application development (RAD), systems development life cycle (SDLC), object-oriented design (OOD) techniques, and so on ■■ Review an application development and implementation process for appropriate use of: ■■ Application design and architecture based on the associated risks and controls inherent with each approach ■■ Application change control both during development and in the post-implementation phases ■■ Segregation of duties principles during the development and designed into the systems under development ■■ Input and output controls ■■ Quality assurance and testing techniques and methodologies ■■ Protection of code and data during development and testing ■■ Flowcharting, entity relationship diagramming, and modeling ■■ Built-in controls using file structures, interface design, and reporting ■■ Apply your knowledge of project management principles, tech- niques, and practices to the evaluation of their use in the applica- tion’s build or buy, implementation, and maintenance processes ■■ Assess proper build versus buy decision-making and the related vendor evaluation and contract negotiations ■■ Assess the adequacy of data conversion, the integration of new systems, and ongoing system maintenance processes ■■ Review programming and testing processes at a high level for adequate approach and applied controls I have found that being a programmer is not a requirement for reviewing this kind of work. A project management understanding is a requirement, 346 Chapter 6 however. It also helps to have the ability to think through the logical appli- cation of the process steps like a programmer might. In order to under- stand why deviations to what seems like a better-controlled way of doing things are being employed, the IS auditor must keep an open mind to understanding why the logic behind the chosen and better approach might not be the more controlled one for any one particular development effort. Evaluation Approach When tasked with the evaluation of a development effort, it will be very important to fully understand the scope and objectives for which your assigned review is intended. Is it to understand the efficiency and effec- tiveness of the software development that has already been concluded? Is it to opine on the overall process used by an organization for all develop- ment methods (therefore focusing on the methodologies involved with perhaps some samples cases used to validate the methods as examples)? As with all evaluation engagements, knowing the scope of the review will help set the boundaries and enable you to direct your resources appropri- ately on those tasks that are most likely to result in reaching the right areas of focus and meeting the needs of the business that is engaging you for the review. Generally, the type of review can be classified as either proactive— where you review the processes used before or at the initial stages of the process—or detective, where a review assesses performance after a project is completed. After-the-fact auditing, also referred to as bayoneting the wounded, is often less useful to those who need guidance most but is often used because management is not alerted to project problems until they are significant enough to appear on the radar. An internal audit organization might review the overall development methodology used as one of its reg- ularly scheduled audits to avoid being put in the situation of a Monday morning quarterback and offering solutions that were not apparent at the time of the development process compromise. If the target is one particular applications development effort, the scope should be clearly understood—and limits of any review assessment activi- ties should be documented and agreed to before beginning the fieldwork, if possible. If a standard and approved methodology has been documented for an organization and the review is one of execution against that methodology, then the objectives are a little less ambiguous and more straightforward. Knowing the rules used as the development and quality standards is a first step toward this kind of audit, and a little legwork to determine the de facto standards and how they might differ from the Business Application Systems 347 documented standards will serve you well in avoiding pitfalls along the way. As you review these efforts, you will want to understand the author- ities and decision makers as well as the project management team’s scope of influence across the entire project so that boundaries can be best applied and your recommendations can serve successfully for those involved. Be wary of attempts to use the audit effort to pit one point of view or political faction against another by not committing to judgmental calls or prema- ture conclusions before hearing all sides of the story and the rationale for approach and methodology. One way to evaluate development processes is to be involved with the development process as a team member, keeping an eye on proper process execution along the way and ensuring that proper controls are built into the systems as they are developed. This approach also provides the IS auditor with a firsthand view of the compromises and risks assumed along the way and gives them an opportunity to bring their risk management expertise directly into the decision-making process. IS auditors attend development meetings, take note of progress against milestones, observe the change management and problem-solving processes for proper docu- mentation and control, and assess the documentation quality while it is in progress. There are some concerns and pitfalls with this approach, how- ever. Independence is the primary issue. Where the IS audit function is involved with the decisions and is complicit to compromises made during the development, it is in a difficult position when it comes to criticizing these situations down the road. The function will not be able to audit this system in the future when it represents its own work. This approach can also consume a lot of IS audit resource time with few direct deliverables to show for the time invested. Not everything that occurs in a development process is audit relative or interesting to IS audit, but even when using good judgment and triage, using time efficiently is difficult at best. It does provide excellent opportunities to develop relationships with software developers and can lead to a better controls environment all around within an IS organization. Testing and corrective actions occur in more real time as well, and value-added opportunities might outweigh the independence concerns if resources are available and IS auditing ethics are strictly observed and monitored to some extent. Often, an internal application review related to application development will involve the normal maintenance and ongoing enhancement efforts of an existing production application currently used in the business with the objective of ensuring that its integrity and support are sufficient to keep the application viable and effective in supporting the business needs. Many smaller development and maintenance cycles will be part of this type of 348 Chapter 6 review, and change control and prioritization of fixes will become the pri- mary scope items for inclusion in fieldwork procedures. Objectives will focus more closely on the translation of problems and evolving business needs into product enhancements that keep the business competitive and profitable. Ensuring that data integrity is protected while development and testing are conducted will be a primary control concern. I have divided this chapter into a classic SDLC methodology in order to show how each section relates to audit techniques and fieldwork tasks nec- essary for the review of each associated SDLC step. Each section has sev- eral items that require good practice to be followed and testing that will reveal how well this goal has been accomplished for the development assignment at hand. First, let’s review some of the various ways in which development can occur successfully and how their management affects the reviews that you will need to conduct. Subsequently, you will then be able to apply the relevant subsections to the various development methods as applicable. Systems Development Approaches and Management There was a time when most development efforts followed a life cycle that had documented and predefined reasons for all tasks and efforts that loosely followed the scientific methods taught in grade schools in the 1960s and early 1970s. Requirements were defined and identified; hypotheses were formed and tested; evaluation of experimental results was docu- mented; and decisions were made in order to obtain a desired result. Sys- tems were broken down into structured subcomponents that were further analyzed for their root processes, which were then reassembled into over- all solutions. This method is still the most predictable for achieving results but is often short cycled due to time and money constraints in modern business environments. The scientific approach failed to appropriately involve the end user’s point of view as well, resulting in solutions that were not user friendly. While they were technically effective, they resulted in over-engineered or needlessly complex solutions. The e-commerce era swung development approach styles to the other extreme, promoting rapid design with little documentation and often buggy code that could not scale. The tendency of users and abusers to try things with the code that it was not designed for resulted in unexpected and often erroneous results. The ubiquitous buffer overflow security vul- nerabilities that are prevalent throughout modern PC coding efforts is the obvious example. Getting it to the market, finding out what the problems are, and selling upgrades that fix these problems for even more money is Business Application Systems 349 an approach popularized by many well-known operating system vendors today. This prototyping and incremental development style can work well if user expectations are managed and evolution is understood and accepted by the sponsoring business along with the associated risks. The system development life cycle (SDLC) approach in the classic sense rep- resents the scientific method—a structured technique that will be the basis of this chapter’s evaluation methodology. This method takes the problem and breaks down the requirements and needs into well-defined and docu- mented criteria that are then used to identify possible solutions. The possi- ble solutions are compared to the standard for achieving a solution to the problem and then to the integration of other problem-solving subsets. The result is an overall solution that meets all of the criteria in a structured and measured fashion. All attributes, activities, and outcomes are predeter- mined and solved as part of the problem analysis. This process tends to be more of a process-oriented development methodology. Rapid application development (RAD), where modeling and prototyping is used to quickly get a version into the hands of the users for feedback and modification, is popular today because a working model of the final solu- tion is more quickly available for evaluation. Problems are solved itera- tively, and the final design evolves as representative user groups evaluate and assess the functionality and performance of interim prototypes and modeled solutions. Scope creep can be problematic as new ideas are sparked by partial and workaround solutions, leading to Rube Goldberg complexity if sanity checks are not a frequent part of the design process. This process tends to be more of a data oriented development methodology. Object-oriented programming designs methodologies strive to develop modular, reusable subsets of code and functionality that can subsequently be reassembled and used as building blocks for other purposes as utility programs with stand-alone functionality and requirements. Another method worth mentioning is CASE, or computer-aided systems engineer- ing. With this method, a set of programs aid in the design based on inputted parameters and requirements definitions. This method is useful when working within a well-defined programming environment where interfaces and database interaction must be consistently managed and enforced. Project Management Project management practices were covered in Chapter 2, “Management, Planning, and Organization of Information Systems” and are critically important to success in any development process. Your evaluation will pri- marily focus on interactions with the project managers and those support 350 Chapter 6 personnel who they provide for you to interact with related to their devel- opment projects. Evaluation of the controls over the development process, their management and motivational styles, and the diligence and impor- tance that they place on good structure and documentation will reflect throughout the development review engagement and ultimately reflect on their ability to successfully develop applications. Your approach will need to be based on an objective approach with scope that everyone agrees with in order to deflect any criticism and to maintain an even-handed result that identifies risks based on principle and in comparison to agreed-upon methodologies. The best way to approach any of these kinds of reviews where personal agendas and careers can be involved is to get everyone to agree on the right way to perform the work before any fieldwork reviews start. Functional Requirements All business application systems designs, whether they are for completely new processes and sets of functionalities that have not been addressed pro- grammatically before or for minor enhancements to an existing operational system, need functional requirements definitions as a starting point. These requirements must come from the business users and management and will define what outcome needs to be the result of the application pro- gramming solution under development. Often, this wish list must be care- fully examined and questioned in order to ensure that the needs are fully understood and to avoid misinterpretation. Your evaluation of a develop- ment effort should find that this process of understanding the require- ments is in place and ensure that business processes and goals drive it. Coordination between the development team and the business representa- tives will need to occur in order to define these requirements in a way that is achievable and that will not result in an overly complex solution that does not really meet true business requirements. Gleaning the true busi- ness needs from a wishlist is a business analyst’s talent, and you should use it as part of the process. Some amount of effort must be evident in intelligently gathering the requirements, and your review of the documentation should show that these user requirements are documented clearly and completely. The user executives who have authority for making decisions need to be identified, and they should be consciously approving the requirements before any feasibility or preliminary design investigation takes place. These executive sponsors will ensure that the business objective can be satisfied by the planned effort, that the relative priority of this request for design has been Business Application Systems 351 [...]... group to another will need to be performed Knowledge of the business use cases, the business processes, and the roles of the different job functions, as well as their processes and the next steps in each of their functions’ support will help the IS auditor determine whether these controls were developed according to the security standards documented by the IS organization and will support the business... of the design phase so the design can be built with these goals and criteria in mind all along Your objective in the review of the completed design will be to ensure that the QA controls exist and were known at the start of the design phase, are then compared to the design, and that any discrepancies were identified and followed up on to the satisfaction of the project lead acting on behalf of the. .. of their tasks Reports of these reviews and the compliance to standards performance of the team should be found as part of the documentation trail that result from the QA efforts Participating and advising in an ongoing fashion with these efforts will lead to higher-quality information systems being produced The plans for performing these steps and what the acceptable passing criteria will be for the. .. with the associated process flow changes that are being proposed Replaced or interfaced systems documentation should be reviewed for completeness and accuracy Because this process involves other departments, their systems, and feeds to or outputs from their systems, they will need to be addressed within the systems development process The other businesses’ input should be sought and documented, and the. .. Application Systems Communication Controls Controlling the communication subsystems refers to applying controls over the transport layer of the network supporting the IS organization’s infrastructure that the development application is connected to This information highway brings input into the application programs and sends the output to the peripheral devices accessed by the users or to other applications... directly to the development project, final checks by the IS auditor at the conclusion of each project phase related to quality assurance goals should be performed The auditor can compare the standards to the work and create a gap analysis to determine the assurance of quality contained in the effort to that point Certainly the functional requirements will also be evaluation criteria and the program... and advise on these portions of the planning You should identify places in the planning process where this situation has occurred and note any concerns made by their review that might impact the project or need a follow up Other aspects of the security design related to the transfer of sensitive data fit into the security architecture; the approach to managing permissions and access and the need for... included in the analysis This preliminary design should meet the criteria described through the agreed-upon user requirements You should evaluate the design documentation that is available at this phase of the development to determine whether the detail contained in it is sufficient to support the estimates and analysis and that the level of detail in the design can support any conclusions drawn from the analysis... activated through the presentation of some level of authentication checks These checks, typically the presentation of a password, will permit the prescribed access to occur and should simultaneously log the fact that access has been approved through the identification and authentication processes The compartmentalization of access to files and functions within the application that are available to the users... in concurrence with the recommendations contained in the report Finally, if internal audit is involved at all in the project, their opinion at this point should be included as part of the reporting on the process used in determining the feasibility phase of the project It might be inappropriate for the audit team to give an opinion on the feasibility because it could jeopardize their independence, . involves other departments, their systems, and feeds to or outputs from their sys- tems, they will need to be addressed within the systems development process. The other businesses’ input should. reaching the right areas of focus and meeting the needs of the business that is engaging you for the review. Generally, the type of review can be classified as either proactive— where you review the. determine the de facto standards and how they might differ from the Business Application Systems 3 47 documented standards will serve you well in avoiding pitfalls along the way. As you review these