Veeam Software, a business continuity product company for virtualization, has a complete list of vCenter Events sorted by ID. Here’s the first event in the list:
esx.problem.vmsyslogd.remote.failure|The host “{1}” has become unreachable. Remote logging to this host has stopped.
Since 5.0 Reference
This is an important change from prior versions of ESXi, which would not stop logs on an error (note the “Since 5.0” in the Message Catalog Text field). An alarm for this event can easily be created by using “esx.problem.vmsyslogd.remote.failure” as the trigger.
[Rep. Rush D. Holt, a New Jersey Democrat] said a fuller reckoning of the number of suicides among military personnel and veterans is needed not so much to tell lawmakers and the public that there is a problem — that, he says, they know. Rather, it is needed to more accurately gauge the extent to which programs to help troubled troops are having an effect.
‘american kills’ by chilean-born new york based artist sebastian errazuriz
Speaking of static routes and layer-3 routing (yep, that’s the best transition I can come up with), I have found many of my customers questioning what is actually possible with the use of these features. My favorite argument of all is, “NAT does not equal routing!â€. This misconception is probably due to the confusing label of “NAT-Routed†when referring to an external org network behind an auto-provisioned VSE appliance. That may have been the case with previous versions, but not so today. In fact, a VSE appliance can perform basic L3 routing functions independent of NAT’ing. I prefer to avoid NAT’ing (when it’s an option) — and some enterprises have banned it all together across internal networks — so this capability often comes in handy.
presents an enterprise continuous monitoring technical reference architecture that extends the framework provided by the Department of Homeland Security’s CAESARS architecture. The goal is to facilitate enterprise continuous monitoring by presenting a reference architecture that enables organizations to aggregate collected data from across a diverse set of security tools, analyze that data, perform scoring, enable user queries, and provide overall situational awareness. The model design is focused on enabling organizations to realize this capability by leveraging their existing security tools and thus avoiding complicated and resource intensive custom tool integration efforts.
NISTIR 7799, Continuous Monitoring Reference Model Workflow, Subsystem, and Interface Specifications
provides the technical specifications for the continuous monitoring (CM) reference model presented in NIST IR 7756. These specifications enable multi-instance CM implementations, hierarchical tiers, multi-instance dynamic querying, sensor tasking, propagation of policy, policy monitoring, and policy compliance reporting. A major focus of the specifications is on workflows that describe the coordinated operation of all subsystems and components within the model. Another focus is on subsystem specifications that enable each subsystem to play its role within the workflows. The final focus is on interface specifications that supply communication paths between subsystems. These three sets of specifications (workflows, subsystems, and interfaces) are written to be data domain agnostic, which means that they can be used for CM regardless of the data domain that is being monitored.
NISTIR 7800, Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains
binds together the Continuous Monitoring workflows and capabilities described in NIST IR 7799 to specific data domains. It focuses on the Asset Management, Configuration and Vulnerability data domains. It leverages the Security Content Automation Protocol (SCAP) version 1.2 for configuration and vulnerability scan content, and it dictates reporting results in an SCAP-compliant format. This specification describes an overview of the approach to each of the three domains, how they bind to specific communication protocols, and how those protocols interact. It then defines the specific requirements levied upon the various capabilities of the subsystems defined in NIST IR 7799 that enable each data domain.
Updated to add related docs on Continuous Monitoring:
NIST SP 800-137 – Final – Information Security Continuous Monitoring for Federal Information Systems and Organizations
NIST SP 800-126 Rev 2 – Final – The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
NIST IR 7694 – Final – Specification for the Asset Reporting Format 1.1
NIST IR 7693 – Final – Specification for Asset Identification 1.1
Summaries:
SP 800-137 – High-level guidance document for CM
SP 800-126 Rev 2 – Technical specification that defines how to represent checks and checklists for configuration and vulnerability
IR 7694 – A high level reporting format to carry data about assets
IR 7693 – A standard data model for identifying assets
