The ISO 15504 standard is a modified version of the CMM. These changes were intended to clarify the different maturity levels across different languages and cultures. Notice that level 0 is relabeled as incomplete. Level 1 is renamed to indicate that the process has been successfully performed. Level 2 indicates that the process is managed. Level 3 shows that the process is well established in the organization. Level 4 indicates that the process output will be very predictable. Level 5 shows that the process is under a continuous improvement program using statistical process control. Table 5.1 illustrates the minor variations between the CMM and the ISO 15504 standard, also known as SPICE.

The purpose of ISO 15504 is identical to the CMM. Variations in language forced the ISO version to use slightly different terminology to express their objectives. Let's move on to a quick overview of two ISO quality-management standards.

The ISO has promoted a series of quality practices that were previously known as ISO 9000, 9001, and 9002 for design, manufacturing, and service, respectively. These have now been combined into the single ISO 9001 reference. Many organizations have adopted this ISO standard to facilitate worldwide acceptance of their products in the marketplace. ISO compliance also brings the benefits of a better perception by investors. Compliance does not guarantee a better product, but it does provide additional assurances that an organization should be able to deliver a better product.

Within the ISO 9001 reference, you will find that a formally adopted quality manual is required by the ISO 9001:2000. The ISO 9001:2000 quality manual specifies detailed procedures for quality management by an organization. The same quality manual provides procedures for strong internal controls when working with vendors, including a formal vendor evaluation and selection process. To ensure quality, the ISO 9001:2000 mandates that personnel performing work shall be properly trained and managed to improve competency. Because an organization claiming ISO compliance is required to have a thoroughly written quality manual in place, an IS audit may request evidence demonstrating that the quality processes are actively used.

ISO 9126 is a variation of ISO 9001. The ISO standard 9126-2:2003 explains how to apply international software-quality metrics. This standard also defines requirements for evaluating software products and measuring specific quality aspects.

The six quality attributes are as follows:

Once again, organizations claiming ISO compliance should be able to demonstrate active use of software metrics and supporting evidence for ISO 9126-2 compliance. You need to remember that no evidence equals no credit.

As a CISA, you should be prepared to identify the terminology used by the CMM and various ISO quality standards. Now that we've reviewed these maturity standards, it is time to mention the matching ISO document-control requirements.

The steering committee charters a project team to perform the administrative tasks necessary for an information request (RFI) or proposal request (RFP). The request is sent to a small number of prospective vendors or posted to the public, depending on the client's administrative operating procedure. An internal software development staff may provide their own proposal in accordance with the RFP or participate on the review team. A typical RFP will contain at least the following elements:

The RFP project team works with the steering committee to formulate a fair and objective review process. The organization may consult ISO 9001:2000 and ISO 9126-2:2003 standards for guidance. The proposed software could be evaluated by using the CMM. In addition, ISACA's Control Objectives for Information and related Technology (CObIT) provides valuable information to be considered when reviewing a vendor and their products.

As an IS auditor, you should remember that your goal is to be thorough, fair, and objective. Care should be given to ensure that the requirements and review do not grant favor toward a particular vendor. The reviews are actually a form of audit and should include the services of an internal or external IS auditor. It is essential that vendor claims are investigated to ensure that the software will fulfill the desired business objectives.

The systematic process of reviewing vendor proposals is a project unto itself. Each proposal has to be scrutinized to ensure compliance requirements identified in the original RFP documents provided to the vendor. You need to ask the following questions:

One of the major problems in reviewing a vendor is the inability to get a firm commitment in writing for all issues that have been raised. There are major vendors that will respond to the RFP with a lowball offer that undercuts the minimum requirements. Their motive is to win by low bid and then overcharge the customer with expensive change orders to bring the implementation up to the customer's stated objective.

Evolutionary software development is an iterative process of requirements, prototypes, and improvement. In the 1970s, Barry Boehm used W.W. Royce's famous waterfall diagram to illustrate the software development life cycle. A simplified version of the waterfall model used by ISACA is shown in Figure 5.1.

Figure 5.1. Simplified waterfall model (W.W. Royce)

Based on the SDLC phases, this simplified model assumes that development in each phase will be completed before moving into the next phase. That assumption is not very realistic in the real world. Changes are discovered that regularly require portions of software to undergo redevelopment.

Boehm's version of the software life cycle model contained seven phases of development. Each of the original phases included validation testing with a backward loop returning to the previous phase. The backward loop provides for changes in requirements during development. Changes are cycled back to the appropriate phase and then regression-tested to ensure that the changes do not produce a negative consequence. Figure 5.2 shows Boehm's model as it appeared in 1975 from the Institute of Electrical and Electronics Engineers (IEEE).

