REGISTER  |  SIGN IN
United States Patent6993448
Tracy , ; et al.January 31, 2006
Title
System, method and medium for certifying and accrediting requirements compliance
Abstract
A computer-implemented system, method and medium for assessing the risk of and/or determining the suitability of a system to comply with at least one predefined standard, regulation and/or requirement. In at least some embodiments of the present invention, the method comprises the steps of: 1) automatically or manually gathering information pertaining to the system, 2) selecting one or more requirements with which the system is to comply; 3) testing the system against the requirements; 4) performing risk assessment of the failed test procedures, and 5) generating certification documentation based on an assessment of the first four elements.
Inventors:Tracy; Richard P. (Ashburn, VA), Barrett; Hugh  (Centreville, VA), Berman; Lon J.  (Sterling, VA), Catlin; Gary M.  (Bricktown, NJ)
Assignee:Telos Corporation (Ashburn, VA)
Appl. No.:822868
Filed:April 2, 2001
Current U.S. Class:702/119 702/120 702/121 702/188 702/189 
Current International Class:G06F 13/00 (20060101)
Field of Search:702/119-123,186-189 455/414 709/225 714/39,89 717/174
U.S. Patent Documents
20010027389October 2001Beverina et al.
20010034847October 2001Gaul, Jr.
20020042687April 2002Tracy et al.
20020069035June 2002Tracy et al.
20020104014August 2002Zobel et al.
20020198750December 2002Innes et al.
20020199122December 2002Davis et al.
20030046128March 2003Heinrich
20030064717April 2003Rajaram
20030065793April 2003Kouznetsov et al.
20030159063August 2003Apfelbaum et al.
20030163728August 2003Shaw
20030172166September 2003Judge et al.
20040010709January 2004Baudoin et al.
20040025015February 2004Satterlee et al.
20040049698March 2004Ott et al.
5032979July 1991Hecht et al.
5621889April 1997Lermuzeaux et al.
5625751April 1997Brandwajn et al.
5684959November 1997Bhat et al.
5699403December 1997Ronnen
5740248April 1998Fieres et al.
5796942August 1998Esbensen
5850516December 1998Schneier
5859847January 1999Dew et al.
5870545February 1999Davis et al.
5892900April 1999Ginter et al.
5892903April 1999Klaus
5931946August 1999Terada et al.
6006328December 1999Drake
6134664October 2000Walker
6148401November 2000Devanbu et al.
6151599November 2000Shrader et al.
6185689February 2001Todd, Sr. et al.
6205407March 2001Testa et al.
6219626April 2001Steinmetz et al.
6219628April 2001Kodosky et al.
6219805April 2001Jones et al.
6230105May 2001Harris et al.
6256773July 2001Bowman-Amuah
6282546August 2001Gleichauf et al.
6298445October 2001Shostack et al.
6317868November 2001Grimm et al.
6324647November 2001Bowman-Amuah
6370573April 2002Bowman-Amuah
6389402May 2002Ginter et al.
6401073June 2002Tokuda et al.
6405364June 2002Bowman-Amuah
6408391June 2002Huff et al.
6473794October 2002Guheen et al.
6546493April 2003Magdych et al.
Foreign Patent Documents
0999489May., 2000EP
WO 00/70463Nov., 2000WO
WO 01/37511May., 2001WO
WO 01/59989Aug., 2001WO
WO 01/99349Dec., 2001WO
WO 02/061544Aug., 2002WO
Other References
Dec. 26, 1985. "Department of Defense Trusted Computer System Evaluation Criteria." DoD 5200.28-STD. cited by other .
Jul. 31, 2000. "Department of Defense Information Technology Security Certification and Accreditation Process (DITSCAP): Application Manual." DoD 8510.1-M. cited by other .
Jan. 23, 2003. International Search Report from PCT/US02/28179. cited by other .
Apr. 11, 2003. International Preliminary Examination Report from PCT/US00/09842. cited by other .
Dennis Szerszen, "Secure Strategies--A Year-Long Series on the Fundamentals of Information Systems Security--Extending your business to the Web requires a firm understanding of directories, what they offer and the challenges you'll face in deploying them," Apr. 2000, Part 1, from http://infosecuritymag.techtarget.com/articles/april00/features4.shtml. cited by other .
"DOD Information Technology Security Certification and Accreditation Process (DITSCAP)," Lesson 11, Aug. 29, 2000, from http://atzhssweb.gordon.army.rail/otd/c2protect/isso/item17.html, pp. 1-25. cited by other .
The Mitre Corporation, "The Key to Information Sharing--Common Vulnerabilities & Exposures," Aug. 17, 2000, from http://www.cve.mitre.or- g/about/introduction.html. cited by other .
Al Berg, "Secure Strategies--A Year-Long Series on the Fundamentals of Information Systems Security--On the surface, all vulnerability assessment scanners perform essentially the same way. Here's how to decide which one-if any-is right for your requirements," Part 2, "Audits, Assessments & Tests (Oh, My)," from http://www.infosecuritymag.com/aug200- 0/securestrategies.htm, pp. 1-5. cited by other .
Dan Swanson, "Secure Strategies--A Year-Long Series on the Fundamentals of Information Systems Security--Avoiding IS Icebergs," Part 4, "Audits, Assessments & Tests (Oh, My)," from http://www.infosecuritymag.com/oct200- 0/icebergs.htm, pp. 1-4. cited by other .
George Kurtz and Chris Prosise, "Secure Strategies--Penetration Testing Exposed," Part 3, "Audits, Assessments & Tests (Oh, My)," from http://www.infosecuritymag.com/sep2000/securestrategies.htm, pp. 1-5. cited by other .
Polk, W. T. Dec. 1992. "Automated Tools for testing computer system vulnerability (Abstract)." National Institute of Standards & Technology. Washington, DC. cited by other .
U.S. Appl. No. 09/794,386, filed Feb. 28, 2001, Tracy et al. cited by other .
Hochberg, Judith, Kathleen Jackson, Cathy Stallings, J.F. McClary, David Dubois, and Josephine Ford. May 3, 1993. "NADIR: An automated system for detecting network intrusion and misuse (Abstract)." Computers & Security, vol. 12, No. 3, pp. 235-248. cited by other .
Baskerville, Richard. Dec. 4, 1993. "Information Systems Security Design Methods: Implications for Information Systems Development." ACM Computing Surveys, vol. 25, No. 4, pp. 375-414. cited by other .
Zhou, Qin, J. Davidson, and A.A. Fouad. Feb. 1994. "Application of artificial neural networks in power system security and vulnerability assessment (Abstract)." IEEE Transactions on Power Systems, vol. 9, No. 1, pp. 525-532. cited by other .
Jackson, K. A., J. G. Hochberg, S. K. Wilhelmy, J. F. McClary, and G. G. Christoph. May 3-5, 1994. "Management issues in automated audit analysis (Abstract)." Los Alamos National Lab, Department of Energy computer security group training conference. Denver, Colorado. cited by other .
Jackson, K. A., M. C. Neuman, D. D. Simmonds, C. A. Stallings, and J. L. Thompson. May 1-4, 1995. "Misuse and intrusion detection at Los Alamos National Laboratory (Abstract)." Department of Energy computer security group training conference (17.sup.th). Milwaukee, Wisconsin. cited by other .
Casella, K. A. Sep. 17-22, 1995. "Security administration in an open networking environment (Abstract)." Proceedings of the Ninth Systems Administration Conference, pp. 67-73. Monterey, California. cited by other .
Doty, T. Fall 1995. "Test Driving SATAN (Abstract)." Computer Security Journal, vol. 11, No. 2, pp. 9-14. cited by other .
Karygiannis, T. Mar. 23-25, 1998. "Network security testing using mobile agents (Abstract)." Proceedings of the Third International Conference on the Practical Application of Intelligent Agents and a Multi-Agent Technology, pp. 625-626. London, United Kingdom. cited by other .
Gimble, T. F., M. F. Ugone, C. A. Miggins, D. L. Dixon, and K. Fitzpatrick. Jun. 3, 1998. "Information Assurance for the Defense Civilian Personnel Data System--Washington, Headquarters Services (Abstract)." Audit Report, Department of Defense, Office of the Inspector General. Washington, DC. cited by other .
Swiler, L. P. and C. Phillips. Jun. 30, 1998. "Graph-based system for network-vulnerability analysis (Abstract)." USDOE Office of Financial Management and Controller. Washington DC. cited by other .
Rudd, Alan, Joel McFarland, and Scott Olsen. Aug. 1998. "Managing security vulnerabilities in a networked world (Abstract)." Journal of Digital Imaging, vol. 11, No. 3, Suppl. 1, pp. 216-218. cited by other .
Mar. 1999. "DoD Information Technology Security Certificate and Accreditation Process (DITSCAP) (on CD-ROM) (Abstract)." Defense Information Systems Agency. Arlington, Virginia. cited by other .
Levine, Diane E. May 24, 1999. "CyberCop Patrols on Linux: Network Associates Scanner Detects Security, System Vulnerabilities." InformationWeek. cited by other .
Jun. 1999. "Intrusion detection [market survey] (Abstract)." Secure Computing (International Edition), pp. 58-60, 62, 64, 66, 68. United Kingdom. cited by other .
Rogers, Amy. Jul. 9, 1999. "Testing For Network Vulnerabilities: VARs Can Build Lucrative Practices Around Emerging Products." ChannelWEB. cited by other .
Mixer, R. A. Jul. 26, 1999. "Common Database Format for Network Security Data (Master's Thesis) (Abstract)." Air Force Institute of Technology, Wright Patterson AFB, Ohio. cited by other .
Apr. 2000. "Secure Strategies: A Year Long Series On The Fundamentals of Information Systems Security." www.infosecuritymag.com/articles/april00/f- eatures4.shtml. cited by other .
Mayer, A., A. Wool, and E. Ziskind. May 14-17, 2000. "Fang: A firewall analysis engine (Abstract)." Proceeding 2000 IEEE Symposium on Security and Privacy, pp. 177-187. Berkeley, California. cited by other .
Korzeniowski, Paul. Aug. 2000. "Audit and Assessment: Ironclad Security." www.infosecuritymag.com/articles/august00/columns6.shtml. cited by other .
Nov. 8, 2000. "BMC Software Automates Security Management for E-businesses; Provides Customers with Automated Access Management and E-business Information Security (Abstract)." Business Wire, p. 084. Houston, Texas. cited by other .
Mendelson, Edward. Dec. 5, 2000. "The Danger Within." PC Magazine. cited by other .
Dec. 18, 2000. "TruSecure Adopts Sanctum Inc.'s Web Application Security Audit Solution; Sanctum's Powerful Web Application Security Audit Software Complements TruSecure's Security Program (Abstract)." Business Wire, p. 0121. Santa Clara, California. cited by other .
Shipley, G. Jan. 8, 2001. "Vulnerability assessment scanners (Abstract)." Network Computing, vol. 12, No. 1, pp. 51-65. cited by other .
May 3, 2001. "Mixing Solutions to Garner Full Assessments: Vulnerability Assessment Tools." Channel WEB. cited by other .
Mohamed, Baith. Jun. 19-22, 2001. "An effective modified security auditing tool (SAT) (Abstract)." Proceedings of the 23.sup.rd International Conference on Information Technology Interfaces, part vol. 1, pp. 37-41. Pula, Croatia. cited by other .
Gilliam, D. P., J. C. Kelly, J. D. Powell, and M. Bishop. Jun. 20-22, 2001. "Development of a software security assessment instrument to reduce software security risk (Abstract)." Proceedings Tenth IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, pp. 144-149. Cambridge, Massachusetts. cited by other .
Langa, Fred. Jun. 11, 2001. "Good and Bad Online Security Check-Ups." InformationWeek.com. cited by other .
Chi, Sung-Do, Jong Sou Park, Ki-Chan Jung, and Jang-Se Lee. Jul. 2001. "Network security modeling and cyber attack simulation methodology (Abstract)." Information Security and Privacy. 6.sup.th Australasian Conference, ACISP 2001 Proceedings, pp. 320-333. Sidney, NSW, Australia. cited by other .
Jul. 12, 2001. "Xacta Web C & A.TM. User Notification Setup For Work Product Manager User Guide." Xacta Corporation. cited by other .
Aug. 22, 2001. "Xacta Detect Installation Guide." Xacta Corporation. cited by other .
Aug. 29, 2001. "Xacta Web C & A.TM. 2001 System Administrator Guide." Xacta Corporation. cited by other .
Aug. 29, 2001. "Xacta Web C & A.TM. 2001 Installation Guide." Xacta Corporation. cited by other .
XACTA.TM. Corporation. Aug. 2001. Xacta Web C&A.TM. 2001 User Guide: DITSCAP/NIACAP. Ashburn, VA: Xacta Corporation. cited by other .
Hulme, George V. Sep. 21, 2001. "Sanctum Adds Audit-Automation Tools to Security Software: Sanctum Introduces Enhanced Version of AppScan Software, Which Automates the Auditing of Web Applications for Holes that Hackers Could Use to Break Into Systems." InformationWeek.com. cited by other .
Wang, Rong, Feiyi Wang, and G. T. Byrd. Oct. 15-17, 2001. "Design and implementation of acceptance monitor for building scalable intrusion tolerant system (Abstract)." Proceedings Tenth Annual International Conference on Computer Communications and Networks, pp. 200-205. Scottsdale, Arizona. cited by other .
Fisher, Dennis. Oct. 29, 2001. "HP Expands Security Practice." EWEEK. cited by other .
Sidel, Scott and Andy Briney. Feb. 2002. "Patching Across the Enterprise" www.infosecuritymag.com/2002/feb/features_sidebar1.shtml. cited by other .
Hulme, George V. Mar. 14, 2002. "Hercules' Strength is Security Automation: Citadel's New Tool Gathers Info from Software-Vulnerability Scanners and Downloads Available Patches." InformationWeek.com. cited by other .
Hulme, George V. Mar. 18, 2002. "Herculean Help For Patching: Tool Collates Vulnerabilities and Aids with Patch Deployment." InformationWeek.com. cited by other .
Sturdevant, Cameron. Apr. 8, 2002. "Top Layer Testing." EWEEK. cited by other .
Machrone, Bill. Apr. 22, 2002. "Syscheck: System Tests and Port Scanners." ExtremeTech. cited by other .
Machrone, Bill. Apr. 22, 2002. "Syscheck: Network Tests." ExtremeTech. cited by other .
Fisher, Dennis. May 20, 2002. "Enforcer Keeps Far-flung Systems in Check." EWEEK. cited by other .
Dyck, Timothy. May 20, 2002. "App Scanning Helps Secure Weak Spots." EWEEK. cited by other .
Rapoza, Jim. May 20, 2002. "Foundscan Roots Out Problems." EWEEK. cited by other .
Musich, Paula. May 28, 2002. "Loudcloud Automates Patch Management." EWEEK. cited by other .
Karagiannis, Konstantinos. Jun. 20, 2002. "Finding and Fixing Network Vulnerabilities." PC Magazine. cited by other .
Jul. 29, 2002. "Best Practices and Beyond. (Industry Speaks)." Government Computer News,_vol. 21, No. 21, p. S14(6). cited by other .
James, Robert. Sep. 2002. "Hercules: Citadel provides some muscle to vulnerability scanners." www.infosecuritymag.com/2002/sep/testcenter.shtm- l. cited by other .
Briney, Andrew. Oct. 2002. "Automating Policies: New Software Tools Relieve the Headache of Policy Management." www.infosecuritymag.com/2002/- oct/policytools.shtml. cited by other .
Wood, Lamont. Oct. 24, 2002. "Smart Security: Network Scanners." Tech Update. cited by other .
Greenemeier, Larry. Nov. 4, 2002. "Certified Secure." InformationWeek.com. cited by other .
Hulme, George V. Nov. 11, 2002. "Discover Security Threats Faster: E-Security's New Tool Helps Companies Quickly Identify Problems Before an Attack Occurs." InformationWeek.com. cited by other .
Nov. 11, 2002. "Microsoft Gets Security Approval." Federal Computer Week. cited by other .
2002. "ActiveSentry.TM. 3.0 (Security You Can See)." Intranode Software Technologies, pp. 1-19. cited by other .
2002. "Managed Vulnerability Assessment: A Proactive Approach to Network Security." www.qualys.com. cited by other .
2002. "SecureScan SP." www.vigilante.com. cited by other .
2002. "Xacta Web C & A.TM. User Guide Version 3.3." Xacta Corporation. cited by other .
Linger, Richard C. Nov. 2000. "Systematic Generation of Stochastic Diversity as an Intrusion Barrier in Survivable Systems Software." Carnegie Mellon University. http://www.sei.cmu.edu/programs/nss/stochasti- c-divers.html. cited by other .
The Software Engineering Institute (SEI). Nov. 2000. "Operationally Critical Threat, Asset, and Vulnerability Evaluation (Octave) Framework. Version 1.0." Carnegie Mellon University. http://www.sei.cmu.edu/publicat- ions/documents/99.reports/99tr017/99tr017chap01.html. cited by other .
The Software Engineering Institute (SEI). Nov. 2000. "Survivable Network Analysis." Carnegie Mellon University. http://www.sei.cmu.edu/organizatio- n/programs/nss/analysis-method.html. cited by other .
XACTA.TM. Corporation. Sep. 2000. Web C&A.TM.. Ashburn, VA: Xacta Corporation. cited by other .
Winkler, Ira, Al Berg, George Kurtz, Chris Prosise, and Dan Swanson. Jul. 2000. "Audits, Assessments & Tests (Oh My)." http://www.infosecuritymag.c- om/july2000/audits.html. cited by other .
Dorobek, Christopher J. May 2000. "Project Matrix Identifies How Systems Interact." Government Computer News. Post--Newsweek Tech Media Group, Inc. http://www.gcn.com/vol19_no11/news/1974-1.html. cited by other .
Government Computer News. May 2000. "CIO Council Launches Security Best Practices Web Site." Post--Newsweek Tech Media Group, Inc. http://www.gcn.com/vol1_no1/daily-updates/2067-1.html. cited by other .
Government Computer News. Aug. 1999. "Scanner Suite Increases its Risk Assessment Tool Features." Post--Newsweek Tech Media Group, Inc. http://www.gcn.com/vol18_no28/com/495-1.html. cited by other .
FDIC. Jul. 1999. "Risk Assessment Tools and Practices for Information System Security." http://www.fdic.gov/news/financial/1999/FIL9968a.html. cited by other .
Fisher, David A., and Howard F. Lipson. Jan. 1999. "Emergent Algorithms: A New Method for Enhancing Survivability in Unbounded Systems." Proceedings of the Hawaii International Conference On System Sciences. Maui, Hawaii: IEEE. http://www.sei.cmu.edu/organization/programs/nss/emergent-algor.htm- l. cited by other .
Ellison, R. J., R. C. Linger, T. Longstaff, and N. R. Mead. Sep. 1998. A Case Study in Survivable Network System Analysis. Pittsburgh, PA: Carnegie Mellon Software Engineering Institute. cited by other .
Linger, R. C., N. R. Mead, and H. F. Lipson. 1998. "Requirements Definition for Survivable Network Systems." IEEE. http://www.sei.cmu.edu/- programs/nss/icre.html. cited by other .
Ellison, Robert J., David A. Fisher, Richard C. Linger, Howard F. Lipson, Thomas A. Longstaff, and Nancy R. Mead. 1998. "Survivability: Protecting Your Critical Systems." Proceedings of the International Conference on Requirements Engineering. Colorado Springs, CO: IEEE. http://www.sei.cmu.edu/programs/nss/project-critical-systems.html. cited by other .
Valletta, Anthony M. Dec. 1997. "DoD Information Technology Security Certification and Accreditation Process (DITSCAP)." Department of Defense INSTRUCTION. Doc. No . 5200.40. cited by other .
Bassham, Lawrence E., and Timothy Polk. "Threat Assessment of Malicious Code and Human Computer Threats." Oct. 1992. National Institute of Standards and Technology. http://www.it.kth.se/.about.cwe/wastebin/threat- -assess.html. cited by other .
"System Accreditation." http://bsp.cio.gov/getfile.cfm?messageid=000. cited by other .
Ellison, Robert J., Richard C. Linger, Thomas Longstaff, and Nancy R. Mead. "Survivable Network System Analysis: A Case Study." Carnegie Mellon University. cited by other .
International Search Report for PCT/US03/37603 dated Oct. 25, 2004. cited by other.~
Primary Examiner: McElheny, Jr.; Donald E.
Assistant Examiner: Suarez; Felix
Parent Case Text


