31-60 CISA Domain III Questions Answer and Explanation

Acceptance testing is the final stage before the software is installed and is available for use. The greatest impact would occur if the software fails at the acceptance testing level because this could result in delays and cost overruns.

System testing is undertaken by the development team to determine if the combined units of software work together and that the software meets user requirements per specifications. A failure here would be expensive but easier to fix than a failure found later in the testing process.

Integration testing examines the units/modules as one integrated system and unit testing examines the individual units or components of the software. A failure here would be expensive and require re-work of the modules but would not be as expensive as a problem found just prior to implementation.

System,integration and unit testing are all performed by the developers at various stages of development;the impact of failure is comparatively less for each than failure at the acceptance testing stage.

One of the major benefits of object-oriented design and development is the ability to reuse modules.

Object-oriented design is not intended as a method of improving system performance.

The use of object-oriented design may speed up the system development life cycle (SDLC) for future projects through the reuse of modules, but it will not speed up development of the initial project.

Control effectiveness is not an objective of object-oriented design and control effectiveness may, in fact, be reduced through this approach.

Validating data prior to transmission is the most efficient method and saves the effort of transmitting or processing invalid data. However, due to the risk of errors being introduced during transmission it is also good practice to re-validate the data at the central processing site.

It is important that the data entered from a remote site is edited and validated prior to transmission to the central processing site.

To validate the data after it has been transmitted is not a valid control.

Validating data prior to transmission is the most efficient method and saves the effort of transmitting or processing invalid data. However, due to the risk of errors being introduced during transmission it is also good practice to re-validate the data at the central processing site.

The requirements may change over the life of a project, but the initial deliverables should be documented from the beginning of the project.

It is extremely important that the project be planned properly, and that the specific phases and deliverables are identified during the early stages of the project. This enables project tracking and resource management.

Risk management is a never-ending process,.so project planning cannot wait until all risk has been identified.

Determining the deliverables and timelines of a project are a part of the early project planning work.

