[2023年04月] 合格 ISACA CISA テストエンジンpdf – 完全版無料問題集 [Q43-Q66]

Explanation/Reference:
Explanation:
When the external key of a transaction is corrupted or lost, the application system will normally be incapable of directly attaching the master data to the transaction data. This will normally cause the system to undertake a sequential search and slow down the processing. If the concerned files are big, this slowdown will be unacceptable. Choice B is incorrect, since a system can recover the corrupted external key by reindexing the table. Choices C and D would not result from a corrupted foreign key.

Explanation/Reference:
Explanation:
Dynamic Host Configuration Protocol (DHCP) automatically assigns IP addresses to anyone connected to the network. With DHCP disabled, static IP addresses must be used and represent less risk due to the potential for address contention between an unauthorized device and existing devices on the network.
Choice B is incorrect because DHCP is suitable for small networks. Choice C is incorrect because DHCP does not provide IP addresses when disabled. Choice D is incorrect because disabling of the DHCP makes it more difficult to exploit the well-known weaknesses in WEP.

Explanation/Reference:
The recovery time objective (RTO) is the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.
It can include the time for trying to fix the problem without a recovery, the recovery itself, testing, and the communication to the users. Decision time for users representative is not included.
The business continuity timeline usually runs parallel with an incident management timeline and may start at the same, or different, points.
In accepted business continuity planning methodology, the RTO is established during the Business Impact Analysis (BIA) by the owner of a process (usually in conjunction with the business continuity planner). The RTOs are then presented to senior management for acceptance.
The RTO attaches to the business process and not the resources required to support the process.
The RTO and the results of the BIA in its entirety provide the basis for identifying and analyzing viable strategies for inclusion in the business continuity plan. Viable strategy options would include any which would enable resumption of a business process in a time frame at or near the RTO. This would include alternate or manual workaround procedures and would not necessarily require computer systems to meet the RTOs.
For your exam you should know below information about RPO, RTO, WRT and MTD :
Stage 1: Business as usual
Business as usual

Image Reference – http://defaultreasoning.files.wordpress.com/2013/12/bcdr-01.png At this stage all systems are running production and working correctly.
Stage 2: Disaster occurs
Disaster Occurs

Image Reference – http://defaultreasoning.files.wordpress.com/2013/12/bcdr-02.png On a given point in time, disaster occurs and systems needs to be recovered. At this point the Recovery Point Objective (RPO) determines the maximum acceptable amount of data loss measured in time. For example, the maximum tolerable data loss is 15 minutes.
Stage 3: Recovery
Recovery

Image Reference – http://defaultreasoning.files.wordpress.com/2013/12/bcdr-03.png At this stage the system are recovered and back online but not ready for production yet. The Recovery Time Objective (RTO) determines the maximum tolerable amount of time needed to bring all critical systems back online. This covers, for example, restore data from back-up or fix of a failure. In most cases this part is carried out by system administrator, network administrator, storage administrator etc.
Stage 4: Resume Production
Resume Production

Image Reference – http://defaultreasoning.files.wordpress.com/2013/12/bcdr-04.png At this stage all systems are recovered, integrity of the system or data is verified and all critical systems can resume normal operations. The Work Recovery Time (WRT) determines the maximum tolerable amount of time that is needed to verify the system and/or data integrity. This could be, for example, checking the databases and logs, making sure the applications or services are running and are available.
In most cases those tasks are performed by application administrator, database administrator etc. When all systems affected by the disaster are verified and/or recovered, the environment is ready to resume the production again.
MTD

