1 EXECUTIVE SUMMARY *

2 MISST&E PROCESS DESCRIPTION *

3 SUMMARY RESULTS *

4 CONCLUSION *

APPENDIX A Letter Agreement *

APPENDIX B Terms Of Reference / SRTM *

APPENDIX C RFA Draft Final Report *

APPENDIX D RFE/RL Final Report *

APPENDIX E SAMPLE Penetration Test Plan Document *

Figure 1 Distribution of SRTM Criteria *

Table 1 SRTM Numeric Data Summary *

1. EXECUTIVE SUMMARY

In September 2002, Radio Free Asia (RFA) and Radio Free Europe / Radio Liberty (RFE/RL) agreed to participate in a Mutual Information System Security Test and Evaluation (MISST&E) process. The MISST&E involved penetration testing by information security personnel within RFE and RFE/RL. This document, which includes recommendations, outcomes and appendices, is the final report on this activity.

The MISST&E process was proposed and accepted as methodology to determine system risks and vulnerabilities with the additional goals of:

1. COST-EFFECTIVENESS: Cost savings related to the unnecessary requirement to import maintain personnel and equipment from outside the European continent for an extended period to conduct testing and analyses.
2. SECURITY AWARENESS TRAINING AND EDUCATION: The MISST&E process was designed to allow agency security personnel to develop a deeper understanding of defensive measures to system attacks by employing actual attack techniques to thoroughly comprehend attack types, methodologies, technologies and consequences.
3. LONG TERM IMPACT: The long-term effect of the MISST&E is to establish and develop a cadre of security personnel within each agency with specialized knowledge, skill, aptitudes, and experience in detection, recognition, and response to attacks through specific knowledge of attack parameters.

These additional benefits did not constrain the most important short-term goal, which remained the assessment of threats and vulnerabilities as risks.

1. POSITIVE RESULTS

The positive effect of presentation of this MISST&E testing process was the development of heightened security awareness. In development of the Agreement between the agencies, the respective staff and CIO immediately became aware of obvious needs for improvement in information security function.

• Preparation of the MISST&E created a positive and cooperative atmosphere of information security awareness, prompted purchase and installation of the ThreatSmart^SM Internet Threat Monitor (T-ITM) by RFE/RL. RFA had previously purchased T-ITMT-ITM, which remained operational and maintained a reporting capability. A description of this hardware and security service is described in the APPENDIX E.
• Both teams found the obvious vulnerabilities in each other's File Transfer Protocol (FTP) servers that any broadcast organization requires for anonymous filing of stories. Risk Acceptance of these servers needs to be established.

1. Insufficient Results and Analysis

Although a modicum of testing was conducted by the agencies, this testing was too elementary and superficial to and an assessment of vulnerabilities and threats cannot be the basis of analysis in a requirements driven context. There are several possible factors to be considered that may have contributed to this outcome:

• Traditionally, information security personnel are trained and experienced in response to attacks and attempted attacks. The actual employment of attack methodologies represents a new and unknown area for these individuals, and engagement in this exercise represents additional time for learning and penetration testing in addition to normal and routine responsibilities.
• Participation in this exercise requires each agency to assign appropriate personnel, create sufficient time for task achievement, and ensure exercise participation through a compulsory process.
• Each agency team must be strongly motivated to participate in the attack exercise. System administrators are more accustomed to the defensive position than the offensive, and minimal agency education may be required to demonstrate and emphasize the overall defensive security benefits in fully comprehending the attack process.
• The Agreement, as drafted, did not require specific deliverables and time constraints. This did not motivate engagement in the testing through deadline compliance.

1. Recommendations

The assessment team recommends that follow-up MISST&E penetration testing program be developed to complete vulnerability determinations, and with these additional terms, conditions, and mutually acceptable requirements:

1. Amended agreement between the agencies to establish deliverables within established time frames.
2. Commitment by the agencies to monitor and demand timely completion of deliverables.
3. Review and approval of this methodology by the cognizant and designated approving authorities (e.g. State Department Inspector General).
4. Participation by the agencies in establishing appropriate and realistic time frames considering normal duties and responsibilities of involved personnel.
5. Minimal training of information security personnel relating to the benefits of participation in aggressive penetration techniques.
6. Appropriate and timely evaluation and assistance by external subject matter specialists as required to meet designated deliverables.

1. MISST&E PROCESS DESCRIPTION

 

The origin of the MISST&E process is based upon a proposed method first described in an article, Media Convergence Info Warfare, in the trade journal Radio World (November 2000 page 19). This article germinated discussion with David Baden and expanded into subsequent discussions at the National Association of Broadcasters Convention (NAB 2000), the Mutual Information System Security Test and Evaluation (MISST&E) methodology has thus been developed as broadcast industry based method of penetration testing where the following goals are accomplished:

Organizations, within a related field or business purpose, test each other’s data systems for security weaknesses.

RFA and RFE/RL have similar goals, objectives and security concerns. In establishing two teams from commonly structured organizations, each team is composed of information security personnel possessing similar backgrounds, experience and training. The objective of this goal is not to produce a group of random ‘hackers’; rather, to enhance the understanding of personnel in each organization relating to types, methods and possible consequences of future attacks upon their own respective systems. With this knowledge, intruder response becomes more relevant and more timely to actual or attempted attacks, thereby optimizing defensive control

Network Security and Administrative personnel in each case gain valuable experience in what tools and techniques are available to breach the prevailing Security Architecture.

Tools and techniques used to attack RFA and RFE/RL are expected to be similar because the results sought by an intruder will be similar. The valuable experience to be gained by information security personnel is the hands-on knowledge of the methodologies to be reasonably expected in the future from the perspective of both aggressor and defender.

Each organization in preparation, testing and reviews, strengthens the defensive posture of their Networked Automated Information Systems.

The acts of preparation, testing and analysis of results develop a deeper appreciation of potential vulnerabilities by information security personnel in both RFA and RFE/RL. The objective of this goal is to establish the necessary nexus between penetration events and the security guidelines of the attached SRTM, and the interrelation between them in creating the most secure information protection of confidentiality, integrity and availability.

 

1. MISST&E Process Goals

• Mutual Requirements Based Testing

• Accurate Penetration Testing of both Networked Automated Information Systems

1. MISST&E Process Implementation

• Local Control of testing process with no outside intervention
• Independent external system monitoring and reporting by a neutral third party.
• Testing Based upon specific Security Requirements

1. Security Requirements Traceability Matrix

The Assessment Team developed a Security Requirements Traceability Matrix (SRTM) against which the testing was constrained. This matrix includes all relevant federal laws, regulations and guidelines, which either mandate, direct or recommend information assurance policies and procedures to protect the confidentiality, integrity and availability of information technology (IT) resources within a federal agency system. The SRTM has been scored as completely as possible using data from observation and team experience, as well a data from the limited testing conducted by the agencies. The Scoring system is comprised of the following four categories:

1. M-Met Requirement
2. PM Partially Meg Requirement
3. NM-Not Met Requirement
4. NA - Non Applicable Requirement
5. NT - Non Tested Requirement

The SRTM used in the risk assessment phase of this project is separated into two distinct tabular formats: Security Requirements and Security Considerations:

• Security Requirements addresses those information assurance issues that are required by federal law and regulation, and are mandatory for all federal agencies. This section includes:
1. Source Document: Specifically sets forth the federal act, law, executive decision or federal directive.
2. Paragraph Reference: Identifies the particular section or paragraph in the Source Document from which a requirement flows.
3. Title: The general category of policy or procedure addressed in the Paragraph Reference.
4. Stated Requirement: A synopsis of the actual requirement addressed.
5. Rating: Determination by the Assessment Team concerning compliance the particular security requirement.
6. Comments and Observations: Notations by the Assessment Team relating to compliance with the particular security requirement.

 

• Security Considerations addresses those information assurance issues that are recommended by NIST and the FISCAM. The NIST Special Publications, although not mandatory in and of themselves, are referred to by OMB A-130 and by GISRA, which, in essence, is a codification of OMB A-130. It must also be noted that the E-Government Act of 2000 charges the Secretary of Commerce with requiring that NIST recommendations be incorporated in federal security requirements. This section of the SRTM includes:

