Information Security

Defending the digital infrastructure

Sergey Nivens - Fotolia

Get started Bring yourself up to speed with our introductory content.

Continuous monitoring demystified

A continuous monitoring program can improve everything from configuration and patch management to event monitoring and incident response.

For security teams in many organizations, continuous monitoring is an ambiguous concept that originated in association with Federal Information System Management Act (FISMA) compliance.

The goals of continuous monitoring are twofold: provide up-to-date intelligence to auditors performing system review and authorization, and allow security teams to better understand how controls are performing given the dynamic nature of today's IT environments.

Even for enterprises that fall outside of the 2012 FISMA mandate, continuous monitoring of information systems and networks is still worth the investment, and here's why.

Even for enterprises that fall outside of the 2012 FISMA mandate, continuous monitoring of information systems and networks is still worth the investment.

The 2010 release of the National Institute of Standards and Technology's Risk Management Framework SP800-37 series changed the U.S. government's previous Certification and Accreditation of federal information systems to a model that emphasizes front-end and back-end security. The first half of the security lifecycle in the six-step Risk Management Framework (categorizing information systems, selecting security controls and implementing security controls) is focused on design and implementation. The rest of the lifecycle (assessing security controls, authorizing information systems and continuous monitoring of security controls) emphasizes back-end security, which allows for finalizing audits and improving the state of controls.

Defining risks (threats and vulnerabilities), scoping and implementing controls, and developing an inventory of systems and applications are important parts of a sound security strategy, but without audits and monitoring, security teams will face an uphill battle when they attempt to manage the state of controls, policy and events over time. Integrating a continuous monitoring methodology into your security program can facilitate improvements in everything from configuration and patch management to event monitoring and incident response.

Dynamic strategy

Even though continuous monitoring has been a part of the information security lexicon for several years now, many security professionals are still wondering how to get started: What technologies typically make up continuous monitoring infrastructure? What steps should you take to successfully implement these types of security controls organization-wide?

Before implementing a model with specific technologies, you and your team should set high-level goals and plan to achieve the following objectives with your continuous monitoring approach:

  • Measurement of security posture
  • Identification of deviations from expected control state
  • Visibility into asset condition
  • Automation wherever possible for evaluation and data reporting
  • Determination of ongoing controls' effectiveness
  • Facilitation of prioritized remediation activity
  • Alerting and audit support

Many organizations have found some value in the Department of Homeland Security's (DHS) Enterprise Continuous Monitoring Technical Reference Model called CAESARS (Continuous Asset Evaluation, Situational Awareness and Risk Scoring), with NIST's Framework Extension to make the model more applicable to multi-tier environments. The framework seeks to help organizations implement continuous monitoring by proposing an architecture that is comprised of several key categories of technology and security process.

DHS model for the rest of us

  1. Sensor subsystem. This group of technologies makes up the majority of the continuous monitoring data capture for analysis. The following technologies should be implemented:
    1. System configuration management
    2. Network configuration management
    3. Authenticated vulnerability and patch scanners
    4. Unauthenticated vulnerability scanners
    5. Web vulnerability scanners
    6. Database vulnerability scanners
    7. Antimalware tools
  2. Audit findings. For disconnected systems that may not be able to support continuous monitoring, input from auditors can be fed into the continuous monitoring analysis tools to ensure more complete security controls analysis and coverage.
  3. Database subsystem. This set of databases and data repositories includes all system and application inventory data, system configuration information, and links to well-known online vulnerability databases, such as the National Vulnerability Database.
  4. Presentation/reporting and analysis/risk scoring subsystems. Reporting and aggregate risk scoring are fed from the various data repositories, and the risk evaluation systems can also feed data back to the central data stores.

Source: National Institute of Standards and Technology Interagency Report 7756 (Jan. 2012), https://csrc.nist.gov/csrc/media/publications/nistir/7756/draft/documents/draft-nistir-7756_second-public-draft.pdf

Scanning and monitoring tools

