Subject: [sacm] SACM Charter Focused

From: Stephen Hanna <[email-masked]>
Date: Thu, 17 Jan 2013 18:09:45 +0000

Here (attached and below) is a new version of the proposed
SACM charter that makes these changes:

* Added two deliverables: a SACM Architecture document and
  a Use Cases and Requirements document

* Changed our areas of focus to be system security assessment
  and interacting with content repositories

* Removed the exchange of information across organizational
  boundaries

Please review this text and raise any concerns or questions.
And look out for another email from me suggesting more
simplifications and clarifications to the charter.

Thanks,

Steve

--------

Proposed Working Group Charter

Name: Security Automation and Continuous Monitoring (SACM)
AREA: Security

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <stephen.farrell at cs.tcd.ie>
     Sean Turner <turners at ieca.com>

Security Area Advisor:
     Sean Turner <turners at ieca.com>

Mailing Lists:
     General Discussion: sacm at ietf.org
     To Subscribe:       http://www.ietf.org/mailman/listinfo/sacm
     Archive:            http://www.ietf.org/mail-archive/web/sacm

Description of Working Group

Securing information and the systems that store, process, and transmit
that information has become a challenging task for organizations of
all sizes, and we find that security practitioners spend most of their
time on manual processes relegating them to ineffectiveness. Security
automation to verify system configurations with the ability to
prioritize risk based on increased situational awareness from shared
intelligence is the key to escaping this rut. This working group will
develop security automation protocols and data format standards in
support of information security processes and practices where
practical. These standards will help security practitioners to be
better utilized within their organizations by automating routine tasks
related to endpoint and server security so that practitioners can
focus on more advanced tasks. The initial focus of this work is to
address enterprise use cases.

The working group will achieve this by enabling the exchange of shared
intelligence and continuing the security automation work already
performed by various organizations around the world.  The initial work
has been fruitful, and the data formats previously published are ready
for expansion on the international stage. Of particular interest to
this working group are the security automation specifications
supporting asset, change, configuration, and vulnerability
management.

By undertaking this work, we recognize that there are multiple
categories of problems in the security automation domain: enabling
interoperable data exchanges through standardized protocols, defining
expressions for particular domain concepts (i.e. data formats),
establishing a standards-based foundation supporting the curation and
exchange of security automation content collections in content
repositories, and enabling interoperability through the development
and use of standard interfaces and communications protocols. Content
based on rich data standards and protocols will provide the
authoritative instructions needed by data-driven tools to enable the
automated collection and exchange of configuration and vulnerability
data pertaining to enterprise assets. Information produced by these
tools will provide accurate and timely situational awareness in
support of organizational decision making.

The data exchange protocols will need to meet several exchange types
including requesting assessments and reporting on assessment results.
Exchanging information across organizational boundaries will not be
within scope for this effort at this time.

This working group will provide solutions to these categories of
problems and the main areas of focus for this working group are
described as follows:

1. Define, either by normative reference, adoption, or creation, a set
of standards to enable security assessment of computing systems.
This area of focus provides for necessary language and data format
specifications.

2. Define, either by normative reference, adoption, or creation, a set
of standards for interacting with repositories of content related to
security assessment of computing systems.

This working group will achieve the following milestones:

- An Informational document on Use Cases and Requirements
- An Informational document on SACM Architecture
- A Standards Track document to define a protocol for interacting
  with content repositories
- Standards Track documents specifying communication protocols and
  data formats used for security assessment of systems
- A Standards Track document specifying asset description format
- A Standards Track document specifying asset identification
[- A Standards Track document specifying platform naming
- A Standards Track document specifying platform matching
- A Standards Track document specifying platform applicability]

After this work is completed, complementary deliverables
may be defined.

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Fri, 18 Jan 2013 05:12:55 +0000

Hi - Apologize for the delay in reviewing the charter document that Steve
sent out.

I have several questions and comments that may influence the charter
writeup. Appreciate if the group consider them.

1) Need a crisp definition of "Security assessment"