RELATED APPLICATIONS

This application is a Continuation-in-Part of application Ser. No. 09/794,386, filed Feb. 28, 2001, entitled "System, Method And Medium For Certifying And Accrediting Requirements Compliance", which in turn claims priority to application Ser. No. 60/223,982, filed Aug. 9, 2000, entitled "Web Certification and Accreditation System, Method and Medium", each of which is assigned to the assignee of this application and incorporated herein by reference.
Claims

Having thus described our invention, what we claim as new and desire to secure by Letters Patent is as follows:
1. A computer-assisted method of generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said method comprising the steps of: a) collecting information descriptive of at least a hardware and/or software specification for the at least one device; b) selecting at least one predefined standard, regulation and/or requirement with which the target system is to comply; c) associating hardware and/or software information pertaining to the at least one device, collected in said step a), with at least one pre-defined platform category; d) for each of said at least one platform category, determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and e) generating one or more test procedures as determined in said step d) for each platform category.

2. The method according to claim 1 further comprising the step of associating at least one application software program with at least one platform category, the association indicating that the application program is typically installed on devices belonging to the platform category.

3. The method according to claim 1 wherein said step a) information is collected, for the target system comprising a plurality of devices within a network, by at least one of electronic discovery via a network and manual entry.

4. The method according to claim 3 wherein electronic discovery comprises an enterprise management system.