1. Source Document: NIST or FISCAM security recommendations.
2. Stated Requirement/Consideration: A synopsis of the recommendation found in the Source Document.
3. Rating: Determination by the Assessment Team concerning compliance with the particular recommendation stated.
4. Comments and Observations: Notations by the Assessment Team relating to compliance with the particular security recommendation.

Requirements that are beyond the scope of this assessment, not applicable to the project, or undetermined through limited testing may be rated as N/A or UNK, with an explanation placed in the Comments and Observations column. Items that remain untested after the completion of the test period are rated Not Tested (NT) without further comment.

1. Numeric Results

The Two Charts Below Summarize the SRTM results:

Figure 1 Distribution of SRTM Criteria

The Charts below quantitatively summarizes the SRTM based test data:

Table 1 SRTM Numeric Data Summary

Our initial conclusion based upon this data is that due to the large number of Non Tested (NT) requirements is to discount a numerical scoring method as inconclusive. Future testing should not be prejudiced by this result, rather re-evaluation of the requirements and scoring are a reasonable remedial action.

1. SUMMARY RESULTS

The positive results of this exercise are detailed in the Table below:

 

Table 2 Results of the MISST&E

Positive Result	RFE/RL	RFA	Comment
Was Prime Directive Followed?	No Negative Side Effects of testing to broadcast operations	No Negative Side Effects of testing to broadcast operations	No operational errors or deficiencies were reported by either side during the test period.
Off site attacks of external ISP maintained Web sites	No miss targeting reported. Internal web sites probed	No miss targeting reported. Probed Internal web sites	Both organizations maintain web sites controlled by external ISPs and internal sites.
Benefits of Preparation for Attach	Installation of Security Monitoring Equipment	Maintenance of Security Monitoring Equipment	Monitoring system
Created Staff Awareness of and for Information Assurance and Security	Validation of switch design and MAC lockdown methodology	Validation of in house monitoring operation, DMZ and Coyote LRP security method.
Investigation of offensive tools	TBA	Tools exercised and studied during attack phase included: nmap, nessus, nbtscan, fragroute, brutus, nikto, vomit and queso
FTP Vulnerability	Discovered	Discovered	Acceptable Risk in both cases
MISST&E Report Availability	STATE Inspector General, and GISRA process can validate	STATE Inspector General, and GISRA process can validate	Report represents evaluation of security which appears to be within the IA doctrine

 

1. Summary Discussion

In summary, the MISST&E Exercise was successful and of benefit to both organizations, although additional testing is appropriate for a complete risk and vulnerability assessment. Cost-effectiveness is evident in that two distinct systems can be assessed simultaneously with limited funding by either organization for outside information assurance testing personnel, and these expenditures are comparable with the assessment of a single information system.

Specifically, and incorporated in their final report, RFA recognizes the benefits of the MISST&E process, and acknowledges that additional testing with modifications, addressed above, would represent a valuable tool in their information assurance program.

1. Benefit To Both Organizations

• Created Awareness Of And For Security. The MISST&E negotiation and preparation between RFA and RFE/RL established a better understanding of the information technology security issues facing each organization. The SRTM presented a concise compendium of laws, regulations, recommendations and best practices that shall impact upon both organizations as a result of the E-Government Act of 2002, which was signed into law in February 2003. This new act requires the Secretary of Commerce to accept National Institute of Standards and Technology (NIST) guidance, and to mandate application of such guidance to all federal information technology systems.
• Detection of Obvious Security Flaws.

• Level Of Security Improvement.

• Report Availability. Both RFA and RFE/RL will maintain on-site data relating to the findings of the MISST&E report. The SRTM provides sufficient information to complete extensive self-assessments by each organization, and establishes all necessary requirements as the foundation for a Baseline Security Requirements document (BLSR). RFA and RFE/RL now have the tools necessary to detect, mitigate or accept federally recognized risks within each system. Because of the similarities found in the RFA and RFE/RL systems, the organizations are able to consult and confer with each other concerning common and cost-effective best practices in risk mitigation.

• Testing Of Defenses.

1. Direct Benefit To RFA

• Investigation Of Offensive Tools.

1. Direct Benefit To RFE/RL

• Installation Of ITM Equipment. Upon discussions with the assessment team, RFE/RL recognized the immediate need to purchase and install the ITM hardware and service to detect and analyze threats to their information technology system. This act, in itself, demonstrated RFE/RL’s understanding of current information assurance issues, as well as their determination to seek resolution to apparent problems.

1. CONCLUSION

Through the use of the MISST&E we have been able to determine that external penetration of two of the American Government's premier Surrogate Broadcast organizations are not subject to casual attack or successful disruption of their activities through ordinary means. Can it be said that extraordinary concentration or extreme methods are vulnerability for either site? Only subsequent testing can determine an answer. The positive aspects of this test process as summarized in Table I speak to a good beginning but information security is cyclic in implementation. As new staff and threats arrive at both of these institutions, there will remain a need to train and drill them in the proper methods to maintain and enhance information security within their respective organizations and architectures. This first MISST&E has demonstrated a remarkable value in enhancing security and should be considered a success.

 

1. MISST&E Process Improvements In Subsequent Projects

One of the primary objectives of the MISST&E process is education and training of all parties involved in the testing exercises. This Assessment Team also undergoes a learning process each time the MISST&E is engaged between organizations. Observations can be made concerning potential improvements to the process, both internal and external to the participating organizations.

 

Although MISST&E was not fully applied in this project, the project remains successful in that it met goals relating to increased security awareness, demonstrated necessity for additional security hardware and services, and initial understanding of penetration processes by the participating organizations, RFA and RFE/RL. The following considerations are recommended in future testing using this process:

1. Internal Improvements to the Process

• Amended agreements between organizations to establish commitment to the process with interim deliverables.
• Realistic determinations of time frames in which deliverables may be completed, and a compulsory process to enforce deadlines.
• Positive reinforcement for timely completion of tasks by organization information security personnel.
• Equal sharing of expenses for the MISST&E program between participating organizations to establish vested interest in project completion.

1. External Improvements to the Process

• Enhanced initial Assessment Team training for participating personnel.
• Assessment Team monitoring of testing progress with real-time recommendations to each organization for complete and timely satisfaction of deliverables.
• Assessment Team interim reports to participating organizations relating to their penetration testing accomplishments and potential vulnerability determinations.

APPENDIX A Letter Agreement and Photo

On 19 September the following enabling document was signed:

Figure 2 Ratification Of MISST&E Process

APPENDIX B Terms Of Reference / SRTM

LETTER AGREEMENT

This agreement is between the respective Chief Information Officers (CIOs) of Radio Free Asia and Radio Free Europe / Radio Liberty, expressly for the purpose of establishing a Mutual Information Security System Testing and Evaluation (MISST&E) capability. This MISST&E shall begin Friday, November the First (11/1/2002) at Midnight Greenwich Mean Time (GMT) and shall end at Midnight Wednesday, November Twenty Seventh (9/27/2002) two thousand two.

This agreement along with its attachments comprises the entire guideline for this testing and evaluation. Any modification or abrogation of this agreement shall take place upon mutual agreement of the parties undersigned below, documented by written codicil addition to this letter.

The goal of this mutual test and evaluation activity is to accomplish information assurance excellence for both agencies.

The objectives in developing this capability include:

• Cooperative test and evaluation to determine current security posture of stakeholder networked systems;
• Dissemination of network assurance to facilitate cooperative security between all parties;
• Investigation of alternative security architectures;
• Establishment of appropriate information assurance policy and requirements for government and public use and benefit.

The agreed to test constraints and methodologies are included in this agreement as three attachments:

1. Operational Constraints
2. Testing Methodology
3. Security Requirements Trace-ability Matrix

A report of the activities of the MISST&E shall be provided to both parties of this testing upon completion of the test and evaluation.

Signed and agreed to on this twenty-third day of September, two thousand two.

DAVID BADEN KENNETH MOREHOUSE

Chief Information Officer Chief Information Officer

Radio Free Asia Radio Free Europe

