Chapter 3. The Information Systems Audit Program
Solutions in this chapter:
▪ Audit Checklists
▪ Testing your Organization's Security
▪ Developing an Audit Manual
▪ Security Management Model
Summary
Introduction
Audit Checklists
One of the best sources of material that can be used to create an audit checklist from industry standards is an organization such as the Center for Internet Security (www.cisecurity.org), which maintain consensus documents that may be used to create your checklist. The standards provide a list of controls that may be listed in your checklist for you to verify. The purpose of the checklist is to gain metrics associated with compliance and security. This is achieved by measuring conformance against the standard.
The additional benefit of the standard is that it provides a source of referencing for the report. No matter how technical you are, it is unlikely that system administrators will trust your judgment as an auditor. By being able to match best practice controls from a standard with those implemented by the organization you are not relying on your own judgment alone but that of the community.
In some cases, the standard itself may become the basis of the checklist. In the event that you are auditing against a standard the simplest way to create the checklist is to use the standard itself. The secret of a good audit process comes down to being able to create and implement an effective checklist.
When creating a checklist of things to include, consider creating a statement of purpose. This may then act as the scope of the checklist. Using industry standards also allows the checklist to act as a best practice guide for the organization and will help in deciding what needs to be checked and measured. Many of the problems associated with checklists are directly derived from the lack of an effective scope. Many times the checklist is also too vague. It is important to have enough detail in the checklist to ensure that a nontechnical auditor or junior staff member can follow the process.
The inclusion of processes to check controls needs to have industry references cited. The importance of this comes from both the need for a non-technical person to be able to support their process and also so that technical staff such as system administrators can research the proposed checks and ensure that they are compatible with their systems.
The checklist needs to be able to support the policy statements. All of the checklist line items should be able to be matched back to a policy or process that is being reviewed or audited. Each checklist line item should also be supported with a reference. This is the benefit of pre-existing checklists and standards such as those from DISA, NIST, and CIS. By linking best practice research and references it is more likely that the controls determined to be checked through the checklist will be implemented.
Consequently, the first stage of creating a checklist involves research. It is important that you understand the system as it relates to the organization in order to audit or review it. In this way you can focus on best practice rather than pushing security. As strange as it seems it is more likely that you will be able to implement best practice processes for governance and security controls even though the same outcome is achieved. Ensure that you list all of your references in the checklist. Try not taking credit for the creation of the checklist and demonstrating that it is based on industry best practices, as this approach is more likely to achieve the desired results of securing a system.
The other benefit of this methodology is that the research will align the audit process across the individual goals of your organization. This makes the entire process less subjective and will allow the technical staff in the audit team to work together. If done properly, the auditor should be seen as helping the organization and not working against it. In this case it is the checklist that is at fault and not the auditor.
To be effective, a checklist should include a statement of scope. This is a register of what needs to be verified. It may be of use to include why these checks have been included as well. Next the document needs to include the processes that will be used to measure compliance and any specific metrics. This is the how of the checklist. Remember, the checklist needs to be detailed sufficiently for a non-technical person from another organization to be able to rerun the test and gain the same results.
This means that we need to detail the “How” effectively. Rely on industry best practice. As mentioned, sources such as the Center for Internet Security (http://www.cisecurity.org), US Defense Information Systems Agency (DISA, http://www.disa.mil), and National Institute of Standards and Technology (NIST, http://www.nist.gov) have already prepared best practice documents that will take you through the process step by step. Many of the major applications and operating systems have detailed checklists and audit guidelines that have already been created. This makes the process of creating your own organizational checklist procedure simple. Processes and procedures have been created and aligned with a number of audit frameworks such as ISO 17799/27001, COBIT, ITOL, FISCAM, CONNECT, and many others.
Baselines
Simply put, a baseline is the measurement of a system in a known good state. Baseline provides a means of determining what has changed on the system. This change may be used either to verify that an incident has occurred, or to otherwise test or validate changes on a system. Baseline auditing is one of the most effective auditing tools and methodologies and is perhaps one of the simplest audits to perform.
The baseline provides a snapshot of system's state at a point in time. Consequently this may be used to document or describe the existing configuration of a system. It is essential to ensure that the system is in a known good state when taking the baseline initially. Otherwise, you could be measuring in a manner that ensures a system is and remains compromised or insecure.
Baselines should be taken against computer systems. Baseline can also be taken against network traffic, system performance, log growth, or about anything else you can think of. One example of a baseline would be to take an integrity snapshot of the system using a tool such as Tripwire to create a database of hashes associated with the system. In this way, even if the system is compromised with rootkit it may be possible to recover as all changed files will be easily determinable.
Baselines and Automation
One of the best benefits of baseline auditing is that it can be automated in many cases. For this to work, we need to know that a system was in a good state to start with. So it is still essential to ensure the integrity and security of the system before making the baseline. Once we have ensured the start state of the system it then becomes simple to maintain the system in this known good state. Even with patching and updates to the system the change process would involve a quick verification of the baseline, the implementation of the update or patch, and the capture of a new baseline image.
In this way baseline imaging helps us not only to create security controls but also aids with change management. Baseline audit becomes most effective when automated. A snapshot is taken of the system and then compared on a periodic basis. Any unauthorized change should be treated as an incident. On the other hand, a time when no change has occurred is good. This was the basis or foundation of tools such as Tripwire and AIDES.
Think about the different areas you can baseline. Think outside the box and include as many processes and metrics as you can. Looking at traffic profiles and mapping, for instance, the connection between hosts and SMTP ports on servers may provide a simple early warning system for worms or other attacks.
Our goal with baseline auditing is to measure unauthorized or unexpected changes in the system state and any statistically significant changes in the behavior of systems we have baselined. Remember, by system we are not necessarily referring to a computer or host. Looking at how well the system conforms to corporate policy may also be achieved through a baseline strategy.
Subsequent chapters will cover a number of tools and processes that may be used in the creation and maintenance of system baselines.
Assurance
This section provides guidelines for all staff involved in carrying out audit/review work. It has been written for people with a limited understanding of the security audit environment to perform most of the tasks required with minimum supervision. It does however require that the person undertaking a technical task have knowledge of the operating environment that they are working in.
The idea behind this section of the book is to allow any one area of the organization to be reviewed; therefore you may find instructions to gather certain information appear in more than one section. If you are performing a review of more than one component of your organization's infrastructure use your judgment and don't gather the same information twice!
Testing Your Organization's Security
In this section, we'll discuss what you need to do to test your organization's security.
Objectivity
Objectivity is an independent mental attitude that you should maintain in performing audits or reviews. Objectivity requires you to perform in such a manner that you have an honest belief in your work product and that no significant quality compromises are made.
Standards and Ethics
When auditing you have an obligation to exercise honesty, objectivity, and diligence in the performance of your duties and responsibilities.
You must:
▪ Exhibit loyalty in all matters pertaining to the affairs of the organization or to whomever you may be rendering a service. However, you will not knowingly be a part of any illegal or improper activity.
▪ Not accept a fee or gift from an employee, a client, a customer, or a business associate of any sections of the organization which are being audited without the knowledge and consent of senior management.
▪ Be prudent in the use of information acquired in the course of your duties. You shall not use confidential information for any personal gain or in a manner that would be detrimental to the welfare of the organization or its employees.
▪ When expressing an opinion, use all reasonable care to obtain sufficient factual evidence to warrant such expression. In your reporting, you shall reveal such material facts known to you, which, if not revealed, could either distort the report of the results of operations under review or conceal unlawful practice.
Protection Testing, Internet Security Assessments, and Ethical Attacks
Protecting information or an Internet Security Assessment is as important as protecting your company's valuable assets. The complexities of today's network security problems and rapid pace of technology create additional information security management challenges.
An Internet Assessment is designed to test the design and implementation of security solutions using protocol filters, firewalls, proxy servers, and encryption or user authentication depending on your environment.
In today's world, more and more businesses are turning to the Internet and its related technologies to support their business applications. As a result of this increase in the use of the Internet, in both the public and private sector and in business and private life, there is a dramatic increase in computer crime. To put it in terms we have heard over and over again, the “hackers” are out there and they are becoming more brazen with each attack. These people are hacking for money and for the challenge of the deed. It is not just huge conglomerates that are being affected today.
It is also the smaller businesses, and it is these very businesses that have the most to lose. I was recently speaking to a chef who had paid a fair sum of money to have a Web site built and his first day on the Internet he was hacked and his site was destroyed. There is no way to estimate the amount of money he lost on business let alone the cost to rebuild his Web site. He had stored many of his recipes on the site meaning that there is also an unknown loss from IP (Intellectual Property) associated with the copied menu items.
Protection Testing or Internet Assessments
Over the last several years, computing has changed to an almost purely networked environment, but the technical aspects of information protection have not kept up. As a result, the success of information security programs has increasingly become a function of our ability to make prudent management decisions about organizational activities. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.
Why People Do Protection Testing
If you have to ask, you're not secure. To explain: You don't get computer security by accident. In fact, you can just barely get it if you work really hard at it. And if by some accidental miracle or magic, you were secure today, you would not be secure tomorrow, because things change.
I have heard many people talk about strong advocates of security as being paranoid. In fact, many people rate how seriously somebody takes information protection by saying that they are more or less paranoid. While the term may seem appropriate for anyone who would worry about somebody guessing a password and bringing down the entire corporate network, if guessing a single password would do this (there are several major corporations where this was the case) it is not paranoia. Paranoia is irrational fear. A serious concern about such weak protection is not irrational and is not fear.
Penetration Testing or Ethical Attacks Vs Protection Testing
Penetration testing is reactive; this could be problematic, as it does not uncover all vulnerable systems and does not mitigate risk in the manner that is expected. There are alternatives.
▪ Penetration testing is an effort to penetrate a system in order to demonstrate that protection has weaknesses.
▪ Protection testing is a way to confirm or refute, through empirical evidence, that controls are functioning as they should be.
The difference is quite bleak when you consider it. For instance, it is feasible that penetration testing will succeed at detecting a vulnerability even though controls are functioning as they should be. Likewise, it is extremely common for penetration testing to fail to detect a vulnerability whilst controls are not operating at all as they should be.
The objective of a controls assessment should be to gain an understanding and knowledge of the all entry points to the network. This is than measured against known vulnerabilities against each connection type (e.g. radio scanners or line tapping) and any system specific weaknesses. A vulnerabilities matrix can be developed from this information relating to chances of attack, severity of the attack and expected uptime, or availability given the system, platform, and susceptibility to attack (including Denial of Services). A detailed report on all connections can be developed from this information and maintained for future reference.
Miscellaneous Tests
Server Operating System Security Analysis
The Servers that are being protected by a firewall are often vulnerable to attack even with a firewall. One example of this would be a Windows-based RAS server that had been left in an unpatched state or was set up without enhanced security. An attacker, to gain unauthorized access to a site, could use these misconfigured and likely unknown phone lines. Another example is HTTPS. This service is passed via an encrypted tunnel through the Firewall. This means it bypasses any security considerations on the Firewall systems and is patched directly to the Web server.
Phone Line Scanning
Phone Line Scanning identifies unauthorized and undocumented modems connecting client computers directly to the external telephone network. These phone lines and modems are important because they may represent security holes in the organization's security perimeter.
Large organizations employ hundreds of dial-up lines for voice communication with customers, suppliers, and employees. As corporations computerize more of their activities, external phone lines and modems are used with increasing frequency to link internal computers with external computing resources.
These external phone links, while useful, often represent an undocumented back door into the corporate information network.
The objective here is to gain an understanding and knowledge of all entry points to the network. This would then be measured against known vulnerabilities of each connection type (e.g. radio scanners or line tapping) and any system specific weaknesses. A vulnerabilities matrix is developed from this information relating to chances of attack, severity of the attack and expected uptime, or availability given the system, platform, and susceptibility to attack (including Denial of Services). Phone line audits are more commonly known as War Dialing.
Phone / War dialing Audit Project Tasks
In order to determine vulnerabilities associated with modems and phone lines generally it is essential to:
▪ Review of all POTS and ISDN lines (Including PABX)
▪ Perform modem scans and sweeping
This will involve dialing each of the telephone numbers owned by the organization in order to determine whether a modem answers, and if so whether there is a computer behind it. Some telephone numbers will be for lines connected to a fax, either computer generated or a physical fax machine. However, finding these fax systems is not generally the aim of this type of review.
Telephone lines which have authorized modems, which are known will answer but you are confident are secure (i.e. those used for remote staff access going through TACACS+ or RADIUS for token authentication) should be culled from the list of telephone numbers to be provided by the client for this process to be performed upon. Testing systems in an unknown authorized state could be conducted as a separate exercise. This would involve potentially testing authentication and authorization processes.
Social Engineering
Social Engineering is the acquisition of sensitive information or inappropriate access privileges by an outsider, based upon the building of inappropriate trust relationships with insiders. Attackers use this approach to attempt to gain confidential information, such as organizational charts, phone numbers, operational procedures, or passwords in order to evaluate the organization's vulnerability to social engineering attacks.
Social Engineering is the term for cracking techniques that rely on weaknesses inwetware rather than software; the aim is to trick people into revealing passwords or other information that compromises a targetsystem's security. Classic scams include phoning up an employee with the required information and posing as a field service technician or a fellow employee with an urgent access problem. Acting as a salesperson or manager is also frequently utilized.
Social engineering can be defined as misrepresentation of oneself in a verbal manner to another person in order to obtain knowledge that is otherwise unattainable.
Social engineering, from a narrow point of view, is basically phone scams which pit your knowledge and wits against another human. This technique is used for a lot of things, such as gaining passwords, keycards, and basic information on a system or organization.
Generally this is done in conjunction with other reviews, and is designed to ensure that an organization's employees have an adequate awareness of security and the related issues.
Use the following methods to check the awareness levels within your organization:
▪ Phone
▪ Mail
▪ Internet
▪ Live visits
There is only one effective means of reducing social engineering vulnerabilities—awareness training. Social engineering testing can be an effective means of measuring compliance to and the effectiveness of this training.
BCP/DR Testing: Disaster Readiness Assessment
The purpose of Business Continuity Planning (BCP) testing is to achieve organizational acceptance that the business continuity solution satisfies the organizational recovery requirements. Plans may fail to meet expectations due to insufficient or inaccurate recovery requirements, solution design flaws, or solution implementation errors. To this end, testing should include:
▪ Crisis command team call-out testing
▪ Technical swing test from primary to secondary work locations
▪ Technical swing test from secondary to primary work locations
▪ Application test
▪ Business process test
Audit staff need to periodically and regularly conduct in-depth, end-to-end reviews of all critical business applications including:
▪ the application's architecture, design and function;
▪ its development and maintenance processes;
▪ its operational processes and technology components including the platform it runs on;
▪ the networking services used; and
▪ any data base or operating platforms services used.
The auditors then conduct interviews with key managers and staff members responsible for the development, maintenance, deployment, and operations related to the application. Processes and technology are reviewed to ensure that key application failure and survivability dependencies are met and the supporting infrastructure services need to be reviewed for common errors that can compromise the continued operation of the production environment.
What Is Covered in a BCP/DR Review?
The following points detail the primary stages and testing requirements when conducting a review of business continuity planning and disaster recovery.
1 Functional requirements phase
a Business process analysis—practical exercise (verifying the business process)
b Risk analysis and management—practical exercise (testing of the risk register)
c Business Impact Analysis—practical exercise (conducting BIA for the business process)
d Testing survival strategy—practical exercise (testing of Minimal Acceptable Recovery Configuration)
2 Plan design test phase
a Testing emergency management structure
b A test of the main plan components
3 Plan development phase
a Assessment of the written procedures (including any worksheets of preparatory and recovery actions)
b Interviews with the Emergency Management Team
c Emergency and recovery procedures testing
d Evaluation of the Contracts with critical suppliers
4 Assessment of the Business Continuity Plan testing phase
a Plan testing—presentation of different types of tests, test scenario development, test preparation
b Assessment of Internal Test evaluation—documenting test results, development of findings and recommendations, plan maintenance based on test results
5 Assessment of the Plan maintenance phase
a Software tools
b Plan maintenance evaluation criteria
c Plan distribution and security
6 Assessment of the Execution phase
a Disaster declaration
b Plan activation
7 Return to normal operation
What Does BCP Cover?
BCP consists of 10 main disciplines:
2 Risk analysis and management
3 Business Impact Analysis
4 Survival Strategy development
5 Incident Management
6 Plan development and implementation
7 Training and employee awareness program
8 Plan maintenance and testing
9 Public Relations and crisis communication
10 Coordination with public services and supervisory institutions
The auditor needs to evaluate and report on the BCP process covering all 10 of the above listed areas.
Developing an Audit Manual
To develop an audit manual, you need to understand the topics discussed in this section.
Preliminary Survey
Sufficient background information must be obtained about the organization's or business group's customers' activities before an effective program can be prepared. This is usually done through a preliminary survey in which as much information as is practicable and useful is gathered. Most of this information is obtained orally from responsible officials within the organization. It focuses on the size and scope of activities, operating practices, and internal controls. Some concurrent tests may be made during the survey phase, usually to evaluate assertions regarding operating practices.
The preliminary survey usually identifies matters warranting in-depth attention. These may include areas in which there may be weaknesses in internal controls, inefficient operations, or lack of compliance with internal policies, state laws, and regulations.
At this point you are prepared to write a program that will focus on matters that are potentially hazardous, plus any others of special interest. These specific objectives represent the framework around which a fabric of procedures is woven.
Criteria for Defining Procedures
A program should conform to certain criteria if it is to meet the overall objectives of the review.
Each work step should show the reason behind it; i.e., the objective of the operation and the controls to be tested.
Work steps should include positive instructions. They should not be stated in the form of questions.
A program should be flexible and permit the use of sound judgment for deviating from prescribed procedures or extending the work done, but the management should be informed of major deviation.
A program should not be cluttered with material from sources readily available to staff. Incorporating by reference is preferable.
Unnecessary information should be avoided. Include only what is needed to perform the audit work.
The Program
Much of the information generated at this point will also serve as the introduction to the final report to the customer and should generally include the following information:
▪ Introduction and background Information should be provided about the business group, customers, organization, activity, or function; its history and current objectives; its principal locations; and similar information needed to understand and carry out the program.
▪ Purpose and scope of the report The purpose of the report should be identified, and information should be provided as to what is included and, if specifically noted, what is excluded.
▪ Objectives of the project The special goals of the review should be clearly stated.
▪ Definition of terms Any unique terms or abbreviations used by the audited entity should be defined or explained.
▪ Procedures For most reviews, it is necessary to prescribe the procedures that will be followed. However, this should be done in a manner that does not restrict your professional judgment. The procedure lists should never be used as a blind checklist in a way that lessens initiative and thoroughness.
When to Prepare the Program
The well-tailored program should not be delayed. It should be prepared immediately after the preliminary survey. At that point the review that is to follow must be structured and given form. It is just as unreasonable to delay preparing the program until later in the review as it is for a navigator to first look at charts well into the voyage.
Immediately after the on-site survey, when the objectives of the operation are fresh in mind and any prior review information has been reviewed, the audit program should be carefully developed. This form of planning requires unhurried thought, so that nothing of significance is omitted. Programs prepared too late may turn out to be marred by gaps and inadequacies and may fail to give priority to significant subjects.
The Final Report
The report should:
▪ Present factual data accurately, completely, and fairly. Include only information, findings, and conclusions that are adequately supported by sufficient evidence.
▪ Present findings and conclusions in a convincing manner.
▪ Be written in language as clear and simple as the subject matter permits.
▪ Be concise but at the same time clear enough to be understood by users.
▪ Place primary emphasis on improvement rather than on criticism. Critical comments should be presented in a balanced perspective considering any unusual difficulties or circumstances faced by the operating staff concerned.
Report Standards
In most cases the final report will consist of the following sections.
The Cover Page
This shows the customer, report title, release version number, and issue date of the report.
Table of Contents
The table of contents is a listing of the subjects and appendixes that are in the report and indicates the page numbers on which they appear. Generally, a table of contents should be used only in reports of ten or more pages.
Summary of Changes
This section should be kept up to date at all times; it details all changes to the document and new release numbers.
Introduction
This portion of the report should identify the organization, Program, activity, or function examined and why the review was performed. The scope of the review should be detailed in this section.
It is important to anyone reading the report to know the boundaries of coverage clearly at the outset. This first contact with the reader should be carefully worded to establish the exact intent; otherwise the remainder of the report may be adversely affected as to its acceptability.
Background of a more comprehensive nature can be provided if the author believes that readers outside the immediate area would otherwise not be able to visualize the operations and understand the findings.
Background information generally includes comments on the nature, purpose, size, and organization of the reviewed department, system, function, or activity.
Executive Summary
This section of the document is very important; it needs to be able to convey the entire content of the report in a maximum of two pages, no matter what the size of the final report may be. It must allow non-technical management to comprehend the scope, issues, and recommendations with a minimum of technical knowledge.
The Body of the Report
The actual body of the report will consist of all or some of the following sections:
▪ Security Policy and Documentation This section provides a review of all client documentation and diagrams.
▪ Security Architecture and Design This section provides a review of the security of the design of the network.
▪ Physical Security This is a review of all physical security, such as access, cameras, backups, media disposal, etc.
▪ Network Security This itemizes the infrastructure devices and any security issues related to them.
▪ Host Security All tested hosts are covered here, whether they are servers or workstations.
Summary of Recommendations
This section summarizes all of the issues raised in the previous sections and prioritizes them.
Appendices
The last part of the report contains the appendices. These appendices are separated from the preceding parts of the report by an otherwise blank page with the caption APPENDICES centered thereon. Each appendix is so identified, in alphabetical order (appendix A, appendix B, etc.).
The purpose of an appendix is to provide further details, explanations, or support for comments included earlier in the report.
For many reports the only material included as an appendix is the glossary of terms used within the document.
Examples of other items that may be included in an appendix are:
▪ Output from programs
▪ Bibliography of quoted texts
▪ Cross references to WWW sites and documents
▪ Network diagrams
▪ Technical related texts (RFCs etc)
Security Management Model
An effective Security Management Model can be constructed from the guidelines developed by the International Standards Organizations, the U.S. Department of Defense, and the European ITSEC committee. This model may be used to produce security procedures that are in full compliance with the various standards of information governance and security that an organization is likely to face.
Figure 3.1, which is taken from the U.S. Department of Defense, lists a cyclic process that may be used to create a security process life cycle.
 |
| Figure 3.1 U.S. Department of Defense Security Process Life Cycle |
The stages of this framework are:
2 Create a security management framework designed to implement the policy
3 Assess the security risks and classify those risks
4 Implement security standards within the organization
5 Configure technical solutions
6 Develop business continuity plans aligned with the security processes and framework
7 Educate staff and develop awareness of security issues and risk
8 Ensure compliance to the framework and measure both compliance and shortcomings
9 Use the information obtained through the audit to update and realign security policies
The process is continuous. Each phase should feedback information from the previous phase and allow a process of continuous improvement.
Summary
The amount and type of information requested might appear onerous to many people not familiar with systems operation in high-threat environments, but rest assured, it should be the minimum you have for your system.
Without access to this information, an adequate assessment cannot be made of whether or not your system adequately provides you the levels you require of:
▪ Confidentiality
▪ Integrity
▪ Availability
Without being able to inspect this documentation, you won't be able to conduct a worthwhile audit, review, or test in a financially realistic time frame and produce verifiable results. It is in all of our best interests to ensure that we know our organizations well.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.