About 12 years later, Boehm developed the spiral model to demonstrate the software life cycle including evolutionary versions of software. The original waterfall model implied management of one version of software from start to finish. This new spiral model provided a simple illustration of the life cycle that software will take in the development of subsequent versions. Each version of software will repeat the cycle of the previous version while adding enhancements. Figure 5.3 shows the cycle of software versions in the spiral model.

Figure 5.2. Boehm's modified waterfall model

Figure 5.3. Spiral model for software life cycle

Notice how the first version starts in the planning quadrant of the lower left and proceeds through requirements into risk analysis and then to software development. After the software is written, we have our first version of the program. The planning cycle then commences for the second version, following the same path through requirements, risk analysis, and development. The circular process will continue for as long as the program is maintained.

The Constructive Cost Model (COCOMO) was developed by Boehm in 1981. This forecasting model provides a method for estimating the effort, schedule, and cost of developing a new software application. The original version is obsolete because of evolution changes in software development. COCOMO was replaced with COCOMO II in 1995.

The COCOMO II model provides a solid method for performing "what if" calculations that will show the effect of changes on the resources, schedule, staffing, and predicted cost. The COCOMO II model deals specifically with software programming activities but does not provide a definition of requirements. You must compile your requirements before you can use either COCOMO model. COCOMO II templates are available on the Internet to run in Microsoft Office Excel.

The COCOMO II model permits the use of three internal submodels for the estimations: Application Composition, Early Design, or Post Architecture. Within the three internal submodels, the estimator can base their forecast on a count of source lines of code or Function Point Analysis.

Source Lines Of Code (SLOC) forecasts estimates by counting the individual lines of program source code regardless of the embedded design quality. This method has been widely used for more than 40 years and is still used despite advances with 4GL programming tools. It is important for you to understand that counting lines of code will not measure efficiency. The most efficient program could have fewer lines of code, and less-efficient software could have more lines. Having a program with few lines of program code typically indicates that the finished software will run faster. Smaller programs also have the advantage of being easier to debug.

Function Point Analysis (FPA) is a structured method for classifying the required components of a software program. FPA was designed to overcome shortfalls in the SLOC method of counting lines in programs. The FPA method (see Figure 5.5) divides all program functions into five classes:

The five classes of data are assigned a complexity ranking of low, average, or high. The ranking is multiplied by a numerical factor and tallied to achieve an estimate of work required (see Figure 5.6).

Figure 5.5. Concept overview of Function Point Analysis

Figure 5.6. Calculating function points

FPA is designed for an experienced and well-educated person who possesses a strong understanding of functional perspectives. Typically this is a senior-level programmer. An inexperienced person will get a false estimate. This model is intended for counting features that are specified in the early design. It will not create the initial definition of requirements. Progress can be monitored against the function point estimate to assess the level of completion. Changes can be recorded to monitor scope creep. Scope creep refers to the constant changes and additions that can occur during the project. Scope creep may indicate a lack of focus, poor communication, lack of discipline, or an attempt to distract the user from the project team's inability to deliver to the original project requirements.

The overall cost budget should include an analysis of the estimated personnel hours by function. The functions include clerical duties, administrative processes, analysis time, software development, equipment, testing, data conversion, training, implementation, and ongoing support.

Best practices in software development require a review meeting at the end of each phase to determine whether the project should continue to the next phase. The review is attended by an executive chairperson, project sponsor, project manager, and the suppliers of key deliverables.

The meeting is opened by the chairperson. The project manager provides an overview of the business case and presents the initial assessment reports. Presentations are made to convey the results of risk management analysis for the project. Project plans and the initial budget are presented for approval. Meeting attendees review the phase 1 plans to ensure that the skills and resource requirements are clearly understood.

At the end of the phase review meeting, the chairperson determines whether the review has passed or failed based on the evidence presented. In the real world, a third option may exist: deciding that the project should be placed on temporary hold and reassessed at a future date. All outstanding issues must be resolved before granting approval to pass the phase review.

Formal approval is evidenced by a signed project charter accompanied by a preliminary statement of work (SOW). The project manager is responsible for preparing the project plan documentation. The sponsor grants formal authority by physically signing the documents. Without either of these documents, chances are a dispute will evolve into a conflict that compromises the project. A signed charter and SOW are frequently used to force cooperation by other departments or to prevent interruptions by politically motivated outsiders.

