Subject: [sacm] Information Model Problem Statement

From: "Watson, Kimberly" <[email-masked]>
Date: Fri, 7 Nov 2014 20:30:08 +0000

Working on updates to the Information Model. This is the first shot at trying to draft a problem statement that is more about the IM than SACM...what is it missing? does the example help or just distract from the point?

   SACM use cases were documented to guide development of vendor
   neutral, interoperable standards for aggregating and evaluating data
   relevant to security posture.[ID.draft-ietf-sacm-use-cases-07]

   In the current operational environment, tools and technologies from
   disparate sources collect, store, and share endpoint posture data in
   different formats for different purposes. This limits the ability of
   administrators to use this data to make decisions and securely manage
   their endpoints in a timely fashion. Often the same data is collected
   by different tools or processes, but because of the disparity in
   collection and processing, this data is rarely consumable or usable
   in an automated manner. People must work with the data and convert it
   into posture information, reproducing it in the myriad of formats
   required by their diverse network and security management tools and
   technologies.

   A standard information model enables interoperability in
   collecting, storing, and sharing information despite platform
   differences. This information model addresses the need to
   integrate security components, support multiple data models, and
   provide interoperability in a way that is platform agnostic, scales,
   and works over time.

   While large amounts of endpoint data are collected, processed, and
   stored on a daily basis, there are gaps in consistently generating
   and sharing the information represented by that data and required
   to accurately assess security posture. For example, the
   organization may use two different endpoint scanners to perform
   configuration (benchmark) checks. One scanner produces a summary of
   endpoints assessed, benchmarks assessed against, and failures. It
   considers failed scan attempts as a failure of every check not
   performed and benchmarks determined as not applicable for an endpoint
   are treated as a pass for every check. The other scanner only
   produces a summary of the failures, so only endpoints that failed at
   least one check are listed. Endpoints that passed every check of an
   applicable benchmark are not listed as being checked. This tool
   treats failed scan attempts the same as not applicable benchmarks,
   and does not include them in the report. In this scenario the
   administrator is unable to derive the following information: what
   endpoints were assessed, using what benchmarks, and what ones had
   what misconfigurations.

   A way is needed to exchange information that (a) maintains context,
   meaning the pieces of the notation can be accurately interpreted and
   used by diverse consumers in a consistent manner, (b) has breadth,
   meaning the pieces of the notation are useful about a variety of
   endpoints and software components, and (b) has longevity, meaning
   that the pieces of the notation will stay useful over time.

--
Kim Watson
Office of Cybersecurity and Communications
Federal Network Resilience
Blackberry: (202) 494-2534