5. The method according to claim 3 wherein the information collected in said step a) pertains to at least one of: an internet protocol address, a hostname, a media access control address, an operating system name, and an operating system version.

6. The method according to claim 1 further comprising the step of editing said step a) information descriptive of at least the hardware specification and the operating system of each device.

7. The method according to claim 1 wherein the platform categories comprise at least one of desktop computer, laptop computer, mainframe computer, hub, handheld device, and other.

8. The method according to claim 1 further comprising the step of printing at least one test procedure generated in said step e).

9. The method according to claim 1 wherein said step e) generates one test procedure for a platform category when there are no devices associated therewith, and generates one test procedure for each device associated with a platform category having an indication that such device is to be tested.

10. The method according to claim 1 further comprising the steps of: f) performing the steps associated with the test procedures generated in said step e) to determine whether the target system passes or fails the at least one the test procedure; g) generating a score for each of a plurality of threat elements, each score indicating a likelihood of that threat element affecting and/or impacting the target system; and h) (1) obtaining a threat correlation indication associated with said at least one test procedure, wherein said threat correlation indication indicates a relative potential of one or more given threats to exploit a vulnerability caused by a failure of the at least one test procedure, and (2) determining a risk assessment by comparing each score generated in said step g) with a corresponding threat correlation indication of said step h) (1).

11. The method according to claim 10 wherein said scores for said step g) comprise at least one of: i) negligible, wherein negligible indicates that the threat element is not applicable or has negligible likelihood of occurrence; ii) low, wherein low indicates that the threat element has a relatively low likelihood of occurrence; iii) medium, wherein medium indicates that the threat element has a medium likelihood of occurrence; and iv) high, wherein high indicates that the threat element has a relatively high likelihood of occurrence.

12. The method according to claim 10 wherein said step g) threat elements comprise at least one of natural disaster elements, system failure elements, environmental failure elements, unintentional human elements, and intentional human elements.

13. The method according to claim 12 wherein the natural disaster threat elements comprise at least one of fire, flood, earthquake, volcano, tornado and lighting elements.

14. The method according to claim 12 wherein the system failure threat elements comprise at least one of a hardware failure, a power failure, and a communication link failure.

15. The method according to claim 12 wherein the environmental failure threat elements comprise at least one of temperature, power, humidity, sand, dust, shock, and vibration.

16. The method according to claim 12 wherein the human unintentional threat element comprises at least one of a software design error, a system design error, and an operator error.

17. The method according to claim 12 wherein the human intentional threat elements comprise at least one of an authorized system administrator, an authorized maintenance personnel, an authorized user, a terrorist, a hacker, a saboteur, a thief, and a vandal.

18. The method according to claim 10 wherein said step h) (1) threat correlation indication comprises at least one of the following scores: i) negligible, wherein negligible indicates that the threat is not applicable to the vulnerability; ii) low, wherein low indicates that the threat has a low potential to exploit the vulnerability; iii) medium, wherein medium indicates that the threat has a potential to exploit the vulnerability; and iv) high, wherein high indicates that the threat has a relatively high potential to exploit the vulnerability.

19. The method according to claim 18 wherein the risk assessment in said step h) (2) is determined in accordance with the following steps: a) for each element in the project threat profile and corresponding element in the threat correlation pattern; 1) if a threat element as determined in said step g) is negligible and a corresponding element in the threat correlation indication as determined in said step h) is anything, then the overall risk of the element is negligible; 2) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is negligible, then the overall risk of the element is low; 3) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is low, then the overall risk of the element is low; 4) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is medium, then the overall risk of the element is low; 5) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is high, then the overall risk of the element is medium; 6) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is negligible, then the overall risk of the element is negligible; 7) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is low, then the overall risk of the element is low; 8) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is medium, then the overall risk of the element is medium; 9) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is high, then the overall risk of the element is medium; 10) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is negligible, then the overall risk of the element is negligible; 11) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is low, then the overall risk of the element is medium; 12) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is medium, then the overall risk of the element is high; and 13) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is high, then the overall risk of the element is high; and b) selecting the risk profile for the failed test procedure as being the highest overall risk element.

20. The method according to claim 19 further comprising the step of determining an overall system risk.

21. The method according to claim 20 wherein the overall target system risk is the highest overall risk element of each of one or more failed test procedures.

22. The method according to claim 20 further comprising the step of printing a documentation package that will enable a determination to be made whether the target system complies with the at least one predefined standard, regulation and/or requirement selected in said step b).

23. The method according to claim 22 wherein the documentation package includes a risk assessment for at least one failed test procedure.

24. The method according to claim 22 wherein the documentation package includes an overall target system risk.

25. In a general purpose computing system, a computer-assisted method of generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said method comprising the steps of: a) collecting information descriptive of at least a hardware and/or software specification for the at least one device; b) selecting at least one predefined standard, regulation and/or requirement with which the target system is to comply; c) associating hardware and/or software information pertaining to the at least one device, collected in said step a), with at least one pre-defined platform category; d) for each of said at least one platform category, determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and e) generating one or more test procedures as determined in said step d) for each platform category.

26. The system according to claim 25 further comprising the step of associating at least one application software program with at least one platform category, the association indicating that the application program is typically installed on devices belonging to the platform category.

27. The system according to claim 25 wherein said step a) information is collected, for the target system comprising a plurality of devices within a network, by at least one of electronic discovery via a network and manual entry.

28. The system according to claim 27 wherein electronic discovery comprises an enterprise management system.

29. The system according to claim 27 wherein the information collected in said step a) pertains to at least one of: an internet protocol address, a hostname, a media access control address, an operating system name, and an operating system version.

30. The system according to claim 25 further comprising the step of editing said step a) information descriptive of at least the hardware specification and the operating system of each device.

31. The system according to claim 25 wherein the platform categories comprise at least one of desktop computer, laptop computer, mainframe computer, hub, handheld device, and other.

32. The system according to claim 25 further comprising the step of printing at least one test procedure generated in said step e).

33. The system according to claim 25 wherein said step e) generates one test procedure for a platform category when there are no devices associated therewith, and generates one test procedure for each device associated with a platform category having an indication that such device is to be tested.

34. The system according to claim 25 further performing the steps of: f) performing the steps associated with the test procedures generated in said step e) to determine whether the target system passes or fails the at least one the test procedure; g) generating a score for each of a plurality of threat elements, each score indicating a likelihood of that threat element affecting and/or impacting the target system; and h) (1) obtaining a threat correlation indication associated with said at least one test procedure, wherein said threat correlation indication indicates a relative potential of one or more given threats to exploit a vulnerability caused by a failure of the at least one test procedure, and (2) determining a risk assessment by comparing each score generated in said step g) with a corresponding threat correlation indication of said step h) (1).

35. The system according to claim 34 wherein said scores for said step g) comprise at least one of: i) negligible, wherein negligible indicates that the threat element is not applicable or has negligible likelihood of occurrence; ii) low, wherein low indicates that the threat element has a relatively low likelihood of occurrence; iii) medium, wherein medium indicates that the threat element has a medium likelihood of occurrence; and iv) high, wherein high indicates that the threat element has a relatively high likelihood of occurrence.

36. The system according to claim 34 wherein said step g) threat elements comprise at least one of natural disaster elements, system failure elements, environmental failure elements, unintentional human elements, and intentional human elements.

37. The system according to claim 36 wherein the natural disaster threat elements comprise at least one of fire, flood, earthquake, volcano, tornado and lighting elements.

38. The system according to claim 36 wherein the system failure threat elements comprise at least one of a hardware failure, a power failure, and a communication link failure.

39. The system according to claim 36 wherein the environmental failure threat elements comprise at least one of temperature, power, humidity, sand, dust, shock, and vibration.

