The CISA Prep Guide Mastering the Certified Information Systems Auditor Exam phần 4 pot

Whether manual or automatic processes are used, there should be docu- mented procedures for emergency changes. Emergency changes occur even in the most well planned development initiatives. If a change control process does not enable immediate corrective action to occur and this process does not provide for authorization and approvals to catch up to the change later, the business will not be successful in meeting its obligations. For this reason, it is important to segregate the duties of the change control librarian from other tasks because this role then can be charged with insur- ing that the backward notification and post change approvals occur. It is preferred that these emergency changes be automatically trapped and iden- tified. A possible control technique is to notify the owners automatically to ensure that all changes, even those that happen in very busy and stressful situations, will get recorded and reviewed. The discipline of recording and reviewing all of these changes must be evidenced by process procedures and logs that indicate this process is used continuously. Part of the change process should be the review of change preparedness prior to scheduling or proceeding with the change. The person accountable for operations will ideally assess all of the changes to be scheduled and the compatibility or interference of these changes with other scheduled tasks and changes. Changes that have not been adequately tested, documented, or reviewed with the user’s representatives for possible impact to the busi- ness should be deferred until these processes have been completed. A checklist of acceptance criteria and a regularly schedule change control meeting is a good way to ensure that all of the items have been considered and everyone involved knows what the plans are. Possible checkpoints to consider include: ■■ Testing and sponsor acceptance of change ■■ Back out procedures and programs that are available and tested ■■ Resource usage changes and plans to accommodate them, including disk and tape storage, CPU usage, job scheduling, production con- trol process changes, and so on ■■ Operator training and procedural manual documentation updates ■■ User training and user manual documentation updates ■■ Business continuity planning impact and recovery procedures and documentation updates, along with updates to off-site data planned for use in recovery ■■ Security changes and modification to security baselines and plans ■■ Interface changes and notification to other processes that depend on or feed this changing system 162 Chapter 3 ■■ User impact of the changes and possible business process workarounds to accommodate downtimes ■■ Notification and coordination of all necessary resources and support teams to implement the change The process of preparing for changing the production code also should be examined. There are several ways to manage the assurance of integrity to the code in production at all times while providing for changes or mod- ifications to that code at the same time. The preferred method would be to copy the production code into a test domain for modification and to subse- quently move the modified version back into production. Version control and keeping track of movement in and out of the production domains can be complicated by having more than one copy of the production code signed out at a time due to the multiple changes being developed simulta- neously. Integrated testing will need to be performed to ensure that these changes do not impact each other or the underlying code when both are applied. Even when emergency changes are required, care must be taken to provide for production code integrity and back out capabilities. Copies of production before and after changes are applied should be maintained until assurance is received that the change will be left as part of the new production code set. Knowing what version the change was built for may be a required validation step. If the changes occur frequently enough, there may be a question as to whether the fix is applicable to the code presently in production and not built for an earlier version. Another way change control is maintained, and this is especially preva- lent for Web page code, is to maintain a Quality Control (QC) copy of the production code that is always a mirror of what is in production. In this manner, copies and evaluation of the production code set can take place without directly impacting the actual code in use. Additional care must be taken to ensure the synchronization of the production and QC code sets at all times. This additional step provides for an ability to reload the produc- tion code quickly into production, should some type of integrity breech or corruption occur. This is the reason for this technique’s popularity for Internet facing programs, which are vulnerable, based on their placement into a hostile and untrustworthy environment. Finally, you should be interested in reviewing the back up processes for the various versions of code in test, staging, and production, which collec- tively make up the change control system. Changes and back ups should be coordinated so that it is possible to recover systems through a combina- tion of restoring the back up and reapplying the changes that have occurred since the back up occurred. Changes will need to be maintained separately from other code in order to accomplish this type of recovery Technical Infrastructure and Operational Practices 163 scheme, and a process to ensure that only those changes between back ups are staged in this manner will need to be developed. Evaluating System Performance A system’s performance evaluation is a review of how well the processes perform against industry benchmarks or in comparison to similar processes and against the management’s expectations. Performance can mean differ- ent things to different people, so your first step will be to understand what particular aspects of performance are included in your scope and objectives. Usually, this comes down to understanding the Service Level Agreement (SLA) and whether the deadlines and commitments are being met. You also may need to understand the process in a broader sense to ensure that the metrics used for managing the business adequately represent the process- ing’s performance and that the risks are managed appropriately. If this is the objective, you will need to inventory all of the potential control and measurement points available to the IS process management and assess the best combination of performance indicators to gather data from in order to form your opinion. These control points will break down into several broad categories such as people, hardware, software, processes, and deliverables. In all cases, when performance fails, an investigation and follow-up to determine an appropriate corrective action should be evidenced and reviewed as part of your evaluation. Monitoring Techniques, Processes, and Tools For people performance management, you will be assessing staffing, train- ing, and performance in terms of units of output per time unit of effort expended. This will be measured against historical trends and comparable industry benchmarks where available. Several companies make a business of providing IT benchmarking services and consulting practices. In addi- tion, many IT specialty focus groups and newsletters provide benchmark information to newsgroup subscribers. Finding relatively comparable examples may take some effort and extrapolation, however. Processes and tools for monitoring and measuring performance will vary, depending on the tasks and the processes with which the staff members are interacting. Labor-related tasks in computer processing environments break down into support of the processes (tape jockeys, print handlers, operators, sched- ulers, user support, and so forth) and technical support of the systems themselves (programmers, service engineers, field engineers, change con- trol, and so forth). Tapes per shift, pages per hour, and calls per person are 164 Chapter 3 some of the metrics that may be key in developing a monitoring program for the support staff performance management and control. You will need to identify the appropriate units of measurement from your knowledge of what meeting the business needs means in each case you encounter. Proj- ect management techniques are probably the best tool to use for managing and tracking performance of the technical support staff. Development and technical support does not break down into units per hour types of mea- surement in most cases. Hardware performance metrics include system utilization, percent busy, response times, uptime statistics, and mean time between failure, to name a few. When reviewing hardware performance, you will need to keep in mind what, of the available metrics, are not only meaningful from a per- formance perspective, but also from the perspective of what is material to the business processing. Statistics can be interpreted in many ways to sup- port conclusions that widely vary. When in doubt, always apply the audi- tor’s best friend for a sanity check, otherwise known as the question, “So what?” By seeking the root concerns of the issues identified and by ques- tioning the gravity of the results you are reviewing in this way, you will support a balanced approach that seeks only to identify the material risk exposures and to address them, rather than chasing statistics and perfor- mance measurements that do not significantly affect the processes. Software performance can be measured against the functional require- ment expectations for which the software was originally designed. Know- ing the design’s limitations and the actual usage in practice will enable you to perform a gap analysis of the actual versus expected performance mea- surements. Because relatively few actual software implementations are textbook simple, identifying the reasons for implementation variations from the recommended installation will be necessary to get a meaningful comparison. Once again, you will need to see information on the perfor- mance over time and understand any changes that might have an effect on this performance in order to be able to opine on software performance met- rics. The challenge will be to ensure that the software is running with a hardware configuration that is supported for its use so that there is no question as to whether the performance issues are software bound or hard- ware bound. Software/hardware performance tools will be covered in more detail in the systems development chapter. If the software perfor- mance metrics are tabulated and monitored routinely to gauge the opera- tion’s performance, your evaluation should identify the integrity and value of these metrics to ensure that they are control parameters that can effectively be used to manage the operations. Processes are monitored to gauge operational performance most often because they represent the business needs most directly. Completion of Technical Infrastructure and Operational Practices 165 tasks and measurements such as response time and availability are black and white issues that are either meeting the need or not meeting the need. They are usually tied directly to SLAs and reported as KPIs because they are not complex enough to understand and to represent the success or fail- ure to the IS organization most directly. The throughput of transactions is a common measurement. Performance management tools usually are imbedded in either the hardware or software and the report generation of process monitoring is a standard feature required in these and most turnkey processes as well. Your evaluation will most likely depend on the designer’s view of process monitoring variables, and the outcomes of these monitoring tools should be reviewed to ensure the consistent performance of the processes based on the predefined definitions. Where variations from expected outcomes exist in the historical reporting of this informa- tion, you should look for corrective action that was timely and effective in bringing the processes back in line with the organization’s expectations. Performance based on the output of the IT processes is the simplest and most effective method for monitoring and managing an IS organization’s performance. Once the outputs are identified and the quality and quantity of those outputs is agreed upon through the SLA’s, the agreed upon met- rics are either met or not, which is an easy to understand performance indi- cator. Understanding exactly what the output needs to be to satisfy the business needs is a much more difficult problem than it first appears to be, however. Capacity Planning Capacity planning is required to manage an IS organization effectively because it reduces the impact of the growth-related changes on the busi- ness and its users. Your objectives in a review of capacity planning are to ensure that a planning process exists, which enables the workload and ser- vice obligations to be met by providing sufficient capacity in a cost effec- tive manner while limiting the impact to the users. Good control over this process will involve a proactive solicitation of future demands for services and it will translate that into a strategic plan for managing the capacity of the processing facilities. Periodic renegotiation of the SLAs provides an excellent vehicle for validating service requirements and identifying the organization’s changing needs. Budget cycles also will drive the need to understand the next fiscal years requirements and may be a good trigger event for assessing the overall capacity and direction for the operation’s requirements. When evaluating the process of planning for capacity, you will expect to see the identification of the business needs as part of a process that is 166 Chapter 3 performed periodically. These needs can be identified through the direct solicitation of the business owners or users. Obtaining this information also may be accomplished through the evaluation of the delivered services over time to show growth and the need for the expansion or adjustment of the capacities based on historical trending and the extrapolation of these trends into the future. Contracts and agreements also can be used to iden- tify the future needs and capabilities for performance, which will have to be met in order for the IS organization to be successful. The evaluation of performance may be additional input to the decision-making process used to identify future size and capacities of systems. Risk is introduced into the capacity planning processes when change occurs either without notice or too quickly to avoid an undesirable impact to the end users. You will expect to see controls in place that not only mea- sure the existing capacities and track them over time but that also measure control techniques providing for the anticipation of change. Anticipation of changes can be an inexact science and therefore should be revisited regu- larly, adjusting plans as conditions shift. Good control processes will regu- larly challenge those assumptions used to make the capacity planning decisions and will give the best chance for accuracy in the process. A thorough knowledge of the standard sizing options available for equipment and licensing will be required to anticipate when the changes will be needed to keep the operations running smoothly and effectively. Keeping capacity in reserve for unanticipated bursts in demand will be part of the cushion that you will assess when determining the risks being assumed in the capacity planning process. Tight schedules and the little chance for error will require more flexibility in capacity in order to reduce risks and ensure the successful completion of the business requirements. An understanding of the limitations that existing configurations present should be documented and used as a basis for comparison to current usage monitoring so that performance does not suffer and the changes can be appropriately anticipated. Performance should not be affected negatively because of the capacity planning deficiencies. Problem logs and deliver- able cycles may need to be assessed to ensure this is not the case. Finally, the cost effectiveness aspects of the capacity planning evaluation will determine what decisions for expansions and changes are being made in a way that adds the most value to the process with the least cost amount. Spending for capacity, where preplanning may have avoided such costs can be assessed by looking at how far out the planning cycle is occurring and assessing how effective the planning has been in the past by avoiding unnecessary and costly upgrades to the capacities of the various IT com- ponents. The planning process should anticipate the changes in needs effectively and enable for economic decision making that provides low cost Technical Infrastructure and Operational Practices 167 solutions with maximum capacity. Reviewing the alternative scenarios may be counter productive, so care must be taken to ensure that the best information available is used to make these judgment calls. Problem Management The objective of a problem management system review is to ensure that all problems are identified, logged, and resolved. Another objective is to ensure that through this problem management process, corrections are made that prevent problems from reoccurring (that is, that the IS organiza- tion learns from its mistakes). Problem identification can be accomplished in several ways, all of which should be evaluated as potential input to the process. Where a process has a known procedural flow and measurable out- comes, problems can be defined as any deviation from the expected flow and outcome. Ideally, this deviation will be trapped through automated problem management processes that ensure all exceptions are identified as problems without human intervention. Seemingly inconsequential excep- tions do not get logged as problems when people are required to decide whether these exceptions are worthy of being defined as a problem. The effort necessary to log and track these problems outweighs the value of reporting too many busy operators. Users also report problems typically through the help desk or user support facilities. Understanding the real problem can be a challenge when dealing with users who do not have a technical background. Other business processes up and down the process flow continuum may identify problems that do not directly affect the origi- nating process. The result will be a flawed outcome to the overall process and the need being identified as a problem as well. In order to manage problems well, a tracking and logging system will need to be put in place. This system will need to maintain a history of all problems in a database to be useful for analyzing problems. Some of the required attributes about the problems that will need to be captured include times, system, a description of problem, and an audit trail of the escalation and referral will need to be tracked from detection through res- olution. This information should be captured in a standard format and sep- arated into fixed field positions in the database so that reporting and queries can be performed against the aggregated data. Your review should assess the data fields that are recorded in the problem tracking process and evaluate the sufficiency of the information for analytical and investigative purposes. Any canned or customizable reporting capabilities should be assessed for functionality and relevance. The ability to refer problems to areas where they can be appropriately addressed without loosing the pertinent information will be an important 168 Chapter 3 attribute of a good problem management system. Various departments should have access to the problem system, such as operational areas, the help desk, scheduling, and programming so that as the problems are assigned and investigated, each additional piece of information can be added to the problem. The problems then can be effectively reassigned without the loss of information, should root cause analysis point the reso- lution to a different group other than the one originally assigned to the problem. All potential problem solving groups in the IS organization should be required to access the system routinely and resolve the issues assigned to them in a timely manner. System oversight should ensure that the problems not being addressed are escalated to management for follow- up and notification of the business process owners. A good method to ensure that problems are being proactively managed is to pull all of the responsible parties together for a weekly meeting that reviews all out- standing or difficult problems or those particularly impacting the organi- zation as a whole. Often this meeting can coincide with the change control planning meetings held by the operations group, because problem resolu- tion usually results in changes to correct the problem. The tracking and res- olution of the problems will need to be evidenced clearly for the auditor to believe that issues are being addressed effectively. All problem resolution should be recorded in the problem system in a way that allows for under- standing problem-related information by application or by an information processing subsystem. The analysis of the overall problem levels related to individual systems and processes then can be used to identify and justify necessary changes to the production systems though systems development efforts. The overall and elapsed time spent on a problem, as well as the time spent in individual areas, should all be tracked and reported on so that the cost of problems can be identified. By understanding the overall cost of problems, the IS organization positions itself to better manage problem prevention and to understand the costs and benefits of doing it right the first time. You should assess the processes in place to use the problem tracking system as a KPI and determine what kinds of analysis are rou- tinely preformed from the problem data. A proactive IS organization will closely review this information for opportunities to improve the processes it manages. Service Level Agreements (SLAs) Service Level Agreements (SLAs) are the glue that holds the business rela- tionship together with the IT processing. Managing the services provided to the customer is a critical piece of the IS organization business, because it Technical Infrastructure and Operational Practices 169 is the point from which the relationship is managed. Your evaluation of this process will be two fold. First, you will need to look at the process from the customer’s perspective to ensure their requirements are understood by IS operations and are being met. Second, you will need to look at the rela- tionship from the IS organization’s perspective to ensure that the business’ expectations are not exceeding the agreement and that demand changes are being appropriately managed and accounted for through the identifi- cation of all provided services and the associated costs of those services. In large and complex IS organizations, managing customer relationships is a full-time job for many individuals who act as client service managers and customer liaisons to the IS organization subgroups. This is a necessary analyst position that translates the business issues into technical ones. Per- sonnel who hold this position can explain the technical issues to businesses in such a way that they can understand them as well. This person acts as a negotiator and arbiter when disputes or conflict arises. They are ideally positioned to contribute to the development and maintenance of an SLA between these two parties as they straddle the fence between the business and computer operations worlds. Whether the organization is large or small, you should seek a business relationship representative that fills this role when performing an evaluation of the service level management processes. This role will identify all of the business requirements, including deliv- erables, time frames and target dates, support coverage requirements, response and escalation for questions and problems, and any other para- meters that are important to the particular business process and work flow. This list of requirements then will be reconciled with the IS organizations view of the cost of support, reasonableness of the request, and scheduling and labor force requirements to meet the needs and satisfy the customer. Once both parties reach a general agreement, there will be a document, which is signed and subsequently used to measure performance and expectations going forward. Common elements of a service level agree- ment include ■■ Purpose, definitions, and limitations of scope ■■ Services to be provided ■■ Availability, throughput, response, or other deliverables commit- ments and methods of reporting and monitoring ■■ Communication and reporting relationships and methods ■■ Requirements of the client receiving services ■■ Problem identification and escalation processes 170 Chapter 3 ■■ Methods for costing out additional or new services and requesting changes ■■ Basis for charges and methods for assessing penalties and charging for services not covered in the agreement ■■ Renewal, annual review, and methods for changing or renegotiating service level commitments There are many others aspect of an agreement to provide services that could be documented as part of an SLA. In previous chapters, contingency planning, security, and regulatory obligations also were mentioned. The variations are limited only by the uniqueness of each individual arrange- ment and by the needs of the business and the support organizations. When evaluating SLAs, the control objective is to determine that all expec- tations are documented and that a means exists for measuring the delivery against these expectations, including reporting mechanisms, so that both parties are aware of the relative success or failure of meeting the objectives. You will not only be reviewing the content of the SLA to assess how it intro- duces or mitigates risk in the business process, but you also will be review- ing how to use it as a tool for understanding the commitments and expectations. Poorly documented services will result in dissatisfaction, confusion, and an all around ineffective business performance, because the expectations are not written down and therefore cannot be met well. Resources ■■ www.google.com ■■ www.auditnet.org/asapind.htm ■■ www.theiia.org/itaudit/ ■■ www.itsecurity.com/papers/fulllist.htm Technical Infrastructure and Operational Practices 171 [...]... identifying the risk and control points and the overall audit approach you should take for evaluating these processes and systems The systems inner workings and the exact technology used to secure them will change over time, probably in the time it takes you to read this chapter Knowledge of the entire body of the security audit subject matter comprises 25 percent of the CISA exam content Some of the exam. .. In a media management system review, the IS auditor does not need to concern themselves with A Whether the systems catalog accurately reflects the physical library’s location of the media B Whether the media is accessed by only those individuals with a “need to know” C Whether the media is accurately identified for movement off site for back up purposes D Whether the system adequately retires media... to know the data, therefore leaving the clerk unable to do their job because of the access profile assigned to them Available also means that the systems have not been prevented from Protection of Information Assets performing their job because someone inadvertently pulled the wrong plug, or launched a denial or service attack against their old boyfriend, bringing down the business process at the same... 15 The primary purpose of key performance indicators are to A Give management the ability to make sure that the staff is doing their work B Monitor the capacity of the systems equipment and process performance metrics C Provide management with a tool to gauge the overall health of the process and to point to potential trouble spots D Enable operators to know when things are going wrong and whether the. .. effort will be required to maintain the product adequately 6 Which of the following is not normally a concern when reviewing the implementation of an operation console system? A Whether the expertise to implement the system is being provided by the vendor to backfill existing functions, enabling the existing staff to learn the new systems B Whether the scope and goals of the implementation plan are being... by the management The security officer’s role can, however, be defined in a variety of permutations from the textbook model, and they can all work well for an organization, depending on the authority and mission of the security function The keys to understanding the particular situation you are assessing lies in the documentation of the security officer’s role and job description and the mandate in the. .. it will most likely be rather expensive If the available funding is limited and time is constrained, then the product’s quality will have to be the variable that is adjusted downward By establishing the security quality requirements of the business and documenting that decision, the other two sides of the good-cheap-fast triangle then can be better assessed and defended, and the project can move forward... authority based on the policy’s directions These directions would be interpretations of the policy applicable to all users and systems within the authority of the standards making body In this way, other subsets of the organization can interpret the policy differently, as long as jurisdictions do not overlap and each interpretation can coexist while still meeting the spirit of the policy Other subjects... feel that they do not want to fund an effort like this, that their data is too sensitive to risk this kind of exposure, that they can perform this assessment sufficiently in house, or that they are afraid the testers will use the information to later compromise the organization’s systems These fears are unfounded for the most part, assuming that qualified and reputable firms are retained for the testing... compromise The security officer’s role should be to consider the effects of the business decisions being considered and to bring their security expertise to the table, by offering alternatives or advice on potential ramifications and possible results of these decisions In this way, the business owners can make informed, riskbased decisions, being fully aware of the potential downside consequences 183 1 84 Chapter . system review, the IS auditor does not need to concern themselves with A. Whether the systems catalog accurately reflects the physical library’s location of the media B. Whether the media is accessed. be added to the problem. The problems then can be effectively reassigned without the loss of information, should root cause analysis point the reso- lution to a different group other than the one. of the following is the most effective method of assessing the controls over the hardware maintenance process? A. Look at the hardware and assess whether the maintenance is cur- rent and that the