Information Security Continuous Monitoring (ISCM) for federal information systems and organizations

Abstract

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation's measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL's responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL's research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. Special Publication 800-137 Information Security Continuous Monitoring for Federal information Systems and Organizations ______________________________________________________________________________________________ PAGE iii AuthorityThis publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III.Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST. Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, includin...

Evaluating Confidentiality Impact in Security Risk Scoring Models

“…Federal Information Processing Standards (FIPS) requirements demands implementation of a categorization [7], but does not require using any particular scale, thus risk comparison of users' systems is difficult.…”

“…Examples of vulnerability specifications used by NVD are: vulnerability category, vendor name, product name, published vulnerability start and end dates, vulnerability update dates, vulnerability severity, access vector, and access complexity [7].…”

“…After identifying these risks, the tools evaluate the potential impacts on the organization. Reference [7] states that SCM systems are aimed at closing the gap between the zero-day of identifying the vulnerability, until the moment the computer is loaded by a patch. www.ijacsa.thesai.org This paper describes the mechanisms of a new SCM framework that will produce better risk scores than current known systems.…”

Quantifying Integrity Impacts in Security Risk Scoring Models

“…Examples of vulnerability specifications used by NVD are: vulnerability category, vendor name, product name, published vulnerability start and end dates, vulnerability update dates, vulnerability severity, access vector, and access complexity [13].…”

“…According to Federal Information Processing Standards (FIPS) 1995 [13], organizations assign their IT resources security importance measures based on component location in the environment, business function using it, and potential losses in case the component is damaged. U.S. government assigns every IT asset to a group of assets called a system.…”