40. The system according to claim 36 wherein the human unintentional threat element comprises at least one of a software design error, a system design error, and an operator error.

41. The system according to claim 36 wherein the human intentional threat elements comprise at least one of an authorized system administrator, an authorized maintenance personnel, an authorized user, a terrorist, a hacker, a saboteur, a thief, and a vandal.

42. The system according to claim 34 wherein said step h) (1) threat correlation indication comprises at least one of the following scores: i) negligible, wherein negligible indicates that the threat is not applicable to the vulnerability; ii) low, wherein low indicates that the threat has a low potential to exploit the vulnerability; iii) medium, wherein medium indicates that the threat has a potential to exploit the vulnerability; and iv) high, wherein high indicates that the threat has a relatively high potential to exploit the vulnerability.

43. The system according to claim 42 wherein the risk assessment in said step h) (2) is determined in accordance with the following steps: a) for each element in the project threat profile and corresponding element in the threat correlation pattern: 1) if a threat element as determined in said step g) is negligible and a corresponding element in the threat correlation indication as determined in said step h) (2) is anything, then the overall risk of the element is negligible; 2) if a threat element as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) (2) is negligible, then the overall risk of the element is low; 3) if a threat element as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) (2) is low, then the overall risk of the element is low; 4) if a threat element as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) (2) is medium, then the overall risk of the element is low; 5) if a threat element as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) (2) is high, then the overall risk of the element is medium; 6) if a threat element as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) (2) is negligible, then the overall risk of the element is negligible; 7) if a threat element as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) (2) is low, then the overall risk of the element is low; 8) if a threat element as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) (2) is medium, then the overall risk of the element is medium; 9) if a threat element as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) (2) is high, then the overall risk of the element is medium; 10) if a threat element as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) (2) is negligible, then the overall risk of the element is negligible; 11) if a threat element as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) (2) is low, then the overall risk of the element is medium; 12) if a threat element as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) (2) is medium, then the overall risk of the element is high; and 13) if a threat element as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) (2) is high, then the overall risk of the element is high; and b) selecting the risk profile for the failed test procedure as being the highest overall risk element.

44. The system according to claim 43, further comprising the step of determining an overall system risk.

45. The system according to claim 44 wherein the overall target system risk is the highest overall risk element of each of one or more failed test procedures.

46. The system according to claim 44 further comprising the step of printing a documentation package that will enable a determination to be made whether the target system complies with the at least one predefined standard, regulation and/or requirement selected in said step b).

47. The system according to claim 46 wherein the documentation package includes a risk assessment for at least one failed test procedure.

48. The system according to claim 46 wherein the documentation package includes an overall system risk.

49. A computer program medium storing computer instructions therein for instructing a computer to perform a computer-implemented and user assisted process of generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said program medium comprising the steps of: a) collecting information descriptive of at least a hardware and/or software specification for the at least one device; b) selecting at least one predefined standard, regulation and/or requirement with which the target system is to comply; c) associating hardware and/or software information pertaining to the at least one device, collected in said step a), with at least one pre-defined platform category; d) for each of said at least one platform category, determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and e) generating one or more test procedures as determined in said step d) for each platform category.

50. The computer program medium according to claim 49 further comprising the step of associating at least one application software program with at least one platform category, the association indicating that the application program is typically installed on devices belonging to the platform category.

51. The computer program medium according to claim 49 wherein said step a) information is collected, for the target system comprising a plurality of devices within a network, by at least one of electronic discovery via a network and manual entry.

52. The computer program medium according to claim 51 wherein electronic discovery comprises an enterprise management system.

53. The computer program medium according to claim 51 wherein the information collected in said step a) pertains to at least one of: an internet protocol address, a hostname, a media access control address, an operating system name, and an operating system version.

54. The computer program medium according to claim 49 further comprising the step of editing said step a) information descriptive of at least the hardware specification and the operating system of each device.

55. The computer program medium according to claim 49 wherein the platform categories comprise at least one of desktop computer, laptop computer, mainframe computer, hub, handheld device, and other.

56. The computer program medium according to claim 49 further comprising the step of printing at least one test procedure generated in said step e).

57. The computer program medium according to claim 49 wherein said step e) generates one test procedure for a platform category when there are no devices associated therewith, and generates one test procedure for each device associated with a platform category having an indication that such device is to be tested.

58. The computer program medium according to claim 49 further comprising the steps of: f) performing the steps associated with the test procedures generated in said step e) to determine whether the target system passes or fails the at least one the test procedure; g) generating a score for each of a plurality of threat elements, each score indicating a likelihood of that threat element affecting and/or impacting the target system; and h) (1) obtaining a threat correlation indication associated with said at least one test procedure, wherein said threat correlation indication indicates a relative potential of one or more given threats to exploit a vulnerability caused by a failure of the at least one test procedure, and (2) determining a risk assessment by comparing each score generated in said step g) with a corresponding threat correlation indication of said step h) (1).

59. The computer program medium according to claim 58 wherein said scores for said step g) comprise at least one of: i) negligible, wherein negligible indicates that the threat element is not applicable or has negligible likelihood of occurrence; ii) low, wherein low indicates that the threat element has a relatively low likelihood of occurrence; iii) medium, wherein medium indicates that the threat element has a medium likelihood of occurrence; and iv) high, wherein high indicates that the threat element has a relatively high likelihood of occurrence.

60. The computer program medium according to claim 58 wherein said step g) threat elements comprise at least one of natural disaster elements, system failure elements, environmental failure elements, unintentional human elements, and intentional human elements.

61. The computer program medium according to claim 60 wherein the natural disaster threat elements comprise at least one of fire, flood, earthquake, volcano, tornado and lighting elements.

62. The computer program medium according to claim 60 wherein the system failure threat elements comprise at least one of a hardware failure, a power failure, and a communication link failure.

63. The computer program medium according to claim 60 wherein the environmental failure threat elements comprise at least one of temperature, power, humidity, sand, dust, shock, and vibration.

64. The computer program medium according to claim 60 wherein the human unintentional threat element comprises at least one of a software design error, a system design error, and an operator error.

65. The computer program medium according to claim 60 wherein the human intentional threat elements comprise at least one of an authorized system administrator, an authorized maintenance personnel, an authorized user, a terrorist, a hacker, a saboteur, a thief, and a vandal.

66. The computer program medium according to claim 60 wherein said step h) (1) threat correlation indication comprises at least one of the following scores: i) negligible, wherein negligible indicates that the threat is not applicable to the vulnerability; ii) low, wherein low indicates that the threat has a low potential to exploit the vulnerability; iii) medium, wherein medium indicates that the threat has a potential to exploit the vulnerability; and iv) high, wherein high indicates that the threat has a relatively high potential to exploit the vulnerability.

67. The computer program medium according to claim 66 wherein the risk assessment in said step h) (2) is determined in accordance with the following steps: a) for each element in the project threat profile and corresponding element in the threat correlation pattern: 1) if a threat element score as determined in said step g) is negligible and a corresponding element in the threat correlation indication as determined in said step h) is anything, then the overall risk of the element is negligible; 2) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is negligible, then the overall risk of the element is low; 3) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is low, then the overall risk of the element is low; 4) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is medium, then the overall risk of the element is low; 5) if a threat element score as determined in said step g) is low and the corresponding element in the threat correlation indication as determined in said step h) is high, then the overall risk of the element is medium; 6) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is negligible, then the overall risk of the element is negligible; 7) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is low, then the overall risk of the element is low; 8) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is medium, then the overall risk of the element is medium; 9) if a threat element score as determined in said step g) is medium and the corresponding element in the threat correlation indication as determined in said step h) is high, then the overall risk of the element is medium; 10) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is negligible, then the overall risk of the element is negligible; 11) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is low, then the overall risk of the element is medium; 12) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is medium, then the overall risk of the element is high; and 13) if a threat element score as determined in said step g) is high and the corresponding element in the threat correlation indication as determined in said step h) is high, then the overall risk of the element is high; and b) selecting the risk profile for the failed test procedure as being the highest overall risk element.

68. The computer program medium according to claim 67, further comprising the step of determining an overall system risk.

69. The computer program medium according to claim 68 wherein the overall target system risk is the highest overall risk element of each of one or more failed test procedures.

70. The computer program medium according to claim 68 further comprising the step of printing a documentation package that will enable a determination to be made whether the target system complies with the at least one predefined standard, regulation and/or requirement selected in said step b).

71. The computer program medium according to claim 70 wherein the documentation package includes a risk assessment for at least one failed test procedure.

72. The computer program medium according to claim 70 wherein the documentation package includes an overall system risk.

73. A system for generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said system comprising: a) a discovery engine that scans the target system for the hardware configuration, operating system and/or application programs of each of the at least one device; b) at least one storage medium for storing thereon at least: (i) at least one predefined standard, regulation and/or requirement with which the segment is to comply; and (ii) data pertaining to at least one platform category, each platform category having associated therewith one or more devices having at least a hardware specification and an operating system; and c) decision logic for determining which of zero or more test procedures will be used to test each of the at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement.

74. The system according to claim 73 further comprising a printer for printing the one or more test procedures.

75. The system according to claim 73 wherein the scanner collects for each device information pertaining to at least one of: an IP address, a hostname, a media access control address, operating system name, operating system version.

76. The system according to claim 73 wherein the scanner further collects information pertaining to at least one of application software, hard disk drive capacity, device manufacturer, and device model.

77. A system for generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said system comprising: a) a discovery engine that scans the target system information descriptive of at least a hardware and/or software specification for the at least one device; b) a storage medium for storing at least one predefined standard, regulation and/or requirement with which the target system is to comply; and c) a plurality of information entities, each of said plurality of information entities storing data pertaining to at least one predefined platform category, each platform category defining one or more devices having at least a hardware specification and an operating system; and d) decision logic for determining which of one or more test procedures will be used to test each platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement.

78. The system according to claim 77 wherein said plurality of information entities comprise relational database tables.