In the Feasibility Study phase, you should review the documentation related to the initial needs analysis. As an auditor, you review the risk mitigation strategy. You ask whether an existing system could have provided an alternative solution. The organization's business case and cost justifications are verified to determine whether their chosen solution was a reasonable decision. You also verify that the project received formal management approval before proceeding into the next phase.

The internal controls for user account management functions are included in this phase to provide for separation of duties:

It is important that the requirements are properly verified and supported by a genuine need. Each requirement should be traced back to a source document detailing the actions necessary for performance of work or legal compliance.

A gap analysis is used to determine the difference between the current environment and the proposed system. Plans need to be created to address the deficiencies that are identified in the gap analysis. The deficiencies may include personnel, resources, equipment, or training.

At the end of phase 2, a phase 2 review meeting is held. This meeting is similar in purpose to the previous phase 1 review. This time, the review focuses on success criteria in the definition of software deliverables and includes a timeline forecast with date commitments. The proposed system users need to submit their final feedback assessment and comments before approval is granted to proceed into phase 3. The purpose of the phase 2 review meeting is to gain the authority to proceed with preliminary software design (phase 3). Once again, all outstanding issues need to be resolved before approval can be granted to proceed to the next phase.

You should obtain a list of detailed requirements. The accuracy of the requirements can be verified by a combination of desktop review of documentation and interviews with appropriate personnel. Conceptual ERD and flowchart diagrams should be reviewed to ensure that they address the needs of the user.

The Requirements Definition phase creates an output of detailed success factors to be incorporated into the acceptance test specifications. As an auditor, you will verify that the project plans and estimated costs have received proper management approval.

The best way to create loyal customers is to exceed their expectations. It's important to deliver within the original scope to satisfy customer needs. Failing project managers may make the dangerous mistake of attempting to switch the deliverables by using a bait-and-switch technique referred to as gold plating. If you gold-plate doggy poop, it's nice and shiny, but still just fancy poop.

We discussed Deming's planning cycle in Chapter 2 as it related to audit planning. Figure 5.10 shows that the Plan-Do-Check-Act cycle also applies to software design.

Figure 5.10. Planning for quality during design (Plan, Do, Check, Act)

Phase 3 is the best time for the software developer to work directly with the user. Most professional programmers encourage the progression of meetings necessary to refine the design before a single line of program code is written. A series of meetings are necessary to help convert user ideas and whims into a structured set of deliverables. Time should be spent on creating screen layouts, designing formats, and matching their desired workflow. Initial plans for developing a prototype in phase 4 are created during this System Design phase.

A significant output during the design phase is to identify how each of the software functions can be tested. Data derived during design provides the base criteria for behavior testing and inspection during phase 4 development testing. Data from user meetings provides a solid basis for user acceptance testing. The documentation created during the design phase initially serves as the road map for programmers during development. Later the phase 3 design documentation will provide a foundation for support manuals and training.

In certain situations, reverse engineering may be used to accelerate the creation of a working system design.

Reverse engineering is a touchy subject. A software decompiler will convert programs from machine language to a human-readable format. The majority of software license agreements prohibit the decompiling of software in an effort to protect the vendor's intellectual design secrets.

An existing system may loop back into phase 3 for the purpose of reengineering. The intention would be to update the software by reusing as many of the components as is feasible. Depending on the situation, reengineering may support major changes to upgrade the software for newer requirements.

At the end of the System Design phase, a software baseline is created from the design documents. The baseline incorporates all the agreed-upon features that will be implemented in the initial version of software (or next version in the case of reengineering). This baseline is used to gain approval for a design freeze. The design freeze is intended to lock out any additional changes that could lead to scope creep.

The phase 3 review meeting starts with a review of the detailed design for the proposed system. Engineering plans and project management plans are reviewed. Cost estimates are compared to the assumptions made in the business case. A comparison is made between the intended features and final design. Final system specifications, user interface, operational support plan, and test and verification plans are checked for completeness. Data from the risk analysis undergoes a review based on evidence. Approval is requested to proceed to the next phase. Once again, all outstanding issues must be resolved before proceeding to the next phase. Each of the stakeholders and sponsors should physically sign a formal approval of the design before allowing it to proceed into development. This administrative control enforces accountability for the final outcome.

You need to review the software baseline and design flowcharts. The design integrity of each data transaction should be verified. During the design review, you verify that processing and output controls are incorporated into the system. Input from the system's intended power users may provide insight into the effectiveness of the design.