________________________________ _________________________________

1. Operational Constraints

This test process explicitly excludes the disruption of program and supporting services of either party. This test and evaluation process will not disrupt the program and program support activities of either party in any way.

Test scenarios shall specifically exclude the following:

1. The public web sites of both parties are under control of contract Information Service Providers not party to this agreement. Security testing of these systems is therefore beyond the scope of the MISST&E.
2. Developed denial of service scenarios may be reported as described under the methodology guidelines below, but will not be implemented under any circumstance.
3. It has been determined by mutual consent that there shall be no physical security (PHYSEC) test and evaluation. While physical security is an important overall component of Information Assurance (IA), both parties agree that resources and circumstances make physical security test scenarios expensive and difficult.

1. Testing Methodology

Testing shall be constrained to documented scenarios that evaluate the requirements as set forth in the attached Security Requirements Trace-ability Matrix (SRTM). The test methodology shall be considered as a two-part process:

1. Develop and perform the test based upon chosen, stated requirements.
2. Summarize test scenario and any results for citation in the MISST&E report.

With respect to the Prime Directive, when a denial of service scenario appears possible, the testers developing the scenario are actively encouraged to:

1. Thoroughly document the scenario,
2. Discuss the test method,
3. Highlight the unfulfilled requirements,
4. Fully disclose contemplated impact, and
5. Submit as a document for citation.

1. security test requirement matrix

The following Security Requirements Trace-ability Matrix (STRM) has been developed from and is traceable to the following specific United Stated Government information security laws, rules, regulations, and other guidance as stated below:

• Computer Security Act of 1987;
• National Institute of Standards and Technology (NIST) Special Publications 800-18 and 800-14;
• Office of Management and Budget (OMB) Circular No. A-130, Appendix III;
• Clinger-Cohen Act Information Technology Management Reform Act of 1996 (Division E of Public Law 104-106);
• Government Information Security Reform Act (GISRA).

Additionally, this and other reference material as documented below has been considered and may be cited within the STRM:

• Each government agency must establish computer security policy commensurate with risk and magnitude of harm resulting from loss, misuse, unauthorized access to or modification of information contained in the system.
• Each government agency must develop security plans for systems that contain sensitive information.
• Summaries of agency security plans must be included in the information resources management plan required by the Paperwork Reduction Act of 1980.
• Each government agency must provide mandatory periodic training for all persons involved in management, use, or operation of computer systems that contain sensitive information.

1. P.L. 104-13, Paperwork Reduction Acts of 1980 and 199, 05/22/1995

The Paperwork Reduction Act, as amended in 1995, is the principal information resources management (IRM) statute for the Federal government. It required OMB to establish government-wide IRM policies and to oversee and review agency implementation. It requires the use of Information Technology (IT) to improve service, program management, increase productivity, enhance quality of decision-making, and reduce fraud and waste. It requires agency development of 5-year plans and the appointment of a senior IRM official. The Act assigned OMB responsibility for improving efficiency through use of new technologies.

The Act directs OMB to develop guidance on information security and to oversee agency practices. It directs agencies to establish computer security programs, and tasks OMB to develop and oversee the implementation of policies, principles, standards and guidelines on security. The act further directs Federal Agencies to apply a risk management process for information collected or maintained. Each agency must implement and enforce applicable policies, procedures, standards and guidelines on privacy, confidentiality, security, disclosures and information sharing.

Consistent with the Computer Security Act of 1987, agencies must identify and afford security protections commensurate with risk and magnitude of harm resulting from loss, misuse, unauthorized access to or modification of information collected or maintained.

2. P.L. 104-106, Information Technology Management Reform Act of 1996, National Defense Authorization Act for Fiscal Year 1996 (later renamed Clinger-Cohen Act), 02/10/1996

The Information Technology Management Reform Act (ITMRA) relieved GSA of responsibility for procurement of automated systems and charged OMB with providing guidance, policy and control of information technology procurement. The ITMRA also requires the appointment of a Chief Information Officer (CIO) and mandates use of business process reengineering and performance measures to ensure effective IT procurement and implementation. The ITMRA also reaffirmed OMB, NIST and agency responsibilities regarding information security

3. P.L. 104-294, Title II, National Infrastructure Protection Act of 1996, 10/11/1996

This act addresses protection of the confidentiality, integrity and availability of data and systems and revises the Computer Fraud and Abuse Act. Unauthorized use of a computer to obtain information that could be used to injure the United States is a felony offense, as is intentional damage to computer. Reckless damage to a computer is a felony if committed by unauthorized individuals; but a misdemeanor offense if the damage were negligent, and not reckless. For authorized personnel, reckless or negligent damage is a misdemeanor offense with understanding that there is a range of additional administrative sanctions that may also be applied.

4. 44 USC 3504, Government Paperwork Elimination Act

This Act requires the Director of OMB to provide direction and oversight in the acquisition of information technologies that provide for electronic submission, maintenance or disclosure of information as a substitute for paper. This Act also directs the acceptance of electronic signatures by executive agencies.

5. P.L. 106-398, National Defense Authorization Act, Fiscal Year 2001 Title X Subtitle G, Government Information Security Reform Act, 10/30/2000

The Security Act (GISRA) amends the Paperwork Reduction Act by enacting new subchapters on information security, and primarily addresses the program management and evaluation aspects of security. Issues addressed include Life Cycle, incident response, agency performance plans, annual agency program reviews, annual Inspector General security evaluations, and required reports to OMB. The OMB is also required to report annually to congress.

6. P.L. 93-579, Privacy Act of 1974, 12/31/1974

The objective of the Privacy Act of 1974 is to protect personal privacy from invasions by Federal agencies. This law allows individuals to specify what information about them may be held by government agencies and gives individuals the right to obtain information held on them. The Act establishes civil and criminal penalties for violations. The act requires agency implementation fo physical security practices, information management practices, and computer and network controls necessary to ensure individual privacy.

7. P.L. 99-474, Computer Fraud and Abuse Act of 1986

This Act provides for fines and imprisonment for individuals who intentionally access a computer without authorization or exceeds authorized access and, by such means, obtains information deemed to require protection against unauthorized disclosure. Criminal and civil sanctions also apply to any individual who accesses a federal interest computer without authorization and alters, damages or destroys information, prevents authorized use of the computer, or traffics any password or similar information.

 

EXECUTIVE ORDERS

8. Executive Office of the President, Executive Order 13010, Critical Infrastructure Protection, The White House, Washington, D.C., 07/15/1996

The purpose of this Order is to develop a strategy for protecting and assuring the continued operation of critical infrastructure, including the continuity of government. It established the Infrastructure Protection Task Force (IPTF) within the Department of Justice and the President’s Commission on Critical Infrastructure Protection. The Order requires all agencies to cooperate with the Commission and the IPTF, provide assistance, information and advice, and share information about threats and warning of attacks and information about actual attacks to the extent permitted by law.

9. Executive Order of the President, Executive Order 13011, Federal Information Technology, The White House, Washington, D.C., 07/16/1996

• Establish mission-based performance measures for IT investments, aligned with agency performance plans.
• Establish agency-wide and project-level management structures and processes that will be responsible and accountable for managing and evaluating investments in IT.
• Support appropriated training to meet these goals
• Select CIO’s

1. Executive Order of the President, Executive Order 13231, Critical Infrastructure Protection in the Information Age, The White House, Washington, D.C., 10/16/2001

This Order is established to protect against disruption of the operation of the information systems for critical infrastructure. It established the President’s Critical Infrastructure Protection Board, which is charged with recommending policies and coordinating programs for protecting information systems for critical infrastructure.

 

OTHER NATIONAL POLICY

2. Presidential Decision Directive 63 (PDD-63), Protecting America’s Critical Infrastructures, 05/22/1998

PDD-63 focuses specifically on protecting critical infrastructures from both physical and "cyber" attack from sources within or without the United States. The lead Federal agency for the Public Health Services Infrastructure Sector is the Department of Health and Human Services (DHHS). This directive established the Critical Infrastructure Assurance Office (CIAO).