79. The system according to claim 78 wherein said relational database tables comprise tables for defining: a) each of the at least one platform category; b) each of the at least one device; c) each application program; d) each defined association between an application program and a platform category, wherein each such association indicates that the application program is typically installed on devices belonging to the platform category; e) each defined association between an application program and a device, wherein each such association indicates that the application program is actually installed on the device; and g) each standard operating system.

80. A system for generating at least one test procedure for a target system comprising at least one device, each of the at least one device comprising a combination of hardware and software, said system comprising: a) a discovery engine that scans the target system for at least a hardware and/or software specification for the at least one device; b) at least one storage medium for storing thereon: (i) at least one predefined standard, regulation and/or requirement with which the target system is to comply; and (ii) data pertaining to at least one platform category, each platform category having associated therewith one or more devices having at least a hardware specification and an operating system; and c) decision logic for: i) associating hardware and/or software information pertaining to the at least one device, collected by said discovery engine, with at least one pre-defined platform category; ii) for each of said at least one platform category, determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and iii) generating one or more test procedures as determined in said step ii) for each platform category.

81. The system according to claim 80 further comprising a printer for printing the one or more test procedures.

82. The system according to claim 80 wherein said network discovery engine collects for each device information pertaining to at least one of: an IP address, a hostname, a media access control address, operating system name, operating system version.

83. The system according to claim 80 wherein said network discovery engine further collects information pertaining to at least one of application software, hard disk drive capacity, device manufacturer, and device model.

84. A system for generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said system comprising: a) means for scanning the target system information descriptive of at least a hardware and/or software specification for the at least one device; b) means for storing at least one predefined standard, regulation and/or requirement with which the target system is to comply; and c) means for associating hardware and/or software information pertaining to the at least one device, collected by said means for scanning, with at least one pre-defined platform category; d) for each of said at least one platform category, means for determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and e) means for generating one or more test procedures as determined in said step d) for each platform category.

85. A system for generating at least one test procedure for a target system comprising at least one device, each of the at least one device comprising a combination of hardware and software, said system comprising: a) means for scanning the target system for at least a hardware and/or software specification for the at least one device; b) means for storing thereon: (i) at least one predefined standard, regulation and/or requirement with which the segment is to comply; and (ii) data pertaining to at least one platform category, each platform category having associated therewith one or more devices having at least a hardware specification and an operating system; and c) means for associating hardware and/or software information pertaining to the at least one device, collected by said discovery engine, with at least one pre-defined platform category; d) for each of said at least one platform category, means for determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and e) means for generating one or more test procedures, as determined by said means for determining, for each platform category.

86. A computer-assisted method of generating at least one test procedure for a target system having at least one device capable of being identified, each of the at least one device having hardware and/or software, said method comprising the steps of: a) collecting information descriptive of at least a hardware and/or software specification for the at least one device; b) selecting at least one predefined standard, regulation and/or requirement with which the target system is to comply; c) associating hardware and/or software information pertaining to the at least one device, collected in said step a), with at least one pre-defined platform category; d) for each of said at least one platform category, determining which of one or more test procedures will be used to test hardware and/or software associated with said at least one platform category based on a mapping between the test procedures and the at least one predefined standard, regulation and/or requirement; and e) generating one or more test procedures as determined in said step d) for each platform category; f) performing the steps associated with the test procedures generated in said step e) to determine whether the target system passes or fails the at least one the test procedure; g) generating a score for each of a plurality of threat elements, each score indicating a likelihood of that threat element affecting and/or impacting the target system; and h) (1) obtaining a threat correlation indication associated with said at least one test procedure, wherein said threat correlation indication indicates a relative potential of one or more given threats to exploit a vulnerability caused by a failure of the at least one test procedure, and (2) determining a risk assessment by comparing each score generated in said step g) with a corresponding threat correlation indication of said step h) (1).
Description
BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to the field of certifications and accreditation (C&A) and, more particularly, to a computer-implemented system, method and medium for C&A that automates target system configuration discovery and formats the network or other target system configuration data obtained for use with a C&A system that can utilize the data to assess the risk of and/or determine the suitability of the network or target system to comply with at least one predefined standard, regulation and/or requirement.

2. Background Description

The general purpose of C&A is to certify that automated information systems adequately protect information in accordance with data sensitivity and/or classification levels. In accordance with Department of Defense (DoD) Instruction 5200.40, dated Dec. 30, 1997, entitled DoD Information Technology Security Certification and Accreditation Process (DITSCAP), which is incorporated herein by reference in its entirety, certification can be defined as the comprehensive evaluation of the technical and non-technical features of an information technology (IT) system and other safeguards, made in support of the accreditation process, to establish the extent that a particular design and implementation meets a set of specified security requirements. Similarly, as used herein, accreditation can be defined as a formal declaration by a designated approving authority that an IT system is approved to operate in a particular security mode using a prescribed set of safeguards at an acceptable level of risk. In general, DISTSCAP is utilized by the DoD for identifying and documenting threats and vulnerabilities that pose risk to critical information systems. DITSCAP compliance generally means that security risk posture is considered acceptable and that potential liability for system "owners" is mitigated.

The C&A process typically involves a number of policies, regulations, guidelines, best practices, etc. that serve as C&A criteria. Conventionally, the C&A process is typically a labor intensive exercise that can require multiple skill sets over a period of time typically spanning 6-12 months. In particular, collecting data pertaining to a network configuration undergoing C&A is done manually by, for example, entering a system hardware configuration, operating system and/or application software package(s) associated with each node (e.g., IP address) on a network undergoing C&A. Several organizations and/or individuals may also be involved in the processes of selecting applicable standards, regulations and/or test procedures, and assembling test results and other information into a DITSCAP compliant package. There is therefore a need to substantially automate the network configuration data collection process, and format the data so that it can be used with, for example, a C&A system that substantially automates the process of performing security risk assessments, certification test procedure development, system configuration guidance, and residual risk acceptance.

SUMMARY OF THE INVENTION

The present invention provides a system, method and medium that substantially automates network configuration discovery and formats the network configuration data for use with an automated C&A system, where the C&A system assesses the risk of and/or determines the suitability of a target system (e.g., one or more devices) to comply with at least one predefined standard, regulation and/or requirement.

In an exemplary embodiment, the data collection process is automated and formatted in a manner that facilitates use with DoD's DITSCAP requirements. The present invention is not, however, limited to a DoD environment, and may also be used in non-DoD government as well as civilian/private sector organizations requiring risk management and guidance. For example, the system and method according to the present invention can also be used to automate the National Information Assurance Certification and Accreditation Process (NIACAP).

An exemplary embodiment according to the present invention contemplates a system, method and medium that automates the network configuration information gathering process, and maps the configuration to, for example, a database table format that can be used by a C&A system such as that originally disclosed in application Ser. No. 09/794,386. An exemplary embodiment according to the present invention also contemplates a browser based solution that automates the DITSCAP process. The browser is preferably directed to five primary elements: 1) gathering information, 2) analyzing requirements, 3) testing requirements, 4) performing risk assessment, and 5) generating certification documentation based on an assessment of the first four elements.

The information gathered primarily relates to a description of the system to be certified, and its respective components and operating environment (e.g., workstation manufacturer and model and/or other hardware characteristics/parameters, operating system and version, secret, or top secret operating environment, etc.). The requirements analysis generally involves selecting by the system, or optionally by the user, a list of standards and/or regulations that the system must or should comply with. Once system/network information is gathered and the requirements analysis is provided, the system can intelligently select a set of test procedures against which the system is tested. Upon completion of testing, the risk assessment provides as output an estimate of the risk level for each individual test failed. Each of the failed tests are also collectively considered and used to evaluate the risk level of the network undergoing C&A (i.e., target system). Then, documentation can be printed that includes information pertaining to the first four elements that would enable an accreditation decision to be made based on the inputs and outputs respectively provided and generated in the first four elements.

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways.

BRIEF DESCRIPTION OF THE DRAWINGS

The Detailed Description including the description of a preferred structure as embodying features of the invention will be best understood when read in reference to the accompanying figures wherein:

FIG. 1 is an exemplary high level flowchart of a method contemplated by at least some embodiments of the present invention;

FIG. 2 is an exemplary introductory screen shot corresponding to the flow chart provided in FIG. 1;

FIG. 3 is an exemplary user login screen shot;

FIG. 4 is an exemplary project definition screen shot;

FIG. 5 is an exemplary project definition screen shot showing user selection of either civilian or Department of Defense applicability;

FIG. 6 is an exemplary block diagram of a certification and accreditation (C&A) system assessment aspect and an associated network and/or target system contemplated by at least some embodiments of the present invention;

FIG. 7 is an exemplary block diagram of a target system discovery engine contemplated by at least some embodiments of the present invention;

FIG. 8 is an exemplary embodiment of a target system configuration file format;

FIG. 9 is an exemplary illustration of the target system scanning and profiling relationships;

FIG. 10 is an exemplary project hardware screen shot;

FIG. 11 is an exemplary flow chart of the requirements analysis process as contemplated by at least some embodiments of the present invention;

FIG. 12 is an exemplary screen shot used to generate a security requirements traceability matrix (SRTM);

FIG. 13 is an exemplary screen shot showing a display of a SRTM;

FIG. 14 is an exemplary flow chart illustrating the testing process as contemplated by at least some embodiments of the present invention;

FIG. 15 is an exemplary screen shot showing how test plan information can be edited;

FIG. 16 is an exemplary screen shot illustrating how a user can select an existing test procedure and/or create a new test procedure and associate the test procedure(s) with one or more requirements;

FIG. 17 is an exemplary flow diagram of a method for generating equipment tests contemplated by at least some embodiments of the present invention;

FIG. 18 is an exemplary screen shot showing how a user can add a test procedure;

FIG. 19 is an exemplary screen shot showing how a user can edit a test procedure;

FIGS. 20A and 20B are exemplary screen shots that enable a user to enter test results;

FIG. 21 is an exemplary high level flow diagram of the risk assessment method according to at least some embodiments contemplated by the present invention;

