Comments Resolution 3/29/2011

Transcription

1 General comment: Suggest adding more implementation-specific text. There are many different Federal organization types central, non- There's a lot of general text on why continuous monitoring is good, and central, and various degrees of hybrids organization types, with high level guidance, but could be more implementation guidance or different and varying types of systems from common operating examples of implementation alternatives. environment to highly distributed "enclave" type environment with mix of mission critical, mission support an administrative systems with associated mix of ICS, legacy and more enterprise architecture related systems. Each of these system types and environments affects the potential continuous monitoring implementation Suggest rewording/augmenting continuous monitoring definition to provide greater detail as identified on page 4 of Draft NIST IR Sample rewording would be: "Information security continuous monitoring is defined as maintaining on going awareness of all organization's security risk posture, providing visibility into assets, and vulnerabilities, by leveraging the use of automation to provide situational awareness to better quantify risk, ensure effectiveness of controls, and enable prioritization of remediation activities". Rewording to next level of detail, provides more focus by specifically identifying the use of automation, and potential targets of automation and use of the output and 2 Suggesting rewording sentence beginning with "Continuous monitoring supports... " to read as follows: "Continuous monitoring supports and facilitates, but does not supplant the need for system reauthorization." Continuous monitoring facilitates the reauthorization process through the re-use of results from system activities as result of normal SDLC activities, as well as focusing assessment and potential need to reauthorize systems based on changes to the system and system environment. 9 last In Information Systems level (Tier 3) paragraph, beginning with sentence "Data feeds from... ", suggest also discussing common controls, and inter-relationship of common, hybrid, and system controls from data feed perspective. Suggest also consider those systems that have Industrial Control system (ICS) components. Many technical and other controls are provided as common controls, especially in Data Center & virtual type of environments. ICS and related systems in operational environment (such as NAS) are not readily adaptable to scanning. and data feed environment. Page 1 of7

2 10 2nd 10 and 2nd to 11 last and Figure 2-2 Suggest incorporating text into 2nd on configuration management and change control to address identifying and maintaining the baseline configuration as the system changes over time, and provision of oversight over the change control process. In sentence identifying Figure 2-2 and its illustrating "these five elements", suggest modifying text or Figure 2-2 to better address 5th element: "Active involvement of organizational officials. n Adding suggested content will then provide level of content as in other s relative to configuration management and change control focus. "Active involvement of organizational officials" is not clearly illustrated in Figure st 3-4 In sentence "Without knowledge of control changes... " suggest rewording such as "Without knowledge of the system baseline (hardware, software, type, version, etc.) and change control processes down to the information system component level, monitoring will result in inaccurate risk data. Many enterprise architectures have not been wen defined, and there are many legacy systems, and systems with rcs components which may not be included/defined in the enterprise architecture. The context of the process should be all inclusive,. and worded such that it addresses non-enterprise architectures as well as enterprise architectures. 18 2nd In "Common Control Provider" paragraph suggest incorporating situation where there are multiple common control providers. Organizations may have common controls at each "tier"" organization controls at tier 1 (PS controls and other XX-Ol) controls, sub-organization common controls at tier 2 (which would also be incorporated into the XX-OI controls; and then system specific controls that may include technical controls that would commonly be provided in a data center environment, especially when there are different AOs represented by that data center - Data Center AO may be hosting systems with different AOs representing different sub-organizations (Line of Business) - such as multiple applications, potentially belonging to different LOBxzJAOs, residing on a server, belonging to yet another LOB/AO. Page 2 of 7