It is important that the needs of the power users are implemented during the design phase. This may include special functions, screen layout, and report layout. You should have a particular interest in the logging of system transactions for traceability to a particular user. You look for evidence that a quality control process is in use during the software design activities. It is important to verify that formal management approval was granted to proceed to the next phase.

Standards and quality control are extremely important during the Development phase. A talented programmer can resolve minor discrepancies in the naming conventions, data dictionary, and program logic. Computer software programs will become highly convoluted unless the programmer imposes a well-organized structure during code writing. Unstructured software coding is referred to as spaghetti bowl programming, making reference to a disorganized tangle of instructions.

The preferred method of organizing software is to implement a top-down structure. Top-down structured programming divides the software design into distinct modules. If top-down program structures were diagrammed, the result would look like an inverted tree. Within the tree, individual program modules (or subroutines) perform a unique function. Modules are logically chained together to form the finished software program. The modular design exponentially improves maintainability of the finished program. Individual modules can be updated and replaced with relative ease. By comparison, an unstructured spaghetti bowl program would be a nightmare to modify. Modular design also permits the delegation of modules to different teams of programmers. Each module can be individually tested prior to final assembly of the finished program.

The software project needs to be managed to ensure adherence to the planned schedule. Scope creep with unforeseen changes can have a devastating impact on any project. It is common practice to allow up to a 10 percent variance in project cost and time estimates. In government projects, the variance is only 8 percent.

The development project will be required to undergo management oversight review if major changes occur in assumptions, requirements, or methodology. Management oversight review would also be warranted if the total program benefits or cost are anticipated to deviate by more than 8 percent for government or 10 percent in industry. The project schedule needs to be tightly managed to be successful. The change control process should be implemented to ensure that necessary changes are properly incorporated into the software development phase.

A version control system is required to track progress with all of the minor changes that naturally occur daily during development.

The effort to write program code depends on the programming language and development tool selected. Examples of languages include Common Business Oriented Language (COBOL), C language, Java, the Beginner's All-purpose Symbolic Instruction Code (BASIC), and Visual Basic. The choice of programming languages is often predetermined by the organization. If the last 20 years' worth of software was developed using COBOL, it might make sense to continue using COBOL.

Computer programming languages have evolved dramatically over the past 50 years. The early programming languages were cryptic and cumbersome to write. This is where the term software coding originated. Each generation of software became easier for a human being to use. Let's walk through a quick overview of the five generations of computer programming languages:

Figure 5.12 shows the hierarchy of the different generations of programming languages.

Figure 5.12. Generation levels of programming languages

After the programming language has been selected, the next step is to choose the development tool. There are still some programmers able to sit down and write code manually by using the knowledge contained in their head. This type of old-school approach usually creates very efficient programs with the smallest number of program lines.

The majority of programmers use an advanced fourth-generation software code program to write the actual program instructions. This advanced software enables the programmer to focus on drawing higher-level logic while the computer program creates the lower-level set of instructions similar to what a manual programmer would have done. Simply put, a computer program writes the computer program.

The better development tools provide an integrated environment of design, code creation, and debugging. This type of development tool is referred to as an integrated development environment (IDE).

One of the best examples of an IDE is the commercial CASE tool software. You need to understand the basic principles behind CASE tools. CASE tools are divided into three functional categories that support the SDLC phases of 2, 3, and 4, respectively:

As a CISA, you should be aware of two alternative software development methods: Agile and Rapid Application Development (RAD). Each offers the opportunity to accelerate software creation during the Development phase. The client may want to use either of these methods in place of more-traditional development. Both offer distinct advantages for particular situations. Both also contain drawbacks that should be considered.

Agile Development Method

Agile uses a fourth-generation development environment to quickly develop prototypes within a specific time window. The Agile method uses time-box management techniques to force individual iterations of a prototype within a very short time span. Agile allows the programmer to just start writing a program without spending much time on preplanning documentation. The drawback of Agile is that it does not promote management of the requirements baseline. Agile does not enforce preplanning. Some programmers prefer Agile simply because they do not want to be involved in tedious planning exercises.

When properly combined with traditional planning techniques, Agile development can accelerate software creation. Agile is designed exclusively for use by small teams of talented programmers. Larger groups of programmers can be broken into smaller teams dedicated to individual program modules.

Note

The primary concept in Agile programming is to place greater reliance on the undocumented knowledge contained in a person's head. This is in direct opposition to capturing knowledge through project documentation.

Rapid Application Development Method

A newer integrated software development methodology is Rapid Application Development (RAD), which uses a fourth-generation programming language. RAD has been in existence for almost 20 years. It automates major portions of the software programmer's responsibilities within the SDLC.