Image Reference – http://defaultreasoning.files.wordpress.com/2013/12/bcdr-05.png The sum of RTO and WRT is defined as the Maximum Tolerable Downtime (MTD) which defines the total amount of time that a business process can be disrupted without causing any unacceptable consequences. This value should be defined by the business management team or someone like CTO, CIO or IT manager.
The following answers are incorrect:
RPO – Recovery Point Objective (RPO) determines the maximum acceptable amount of data loss measured in time. For example, the maximum tolerable data loss is 15 minutes.
WRT – The Work Recovery Time (WRT) determines the maximum tolerable amount of time that is needed to verify the system and/or data integrity. This could be, for example, checking the databases and logs, making sure the applications or services are running and are available. In most cases those tasks are performed by application administrator, database administrator etc. When all systems affected by the disaster are verified and/or recovered, the environment is ready to resume the production again.
MTD – The sum of RTO and WRT is defined as the Maximum Tolerable Downtime (MTD) which defines the total amount of time that a business process can be disrupted without causing any unacceptable consequences. This value should be defined by the business management team or someone like CTO, CIO or IT manager.
The following reference(s) were/was used to create this question:
CISA review manual 2014 page number 284
http://en.wikipedia.org/wiki/Recovery_time_objective
http://defaultreasoning.com/2013/12/10/rpo-rto-wrt-mtdwth/

Accuracy of source data is a prerequisite for the quality of the data in a data warehouse. Credibility of the data source, accurate extraction processes and accurate transformation routines are all important, but would not change inaccurate data intoquality (accurate) data.

Section: Information System Operations, Maintenance and Support

Explanation/Reference:
Explanation:
User account access controls and cryptography can protect systems files and data, respectively. On the other hand, firewalls are by far the most common prevention systems from a network security perspective as they can shield access to internal network services, and block certain kinds of attacks through packet filtering.

Section: Information System Acquisition, Development and Implementation Explanation:
Functionality – A set of attributes that bear on the existence of a set of functions and their specified properties.
The functions are those that satisfy stated or implied needs.
Suitability
Accuracy
Interoperability
Security
Functionality Compliance
For CISA Exam you should know below information about ISO 9126 model:
ISO/IEC 9126 Software engineering – Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.[1] The fundamental objective of the ISO/IEC
9126 standard is to address some of the well-known human biases that can adversely affect the delivery and perception of a software development project. These biases include changing priorities after the start of a project or not having any clear definitions of “success.” By clarifying, then agreeing on the project priorities and subsequently converting abstract priorities (compliance) to measurable values (output data can be validated against schema X with zero intervention), ISO/IEC 9126 tries to develop a common understanding of the project’s objectives and goals.
ISO 9126

The standard is divided into four parts:
Quality model
External metrics
Internal metrics
Quality in use metrics.
Quality Model
The quality model presented in the first part of the standard, ISO/IEC 9126-1,[2] classifies software quality in a structured set of characteristics and sub-characteristics as follows:
Functionality – A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
Suitability
Accuracy
Interoperability
Security
Functionality Compliance
Reliability – A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.
Maturity
Fault Tolerance
Recoverability
Reliability Compliance
Usability – A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.
Understandability
Learn ability
Operability
Attractiveness
Usability Compliance
Efficiency – A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.
Time Behavior
Resource Utilization
Efficiency Compliance
Maintainability – A set of attributes that bear on the effort needed to make specified modifications.
Analyzability
Changeability
Stability
Testability
Maintainability Compliance
Portability – A set of attributes that bear on the ability of software to be transferred from one environment to another.
Adaptability
Install ability
Co-Existence
Replace ability
Portability Compliance
Each quality sub-characteristic (e.g. adaptability) is further divided into attributes. An attribute is an entity which can be verified or measured in the software product. Attributes are not defined in the standard, as they vary between different software products.
Software product is defined in a broad sense: it encompasses executables, source code, architecture descriptions, and so on. As a result, the notion of user extends to operators as well as to programmers, which are users of components such as software libraries.
The standard provides a framework for organizations to define a quality model for a software product. On doing so, however, it leaves up to each organization the task of specifying precisely its own model. This may be done, for example, by specifying target values for quality metrics which evaluates the degree of presence of quality attributes.
Internal Metrics
Internal metrics are those which do not rely on software execution (static measure) External Metrics External metrics are applicable to running software.
Quality in Use Metrics
Quality in use metrics are only available when the final product is used in real conditions.
Ideally, the internal quality determines the external quality and external quality determines quality in use.
This standard stems from the GE model for describing software quality, presented in 1977 by McCall et al., which is organized around three types of Quality Characteristics:
Factors (To specify): They describe the external view of the software, as viewed by the users.
Criteria (To build): They describe the internal view of the software, as seen by the developer.
Metrics (To control): They are defined and used to provide a scale and method for measurement.
ISO/IEC 9126 distinguishes between a defect and a nonconformity, a defect being The nonfulfillment of intended usage requirements, whereas a nonconformity is The nonfulfillment of specified requirements. A similar distinction is made between validation and verification, known as V&V in the testing trade.
The following were incorrect answers:
Reliability – A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.
Usability – A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.
Maintainability – A set of attributes that bear on the effort needed to make specified modifications.
Reference:
CISA review manual 2014 Page number 188