FIG. 22 is a table showing three different levels of illustrative threat categories;

FIG. 23 is an exemplary screen shot showing a portion of the illustrative threat categories of FIG. 22;

FIG. 24 is an exemplary scheme by which the risk of an individual test failure is assessed in accordance with at least some embodiments contemplated by the present invention;

FIG. 25 is an exemplary flow diagram of a method of assessing overall system risk in accordance with at least some embodiments contemplated by the present invention;

FIG. 26 is an exemplary flow diagram of the publishing process in accordance with at least some embodiments contemplated by the present invention;

FIG. 27 is an exemplary screen shot showing how a user can select a portion of a document for publishing;

FIG. 28 is an exemplary screen shot that enables a user to edit and/or view a portion of a document prior to publishing;

FIG. 29 is an exemplary screen shot showing how a user can select a portion of a document for publishing;

FIG. 30 is an exemplary screen shot illustrating how a user can publish a portion of a document;

FIG. 31 illustrates one example of a central processing unit for implementing a computer process in accordance with a computer implemented stand-alone embodiment of the present invention;

FIG. 32 illustrates one example of a block diagram of internal hardware of the central processing unit of FIG. 31;

FIG. 33 is an illustrative computer-readable medium upon which computer instructions can be embodied; and

FIG. 34 is an exemplary entity relationship diagram that describes the attributes of entities and the relationship among them.

DETAILED DESCRIPTION

Referring now to the drawings, and more particularly to FIG. 1, a high level flow diagram is shown that provides an overview of the method according to the present invention. In the first step, information is gathered pertaining to the system or network undergoing C&A. This is indicated by a block 100. The information gathered typically relates to a description of the system to be certified, and its respective components and operating environment (e.g., workstation manufacturer and model, operating system and version, secret, or top secret operating environment, etc.). As will be described in further detail herein, at least some embodiments of the present invention advantageously automate collection of certain information pertaining to the network undergoing C&A. Alternatively, the information pertaining to the network undergoing C&A can be manually entered.

As indicated above, aspects of at least some embodiments of the present invention are described in accordance with DoD's DITSCAP requirements. However, it should be understood that such description is only by way of example, and that the present invention contemplates use with regard to any number of types of requirements or environments. In addition, within its use with regard to DITSCAP requirements, it should be understood that many of the various aspects and selection options are also exemplary, as is the fact that information is shown as being entered via a web browser.

The requirements analysis generally involves selecting (by a human and/or some automated procedure) a list of standards and/or regulations that the system must, or should, comply with. This is indicated by a block 102. Optionally, selection of additional standards/regulations and/or requirements by a user is also contemplated. At least some embodiments of the present invention then contemplate automatically displaying/listing each requirement that comprises the current security requirements traceability matrix (SRTM), which is derived from the selected set of standards and/or regulations that the system must comply with. Additionally, the user will be able to customize the current SRTM by either adding, editing and/or deleting requirements. As known to those skilled in the art, a SRTM can be a table used to trace project lifecycle activities (e.g., testing requirements) and/or work products to the project requirements. The SRTM can be used to establish a thread that traces, for example, testing and/or compliance requirements from identification through implementation. A SRTM can thus be used to ensure that project objectives and/or requirements are satisfied and/or completed.

Once information is gathered 100 and the requirements analysis 102 is provided, the system intelligently selects a set of test procedures against which the system is tested, as indicated by block 104. The test procedures are selected in a manner so that successful completion of the test procedures will render the system undergoing C&A to satisfy the SRTM requirements.

Upon completion of testing 104, the risk assessment step (as indicated by a block 106) then involves assessing for each test failure (should any exist) the vulnerability of the system, as well as the level of the threat as determined by the information gathered. The risk assessment 106 provides as output an estimate of the risk level for each individual test failed. Each of the failed tests are also collectively considered and used to evaluate the risk level of the system as a whole. Then, documentation can be optionally printed 108 that includes information pertaining to the first four elements that would enable an accreditation decision to be made based on the inputs and outputs respectively provided and generated in the first four blocks (i.e., 100, 102, 104, 106). Each block shown in FIG. 1 (i.e., 100, 102, 104, 106 and 108) will be discussed in further detail herein. FIG. 2 is an exemplary screen shot corresponding to the blocks (100, 102, 104, 106, 108) provided in FIG. 1. Further information pertaining to the system and method according to the present invention can be found in the following document: WEB C&A.TM., dated 20 Sep. 2000, available from Xacta Corporation, Ashburn, Va. A copy of this document is incorporated herein by reference in its entirety.

FIG. 3 shows an exemplary access control screen shot (e.g., for access to some or all aspects of the present invention as indicated above). Each user can optionally be required to input a valid user name and password, which provides them with access to only the information for which they are responsible. The system can also optionally exclude the password and access feature, providing users access to a set of predetermined and/or default information.

Information Gathering

FIGS. 4-5 show selected exemplary screen shots of aspects of the information gathering 100 process. Specifically, FIG. 4 shows project definition information, which is assumed to have been selected by tab 402. Fields such as project name 430, project version 432, project acronym 434, project description 436, department 438, and service 440 can be provided as being part of the project definition. The project name 430 field is preferably a read-only field, provided for information only. The project version field 432 enables the numeric version of the system undergoing C&A to be entered, if applicable. The project acronym field 434 is optionally used to provide an acronym for the project. The project description field 436 can be used to provide a detailed description of the project (e.g., mission statement, function, features, and/or capabilities of the system being accredited). The department field 438 can be used to identify the Government (or civilian) department under which this system is being accredited. As shown, the current choice is DoD. The service field 440 is used to identify the Service/Agency under which this system is being accredited. As shown, the current choices are Army, Navy, Marine Corps, Air Force, OSD, and Other. Each of the above-identified fields can be tailored to suit a particular need and/or application.

FIG. 5 shows how a user can select, via a conventional pulldown menu, either civilian or DoD service from field 438. As disclosed in application Ser. No. 09/794,386, other menus can be provided that, for example, enable a user to select a military service branch (e.g., Army, Air Force, Marine Corps, OSD, or other), and to input Information Technology Security (ITSEC) parameters (that can pertain to, for example, interfacing mode, processing mode, attribution mode, mission-reliance factor, accessibility factor, accuracy factor, information categories, system class level, and certification analysis level, as explained in DoD Instruction 5200.40) of the system being accredited. In addition, as disclosed in application Ser. No. 09/794,386, menus can also be provided that allow a user to, for example, select a security level (e.g., secret, unclassified, sensitive, etc.) and related information, and/or provide context sensitive help.

FIG. 6, shows a high level system diagram that provides an overview of the target system assessment aspect 600 (hereinafter system 600) and an associated network or target system 612 according to at least some embodiments of the present invention. As used herein, a network can be defined as two or more objects that are directly or indirectly interconnected. Referring now to FIG. 6, a network interface 608 provides an interface to one or more networks 612 having one or more network devices 614a-n operatively connected thereto. The network interface 608 can be a conventional RJ-11 or other similar connection to a personal computer or other computer that facilitates electronic interchange with the network 612.

Network Discovery Engine

As shown in FIG. 7, at least some embodiments of the present invention contemplate that the network discovery engine 606 comprises three separate modules: a network scanner 702, a host profiler 704, and a profile integrator 706. As will be discussed in further detail herein, the network discovery engine 606, via the network interface, collects information such as IP Address, hostname, media access control (MAC) address, operating system (OS), and OS version for one or more network devices (e.g., 614a-n).

Network Scanner

The network scanner 702 scans a network segment 614 (comprised of network devices 614a-n) and reports the results to a network scan file 708 (e.g., a text file). Network devices 614a-n can be any devices that, for example, have an Internet Protocol (IP) address associated therewith (or that have some other mechanism by which the devices/components can be identified). The network scanner 702 can scan through a specified range of IP addresses associated with each respective network device
614a-e within the network segment 614.

The network discovery engine 606 can utilize conventional network topology discovery techniques such as transmission control protocol (TCP)/user datagram protocol (UDP) port interrogation, and/or simple network management protocol (SNMP) queries, and receive network configuration information provided by such technique(s). Network topology information can optionally be manually added via the user interface 602. Upon entering or providing one or more IP address (e.g., a range of IP addresses), the host name of a network device 614a-n can be obtained by using, for example, a getHostName (or similarly named) function that will query a network device 614a-n for a host name. Functionally, the getHostName function can scan one or more domain naming service (DNS) servers internally and optionally over, for example, the World Wide Web to try and resolve the IP address (i.e., match the IP address with its respective host name). In the case of a MAC address, the initial sweep of, for example, a network segment 614 can have one or more Internet Control Message Protocol (ICMP) requests. One such request can be a "ping request." The packet returned from such a ping request can include, for example, the MAC address of the host device. Similarly, during a port sweep/interrogation, the OS family (e.g., Unix, Windows, etc.) and version can generally be determined. Regarding SNMP queries, if a queried network device 614a-n is SNMP enabled, additional information (e.g., device manufacturer, model, application software), etc. can generally be obtained. Finally, if a network device 614a-n utilizes (e.g., has installed thereon) an Enterprise Management (EM) software/system, the system 600 can scan the EM database (or an extract or portion thereof) associated with a particular network device 614a-n to obtain additional detailed information on each network device 614a-n in the IP range.

The network scanner 702 can obtain the following information relating to network devices 614a-e (which correspond to the network segment 614 under consideration): IP Address, hostname, media access control (MAC) address, operating system (OS), and OS version. This information can be written to a network scan text file 708. The MAC address, as used herein is a hardware address that uniquely identifies each node of a network. In IEEE 802 networks, for example, the Data Link Control (DLC) layer of the Open System Interconnection (OSI) Reference Model is divided into two sublayers: the Logical Link Control (LLC) layer and the Media Access Control (MAC) layer. The MAC layer interfaces directly with the network media. Consequently, each different type of network media requires a different MAC layer. On networks that do not conform to the IEEE 802 standards but do conform to the OSI Reference Model, the node address is called the Data Link Control (DLC) address.