The lack of an adequate change control process could impact the integrity of the data; however, the system should be documented first to determine whether the transactions flow to other(systems.

The review of user access would be important; however, in terms of data integrity it would be better to review the data flow diagram.

Evaluating the reconciliation controls would help to ensure data integrity; however, it is more important to understand the data flows of the application to ensure that the reconciliation controls are located in the correct place.

The IS auditor should review the application data flow diagram to understand the flow of data within the application and to other systems. This will enable the IS auditor to evaluate the design and effectiveness of the data integrity controls.

Validation testing is used to test the functionality of the system against detailed requirements to ensure that software construction is traceable to customer requirements.

Sociability testing is used to see whether the system can operate in the target environment without adverse impacts on the existing systems.

Regression testing is used to test for the introduction of new errors in the system after changes have been applied.

Software quality assurance and code reviews are used to determine whether development standards are maintained.

User acceptance testing should be completed prior to implementation.

The implementation planning phase is when the tests are conducted. It is too late in the process to develop the test plan.

The feasibility study is too early for such detailed user involvement.

During requirements definition, the project team will be working with the users to define their precise objectives and functional needs. At this time, the users should be working with the team to consider and document how the system functionality can be tested to ensure that it meets their stated needs. An IS auditor should know at what point user testing should be planned to ensure that it is most effective and efficient.

A post incident review may result in improvements to controls, but its primary purpose is not to harden a network.

The purpose of post incident review is to ensure that the opportunity is presented to learn lessons from the incident. It is not intended as a forum to educate management.

An incident may be used to emphasize the importance of incident response,but that is not the intention of the post incident review.

A post incident review examines both the cause and response to an incident. The lessons learned from the review can be used to improve internal controls. Understanding the purpose and structure of post incident reviews and follow-up procedures enables the information security manager to continuously improve the security program. Improving the incident response plan based on the incident review is an internal (corrective) control.

Internal credibility checks are valid controls to detect errors in processing but will not detect and report lost transactions.

A clerical procedure could be used to summarize and compare inputs and outputs; however, an automated process is less susceptible to error.

Input and output validation controls are certainly valid controls but will not detect and report lost transactions.

Automated systems balancing would be the best way to ensure that no transactions are lost as any imbalance between total inputs and total outputs would be reported for investigation and correction.

Stress testing is carried out to ensure that a system can cope with production workloads. Testing with production level workloads is important to ensure that the system will operate effectively when moved into production.

Testing should never take place in a production environment.

It is not advisable to do stress testing in a production environment. Additionally, if only test data are used, there is no certainty that the system was stress tested adequately.

test environment should always be used to avoid damaging the production environment, but only testing with test data may not test all aspects of the system adequately.

Internal control procedures are too detailed for this phase. They would only be outlined, and any cost or performance implications shown.

Third-party agreements are too detailed for this phase. They would only be outlined, and any cost or performance implications shown.

The communications protocols must be included because there may be significant cost implications if new hardware and software are involved, and risk implications if the technology is new to the organization.

Encryption algorithms are too detailed for this phase. They would only be outlined, and any cost or performance implications shown.

Program interfaces with files are tested for errors during system testing.

The purpose of parallel testing is to ensure that the implementation of a new system will meet user requirements by comparing the results of the old system with the new system to ensure correct processing.

Unit and system testing are completed before parallel testing.

Parallel testing may show that the old system is, in fact, more cost-effective than the new system, but this is not the primary reason for parallel testing.

While standardization can reduce support costs, the transition to a standardized kit can be expensive; therefore, the overall level of IT infrastructure investment is not likely to be reduced

A standardized infrastructure results in a more homogeneous environment, which is more prone to attacks.

A standardized IT infrastructure provides a consistent set of platforms and operating systems across the organization. This standardization reduces the time and effort required to manage a set of disparate platforms and operating systems. In addition, the implementation of enhanced operational support tools (e.g., password management tools, patch management tools and auto provisioning of user access) is simplified. These tools can help the organization reduce the cost of IT service delivery and operational support.

A standardized infrastructure may simplify testing of changes, but it does not reduce the need for such testing.

A validity check is programmed checking of the data validity in accordance with predetermined criteria.

In a duplicate check, new or fresh transactions are matched to those previously entered to ensure that they are not already in the system.

A range check is checking data that matches a predetermined range of allowable values.

A check digit is a numeric value that is calculated mathematically and is appended to data to ensure that the original data have not been altered (e.g., an incorrect, but valid, value substituted for the original). This control is effective in detecting transposition and transcription errors.

The licensing policy should be reviewed to ensure proper licensing but only after the purchasing procedures are checked.

In the case of a deviation from the predefined procedures, an IS auditor should first ensure that the procedure followed for acquiring the software is consistent with the business objectives and has been approved by the appropriate authorities.

Because the software package has already been acquired, it is most likely that it is in use and therefore compatible with existing hardware. Further, the first responsibility of the IS auditor is to ensure that the purchasing procedures have been approved.

Because there was no request for proposal, there may be no documentation of the expectations of the product and nothing to measure a gap against. The first task for the IS auditor is to ensure that the purchasing procedures were approved.

An impact study will not determine whether users will agree with a change in scope.

A change in scope does not necessarily impact the risk that regression tests will faiL

Conducting an impact study could identify a lack of resources such as the project team lacking the skills necessary to make the change; however,this is only part of the impact on the overall timelines and cost to the project due to the change.

Any scope change might have an impact on duration and cost of the project; that is the reason why an impact study is conducted, and the client is informed of the potential impact on the schedule and cost.

While all choices are valid, the post implementation focus and primary objective should be understanding the impact of the problems in the first phase on the remainder of the project.

Ensuring That the system works is a primary objective of the IS auditor,but in this case because the project planning was a failure,the IS auditor should focus on the reasons for, and impact of, the failure.

Because management is aware that the project had problems, reviewing the subsequeut impact will provide insight into the types and potential causes of the project issues. This will help to identify whether IT has adequately planned for those issues in subsequent projects.

The review should assess whether the control is working correctly but should focus on the problems that led to project overruns in budget and time.

Bottom-up testing tests individual components and major functions and processing will not be adequately tested until systems and integration testing is completed.

Interface errors will not be found until later in the testing process--as a result of integration or system testing.

The bottom-up approach to software testing begins with the testing of atomic units, such as programs and modules, and works upward until a complete system testing has taken place. The advantages of using a bottom-up approach to software testing are the fact that errors in critical modules are found earlier.

Confidence in the system cannot be obtained until the testing is completed.

Production data are easier for users to use for comparison purposes.

Using a copy of production data may not test all functionality, but this is not as serious as the risk of disclosure of sensitive data.

There is a risk that former production data may not test all error routines; however, this is not as serious as the risk of release of sensitive data.

Unless the data are sanitized, there is a risk of disclosing sensitive data.

Reviewing change requests may be a good idea, but this is more important if the application is perceived to have a problem.

It is important to assess the effectiveness of the project; however, assuring that the production environment is adequately controlled after the implementation is of primary concern.

Because management is assuming that the implementation went well, the primary focus of the IS auditor is to test the controls built into the application to assure that they are functioning as designed.

The IS auditor should check whether user feedback has been provided, but this is not the most important area for audit.

Lack of synchronization between source and object code will be a serious risk for later maintenance of compiled programs, but this will not affect other types of programs and is not the most serious risk at the time of implementation.

Programming errors should be found during testing, not at the time of implementation.

Having multiple versions is a problem, but as long as the correct version is implemented, the most serious risk during implementation is to have the parameters for the program set incorrectly.

Parameters that are not set correctly would be the greatest concern when implementing an application software package. Incorrectly set parameters are an immediate problem that could lead to system breach, failure or noncompliance.

The agile software development methodology is an iterative process where each iteration or "sprint" produces functional code. If a development team was producing code for demonstration purposes, this would be an issue because the following iterations of the project build on the code developed in the prior sprint.

After each interation or "Sprint", agile development teams re-plan the project so that unfinished tasks are performed, and resources can be reallocated as needed. The continual re-planning is a key component of agile development methodology.

One focus of agile methodology is to rely more on team knowledge and produce functional code quickly. These characteristics would result in less extensive documentation or documentation embbed in the code itself.

The management of agile software development is different from conventional development approaches in that leaders act as facilitators and allow team members to determine now to manage their own resources to get each sprint completed. Because the team members are performing the work, they are in a good position to understand how much time/effort is required to complete a sprint.

During testing, the IS auditor will ensure that the security requirements are met. This is not the time to assess the control specifications.

The best time for the involvement of an IS auditor is at the beginning of the requirements definition of the development or acquisition of applications software. This provides maximum opportunity for review of the vendors and their products. Early engagement of an IS auditor also minimizes the potential of a business commitment to a given solution that might be inadequate and more difficult to overcome as the process continues.

During the implementation phase, the IS auditor may check whether the controls have been enabled; however, this is not the time to assess the control requirements.

The control specifications will drive the security requirements that are built into the contract and should be assessed before the product is acquired and tested.

Inadequate controls are most likely present in situations in which information security is not duly considered from the beginning of system development; they are not a risk that can be adequately addressed by software baselining.

Sign-off delays may occur due to inadequate software baselining; however, these are most likely caused by scope creep.

Software integrity violations can be caused by hardware or software failures, malicious intrusions or user errors. Software baselining does not help prevent software integrity violations.

A software baseline is the cutoff point in the design and development of a system. Beyond this point, additional requirements or modifications to the scope must go through formal, strict procedures for approval based on a business cost-benefit analysis. Failure to adequately manage a system through baselining can result in uncontrolled changes in a project's scope and may incur time and budget overruns.

Prototyping often has poor internal controls because the focus is primarily on functionality, not on security.

Change control becomes much more complicated with prototyping.

Prototyping often leads to functions or extras being added to the system that were not originally intended.

Prototype systems can provide significant time and cost savings through better user interaction and the ability to rapidly adapt to changing requirements; however, they also have several disadvantages, including loss of overall security focus, project oversight and implementation of a prototype that is not yet ready for production.

A data warehouse is used for analysis and research, not for production operations, so the speed of transactions is not relevant.

Data in a data warehouse is frequently received from many sources and vast amounts of information may be received on an hourly or daily basis, Except to ensure adequate storage capability, this is not a primary concern of the designer.

Data warehouses may contain sensitive information, or can be used to research sensitive information, so the security of the data warehouse is important. However, this is not the primary concern of the designer.

Quality of the metadata is the most important element in the design of a data warehouse. A data warehouse is a copy of transaction data specifically structured for query and analysis. Metadata describes the data in the warehouse and aims to provide a table of contents to the stored information. Companies that have built warehouses believe that metadata are the most important component of the warehouse.

Test data will be representative of live processing; however, it is important that all sensitive information in the live transaction file is sanitized to prevent improper data disclosure.

Not all error types are sure to be tested because most production data will only contain certain types of errors.

Sanitized production data may not contain all transaction types. The test data may need to be modified to ensure that all data types are represented.

The results can be tested using normal routines, but that is not a significant advantage of using sanitized live data.

The IT budget is important to ensure that the resources are being used in the best manner, but this is secondary to the importance of reviewing the business plan.

The existing IT environment is important and used to determine gap analysis but is secondary to the importance of reviewing the business plan.

One of the most important reasons for which projects get funded is how well a project meets an organization's strategic objectives. Portfolio management takes a holistic view of a company's overall strategy. IT strategy should be aligned with the business strategy and, hence, reviewing the business plan should be the major consideration.

The investment plan is important to set out project priorities, but secondary to the importance of reviewing the business plan.

Decision trees use questionnaires to lead a user through a series of choices until a conclusion is reached.

Rules refer to the expression of declarative knowledge through the use of if-then relationships.

A data flow diagram is used to map the progress of data through a system and examine logic, error handling and data management.

Semantic nets consist of a graph in which nodes represent physical or conceptual objects and the arcs describe the relationship between the nodes.

The involvement of process owners will ensure that the system will be designed according to the needs of the business processes that depend on system functionality. A sign-off on the design by the process owners is crucial before development begins.

Process ownership assignment does not have a feature to track the completion percentage of deliverables.

Whether the design cost of test cases will be optimized is not determined from the assignment of process ownership. It may help to some extent; however, there are many other factors involved in the design of test cases.

For gap minimization, a specific requirements analysis framework should be in place and then applied; however, a gap may be found between the design and the as-built system that could lead to system functionality not meeting requirements. This will be identified during user acceptance testing. Process ownership alone does not have the capability to minimize requirement gaps.