For most organizations, the best place to start a continuous monitoring strategy is by ensuring you have the base technologies in place to gather control information. Assuming the front-end security has been properly designed and implemented, continuous monitoring can get off the ground if you have the following tools in place:

  • Enterprise vulnerability scanning. Using commercial vulnerability scanning tools to perform both authenticated and unauthenticated scans can produce a large volume of data. For continuous monitoring, scheduling daily or weekly scans of systems and subnets will produce enough data for a sound baseline of what is running in the environment and at a system level, which can then be assessed against newer scans to determine what has changed and what the risks are. Specialized Web application and database scanning tools are preferred, but most enterprise vulnerability scanners can cover these technologies adequately as a starting point.
  • Configuration and patch management. Ideally, systems will have a host-based agent installed that can provide updates on patch status and configuration items when queried, or send scheduled updates to a central monitoring toolset. Organizations that have mature patch and configuration management definitions, processes and tools (ideally with a configuration management database) will be in a good position to start collecting and assessing vulnerability data for a continuous monitoring program.
  • Antimalware tools. Both network-based malware detection sandboxing tools and host-based antivirus and whitelisting tools can produce significant monitoring and event data on a scheduled basis or on-demand. Most antimalware platforms and tools have a central management console and database that can integrate and correlate with other data in a continuous monitoring environment.
  • Network configuration management. Network monitoring tools that leverage SNMP traps and network flow data can easily play a role in continuous monitoring, as can tools that evaluate network device configuration templates and compare against running configurations. These tools, much like other enterprise monitoring platforms, usually have central database repositories and granular event data that can be exported to a central monitoring environment.

With these technologies in place, the next steps to implementing continuous monitoring involve building or purchasing tools that can digest most or all of the data associated with configuration and vulnerability management, as well as antimalware events and tool configurations. Federal agencies have been required to use the various protocols and standards associated with SCAP (Security Content Automation Protocol) for some time. As such, many security vendors support data import, export and analysis in standard SCAP-compatible formats that interoperate. Security information and event management (SIEM) platforms and analytics systems may be a reasonable starting point for aggregation and analysis, while governance, risk and compliance tools and dashboards may offer more reporting and risk scoring capabilities.

High-maintenance security controls? Here's how to decide

Some security controls may need more frequent evaluation. Here's a checklist to help you determine which security controls at your organization may require closer scrutiny on a shorter timetable:

  • Security controls that tend to change often, like configuration information (registry settings or user account repositories);
  • High-impact system controls or controls performing critical functions;
  • Security controls that have been traditionally weak and need improvement; and
  • Threat and vulnerability information should ideally be updated daily or more frequently.

-- D.S.

How often should security controls be assessed and monitored? This is a subjective question, as all organizations will have different needs and capabilities, but hourly, daily and weekly are good starting points for individual system-level or application controls, whereas network controls may be evaluated daily or weekly. See "High-Maintenance Security Controls? Here's How to Decide."

Common metrics

Once data is being aggregated and correlated for analysis, most organizations will want to start producing some security metrics on a regular basis. Many enterprises start with the following measurements:

  • Unapproved changes in configuration over time (negative or benign)
  • Number of critical and high-severity missing patches
  • Length of time critical and high-severity patches have been missing
  • Network ports open on critical systems (baseline) vs. daily scans (changes)
  • Number of unauthorized software programs installed on critical systems
  • Percentage of systems that meet or don't meet standard configuration baselines
  • Number of systems of high, medium and low criticality with high-severity vulnerabilities
  • Exposure to top threat vectors (risk-based)

For organizations thinking of implementing a continuous monitoring strategy, don't be dissuaded by the confusion about what it is and how it's implemented. Continuous monitoring can be simple or complex, depending on your technology, budget, and compliance and security requirements.

NIST has developed a robust, complex framework in conjunction with DHS that involves Web services, orchestration, and distinct modular technology roles and data types. Some organizations should strive for this level of depth and granularity, and others may simply need to collect and aggregate data more effectively for central control, monitoring and analysis.

Fortunately, numerous tools, both commercial and open source, are available to help implement continuous monitoring networking technology. By working to implement continuous monitoring, over time you can improve security policy and regulatory compliance, as well as overall security posture.

About the author:
Dave Shackleford is the owner and principal consultant of Voodoo Security LLC; lead faculty at IANS; and a SANS analyst, senior instructor and course author. He previously worked as CSO at Configuresoft; as CTO at the Center for Internet Security; and as a security architect, analyst and manager for several Fortune 500 companies. He currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance.

Send comments on this article to feedback@infosecuritymag.com.

Article 2 of 7
This was last published in October 2014

Dig Deeper on Real-time network monitoring and forensics

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

It´s a great summary. Thanks for the great and clear speech.
Cancel

Get More Information Security

Access to all of our back issues View All

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly.com

Close