Host Profiler

The host profiler 704 can produce a host profile file 710 (e.g., a text file) containing information such as hardware configuration, operating system and patch levels, installed software list, etc. Host profilers 704 can optionally be provided to accommodate different classes of hosts (e.g., Windows-based machines, UNIX-based machines, etc.). The host profile can be conventional enterprise management software developed by Tivoli Systems Inc., Austin Tex., or by Computer Associates International, Inc., Islandia, N.Y.

Using conventional system commands, operating system application program interface (API) calls, registry calls, etc., the host profiler 704 can determine information about the hardware configuration, operating system options, installed software, etc. of each network device 614a-e within a particular network segment 614. This information for each host 614a-e can be recorded in the host profile file 710. The data in the host profile file 710 can then be used to supplement the information about the respective host in the network scan file 708. A host profile text file 710 can contain information about more than one host.

Profile Integrator

The profile integrator 706 enables information from host profile file 710 to be added to an existing network scan file 708. The profile integrator 706 takes the data in one or more host profile text files 710 and integrates the data into an existing network scan text file 708.

Network Scan File

The network scan file 708 can utilize the conventional Microsoft .INI type file format. As will be appreciated by those skilled in the art, an .INI file is a file that contains startup information required to launch a program or operating system. In general, the network scan file 708, which can be an ASCII file, can identify particular network devices 614a-e by using the form <parameter>=<value>, where <parameter> is the name of the particular item of information, and <value> is the value of that item of information for the network device 614a-e under consideration. For example, as shown in FIG. 8 at 808a, the IP Address=192.168.0.10 indicates the identified host responded at the specified IP address.

As further shown in FIG. 8, the network scan file 708 can begin with a [Network] section 802 that describes the overall network being scanned. The network (e.g., network 612) name is Xacta, as indicated at 802a. Each network segment (e.g., 614) can be described by a [Segment] section 806. The network segment is called Office, as indicated at 807. At 806a, the network name Xacta is again provided. The Office segment has IP addresses in the 192.168.0.0-255 subnet, as indicated at 806b. The subnet was scanned twice: once on Dec. 1, 2000, and once on Dec. 15, 2000, as indicated at 806c and 806d, respectively.

A [Host] section 808, 810 can also be provided for each network device (e.g., 614a-e) within the network segment 614. The IP Address 808a, MAC 808b, Hostname 808c, OS 808d, and Version 808e are the basic information collected by the network scanner 702. At 810, the information collected by the host profiler 704, which has been integrated into the network scan file 708 by the profile integrator 706, includes: IP Address 810a, MAC 810b, Hostname 810c, OS 810d, and Version 810e, mfr 810f, model 810g, CPU 810h, CPU Qty 810i, CPU Speed 810j, RAM 810k, Disk Space 810l, and Software 810m-p. The host profile file 710 can use the same file format (e.g., .INI) as the network scan file 708. The profile integrator 706 can integrate one or more host profile files 710 with a network can file 708. Each [Host] sections (e.g., 810) can either have their own separate host profile files 710. Alternatively, two or more host sections 810 can be included in a host profile file.

FIG. 9 illustrates an exemplary schema 900 that can be used in conjunction with network discovery. As shown, the schema 900 comprises: platform categories 902 (comprising categories 902a-n), network 612 (comprising network devices 614a-n), and software inventory 906 (comprising application software programs/packages 906a-n).

Platform category elements 902a-n represent generic categories of equipment that lie within the accreditation boundary (e.g., network segment 614) that includes the components (e.g., network devices 614a-e) that are associated with the network segment 614 being accredited. Representative platform categories can include desktop computer, laptop computer, mainframe computer, handheld device, hub, etc. Platform categories generally represent typical configuration(s) of the network devices 614a-n that belong to a particular platform category. As used herein, an accreditation boundary can be defined as the network devices (e.g., 614a-e) that comprise the network segment 614 (or target system) being accredited. There can also be one or more devices that are associated with the network segment 614 being accredited, but that are outside of the accreditation boundary and thus not included in the accreditation. Equipment outside the accreditation boundary can include equipment/services as a domain naming service (DNS) used to translate the host names to IP addresses.

With regard to platform category elements 902a-n, the typical office LAN might consist of the following platform categories: file server, mail server, network printer, router, switch, and workstation. Information about each platform category
902a-n can include hardware specifications (e.g., manufacturer, model, CPU, memory, etc.) and OS specifications (e.g., OS name, version, patches, etc.). Since the platform categories 902a-n are generic, and numerous actual network devices 614a-n generally exist, the hardware and OS specifications of a platform category 902a-n will represent the typical configuration expected of network devices that belong to a particular platform category (e.g., network devices 614a, 614b, 614c and 614i belong to equipment category 902b).

Network devices 614a-n represent actual pieces of equipment within the accreditation boundary. Each network device 614a-n belongs to one of the exemplary platform categories 902a-n, as discussed above. Upon assignment to a platform category
902a-n, each network device 614a-n can "inherit"(or is assumed to have) the generic information (e.g., hardware and OS specs) of its assigned category. A user, via user interface 602, can then optionally add, delete and/or edit information. Network devices 614a-n are assigned to a platform category (e.g., 902a) to facilitate test procedure generation, as will be discussed in further detail herein, particularly with regard to FIG. 17.

Software inventory elements 906a-n represent application programs (i.e., operating systems are not included). The system 600 can form an association between one or more software elements 906a-n and one or more platform category element 614a-n (e.g., an association is formed between software elements 906a, 906b, 906c and platform category 902a). When such an association is formed, the software is considered to be installed on all equipment in that platform category 902a-n. Similarly, the system 600 can form associations between a software element 906a-n and a network device 614a-n. Such an association indicates that the software is actually installed on the associated network device 614a-n, but that the software element is not necessarily installed on every network device in a given platform category 902a-n.

Network configuration information can also be manually entered into the system 600. For example, returning to FIG. 4, when project hardware tab 414 is activated, a menu as shown in FIG. 10 can be provided. The menu allows a user to, for example, Edit/Delete H/W 472, enter various Platform Information 474, CPU information 476, and/or Memory/Storage Information 478. This information can be modified to reflect changes in system configurations throughout the information gathering requirements analysis and testing phases.

Database Tables

At least some embodiments according to the present invention contemplate a database structure with at least the following tables that can be utilized to accommodate the network scanning and profiling features. The exemplary data dictionary disclosed herein provides additional details pertaining to the following tables. WCA_ProjPlatCat Table--contains a row for each defined platform category. WCA_ProjEquipInven Table--contains a row for each piece of equipment. WCA_ProjSWInven Table--contains a row for each defined software element. WCA_ProjPlatSW Table--contains a row for each defined association between a software inventory element and a platform category (for each project); each such association indicates that the software element is typically installed on members of the associated platform category. WCA_ProjEquipSW Table--contains a row for each defined association between a software inventory element and an equipment inventory element (for each project); each such association indicates that the software element is actually installed on that particular piece of equipment. WCA_OSSource Table--contains a row for each `standard` operating system, including family (NT, UNIX, or Other), manufacturer, name, version, etc. WCA_SWSource Table--contains a row for each `standard` software application, including family (e.g. database, network OS, etc.), manufacturer, name, version, etc.

Certification and Accreditation Engine

As will be explained in further detail herein, once information has been collected (either manually or via an automated process, each as described above) pertaining to devices 614a-e belonging to the network segment 614, the certification and accreditation engine 614, can select compliance requirements/standards and test procedures applicable to the C&A under consideration. A user can also select requirements/standards and/or test procedures by using, for example, user interface 602.

Additional Information Gathering

Returning again to FIG. 4, when project personnel tab 408 is activated, a menu (not shown) can be provided that enables a user to enter information identifying all the project personnel associated with the accreditation effort. The personnel are preferably identified by the role, as discussed below, that they serve in the accreditation process. At least one entry for each role is preferably defined for the project.

For example, the following fields can be provided in a menu (not shown) subsequent to clicking the personnel tab 408: Role Name--The role associated with the accreditation team member. The available choices can be: Accreditation Team Lead--The person in charge of the accreditation effort, usually the Project Manager. Accreditation Team Member--All the members of the accreditation team (analysts, testers, etc.). Certification Authority (CA)--Person in charge of the system certification. Certification Authority POC--Point of Contact (POC) to the CA. DAA--Designated Approving Authority. Person ultimately responsible for the accreditation of the system. DAA POC--Point of Contact (POC) to the DAA. ISSO--Information System Security Officer. Person responsible for the security implementation of the system being accredited. Organization Responsible--Organization responsible for the design and development of the system being accredited. Organization Responsible POC--Point of Contact to the Organization responsible. Program Manager--Program manager of the system being accredited. User Representative--Representative from the user community. Title--The title associated with the accreditation team member (Mr., Ms. or Dr., etc.) First Name--The first, middle initial, and last name of the accreditation team member. Office--The office (e.g., Office of the Assistant Deputy for Policy and Planning) of the accreditation team member. Office Designation--The office designation of the accreditation team member. For example, if the office is the Office of the Assistant Deputy for Policy and Planning, then the office designation may be ADS-P. Organization--An organization that is associated with the accreditation team member. Work Address--A work address if applicable for the accreditation team member (include city, state and zip code). Work Phone--A work phone number for the accreditation team member. Work Fax--A work fax number if applicable for the accreditation team member. Email Address--An email address if applicable for the accreditation team member.

When the project schedule tab 412 of FIG. 4 is activated, a screen can appear (not shown) that provides the capability to describe and store each project milestones for the system being accredited. Fields such as milestone title, milestone date, and milestone description can be provided.

When project hardware tab 414 is activated, a menu as shown in FIG. 10 can be provided. The menu allows a user to, for example, Edit/Delete H/W 472, enter various Platform Information 474, CPU information 476, and/or Memory/Storage Information
478. This information can be modified to reflect changes in system configurations throughout the information gathering requirements analysis and testing phases.

