Subject: [sacm] Thoughts on additional requirements for SACM (long)

From: Lisa Lorenzin <[email-masked]>
Date: Wed, 21 May 2014 18:09:48 +0000

Greetings!

In thinking about & discussing with colleagues the properties
and functions of a security automation ecosystem (architecture
/ transport protocol / information model / workflow), I've
accumulated a list of additional requirements that I believe
are necessary for data security, efficient operations, and
optimal functionality.

All of these are based on several years of real-world
experience with security automation using IF-MAP and how those
standards had to evolve once people started implementing and
deploying technology based on them. :)  If you have questions
about any particular item, I'll be happy to share the
background / usage experience that leads me to list it as a
requirement here.

I propose that we add these as general requirements for SACM.
I'm happy to make a first pass at writing up draft verbiage
to go into the requirements I-D, but would like to get input
/ approval from the group before I move on to the next step
of writing them up in that format.

If there's any item in this list that you feel is _not_
appropriate to add as a requirement, I'd love to understand
why, and whether you think it needs revision to better fit
the SACM use cases or should be omitted altogether!

Here are my proposed requirements:

Requirement for data integrity and data protection

Requirement for support for both centralized and decentralized
(peer to peer) information exchange
  Seems implicit here; would like to make it explicit.
  Some thoughts on what is required and why:
    * Support for both direct peer-to-peer data exchange as
      well as centralized data storage and distribution
      * Direct data exchange that enables:
        * Systems to utilize an already established mutually
          agreed upon native data format, which may be standard
          or implementation-specific
        * Simplicity of sharing between a small number of systems,
          especially within a single enterprise domain
        * Simplicity of sharing data between relatively uniform systems
      * Centralized data exchange that enables:
        * Common data format to bridge together data exchange
          between diverse systems
        * Virtual data store that centralizes and offloads all
          data access, storage and maintenance to a dedicated
          resource

Requirement for ability to partition data
  Implicit in G-007/authorization; would like to make it explicit
  Supports considerations such as:
    * Federation, where an organization may want to differentiate
      between information that can be shared outside its own domain
      and information which cannot
    * Geographic / regulatory / overlay boundaries

Requirement for a method of negotiating capability
  Version of transport protocol, version of standard attribute
  expression sets, etc.
  Supports future growth and mixed-capability ecosystem

Requirement for discovery - what information is available across
  the entire ecosystem? Where can I go to get a specific piece of
  that information?
    * A means by which data available in the ecosystem is
      categorized and advertised to nodes in the ecosystem
    * A means by which a node can locate and consume relevant
      topics of information available in the ecosystem

Requirement for time discrepancy detection
  Time-sensitive data such as user logon/logoff, endpoint
  connection/disconnection, events related to endpoints all
  depend on a synchronized understanding of time. If a node
  in the ecosystem has clock skew relative to the rest of
  the ecosystem, some mechanism for detection/notification
  of that discrepancy should be provided.

Specific requirements for the information model/data model
  * Uniqueness of objects of reference, such as endpoints, IP
    addresses, etc.
    * Mechanism to resolve or tolerate ambiguity in referents
      (e.g. same IP address used in two separate networks)
  * Support for rootless searches / wildcard searches
    * Ability to start a search anywhere in the tree, rather
      than at a specific leaf
  * Data lifetime management (longevity / expiration of data)
  * Looseness of coupling between producer and consumer
    * Ability to identify data from a specific producer
  * Metadata cardinality - single-valued vs. multi-valued
  * Capability negotiation - what data types / schemas are
    supported
  * Provenance of data - for example:
    * Publisher identity, classification, trustworthiness,
      authoritativeness
    * Freshness of data
    * Method by which data was generated (i.e. self-reported,
      reported by aggregator, result of scan, etc.)
    * Location of data

--
Lisa Lorenzin  /  919-384-7275  /  [email-masked]
Principal Solutions Architect - Security & Mobility
Juniper Networks  /  http://www.juniper.net/