RAD supports the analysis portion of SDLC phase 2, phase 3, phase 4, and phase 5. Unfortunately, RAD does not support aspects of phase 1 or phase 2 that are necessary for the needs of a major enterprise business application. RAD is a powerful development tool when coupled with traditional project management in the SDLC.

During the Development phase, it is customary to create system prototypes. A prototype is a small-scale working system used to test assumptions. These assumptions may be about user requirements, program design, or the internal logic used in critical functions. Prototypes usually are inexpensive to build and are created over a few days or weeks. The principal advantage of a prototype is that it permits change to occur before the major development effort begins.

Prototypes seldom have any internal control mechanisms. Each prototype is created as an iterative process, and the lessons learned are used for the next version. A successful prototype will fulfill its mission objective and validate the program logic. All development efforts will focus on the production version of the program after the prototype has proven successful.

A computer program can be written as either a program script or a compiled program. Program scripts are written like movie scripts and contain instructions for the computer to follow. The programmer uses a scripting language such as Perl, JavaScript, or Visual Basic. The advantage of scripts is that they are easy to maintain. The program script is stored in human-readable form. The disadvantage is that program scripts are run by using a script interpreter. The script interpreter is slow to execute. A script interpreter compiles a temporary version of the scripted program as it is running on the computer. The scripted program is considered a crystal box, or white box, because a trained human being could read the program script and decipher the structural design of the program.

Compiling programs is a process of converting human-readable instructions into machine-language instructions for execution. The human-readable version of software is referred to as source code. A computer programmer will compile programs to increase the execution speed of the software. A simple way to remember the definition is that source code is what the compiler started with. The compiled program is unreadable to humans. This unreadable version of the program is referred to as the object code.

Think of object code as the output object created by the compiler. Compiling software provides rudimentary protection of the program's internal logic from inquisitive people. The disadvantage of compiled programs is that reviewing the internal structural design would be practically impossible. The compiled program is essentially a black box. Figure 5.13 shows the different creation paths for compiled programs and program scripts.

Computer programmers will usually compile multiple versions of a program during development and debug testing. Without proper management, this scenario could become a nightmare. How do you ensure that the latest copy is in use? It is the job of configuration and version management to provide a traceable history of multiple versions of computer software.

Managing a changing environment is a significant challenge. Constant changes make it difficult to remain organized and coordinated, no matter what you're trying to accomplish. But suppose, for example, that a company wants to release a new software product. During software development, multiple programmers may be working on different modules of the same program. For this example, let's name the program Report Whiz. The programming used in the individual modules for Report Whiz may have different levels of maturity to consider. For example, the screen-printing utility might be in version 1.1, while the report-writer module may be in version 6.0. By combining these two modules into Report Whiz, the result will become our finished configuration for Report Whiz version 1.0. Does it sound like this could get confusing?

Figure 5.13. Compiled programs versus scripts

Well, it can. That is the challenge. How will the company manage and track all these different components with the correct versions?

Version control is the tracking of all the tiny details inside both major and minor version changes. By tracking these tiny details, we can understand the internal construction of our finished software configuration. Detailed version control is the foundation of configuration. With version control, we have a detailed configuration that is ready to be managed.

Configuration management is focused on management exercising control over the finished software version. The primary elements of configuration management are control, accounting and reporting.

The auditor needs to investigate how the client manages and records changes to a configuration. After obtaining this understanding, you need to ask who authorizes the changes. Finally, you need to ask how the changes are tested and accepted for production use.

Fortunately, there are software tools to assist software developers in managing version control. One of the most common commercial applications for tracking version changes is known as a Poly Version Control System (PVCS). PVCS software contains a database that manages the tracking of programming changes and revisions of software code. In industry slang, we may refer to the PVCS function as a Top Copy or Latest Copy system.

The purpose of PVCS is to ensure that each programmer is working with the latest version of the software program code. During the day, the programmer checks out the latest copy of the program code from the PVCS database. The checkout process is similar to the checkout of books from your local library. The PVCS database is designed to synchronize the work of every programmer. A programmer checks out the latest software version and then uses that version to start writing program code. Each day the programmer returns their finished work to the PVCS-controlled library by using a check-in process. During check-in, the PVCS database informs the programmer with a list of any related changes made by the other programmers. This provides coordination for the team of programmers.

A vast assortment of errors occur naturally during the development process. These errors may include syntax errors, inconsistent naming structures, logic errors, and other common mistakes. Most online development tools will assist the programmer by debugging some of the errors. Using top-down structured programming techniques makes it easier to troubleshoot problems.