Defense in-depth means using different security mechanisms that back each other up. When network traffic passes the firewall unintentionally, the logical access controls form a second line of defense. Using two firewalls of different vendors to consecutively check the incoming network traffic is an example of diversity in defense. The firewalls are the same security mechanisms. By using two different products the probability of both products having the same vulnerabilities is diminished. Havingno physical signs on the outside of a computer center building is a single security measure. Using two firewalls in parallel to check different types of incoming traffic is a single security mechanism and therefore no different than having a single firewall checking all traffic.

Explanation/Reference:
Explanation:
The effectiveness of the business continuity plan (BCP) can best be evaluated by reviewing the results from previous business continuity tests for thoroughness and accuracy in accomplishing their stated objectives. All other choices do not provide the assurance of the effectiveness of the BCP.

The most effective method is to determine through code comparisons what changes have been made and then verify that they have been approved. Change control records and software migration records may not have all changes listed. Ensuring that only appropriate staff can migrate changes into production is a key control process, but in itself does not verify compliance.

Section: Protection of Information Assets
Explanation:
The first step in the managing risk is the identification and classification of critical information resources
(assets). Once the assets have been identified, the process moves onto the identification of threats,
vulnerabilities and calculation of potential damages.

Section: Information System Acquisition, Development and Implementation Explanation Explanation:
The correct sequence of BRP application step is Envision, Initiate, Diagnose, Redesign, Reconstruct and Evaluate.
For your exam you should know the information below:
Overview of Business Process Reengineering
One of the principles in business that remains constant is the need to improve your processes and procedures. Most trade magazines today contain discussions of the detailed planning necessary for implementing change in an organization. The concept of change must be accepted as a fundamental principle. Terms such as business evolution and continuous improvement ricochet around the room in business meetings. It’s a fact that organizations which fail to change are destined to perish.
As a CISA, you must be prepared to investigate whether process changes within the organization are accounted for with proper documentation. All internal control frameworks require that management be held responsible for safeguarding all the assets belonging to their organization. Management is also responsible for increasing revenue.
BPR Application Steps
ISACA cites six basic steps in their general approach to BPR. These six steps are simply an extension of Stewart’s Plan-Do-Check-Act model for managing projects:
Envision -Visualize a need (envision). Develop an estimate of the ROI created by the proposed change.
Elaborate on the benefit with a preliminary project plan to gain sponsorship from the organization. The plan should define the areas to be reviewed and clarify the desired result at the end of the project (aka end state objective). The deliverables of the envision phase include the following:
Project champion working with the steering committee to gain top management approval Brief description of project scope, goals, and objectives description of the specific deliverables from this project with a preliminary charter to evidence management’s approval, the project may proceed into the initiation phase.
Initiate -This phase involves setting BPR goals with the sponsor. Focus on planning the collection of detailed evidence necessary to build the subsequent BPR plan for redesigning the process. Deliverables in the initiation phase include the following:
Identifying internal and external requirements (project specifications) Business case explaining why this project makes sense (justification) and the estimated return on investment compared to the total cost (net ROI) Formal project plan with budget, schedule, staffing plan, procurement plan, deliverables, and project risk analysis Level of authority the BPR project manager will hold and the composition of any support committee or task force that will be required From the profit and loss (P&L) statement, identify the item line number that money will be debited from to pay for this project and identify the specific P&L line number that the financial return will later appear under (to provide strict monitoring of the ROI performance) Formal project charter signed by the sponsors It’s important to realize that some BPR projects will proceed to their planned conclusion and others may be halted because of insufficient evidence. After a plan is formally approved, the BPR project may proceed to the diagnostic phase.
Diagnose Document existing processes. Now it’s time to see what is working and identify the source of each requirement. Each process step is reviewed to calculate the value it creates. The goal of the diagnostic phase is to gain a better understanding of existing processes. The data collected in the diagnostic phase forms the basis of all planning decisions:
Detailed documentation of the existing process
Performance measurement of individual steps in the process
Evidence of specific process steps that add customer value
Identification of process steps that don’t add value
Definition of attributes that create value and quality
Put in the extra effort to do a good job of collecting and analyzing the evidence. All future assumptions will be based on evidence from the diagnostic phase.
Redesign- Using the evidence from the diagnostic phase, it’s time to develop the new process.
This will take several planning iterations to ensure that the strategic objectives are met. The formal redesign plans will be reviewed by sponsors and stakeholders. A final plan will be presented to the steering committee for approval. Here’s an example of deliverables from the redesign phase.
Comparison of the envisioned objective to actual specifications
Analysis of alternatives (AoA)
Prototyping and testing of the redesigned process
Formal documentation of the final design
The project will need formal approval to proceed into the reconstruction phase. Otherwise, the redesign is halted pending further scrutiny while comparing the proposed design with available evidence. Insufficient evidence warrants halting the project.
Reconstruct With formal approval received, it’s time to begin the implementation phase.
The current processes are deconstructed and reassembled according to the plan. Reconstruction may be in the form of a parallel process, modular changes, or complete transition. Each method presents a unique risk and reward opportunity. Deliverables from this phase include the following:
Conversion plan with dependencies in time sequence
Change control management
Execution of conversion plan with progress monitoring
Training of users and support personnel
Pilot implementation to ensure a smooth migration
Formal approval by the sponsor.
The reconstructed process must be formally approved by management to witness their consent for fitness of use. IT governance dictates that executive management shall be held responsible for any failures and receive recognition for exceptional results. System performance will be evaluated again after entering production use.
Evaluate (post evaluation) The reconstructed process is monitored to ensure that it works and is producing the strategic value as forecast in the original justification.
Comparison of original forecast to actual performance Identification of lessons learned Total quality management plan to maintain the new process A method of continuous improvement is implemented to track the original goals against actual process performance. Annual reevaluation is needed to adapt new requirements or new opportunities.
Benchmarking as a BPR Tool
Benchmarking is the process of comparing performance data (aka metrics). It can be used to evaluate business processes that are under consideration for reengineering. Performance data may be obtained by using a self-assessment or by auditing for compliance against a standard (reference standard). Evidence captured during the diagnostic phase is considered the key to identifying areas for performance improvement and documenting obstacles. ISACA offers the following general guidelines for performing benchmarks:
Plan Identify the critical processes and create measurement techniques to grade the processes.
Research Use information about the process and collect regular data (samples) to build a baseline for comparison. Consider input from your customers and use analogous data from other industries.
Observe Gather internal data and external data from a benchmark partner to aid the comparison results.
Benchmark data can also be compared against published standards.
Analyze Look for root cause-effect relationships and other dependencies in the process. Use predefined tools and procedures to collate the data collected from all available sources.
Adapt Translate the findings into hypotheses of how these findings will help or hurt strategic business goals. Design a pilot test to prove or disprove the hypotheses.
Improve Implement a prototype of the new processes. Study the impact and note any unexpected results.
Revise the process by using controlled change management. Measure the process results again. Use reestablished procedures such as total quality management for continuous improvement.
The following answers are incorrect:
The other options specified does not represent the correct sequence of BRP application steps.
Reference:
CISA review manual 2014 page number 219 to 211
CISA certified information system auditor study guide Second Edition Page Number 154 to 158