3. Office of Management and Budget, OMB Circular A-123, Management Accountability and Control, Executive Office of the President, Publication Services, 06/21/1995

OMB A-123 implements the Federal Managers’ Financial Integrity Act and provides guidance to Federal managers on improving accountability and effectiveness of programs and operations by establishing, assessing, correcting and reporting on management controls. This Circular requires a review of security controls for each system whenever significant changes are made to a system, but at least every three years.

4. Memorandum 99-18 (M-99-18), Privacy Policies of Federal Web Sites, 06/02/1999

This Memorandum requires that every Federal web site must include a privacy policy statement, even it the site does not collect any information that results in the collection of a Privacy Act record. This statement must tell site visitors how any information from their site visit is handled by the agency. Privacy policies for agencies may be diverse and may be designed to the information practices of each individual site.

5. Memorandum 99-20 (M-99-20), Security of Automated Information Resources, 06/23/1999

The purpose of this Memorandum is to reaffirm that, consistent with OMB A-130, agencies must continually assess risk to their computer systems and maintain adequate security commensurate with that risk.

6. Office of Management and Budget, OMB Circular A-130, Management of Federal Information Resources, Executive Office of the President, Publication Services, November 2000

• Agency inclusion of system security plans and major application plans summaries in the strategic plan required by the Paperwork Reduction Act (44 U.S.C. 3506)
• For general support systems, agencies must: assign responsibility for security; develop and implement a security plan; establish rules of behavior that delineate responsibilities and expectations for all users and state consequences for violations; review security controls at least every three years or sooner upon significant modifications; and written authorize processing before beginning or significantly changing processing in the system
• For major applications, agencies must: assign responsibility for security, develop and implement a system security plan, perform independent review or audit of security controls at least every three years, and ensure written authorize processing for the use of the application

1. Memorandum 01-08 (M-01-08), Guidance on Implementing the Government Information Security Reform Act (GISRA), 01/16/2001

This Memorandum provides guidance to agencies on carrying out the provisions of GISRA and focuses only upon areas of GISRA that introduce new or modified requirements. The Act requires annual Inspector General (IG) evaluations, agency reporting to OMB of the IG evaluations, and the required OMB annual report to congress.

2. Memorandum 02-01 (M-02-01), Guidance for Preparing and Submitting Security Plans of Actions and Milestones, 10/17/2001

This Memorandum establishes guidance for implementation of OMB M-01-24, directing agencies to submit to OMB plans of action and milestones (POA&M), with quarterly updates thereafter, to address all weaknesses identified by program reviews and IG evaluations required by GISRA and other previous OMB guidance.

Additionally, the following guidelines and publications of the National Institute of Standards and Technology (NIST) were drawn upon, utilized and referenced in the development of the SAMHSA AISSP.

3. NIST, Federal Information Processing Standard (FIPS) 87, Guidelines for Contingency Planning, 03/27/1981
4. NIST, Federal Information Processing Standard (FIPS) 102, Guidance for Security Certification and Accreditation, 09/27/1983
5. NIST, Federal Information Processing Standard (FIPS) 112, Password Usage, 05/30/1985
6. NIST Special Publication 800-12 (SP 800-12), An Introduction to computer Security: The NIST Handbook, 10/1995

The NIST Handbook is referenced frequently in OMB A-130, Appendix III and provides a broad overview for development of a sound approach to security controls. The handbook illustrates the benefits of security controls, major techniques for each control and addresses important related considerations.

7. NIST Special Publication 800-14 (SP 800-14), Generally Accepted Principles and Practices for Security Information Technology Systems, 09/1996

This document provides a baseline to be used to establish and review Information Technology (IT) security programs. The security principles are to be applied in the use, protection, and design of government information systems.

8. NIST Special Publication 800-18 (SP 800-18), Guide for Developing Security Plans for Information Technology Systems, 12/1988

Local rules and regulations as presented to the reporting agency shall also be considered as requirements for this testing and evaluation process.

Security Requirements Trace-ability Matrix

The following Security Requirements Trace-ability Matrix (STRM) shall be the basis for all test scenarios developed by both parties for the duration of the test period. The supplied matrix can be used to support activity reporting in the columns provided.

APPENDIX C RFA Draft Final Report

DRAFT

9 March 2003

RFA and RFE/RL Mutual Probe Report

In January 2003, Radio Free Asia and Radio Free Europe/Radio Liberty held a mutual network "probe" – testing vulnerabilities to various sorts of network attacks. While an educational exercise, many of the lessons learned were of the "how to do it better next time" variety, as opposed to successful penetrations. This should not be construed as a high score for security – while there were no significant exploits, the efforts were rudimentary. This stems from the fact that the average Network Administrator is more fluent in defense than offense. Becoming fluent in the tricks of the hacker trade is not something one typically does in one month, and in RFA’s case, travel and other job-related commitments cut into this effort significantly. Additionally, there was much confusion on which machines, IP ranges and sites were involved in this test. Nevertheless, some tools were explored, and some promising avenues raised at least as to a more thorough testing of network defenses. Below follows a description of basic results and approaches.

To start with, there were 2 presumed exploits found in remote systems. One was an open "test" account on an ftp server (rfeftp). The second was an IIS 5.0 server (alamo) reportedly open to the remote printing shell exploit. However, in the latter case, the supposed successful upload of data using the "jill" program did not upload the file (at least by file’s name). Some testing would be required to find out if the server was inaccurately represented as having a hole, or whether the exploit program did not work as advertised.

Some of the tools available for network testing included nmap, nessus, nbtscan, fragroute, brutus, nikto, vomit, et al. Some of these had difficulties with use from within a firewall, and due to time limitations, most were not successfully configured for testing purposes. Information gained from nmap scans led to categorizing a variety of systems publically available – packages and systems including Lotus, Eudora, Communigate, IIS, Apache, Cisco, Terminal Services, and a variety of open ports. Robustly categorizing and attempting possible exploits on these systems was not feasible at this time, though would be very useful to do.

Other useful tests would be actively testing from within the LAN to see what lies open. Disgruntled workers can be a source of much mischief, and knowing what vulnerabilities are present if an intruder passes the firewall is needed. Aside from this, user and maintenance dial-ins can be more weakly protected than internet firewalls, and in a real exploit, intrusion counts no matter what form the access takes.

From RFA’s defensive side, very little was required to prepare for the probe – fixing one Cisco box’s SNMP and VLAN parameters, disabling a few old generic accounts and turning off a couple of unneeded services on a Linux box. That said, it is again presumed that the serious hacker hobbyist would have more insight into exploits, and more time spent in the future learning some of these skills would provide more assurance that defenses are indeed solid.

In summary, the Mutual Probe while initially a bit weak seems to be a good candidate for a repeat exercise, perhaps with modifications to make it more thorough, informative and assured. While the probe is sometimes seen as an extracurricular activity, it is an opportunity for a planned investigation of outstanding security issues that normally does not happen due to typical workloads and crisis handling.

William M. Eldridge

Director Technical Development

Radio Free Asia

APPENDIX D RFE/RL Final Report

This report to be supplied

APPENDIX E SAMPLE Penetration Test Plan Document

During the course of the MISST&E the test facilitators were asked by the RFE/RL staff to produce a Sample Penetration Test Plan. This plan is included herein as a reference document.

Division of Information Resource Management

PENETRATION TEST PLAN

November 2002

Version 0.069

Submitted to:

Federal Deposit Insurance CorporationSample Organization

3501 1000 North Fairfax Sample Drive, Room VS42352

Arlington, Virginia 22226-350007

Submitted by:

MAXIMUSCONSULTANT

DRAFT FOR REVIEW ONLY

TABLE OF CONTENTS

1 Overview *

2 Methodology *

3 Objectives *

4 Network Description *

5 Test Requirements *

6 Test Performance *

7 Procedures *

8 Network Penetration Test Approach *

1 Overview 3

2 Methodology 3

3 Objectives 4

4 Network Description 6

5 Test Requirements 6

6 Test Performance 8

7 Procedures 8

8 Network Penetration Test Approach 9

TABLE OF FIGURES

Figure 1 Information Assurance Functional Spectrum. *

APPENDICES