During the Development phase, it is imperative that tests and verification plans are created to debug the software programs. Tests should be performed to validate processing accuracy. Test plans are created to uncover program flaws, manage defects, and search for unintended results. A logic path monitor can be used to provide programmers with information about errors in program logic.

During development, software testing occurs at multiple levels. Any deficiencies or errors need to be discovered before the finished program is implemented. There are four basic types of test methods:

All tests should follow a formal procedure in a separate testing environment. The following types of structured technical tests occur during the Development phase:

The test plan and results of each test need to be carefully documented. In environments where strong controls are desired, archiving test records for future reference is necessary. After all the technical tests have been completed to satisfaction, it is time for the most important test of all. The last test in the Development phase is user acceptance testing. This is when the project sponsor determines whether to accept the system. If accepted, the system moves into the Implementation phase.

Once again, a phase review meeting is held. The phase 4 review focuses on the software being delivered by the programmers for the users. The Development phase has now concluded. The finished software is compared for compliance against the original objectives, requirements list, and design specifications. Evidence is presented from test results, which should indicate that the software is performing as expected. Plans for ongoing operation are compared to the previous gap analysis to uncover any remaining deficiencies. After all outstanding issues have been resolved, the plan is put before the chairperson for approval to proceed to the Implementation phase.

As an auditor, your prime interest in the Development phase is to verify that a quality control process has been utilized to develop an effective computer program. All internal control mechanisms should be present in the finished program. The programs have undergone debugging with formal testing. Evidence from test results is expected to provide assurance of system integrity. Support documentation has been created in conjunction with an operational support plan for production use. The finished software capabilities have been verified for compliance to the original objectives. The user has accepted the finished computer program. And finally, management has granted formal approval for the software to be implemented.

Computer software is authorized for distribution via a release process. Software is released from development and authorized to be installed for production use. Each vendor has their own release schedule.

Computer software releases fit one of the following profiles:

The computer program is now a finished version ready for final acceptance testing and user training. The next step for implementation is to load the client's current data.

A data conversion plan is developed to migrate existing data into the new system. Great care needs be taken to prevent loading garbage data into the new system. A successful technique to prevent loading garbage is to reload selected portions of shared data directly from the latest source file. An example is reloading a manufacturing kit list directly from the latest engineering design. This would eliminate the migration of outdated information into the new system.

A list of data files eligible for migration is developed. Each file is verified against the system design requirements. If the file is required, procedures would be created to scrub (remove) outdated entries from each file. It is a common practice to hire a data entry service to assist in data conversion. Sometimes it is easier to re-create a file with minimal data, as opposed to the tedious job of grooming existing files. The programmers may write a data conversion utility to reformat existing files, such as a customer list, into the new system. A comprehensive data conversion plan is always required.

Certification is a technical process of testing against a known reference. The system is tested to ensure that all internal controls are present and functioning correctly. The system certification is based on measuring compliance to a particular requirement. Systems used in the government are required to undergo a certification process before being placed in production use.

The original U.S. computer controls (Trusted Computer System Evaluation Criteria, or TCSEC) have been merged with developments from the European IT security countries (Information Technology Security Evaluation Criteria, or ITSEC) to form an international common criteria for evaluating computer security. This common criteria has been adopted by ISO as Common Criteria standard 15408. CC is the nickname for the complete set of common criteria. Several countries have adopted the CC, including Canada, France, Germany, the Netherlands, the United Kingdom, and the United States. All the ISO member countries are expected to use 15408.

The CC brings the benefits of accumulated wisdom with a flexible approach to standardization and evaluation assurance. Flexibility is provided in this specification of secure products by using seven standardized evaluation assurance levels (EALs). Official testing is provided by an independent lab certified under the ISO 17025 standard for laboratories and testing facilities.

Within the CC is a well-defined set of IT security requirements for perspective products and systems. Here's how it works:A system to be evaluated is referred to as the target of evaluation (TOE). Each TOE has security threats, objectives, requirements, and a summary of functions to be measured. Every TOE contains security functions (TSF) to be relied upon in the enforcement of the TOE's desired security policy (TSP).

The grouping of evaluation test objectives is defined as the protection profile (PP). A variety of protection profiles have already been created for systems used as workstations, firewalls, network servers, secure databases, and so forth. A PP is intended to be reusable and effective in defining the security requirements for the system.

The party requesting evaluation simply picks a PP (protection desired), identifies the TOE (system to test), and pays for the tests to be performed to the appropriate EAL (assurance level 1 through 7). The goal is to make it easier for a vendor to advertise systems appropriate to the client needs. Let's take a brief overview of the elements to be tested.