- We need to clearly define what security aspects are being assessed and
from what perspective.
- There are at least 2 forms of assessing a system.

A) Configuration/Static
B) Behavioral/Dynamic

Static:
- you assess a system's "security" by verifying compliance with a
configuration policy (e.g allowed applications or configuration rules)
- typically is a direct communication with the system

Dynamic:
- you assess a system's "security" by assessing observed
behavior/logs/statisticsŠ..etc by gathering information from multiple
network & security infrastructure devices with information on the system
you are assessing
- typically the assessment does not talk directly to the system being
assessed at all
- in many cases the system being assessed for security is not aware of the
systems that are providing security telemetry to the assessing system

I believe the intent of this group is only the Configuration/Static
category I have described. Is that correct? If so, it would be helpful to
clarify that the group is not trying to solve the second case. If the
group intends to solve both then it would be helpful to understand the
nature/characteristics of protocols for both use cases. They are often
times necessarily very different protocols.

Clarifying the expectations in the charter will help define the scope of
the group's work.

2) "The working group will achieve this by enabling the exchange of shared
Intelligence"

- What specific intelligence are you referring to? There are other forums
and groups working on intelligence sharing and is it the goal of this
group to take on those charters too?
- There are many examples but here are two that come to mind right away:
	A) IODEF/RID enables some level of sharing intelligence that aids in
security assessment.
	B) Multiple security vendors have the concept of reputation and/or
blacklists and have protocols to distribute that information to aid in the
improved assessment of the network security.

- It would seem that this group is focused on assessing security of
endpoints/servers where "intelligence" feeds may influence an assessment
- how that intelligence is gathered/authorized for access...etc is very
different from potentially the direct communication with the
endpoint/server for assessment.
- Please clarify the term intelligence and its use in the charter.
- Is it to distribute intelligence information from multiple sources to
consumers of that intelligence.
- Is intelligence gathering and distribution part of the charter at all?

3) It may be helpful to the charter to define what is actually being
assessed from a security perspective.

- Similar to 1) above the configuration has many aspects including:
A) software including: firmware (BIOS, OS), applications installed
B) user configuration settings (login policy, password settingsŠ.etc)
C) network/application configuration (such as router configuration, laptop
network interface configuration, firewall settingsŠ.etc)

Is the intent of this group to gather all of this information for
"security assessment"?

If so, what requirements have been defined and must be established for
systems being
assessed to gather all of this information? Some that come to mind are
things like latency, volume of data, data access control, authenticity of
the data, number of systems expected in a single assessment domain (e.g.
100s -> 100ks?), version control of assessment protocols Š.etc to ensure
large environment can be assessed even when multiple versions of the
"assessment protocol" are deployed

4) The charter describes a "content repository" and a protocol to access
this repository

- Given that there are likely multiple systems assessing different aspects
of security its not clear to me how a single content repository (even if
logical) is practical or correct

- It may be better to think of the charter and protocols in terms of
logical entities/actors such as:
A) Security assessor
B) Security Assessee
C) Security Telemetry Publisher
D) Security Telemetry Consumer

If there are better "standard" terms for these entities/actors should we
adopt that taxonomy as the basis for the group's work? It would seem there
are possibly some options to consider.

Subsequently, the protocols and interfaces would then be defined utilizing
those
Terms instead of the actors instead of content repository.

5) Enabling vendors (networking; security; server; applications,
combinations
thereof) will understand how to assess the security of their respective
technologies. The idea that a single assessor will be created that is all
knowledgeable about all aspects of technology in the environment is
limiting. We should consider the idea that there is a set of technologies
(applications, configurations, networksŠ.etc) that must be assessed by
appropriate security assessment systems. That means there is NO single
system doing that. There *may* be one but today there are multiple and
likely that will continue for good technology reasons and business reasons.

The charter should define the protocols to enable multiple vendor
interoperability without mandating that all security information or
assessment thereof has to be done utilizing a single content repository.

My 10cents.

Allan Thomson