1. Overview

 

The purpose of this document is to document, describe and source requirements for the Federal Deposit Insurance Corporation (FDIC)SAMPLE ORGANIZATION (SO) Penetration Test Plan. The intent of penetration vulnerability testing is to assure adequate external protection is provided for all information collected, processed, transmitted, stored, or disseminated by FDICSO. The sensitivity of the FDICSO information systems is derived from levels of concern for the confidentiality, integrity, and availability of the information in the system for all FDICSO purposes.

 

The evolution of global, integrated networks has significantly increased the threat to critical IT assets. Unfortunately, the accelerating rate of technology development, and the resulting increase in threats to critical assets, has outpaced the ability of most organizations to protect their information systems from the wide range of threats that they face today. To understand how we approach penetration and vulnerability testing, one needs to understand the FDICSO requirements for protecting information.

 

The purpose of the FDICSO Penetration Test is to ensure that the required security safeguards are in place to protect FDICSO’s Information Technology (IT) assets against unauthorized modifications, disclosure, destruction, and denial of service attacks throughout all of the systems’ life cycles and to ensure the confidentiality, integrity, and availability of these assets. The requirements limiting the level of FDICSO public system exposure establishes the parameters for FDICSO Penetration Test procedure.

2. Methodology

The FDICSO's Information Assurance (IA) Program is based on requirements driven risk mitigation methodologies and technologies. The FDICSO maintains a number of innovative tools from across the information security industry, to augment our assurance program. The FDICSO IA approaches are consistent with the standards of the National Institute of Standards and Technology (NIST), National Security Agency (NSA), Carnegie Mellon University, and with industry best practices of information technology auditing (such as Control Objectives for Information and Related Technology (CobiT)). This methodology and associated tools have proven to be successful in protecting FDICSO business and technical systems through a systematic and flexible approach to problem resolution and risk mitigation. While the FDICSO is not a recognized leader in information technology management, the (Department of Infromation Resource Management, Office of the Chief Information Officer (DIRM OCIO) office provides a value-based approach that includes executive-level participation in risk awareness, as well as mitigation and acceptance of residual risk.

 

The primary directive of the penetration and vulnerability test is to ensure computer systems and network operations will not be intentionally interrupted. Extreme care will be exercised to ensure that network availability and data integrity are in no way compromised. User data will neither be destroyed nor corrupted. In order to further prevent operational risk, FDICSO technical representatives will be informed of serious security shortcomings that should be corrected immediately.

 

The test methodology will include initial "Black Box" testing, where disclosed technical information gathering is strictly limited, and "Grey Box" testing which takes place in a disclosed internal arena. In either case the objective is to test for user, root or administrator access, system penetration including wireless and dial-in attacks.

 

Thus, in testing for potential vulnerabilities, the FDICSO expects the Penetration Team to use a dual (black box/gray box) methodology that captures the security and vulnerabilities of the network system as a series of snapshots in time by, typically, fielding two teams of security vulnerability specialists. The "unknowledgeable" team represents unauthorized persons who are not familiar with the infrastructure and content of FDICSO systems. This team will initiate their "black box" attacks first. The knowledgableknowledgeable gray team follows and simulates a trusted attack.

This dual methodology continues by following the attack by an external threat with an internal threat, such as could be attempted by trusted individuals who are more knowledgeable about FDICSO computer systems and networks. The penetration team follows this "gray box" test process, performing discovery, planning, invasion, and operations starting from the inside network, and working down to the database-level. This gray box team will perform a battery of penetration tests on the internal systems at various times to attempt to exploit weaknesses. No denial No denial of service attacks will be used.

3. Objectives

The most important premise the penetration test test considers as they carry as they carry out their tasks is to understand and protect the business of the FDICSO. The fact is that SECURITY IS A FUNCTION OF BUSINESS. This basic understanding is important to the fundamental objectives and mission of the organization when performing security testing. In reviewing IT security requirements, we know that both proactive countermeasures and reactive functions must be included in an acceptable protection program. Figure 1 depicts a sampling of this information assurance spectrum whereby the health of an organization is also reflected by its depth of integrating into its policies a "tooth-to-tail" solution.

 



Figure 3 Information Assurance Functional Spectrum.Spectrum.

Proactive measures mitigate many IT security risks. Reactive measures can aid in eliminating future risks. Both proactive and reactive actions protect critical assets, information and systems. These are represented as layers in the Figure 2.

 



Figure 4 Concentric Barriers of Protection.

Thus, managing the risk from multiple threats to FDICSO systems requires a structured requirements driven methodology.

4. Network Description

The FDICSO Network is composed of the Virginia Square and Dallas Texas ATM internetworks inside FDICSO’s security perimeter. This "inside" network is demarcated with firewalls and protected by Network Intrusion Detection Systems (NIDs).(NIDs). The interior FDICSO Network is sited within the Virginia Square, Arlington, Virginia and Dallas, Texas, FDICSO buildings respectively. Both sites enjoy an Internet Point of Presence (POP) provided by local Internet Service Providers (ISP). FDICSO staff and contractors administer this protected ATM network, and control all the backbone equipment on this network. Figure 3 depicts this network.

 

 

Figure 5 FDICSO Network Overview

5. Test Requirements

This section defines traces, delineates and demarcates the basis for the Penetration Test discussed in the procedures section which immediately follows.

 

The overriding FDICSO test requirement is to ensure that all information systems within FDICSO control have a level of security that is commensurate with the risk and magnitude of harm that could result from loss, misuse, disclosure, or modification of the information contained in the system.

 

Additional security test requirements can be found in the FDIC Security Requirements Matrix (SRM) which should accompany this test planning document. These requirements are the derived from Law, Policy, Guidance, Best Practice, Rules and Regulations as shown in Figure 4. Additional security test requirements can be found in the SO Security Requirements Matrix (SRM) which should accompany this test-planning document. These requirements are the derived from Law, Policy, Guidance, Best Practice, Rules and Regulations as shown in Figure 4.

 



Figure 6 FDICSO Information Assurance Overview

The purpose of penetration testing is to validate that the controls defined to minimize threats and mitigate vulnerabilities are adequate and capable of supporting these derived requirements.

 

The tangible and deliverable goal of this penetration test exercise is the Vulnerability Report, which will will be analyzed and become part of the Risk Assessment document, which ultimately directs modification of the security controls of the FDICSO IA activity, as shown in Figure 4.

 

6. Test Performance

The risk to these systems by criminal exploitation, attack, malware, or other forms of misbehavior, and the data they carry requires the evaluation and test of the organization’s computing capability to mitigate damage or loss of FDICSO information or assets. Network penetration testing is a major component of assessing the vulnerabilities of IT systems and their operating environments, and is a critical cornerstone to IT governance for adequately managing risk, performance, data privacy, and security. The FDICSO is challenged to ensure data integrity, confidentiality, and systems availability across a large and complex computing infrastructure.

 

The FDICSO seeks assistance in investigating system vulnerabilities, possible misconfigurations, malware identification, risks to FDICSO data and exploitable paths to FDICSO information. The FDICSO understands that this inspection is a ‘snapshots-in-time’ that will establish a benchmark for the FDICSO OCIO’s Cyber Security Program to develop corrective mitigation strategies and objectives for the near future associated with electronic threats and system vulnerabilities.

 

FDICSO representatives must be present to view both the black and gray ‘white hat’ attacks on FDICSO systems. In witnessing this FDICSO engineers and analysts will be sure to provide FDICSO management with a full understanding of test methods, techniques and tools used during each task. This knowledge transfer is essential to the FDICSO for sound reporting, CIRT coordination and effective countermeasures development.

7. Procedures

In light of these constraints, the FDICSO's Office of the Chief Information Officer (OCIO)(OCIO) and the Cyber Security Program expect a group of information security specialists familiar with Information Assurance (IA) practice perform the vulnerability penetration test based upon the FDICSO SRM and submit a report on the vulnerability of the external and internal portions of the FDICSO network. This work will be conducted in order to gauge the strength of FDICSO's network in-depth defenses to meet the requirements derived from the Computer Security Act, OMB Circular A-130, the Privacy Act, the Government Information Security Reform Act (GISRA) and other regulatory mandates as stated in the FDICSO SRM.