Internal control standards require business systems to undergo a certification process. It may be an internal review or a formal review such as the Common Criteria. Every computer system and application should undergo a certification process prior to use in a production environment.

As a CISA, you will be required to undergo update and renewal training to keep your certification current. Existing information systems should also go through a recertification process to remain up-to-date. You should be concerned about systems that the customer has not certified for production, or systems for which the certification was not maintained and is now out-of-date.

The next step after certification is accreditation. After passing the certification test, management determines how or where the system may be used. Accreditation is an administrative process based on management's comfort level with demonstrated performance or fitness of use (management acceptance). Management is responsible for accreditation of systems during the system's useful life cycle. The designated accreditation authority is a senior executive who will accept full responsibility for the consequences of operating the overall system (often the CIO or agency head). Accreditation is by site, type of use, or system.

Accreditation may be in the form of approval to operate in limited use for 90–180 days or (full) annual accreditation. The approved implementation may begin production use. Systems must be recertified and reaccredited annually.

Now it is time to train the users and system operators. Hopefully, the organization had some of its power users actively involved in prior phases. The new system's power users were usually involved in the phase 2 design. If so, these power users can serve as instructors and mentors to the new system users. A user training plan is necessary to ensure that everyone receives appropriate training for their role. During the training process, each user should receive specific instructions on the new functions of the system. Care should be taken to explain which of the old procedures will no longer be used. The training plan needs to provide for ongoing training of new users.

Special training is required for the system custodians (system administrator, database administrator, and computer console operator). The custodians need to be trained for normal operations and emergency procedures unique to the system. After the people are trained, it is time to move the system into production use.

The new system has been running separately from production up to this point. A plan is necessary for switching production processing from the old system to the new system. This process is commonly described by the term changeover, cut over, or go live. The changeover can be a substantial challenge depending on the complexity of the environment. A comprehensive migration plan is required in order to be successful. It is imperative that risk management is used to select and sequence changeover plans.

You need to be aware of the following changeover techniques:

This is the last review meeting, and it is concerned with the implementation of a new system. The chairperson opens the meeting with the project sponsor present. The project manager makes a presentation of project updates and achievements. Progress is reported against the plan objectives. Attention then focuses on a review of outstanding engineering issues, system performance as realized in production use, and ongoing service and support plans. The final risk analysis is presented for management approval. After approval is obtained, the system is authorized for production use.

The system should be installed and fully operational by the Implementation phase. Support documentation must be in place prior to the system entering production use. All of the appropriate personnel will have been trained to fulfill their roles. The system has completed a final user acceptance test. A production operating schedule should now be in use. The completed system will have undergone a technical certification process. Management reviews the system's fitness of use for a particular task or environment. Management accredits the system for a specified use, based on fitness of use for a particular task or by site location.

You need to verify that appropriate quality control procedures have been executed in support of these objectives. You also need to verify that formal management approval was obtained before the system entered production use. Any deficiencies in management approval should be reported to the audit committee or project oversight.

Periodic reviews are necessary to verify that the system is maintained in a manner that supports the original objectives and controls. The review should occur at least annually or following a significant change in the business, regulatory climate, or application itself. You may need to utilize the services of a professional expert to conduct the postimplementation review.

As an auditor, you review evidence indicating that the system objective and requirements were achieved. You should pay attention to users' overall satisfaction with the system. You should review evidence indicating that a diligent process of support and maintenance is in use. In this phase, you review system audit logs and compare them to operational reports.

Auditors want to know whether support personnel are actively monitoring for error conditions. A process of incident response and change control should be in use. Management must demonstrate that they are aware of system limitations with regard to the changing requirements of the organization. Management needs to be cognizant of any deficiencies requiring remediation.

In addition, management and the audit committee should remain aware of any external issues that may dictate system modification or removing the application from service. Examples include changes in regulatory law governing minimum acceptable internal controls. A perfect example is the current trend for strong data encryption to be implemented to protect the privacy of individuals. Previously the concerns were focused on using encryption during external data transmission. The latest requirement is for data in databases and on backup tapes to be stored in encrypted form. The loss of unencrypted data will soon carry harsh penalties.

Evidence should exist to document the disposal process and the records available about prior disposals. The objective is to determine whether the process was correctly followed. A quick check of the asset tags and financial records will help determine the truth. Look to see whether the disposed asset is still shown to hold value in the accounting records. Is it still on the books? Check their plans to preserve the old data. Did the auditee do a good job? Last of all, the auditor looks for evidence that the media was properly sanitized before disposal.