When project operating system 416 is activated, a menu (not shown) that enables a user to manually, in addition to or in lieu of the automated process heretofore, describe and store operating systems associated with the system hardware is provided. The ability to enter information pertaining to multiple operating systems (OS) on each hardware platform can be provided. Fields are provided to enable a user to enter information pertaining to the OS Name (e.g., Windows NT, AIX, HP UX, etc.), OS Type (e.g., NT, UNIX, etc.), OS Manufacturer (e.g., Microsoft, Hewlett Packard, IBM, etc.), OS Version (the numeric value of the operating system version), OS Options (a list of all OS options (if any) obtained for this platform), OS Patches (a list of OS patches (if any) that have been installed on the platform), OS Description (a detailed description of the operating system, possibly including the basic features, and any functions unique to the system being accredited).

When project application tab 418 is activated, a project application screen appears (not shown) that can provide the analyst with the ability to manually, in addition to or in lieu of the automated process described heretofore, describe and store applications associated with the system hardware/OS combinations. The following exemplary fields can be provided: Application Name (the name of the application), Application Type (the type of application on the system being accredited--e.g., database, office automation, e-mail server, etc.), Application Manufacturer (the name of the application manufacturer), Application Version (the numeric version of the application), Application Options (a list of the options associated with the application (if any)), Application Patches (a list of the patches associated with the application), and Application Description (a detailed description of the application).

When system interfaces tab 420 is activated, a menu (not shown) is provided that provides the user the ability to describe and store the flow of information into and out of the accredited system. The system interfaces entries can describe each of the internal and external interfaces identified for the system. The following exemplary fields can be provided: Interface Name (an internal or external name associated with the system interface), and Interface Description (a detailed description of the internal or external system interface, which preferably includes a statement of the significant features of the interface as it applies to the entire system, as well as a high level diagram of the communications links and encryption techniques connecting the components of the information system, associated data communications, and networks).

When system data flow tab 422 is activated, a menu (not shown) is provided that can provide the user the ability to describe and store the flow of information within the accredited system. System data flow entries can describe the flow of information to each of the external interfaces identified for the system. The following exemplary fields can be provided: Data Flow Short Name (a brief user-defined name associated with the system data flow), and Data Flow Description (a detailed description of the data flow associated with the external interface, which preferably includes a statement of the purpose of the external interface and the relationship between the interface and the system, as well as the type of data and the general method for data transmission, if applicable).

When accreditation boundary tab 424 is activated, a menu (not shown) that provides the user with the ability to describe and store the identification of components that are associated with the system being accredited, but are outside of the accreditation boundary (i.e., not included in the accreditation). This category might include such equipment/services as, for example, a domain naming service (DNS) used to translate the host names to IP addresses. The DNS might not be part of the atomic system being accredited, but is required for most communication activities. The following exemplary fields can be provided: Accreditation Boundary Name (a name associated with the external system component), and Accreditation Boundary Description (a detailed description of the external system component, which preferably includes the function that this component/service provides the system being accredited and its relationship to the system).

When project threat tab 426 is activated, a menu (not shown) appears that provides the user the ability to quantify the threat environment where the system is intended to operate. If the system is targeted to operate in multiple locations, the environmental condition that results in the higher or highest level of risk can be selected. The following exemplary fields can be provided: Location (CONUS (CONtinental US) or OCONUS (Outside CONtinenal US) as the primary operating location for the system), System Communications (the primary means of information transfer to external systems, such as No LAN, Local LAN Only, SIPRNET (SECRET Internet Protocol Router Network), NIPRNET (Unclassified but Sensitive Internet Protocol Router Network), Internet, etc.), Connection (the types of connection--e.g., wireless, dial-up, or protected distribution system (PDS), etc.), Training Competency Level (e.g., administrator, maintenance personnel, user, etc.), Installation Facility (the operating environment of the system at its intended end site), Natural Disaster Susceptibility (e.g., fire, flood, lightning, volcano, earthquake, tornado, etc.), and Custom Components.

When project appendices tab 428 is activated, a menu (not shown) that provides the user the ability to identify external documents that are associated with the C&A is provided. These appendices can optionally include references to other documents, or consist of the contents of other documents that are accessible via a computer-implemented embodiment of the present invention. Representative appendices that may be derived are: System Concept of Operations, Information Security Policy, System Rules of Behavior, Incident Response Plan, Contingency Plans, Personnel/Technical Security Controls, Memoranda of Agreement, Security, Education, Training and Awareness Plan, and Certification and Accreditation Statement.

Tabs 402-428 can be activated in any order, and do not need to be activated sequentially. Also, each tab can be optionally customized to contain different, fewer, or additional fields relative to the fields discussed above. Further, the tabs (402-428) can be arranged differently. Fewer or additional tabs can also be provided to suit a particular application or need.

Requirements Analysis

The system configuration captured in the step of block 100 of FIG. 1 is used as input for the determination of the requirements indicated by block 102. The process of editing and/or determining/selecting those requirements is shown in FIG. 11. In at least some embodiments contemplated by the present invention, the Requirements Analysis step is related to the Accreditation Type 404 and Project Security 406 information stored in the step indicated by block 100. In at least some embodiments, data is entered and saved in the Accreditation Type 404 and Project Security 406 fields provided before beginning the Requirements Analysis step indicated by block 102.

In an exemplary embodiment, a general purpose computer on which the present invention operates will have stored thereon or have access to a repository of security regulations and test procedures from various government and/or civilian departments, agencies, organizations, etc (e.g., such as those from DITSCAP). In step 1102 (FIG. 11a), and based at least in part on the information entered in step 100, pertinent regulations will be selected from this repository, upon which to build a security requirement traceability matrix (SRTM) for the C&A. The SRTM, as discussed above, can be a mapping of one or more test procedures to each individual requirement within a requirements document. Satisfactory completion of the respective one or more test procedures that can be mapped to each requirement is generally considered to render the requirement satisfied. However, the user has the flexibility to view and modify 1104 the SRTM as desired to meet the specific needs of the systems being accredited by, for example, adding and/or deleting one or more tests to/from the SRTM, and/or editing one or more of the test procedures to, for example, include additional testing requirements. If the user decides to modify a test procedure, the specified test procedure displayed 1106. The user can then modify and save the revised test procedure 1108. The user can then either end the editing process or continue to modify another security document 1110.

FIG. 12 shows an exemplary Generate Baseline SRTM screen shot. In at least some embodiments of the present invention, clicking the Requirements Analysis tab 1201 from the application menu will switch control to the Generate Baseline SRTM screen. As shown, FIG. 12 provides a menu that provides a list of pre-packaged (i.e., shipped with the application) regulations documents (1202-1222) for the user to select. Each regulations document (1202-1222) contains specific requirements, one or more of which may be utilized when performing the C&A. All unmarked check boxes (e.g., check boxes associated with documents 1202, 1206, 1210, 1212, 1214, 1216, and 1218) represent unselected Regulations Documents, and thus do not factor into the requirements analysis step 102 for the particular project under consideration.

After selections have been made, either by the user by, for example, clicking the appropriate boxes associated with documents (e.g., 1204, 1208, 1220 and 1224), and/or by the system, the application will provide a Display SRTM screen as shown in FIG. 13. Additionally, FIG. 13 may display any optional user-defined requirements as determined at FIG. 12, 1226. FIG. 13 particularly shows pertinent portions of DoD 5200.5, selected in FIG. 12 (1208), that are applicable to the C&A at hand.

Testing

With the security requirements traceability matrix in place (a portion of which is illustratively shown in FIG. 13), the user proceeds to the testing step 104. In at least some embodiments of the present invention, user interfaces will be provided, in accordance with the steps shown in FIG. 14, for the user to have the system 600 generate one or more test procedures, and/or add and/or edit test plan information 1402, associate all the requirements to test procedures 1404, add and/or edit test procedures 1406, enter test results 1408, and/or publish test results 1410. Any of the above steps can optionally be repeated as needed, as indicated in decision step 1412. Each of these steps will be discussed in further detail herein.

An Edit Test Plan Information screen, corresponding to step 1402, is shown in FIG. 15. The exemplary input fields on the screen are Expected Date of Test 1502, Planned Location of Procedure 1504, Test Resources 1506, Test Personnel 1508, and Remarks 1510.

FIG. 16 is an Associate Requirements screen, corresponding to step 1404, which illustrates how a user can manually select a test procedure to associate it with at least one requirement selected. As indicated in the descriptive text block 1602, a user can select a source requirements document 1604. Upon clicking on the associate icon 1606, a list of test procedures (not shown) can be displayed. The user can then select one or more of the test procedures within the test procedure database (as discussed above) and associate it/them with the selected source document 1604. A user can also create a new security test and evaluation procedure (ST&E) 1608 or certification test and evaluation (CT&E) procedure 1610, by clicking on the respective icon. After the user enters the respective CT&E and/or ST&E information into a form presented on a new menu (not shown), the user can save the procedure(s) and optionally associate the procedure(s) via the Associate icon, as described above. As discussed in application Ser. No. 09/794,386, the process described in FIG. 16 can also be automated.

Test Procedure Generation

The certification and accreditation (C&A) engine 604 can generate test procedures, corresponding to step 1406, in accordance with the method shown in FIG. 17. In an exemplary embodiment of the system 600, the C&A engine 604 receives network configuration information from the network discovery engine 606 and compare the network configuration information with approved hardware and/or software standards, which can advantageously provide a substantially continuous and dynamic risk management process.

The system 600 can select one or more tests associated with each standard, regulation, etc. selected as discussed with regard to FIG. 12. For each selected test 1702 and for each platform category 1704, the C&A engine 604 can determine whether there is a test strategy associated therewith 1706. For each given platform category 902a-n, test strategies can include, for example, test one network device 614a-n associated with the platform category, test some network devices 614a-n associated with that category, or test all network devices 614a-n associated with the platform category.

If there is not a test strategy associa