8. Network Penetration Test Approach

Specific to the black testtest, the penetration teams shall assess the security perimeter of FDICSO networks. The development of protective countermeasures requires a multi-layered, defense-in-depth approach because only shutting down the FDICSO network can successfully mitigate all vulnerabilities and risks. It is expected that there are point solutions as well as infrastructure enhancements, and these often lack the integration required, providing further vulnerability for exploitation. The FDICSO is aware that the very nature of security (e.g. deter, detect, delay, defend, defeat, and deny criminal intentions or human error) is proactive and understands the need to attempt to penetrate and go around these protection mechanisms in order to validate them. The FDICSO uses the GSA FEDCIRC to support its internal and external networks. This reactive CIRC function is crucial to fulfilling the expectations of integrity, availability, confidentiality, accountability and restoration as a network security function. The FDICSO expects that the penetration team will work with the FEDCIRC as necessary to provide a total understanding of attempts, failures and successes in testing the assurance capabilities as required by FDICSO.

1. Work Plan Development.

A kick-off meeting begins the planning of the types of activities whichactivities that will require a detailed requirements-based structure. This is followed by the development of a project work plan. The kick-off meeting will set performance expectations and legal boundaries, schedules and milestones. The kick-off meeting minutes and the draft work plan will be submitted for review, and testing will not commence until a final work plan is delivered and approved.

2. Test Tools.

FDICSO provides its staff with global access to extensive databases or Centers of Excellence on systems benchmarking studies, best practice research, training tools and techniques, COTS evaluation, testing, and implementations, business process reengineering, and others which include:

• Knowledge Point--provides research, resources, materials and specialists in best practices and industry information.
• Technology Resources Center--provides research, development, and training facilities established to help clients adopt advanced technologies to support and enhance their core business processes.

Both penetration test teams will consult with FDICSO to use a combination of scanning products and methodologies to conduct a thorough scan for network vulnerabilities. Most importantly, our team will then use its extensive expertise to analyze the results of the scans to advise the agency of the risks associated with each vulnerability found, develop recommendations and countermeasures for corrective actions, estimate the level of effort required to implement corrective actions, and establish the priority of each action. Examples of tools used on past security diagnostic engagements are listed below.

Scanners Scanners

Scanners are programs that sequence through frequencies, IP addresses or port numbers looking for open connections. Examples inlcudeinclude:

• Nmap – Port-scanning tool that will map a network and can scan through firewalls, supports multiple protocols, and can detect operating systems.
• Nessus - Generic security scanning tool that checks for known vulnerabilities on networks.
• Saint - Generic security scanning tool that checks for known vulnerabilities on networks and is based on SATAN (System Administrator Tool for Analyzing Networks).
• Internet Security Systems (ISS) Internet Scanner - A commercial Commercial tool that automatically scans a range of IP addresses and performs numerous tests aimed at detecting known vulnerabilities.
• Cybercop Scanner - Another commercial tool that scrutinizes systems for intrusion vulnerabilities.

Password Crackers

While this may seem outside the scope of this effort, this testing is necessary to assure our depth in capability and technical knowledge. knowledge.

• John the Ripper - Cracks Windows NT passwords, UNIX, and Novell.
• L0phtCrack - Windows NT/ 2000 password cracking tool.
• Cracker Jack - Cracks UNIX passwords,
• LAN Password Guesser: Software that continuously guesses passwords for user IDs associated with LAN environments.

Other tools to consider include but are not limited to:

• NAT - NetBIOS auditing tool.

• BlackWidow – Downloads all pages and mirrors the web site.
• WGET – HTTP mirroring software.
• Lynx – Text browser.
• Webcracker – Brute force password utility.
• Elza – Web scripting tool
• Whisker - Detects vulnerable web code.

• Dsniff – Sniffer that will be used to capture all traffic for log analysis.

• Phonesweep - Dialing software that recognizes and logs systems.
• Toneloc - War dialer.

The selection of tools to be used in FDICSO network testing will be based on industry and FDICSO staff confidence in the reliability of the tools. The FDICSO approach to testing is to use the best tools available for each type of system to aid in our analysis. FDICSO consideration should include CyberCop, a commercial tool that is strong in Unix, (particularly LINUX and Solaris) and reasonably good at Windows NT and Cisco routers. It has many false positives and reports the same vulnerabilities several ways.

Additionally the FDICSO should consider using several public domain tools including Sara, Netcat, NTcrack, Satan, and NMAP. These tools are good but should be deployed with care to avoid any systems problems

1. Black Box Testing Testing

With the written permission from the FDICSO, for a period of performance not to exceed an estimated one month, the black test team will conduct a number of scans and probes of external FDICSO systems in an attempt to penetrate the network in a realistic simulation of external, unauthorized access. All penetration attempts will be documented and witnessed by FDICSO personnel. The results of this test and assessment will be included in the vulnerability report and provide to the FDICSO with specific counter measures recommendations.

1. Technical Information Gathering.

The collection of publicly available information concerning a target network is a vital first step in penetration testing. A wealth of information about any public network is available via a series of internetworking system services as well as through use of information gathering tools. The types and importance of the information varies with each service and tool, but together this information can be used to determine highly probable points of success for surveying. This information can be as simple as host names and operating system versions listed in DNS (e.g., recently, a Sparc Station that carries the name sun0s42.FDICSO.gov or a router that carries the name cisco.FDICSO.gov). The information can, in some cases, be compiled to form educated guesses diagramming the trust relationships between systems and trust flow direction. Such public intelligence can be used in attacks on systems and applications and may be considered in the vulnerability report.

 

Physical network design and routing information can often be determined through use of Wi-Fi (wireless), Dialup or IP scan tools. Additionally, network basednetwork-based intelligence gathering through the use of SNMP Management Information Blocks (MIBs), or a routing protocol are possible avenues. This information can be used later by spoofing tools or other attack methods.

 

Thus supplied and equipped, the "black box box" penetration teams attack from the perimeter inward operating in phases as a "hacker" would; initiating probes, conducting Wi-Fi and Dial-Up exploitation, MIB collection, social engineering and any other technique which advances the assault. The operational goal of the black box tester in invading the network is to obtain and strengthen a position inside the network and continue to conduct intelligence gathering operations as long as possible before being detected or thwarted.

 

2. System Penetration.

Once all possible information is gathered and examined, vulnerable systems on the exposed networks will be exploited. The methods used to gain system access will be selected from those that the analysts feel have the greatest potential for success and have the least potential for detection by monitoring services. Efforts will be directed towards gaining a shell account on a system physically located on the exposed portions of the network. Shell accounts are compromised using a variety of techniques and exploitation software. These techniques and software typically exploit known holes or "bugs" in many common services.

 

The test team will attempt to exploit as many known vulnerabilities of the computers, routers, firewalls, network operating systems, protocols, and other components as possible in the defined test period. In some cases, vulnerabilities of one or more components will be exploited to provide stepping-stones to exploit other components. For example, one might need to exploit Simple Mail Transfer Protocol (SMTP) vulnerabilities to gain access to a firewall system before monitoring traffic ("sniffing") for network addresses to select and compromise a host. Evidence of exploitation will be introduced, where plausible, to demonstrate the seriousness of the vulnerability. vulnerability.

 

1. Scanning

This test team will likely perform an in-depth port scan of FDICSO’s internet perimeter checking for responsive hosts and accessible services (TCP, UDP and ICMP-based) and report those "High-Risk" and other services that are found running on the hosts and visible to the Internet. The test team will then seek to exploit these services. The penetration team will employ a variety of automated and commercially available tools to remotely probe the specified networks for security vulnerabilities determined as appropriate, recording vulnerabilities, configuration problems, and unnecessary services. The vulnerability testing can be expected to check for susceptibility to most or all of the following security holes, as well as others appropriate to the specific configurations:

• Brute Force and Social Engineering Attacks, straight forward attempts to gain system access