The first type of database is designed around data in a predefined format, that is, numbers or characters of a particular length. A perfect example is the typical web form or Excel spreadsheet. This DODB the simplest type of database to create.

For this example, we would like to start with a simple database for client entertainment. Say that you have a few key clients to entertain. Your firm wants to ensure that you build rapport by inviting the client to join you in their favorite activities whenever possible.

The first step is to define the data to be recorded in the database. In the SDLC model, this would be part of phase 2, the Requirements Definition phase. Follow along by using Figure 5.14 as we explain the key points.

Let's start by defining a database table of rows and columns to hold the clients' contact information. The first table is named client_table. This will hold the name, address, phone number, and email address of every client.

Next, build a table for each location where you may take the client to be entertained. This is called locations_table. We have added a space to record the average price for this location and a space to record the specialty of the house.

A third table is created to keep track of all of the favorites: favorites_table could be used to record favorite food, a game such as billiards, sporting events, and so forth. One of the objectives in the DODB is to divide information into multiple tables that are relatively static. This allows the system to perform a basic search very fast and not have to process all the data at once. The standardization and removal of duplicates is referred to as database normalization.

Now you have your tables ready to store information. The next step is to link tables together with a referential link or relation. This is where the term relational enters into the description of the database: An item of data in one table relates to data contained in a separate table. Every entry in the database must have at least one required item to show that the entry actually exists. For example, an account number or a person's name would be required for each entry in the database, even if you don't have all the information. This single required entry is referred to as the primary key. Data items used to link to tables are referred to as foreign keys. The idea is that other data is foreign to the first table. Data that you can search is called a candidate key to the search. The purpose of using the term key is to illustrate that it would be impossible to unlock the information unless we know what to use as the key.

To be usable, a database must also have referential integrity. This means that data is valid across the linked entries (keys) in two tables. Take a look at Figure 5.15, and you will notice the reference lines drawn between client ID and location ID. This diagram is a primitive ERD.

Figure 5.14. Example of client entertainment database

Figure 5.15. Example database showing data relationships

Another way to view the database is to consider a box of index cards. Each entry is the equivalent of a separate index card. The box of index cards is referred to as the table. A table is made up of rows and columns, like an Excel spreadsheet. Computer programmers may use the term tuple in place of the word row. Figure 5.16 shows the database row, or tuple, as it would appear on index cards.

Figure 5.16. Database row, also known as a tuple

The actual database displays its contents as rows and columns. It is also common to hear the term attribute as a synonym for a database column. Figure 5.17 shows the columns, or attributes, as they would appear on the computer screen.

Figure 5.17. Database columns, also known as attributes

In the illustration, you can see that the ID number is used as a unique identifier (primary key) for each entry. Using a unique ID number allows duplicate names to appear within the database. This is valuable if you have the same company listed with multiple shipping addresses. The unique ID number also permits a name to be updated without any headaches. A common example is to change a maiden name to a married name, or vice versa as the case may be.

In summary, the DODB is designed to be used when the structure and format of your data is well known and predictable. What about data whose structure and format is unpredictable? What about a database that stores documents, graphics, and music files simultaneously? Well, that is the very challenge that led programmers to develop the object-oriented database.

In a data-oriented database, the program procedures and data are separate. An object-oriented database (OODB) is the opposite. In an OODB, the data and program method are combined into an object. Think of programmed objects as tiny little people or animals with their own way of doing things. Each programmed object has its own data for reference and its own method of accomplishing a required task. Figure 5.18 shows the basic internal design of program objects.

Figure 5.18. Concept overview of program objects

The number one advantage of using programmed objects is that you can delegate work to another object without having to know the specific procedure or characteristics in advance. An example is the computer display settings in the Microsoft operating system. Microsoft XP and Office are examples of object-oriented programs. When Microsoft Word was written, for example, the program did not need to know the details of the display screen. The Word program would simply delegate screen output to an object specified by the screen display setting. A configuration file would exist that contains the setting SET DISPLAY=vendors_device_driver. The hardware manufacturer for the display would write an object or driver to paint the image on the screen. The whole object-oriented design lends a great deal of flexibility for modular change.

Object-oriented programming is extremely powerful, and the functional design can be confusing to a novice. Objects are grouped together in an object class. An object class is quite similar to a particular class of economy automobiles or class of luxury automobiles, for example. The reference to class indicates the object's position in the hierarchy of the universe. Figure 5.19 shows an example of object classes.

Figure 5.19. Example of object classes