3 Comments Resolution last In "Security control assessor" paragraph, suggest incorporating assessor gathering or otherwise obtaining results from continuous monitoring and SDLC activities to support the security control assessment. Reuse of continuous monitoring results and results from SDLC related activities is very important part of assessment, which can reduce the level of effort for the assessment; and gathering that documentation can often be the long pole in the assessment tent. 21 lst 222nd Suggest incorporating Tier 3 system owners/issos being involved Metrics should be meaningful and be of benefit to system owner with metric development and buy-in to ensure metrics have meaning to to facilitate securing their system(s) rather than be a "reporting" those who implement them at system level overhead Suggest incorporating Tier 3 system owners/issos for those common Common controls should be addressed at all three applicable controls that are implemented at that level, such as technical control tiers, especially at tier 3 which may involve common technical implementation for data centers/gsss who are "offering" controls, and controls, such as the case of one ISO's apphcation(s) residing on ICS-type systems that would include tailoring and use of compensating another ISO/LOBs servers; and the potential extensive use of controls. compensating controls Expected Input: suggest incorporating system/environment information, as applicable Information System (Tier 3) Continuous Monitoring Strategy, in 2nd paragraph, 2nd sentence, suggest incorporating authorization dates, currently at least every 3-years, to read similar to following: "At a minimum, all security controls are assessed, at least once over the authorization period, for effectiveness in accordance with the system security plan, and the methods described in NIST SP A. Monitoring strategy, may be different depending on the system/environment - the strategy for critical system functions using ICS components may be different that that for more traditional IT systems, so may bave a couple of strategies or make allowances for tailoring. Serves to bound periodicity of control assessment to ensure that each applicable security control is assessed in a manner that supports continuous authorization. Page 3 of7

4 Comments Resolution 3/ s Suggest adding a to "Determine system security categorization, and any changes from previous categorization [Define, Establish, Implement; RMF Step I]." If I understand the bracketing correctly, the addition of "Categorization", will help influence the continuous monitoring strategy at Tier 3. system may combine, gain functionality, and process new/additional information types that.1...t t, Suggest moving to section 3.3 Define Sample Populations seems out of place in section 3.1.3; whereas section 3.3 specifically address assessments, security controls and specific assessment objects, such that defining sample sizes seems to be more applicable to that section. 26 and AU Suggest incorporating discussion of situational awareness to content of Situational awareness provides framework to establish section 3.2 meaningful metrics. It also serves to prioritize remediation actions based on criticality to network/mission It seems following sentence - "Additionally, determining the frequency It appears that sentence specifically addresses non-organizational for assessing common controls includes the organization's common control providers. While valid for non-organizational determination of the trustworthiness of the common control provider." Icommon control providers, one would think that common control should be augmented, or clarified, to address organizational common providers from the same organization would inherently be more control providers, and separately non-organizational common control [trustworthy, providers. Page 4 of?

5 Suggest adding content concerning de-centralized organizations, where Organizations may not have reporting infrastructure in place- in might be using multiple tools to provide information that organization that scanning and monitoring is conducted but reporting and has to roll-up or otherwise normalize to address situational awareness, remediation may be activities within that location, and not risk "scoring" and any reporting requirements. Suggest also addressing necessarily reported beyond the walls oftbat location, such as reporting infrastructure. might be the case for a data center. Vulnerability may be accomplished on a system basis, or hybrid, some conducted at organizational level, some at sub-organization level and some at system Jevel; system level scanning would need to be rolled up to the sub-organization, and then sub-org scanning would need to be rolled up to organization level for "risk scoring" and reporting. As an example, an organization may not have a "Common Operating Environment" and thus the SOCINOC may not have visibility behind each LOBs firewall, as in our case; and each LOB may have multiple LANs to support various missions within the LOBs. Page 5 of 7

6 D-2 D.l,lst para. Suggest a) in 3rd sentence replacing "all" with "aspects" so that sentence reads: "However, they can be configured to support aspects of an organizations ongoing security monitoring needs...»; and b) in 4th sentence replace "would" with "may". a) Many organizations use many tools, and each tool depending on its configuration, and how and where the tool measures what it measures, may support some aspect, however many tool results may differ for the measurement of supposedly the same monitoring need, and the output/reports from the various tools may differ significantly, so tools are not necessarily the end all be all at this time, such that "all" is not necessarily a good tenn to use to describe tool functionality; additionally there are controls at this time that are not yet able to be automated, which would further restrict the "all" aspects of the subject statement (see attached set of minutes from CMWGaddressing tool issues); and b) many organizations have components and sub-organizations, that may each have their own tools, such that an organizationwide tool is not feasible or practical based on current investment in tools, and the responsible party for that tool. Many tools are implemented at the data center, which may be different than the tools used for the laptops, from sub-organization to suborganization. In a small or centralized organization, the subject statement may be valid, though for large, decentralized organizations, it may not. D-6 D.1.4 All Suggest adding text to address discovery of unauthorized hardware and It is important to be able to both assign each component to a software system, as well as discover and address unauthorized components. D-ll D.3 2nd Suggest deleting "Authomatically" from 2nd Without careful prior analysis, automatic enabling of security may negatively impact a function of the target system. Page 6 of 7