• Presence of vulnerable CGI scripts
• Distributed Naming Service (DNS) implementation vulnerabilities
• Presence of various vulnerable processes.
• Denial of Service Attacks
• Email system miss configuration vulnerabilities
• Weaknesses in the File Transfer Protocol and its implementations.
• Firewalls’ default user security weaknesses
• NFS file system and X-Windows interfaces for vulnerabilities
• Network Information System implementations for vulnerabilities
• Perform patch and operating system versions tests, determine log access, and display information available through the NetBIOS protocol protocol
• Packet routers and networking hardware vulnerabilities
• Remote Procedure Call (RPC) services vulnerabilities
• Simple Network Management Protocol (SNMP) implementations vulnerabilities
• Protocol-based attacks, such as packet spoofing, packet fragmentation, session hijacking, and packet eavesdropping
• Attacks on active routing systems, network switches, remote access and WAN networking devices
• Exploitable host-based vulnerabilities, such as password guessing and cracking, buffer overruns, and reliance on transitive trusttrust
• Susceptibility of routers and hosts to SNMP and other management and informational protocol commands
• Exploitable weaknesses in application-level software and substandard patch levels.

There exists a wealth of system-specific attacks known to achieve a higher level of privilege within the net. Some common attacks are listed below.

1. Previous Attacks:

Most of the system penetration and shell access attacks can be used to gain increased privilege once user-level access is achieved.

 

2. Password:

All passwords are encrypted, but the user IDs can now be viewed. Password "cracking" software can be run against the password file on compromised NT and Unix systems. Manual (brute force) password guessing may also be used particularly against appliances (e.g. routers and switches) to achieve increased system privileges.

3. Crontab:

Cron jobs are typically available for modification at the user level. Unpatched Crontab can be used to escalate privilege level. Cron jobs are typically available for modification at the user level. Unpatched Crontab can be used to escalate privilege level.

4. System logs:

System logs as well as other publicly known system files can be exploited to gain intelligence and escalate privilege level.

5. "Kiddie Scripts":

"Kiddie Scripts""Kiddie Scripts" are scripts and actual compiled code to employ more advanced exploits of specific known security flaws. Most of these make use of software "bugs" that fail to protect memory isolation. An example of such a "bug" is a buffer overflow condition that allows the analyst to overwrite instruction pointers and execute code.

6. Stealth/Detection Evasion:

Where active administration is apparent, techniques will be used to attempt to hide test team presence and the history of intrusion. These tools typically attempt to bypass monitoring programs and DLLs such as ps, ls, sum, and who. Where required, we will leave non-disputable evidence of access on particular systems.

1. Dial-In Testing

The black test team shall conduct testing of the FDIC dial-up services. Our understanding is that FDIC dial-up consists of 10-14 prefixes in the Arlington and Dallas LATAs. The test team will identify unsecured dial-in services throughout the internal network. To that end, the team will employ automated dialing software to scan entire exchanges. The software will log all results and identify all lines where a modem answers. A penetration team member will then manually dial each modem and determine if the authentication processes are strong enough to resist unauthorized access attempts. This testing could potentially lead to unauthorized access. Due care will be exercised to ensure that network availability and data integrity is in no way compromised. The purpose of these tests is to determine if any external party can gain unauthorized assess through remote means. The black test team shall conduct testing of the SO dial-up services. Our understanding is that SO dial-up consists of 10-14 prefixes in the Arlington and Dallas LATAs (Local Access Transport Area). The test team will identify unsecured dial-in services throughout the internal network. To that end, the team will employ automated dialing software to scan entire exchanges. The software will log all results and identify all lines where a modem answers. A penetration team member will then manually dial each modem and determine that the authentication processes are strong enough to resist unauthorized access attempts. This testing could potentially lead to unauthorized access. Due care will be exercised to ensure that network availability and data integrity is in no way compromised. The purpose of these tests is to determine if any external party can gain unauthorized assess through remote means.

 

2. Wi-Fi Test

Recent advances in radio based networks, particularly but NOT limited to the Wi-Fi (IEE 802.11 standard) have caused prices to drop and availability of wireless technology to blossom in the data processing area. Examples of wireless systems abound, and include:

• IEE 802.11 (A&B)
• Blue Tooth
• PCS 1900
• Global Systems Mobile
• Wireless Access Protocol
• TDMA IS 136
• CDMA IS 95

As well as a plethora of proprietary radio and optical links.

Regardless of what the current operational posture towards this technology is, it is necessary to survey both physical sites and determine the extent that formal or informal use of this technology will breach the FDICSO security posture.

The principal tool used in this survey should be a Sharp Zaurus running Kismet, a scanner tool dedicated to this type of activity.

1. Identification of Critical Operations and Information.

As a prelude to the "Gray Box" testing, the penetration test team will work with FDICSO staff to identify critical, sensitive data that may be involved with or resident on the systems to be tested. (E.g., financial, contracts/bid information, privacy-act data, patents, passwords, investigative data, etc.). This information will be used by the gray team to understand what information we may come in contact with in order to adequately protect and/or exploit it as directed by the FDICSO staff.

 

The information and methods used from the black (unknowledgeable) team will have demonstrated external vulnerability to outside threats. This data will be disclosed to the gray (knowledgeable) test team who, during their review of the internal configurations, will verify the penetration and will capture corrective actions to be identified in the vulnerability report. Any dangerous security vulnerabilities noted will be immediately brought to the attention of the FDICSO in a vulnerability memo.

 

2. Gray Box Testing

The second team, the "knowledgeable" team represents persons who are knowledgeable about the content and infrastructure of FDICSO systems and may look to perform some unauthorized function, data manipulation, theft, or other misbehavior. This team represents both internal threats posed by employees, and potential external risks from previous employees or others outside FDICSO who may have become knowledgeable about certain aspects of the networks, architecture, and information.

 

1. Technical Information Gathering

The FDICSO gray box test penetration team will next perform as a ‘knowledgeable’ threat as directed by the FDICSO and within the scope of the Security Requirements Matrix. Gray Box testing will consist of probing the FDICSO perimeter defenses for vulnerabilities and attempting to penetrate security controls to attain user-level access, and ultimately, system-level control. It is our understanding that approximately 150 IP addresses and additional telephone prefixes are included in this initiative. It is understood that VM, MVX, Unix, Novell and NT operating systems are presently operational on the interior network. Analysts will scan and probe the FDICSO networks to discover and exploit vulnerabilities in an attempt to penetrate corporate systems both internally and externally from the Internet. The security testing performed in this task will be used to complete the vulnerability report in an effort and determine across the organization the security posture of the FDICSO’s information assets.

 

The knowledgeable team shall perform a series of vulnerability scans and configuration reviews of the networks. The tests will be conducted both internally and externally as knowledgeable individuals, with the distinction that these gray team members will detail the findings and report on and make recommendations of defensive countermeasures into the vulnerability report.

 

2. System Evaluation

The testing shall include an extensive internal vulnerability assessment of the FDICSO external network. These tests will assess system vulnerabilities, exploitable mis-configuration and other potential security weaknesses as introduced from either an internal or an external source. The tools used will be as agreed in the Kick Off Meeting and assured free of malicious code. This penetration attempt will establish the protective, security posture of FDICSO from both internal and external threats. Some examples of the type of issues that to be called out and addressed during the perimeter evaluation are:

• Web Server configurations
• DNS server configurations
• FTP server configurations
• Unprivileged Telnet access
• Default password checks on all services
• Transmission Control Protocol (TCP) sequence predictability
• Finger daemon mis-configuration and DOS susceptibilities
• Use of rlogin, rpc and other remote deamons
• Identification of old or vulnerable versions of server software
• Remote NetBios vulnerabilities
• Common Gateway Interface (CGI) arbitrary command holes
• Denial-of-Service vulnerabilities
• Well-known root exploits
• Web site with the client identifying problem areas/concerns
• Configurations of the E-mail server(s)
• CGI script configuration problems
• List of all services and weaknesses inherent in each system
• List of open ports and inherent weaknesses

Potential attacks are based solely upon the targeted system’s active operating system services. Since operating systems and services control and configuration vary widely, exploitation requires an in-depth knowledge of the latest discovered security flaws of each operating system, as well as all system services. This information will have been gathered to as part of the specific methodology that will be used. However, some of the more common system attacks are itemized below.

1. Application and Service Exploits

Applications and services (e.g., mail and information publication) will be examined for weaknesses and design. The goal of the information-gathering step is to provide the team with enough information to be successful in penetrating the first system on the network. The following technical procedures will be performed to exploit open source data:

 

1. Domain Name Service

1. InterNIC:

The commercial public and government InterNIC domain registry databases will be searched for entries referencing the target network. At a minimum, this search should result in the addresses of the network’s external DNS servers.

2. Domain Name Services

Public DNS addresses will be examined. This will provide us with named systems that are exposed, as well as potential inside systems if the DNS publication process is not discrete.

2. E-mail:

E-mail will be examined for Internet design and authority and for software that is being used. E-mail is also a classic source of exploitation through the use of Trojan horse programs.

1. Sendmail:

Sendmail is commonly used to gain unauthorized access to a host system. The deamon software has a wide variety of known security flaws. Common attacks include writing to system files, and forcing the read and re-mailing of system files.

 

3. Network Information Service (NIS):

Insecure services such as NIS provide not only direct access to password files, but in some cases allow remote execution of privileged commands.

 

4. Host Scanning:

Host scanning will be used to identify active hosts that the test team can "see" from the Internet.

5. Trivial File Transfer Protocol (TFTP):

If present, TFTP can provide access to the password file.

6. Network File Service (NFS):

NFS attacks are usually file based, and work via remote file system mounts. This is typically used to access mail or to exploit trust relationships (rlogin, rexec, rsh).

 

7. File Transfer Protocol (FTP):

Mis-configured FTP servers can sometimes provide attack opportunities. These include file access attacks as well as rlogin/exec commands.

8. Hypertext Transfer Protocol (HTTP):

These servers over the past year have become well known for mis-configurations of CGI scripts, as well as bugs in the daemon software which allow remote execution and file access.

9. Port Scanning:

TCP and UDP ports will be randomly scanned on all "visible" hosts. The combination of this information and the previously gathered information will provide the team with knowledge of active system services and, to some degree, application interaction between exposed systems. These applications and system services will be examined to locate systems that are potentially vulnerable to attack.

10. Port Exploitation:

Once determined to be open, the 65,636 available ports per IP address can be a sumptuous source of further intelligence about the FDICSO network. Venerable examples of this are the Finger Services, either port 79 or 2003. Finger data can be used to determine user account information and, in some cases, other traffic flow information.

 

Once a foothold is gained, these steps will be repeated from each compromised system so that levels of trust can be determined as well as to advance placement inside the network.

 

11. Root or Administrator Access.

Once a shell account as a normal user is achieved, the penetration teams attention will turn to obtaining administrative privilege, which is tantamount to having total system and applications control (except perhaps to some databases). Also, once "root" access is achieved (in some systems, called Administrator or Supervisor), that system can often be used for a remote staging point for new attacks. Root access on most Unix-based systems, administrator on Windows NT-based systems and supervisor on Novel systems also provides the ability to place the network interface into promiscuous mode and capture remote network data and traffic. This is typically referred to as "sniffing".

 

12. Sniffing

Once sniffing capability has been achieved, attacks on remote systems become increasingly successful due to the increase in potential attacks and information gathering methods. Also, the ability to "sniff" the external network may provide clues as to what types of traffic are permitted through the firewall. The previous methodologies will continue to be used to gain access to systems located on the external network. If more than one external sub network exists, the methodology is repeated for each targeted sub network. In most cases, the same exploits used to gain user level access on a system can be used locally to gain root access. In addition, any and all configuration errors on the system may potentially be used to obtain privilege.

 

2. Telephone System Testing

Additional telephone system features worthy of test include:

• Voice Mail Exploitation
• Digital Tie Line
• E&M Exploitation
• Other "Convergence" tests

The operant factor here is to understand that the FDICSO Private Branch Exchange (PBX) is in reality merely a network attached computer in its own right, and that as an Automated Information System can be exploited with spectacular result.

1. Vulnerability Report

Following an analysis of our findings and observations, The Penetration Teams will prepare a vulnerability report for submission to the Contracting Officer Technical Representative (COTR). Unless otherwise directed, this report will follow the OMB standards for reports and be presentable to the Inspectors General.Following an analysis of our findings and observations, The Penetration Teams will prepare a vulnerability report for submission to the Contracting Officer Technical Representative (COTR). Unless otherwise directed, this report will follow the OMB standards for reports and be presentable to the Inspectors General.

 

1. Identification and Analysis of Threat Environment.

Threat analysis is extremely important in determining what risks are challenging FDICSO activities. Threat identification consists of determining internal and external threats that can introduce risk to the Agency. The penetration test teams are, in this phase, concentrating on vulnerability detection and analysis, and it is important to be aware of the threat environment. Of particular sensitivity are immediate threats to operational systems. However due to this assessment being limited to vulnerabilities, the FDICSO assumes that threat information will not be detailed, but rather a generic assumption of threat from both internal and external sources. Uunauthorized persons attempting to gain remote access to FDICSO systems will be the basic tenet to these vulnerability tests.

 

2. Vulnerability Analysis.

The penetration team will consider the FDICSO’s current operations and critical information then compare them against the cited vulnerabilities with an eye on the FDICSO requirements. Sensitive information that is unprotected, collectable or exploitable by vulnerability is subject to compromise and is, therefore, at risk. The analysis of the identified vulnerabilities is a necessary element within this step and could be cited within the risk analysis portion of the system certification and accreditation, GISRA review and OMB A-130 documentation. The test team thus takes great care that information collected during the penetration tests is input to a vulnerability report. This data can in turn be used in an automated risk analysis tool that will provide immediate or continuous risk assessment to aid in risk management, the NIACAP and return on control decision making.

 

3. Development of Protective Measures and Recommendations.

While not part of the scope of the penetration testing process, cost-effective countermeasures are often researched and recommended to minimize each identified vulnerability. The test team security professionals possess extensive experience in developing innovative solutions that agency executives should consider. Ad hoc recommendations could include installing encryption devices, additional network monitoring, control, requirement, regulation or policy development.

 

4. Risk and Cost Benefit Analysis.

Informal mitigation strategies, recommendations and protective measures will likely be accompanied with rough order of magnitude cost estimates. These can be prioritized and included in the vulnerability report. This is an area that, in accordance with the FDICSO’s risk management philosophy, budget, and timing might also be included in the formal risk assessment.

 

5. Implementation of Selected Protective Measures.

While not contemplated as part of this penetration testing effort, the FDICSO remains ready to implement these ad hoc recommendations, particularly on areas of critical concern, high risk or high visibility. These recommendations may include:

• Threat Analysis and Operations Security
• Security Training & Education
• Security Policy & Procedure Development
• Computer Systems Security and Accreditation
• Remote Network Monitoring & IA/IT Product Integration
• Business Continuity/Disaster Recovery/National Security Emergency Preparedness
• Communications Security (COMSEC) and Public Key Infrastructure Integration
• Additional Network Penetration Testing
• Firewalls & Encryption

1. Vulnerability Report Guidance

The vulnerability report will be written in accordance and in compliance with the

• NIST Self-Assessment Guide for Information Technology Systems (Section 4.2.6).
• NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems,…..
• NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems, advises that the determination of adequate controls over data integrity requires answers to whether…..
• OMB Circular No A-130 which states "…'adequate security' means security commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of information...."….
• The FY 2001 Defense Authorization Act, Section X, Subtitle G, Government Information Security Reform Act (GISRA), states that, "…The head of each agency …(A) adequately ensuring the integrity, confidentiality, authenticity, availability, and nonrepudiation of information and information systems supporting agency operations and assets; …""…..

1. Conclusion:

The lack of effective data integrity controls based upon stated requirements, can and does pose security vulnerability through inaccurate or missing data resulting from unauthorized destruction or tampering of electronic files and records. The vulnerability report resulting from the process outlined above can be developed into a plan allowing the FDICSO to assign appropriate resources, develop and implement action plans to fully meet data integrity requirements.