Minutes IETF102: sacm
minutes-102-sacm-00
| Meeting Minutes | Security Automation and Continuous Monitoring (sacm) WG | |
|---|---|---|
| Date and time | 2018-07-20 15:50 | |
| Title | Minutes IETF102: sacm | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2018-08-20 |
minutes-102-sacm-00
SACM
------------------------------------------------------------------------------------------------------------------
1. Administrative and Agenda Bashing (Chairs, 5 min)
Note Well, Note Takers, Jabber Scribes, Agenda Bashing
Note Well - Check
Agenda Bashing - Stephen to do CoSWID
2. WG Status (Chairs)
SWIMA published RFC-8412 - Congrats to authors
Interop Testing?
In order to advance on standards track, 2 implementations and
interop testing is there a plan for that? Wont advance on the
standards track without interop testing
Andreas - StrongSwan has SWIMA compliance
Carl Heinz - another effort taking place - no timeline
on that at this time
3. Hackathon Update (Munyan/Montville)
YANG models to express collection information, grabbed some system
characteristics, and created a generic collection model. Some questions
remain: Is this work worthwhile to continue? Can NET/RESTCONF work in
the tradiitional device space?
Frank: What kind of endpoint are you collecting posture from? Just
workstations/servers. Why did you choose YANG model? Because, it's more
suitable for use with network devices.
The reason we chose this was so that we could use YANG as a potential
solution.
Is it a good solution? Possibly. The collection mechanism we defined is
a small model, but it could encapsulate the details of
technology-specific YANG models.
Frank is interested in collaborating next time.
4. Terminology (Montville/Birkholz)
https://datatracker.ietf.org/doc/draft-ietf-sacm-terminology/
Adam successfully deflected this to Henk
Branching the document to reconcile issues
Project on GitHub addressing each issue
On deck, in progress, completed, etc
14->15
Culling of terms
How/Why to bring some of them back
Start with a very concise definition/reference,
followed by more explanatory text - how its used,
declarative guidance, relationship to other terms 21
unresolved issues resolved another 20 issues
Issue 84 - Remove "Asset" and "Asset Management"
Proposal is to narrow it down
Prefix it with "IT", active equipment?
requires installation media?
Retain the terms hardware/software management
Adam is in favor of the removal
Consensus in the room?
Issue 80 - Do we need to define "timestamp"
Suggestion is to name our "timestamp" after
4949 data object timestamp
Basically and architectural feature?
Objections to elaborating on timestamps (how
they are vital to a machine defined as a SACM
component) - How it is used and its
relationships to SACM No objections in the room
(henk digressing from the slide)
Endpoint characterization record: identifying target
endpoints that are not under your own control. If an
endpoint attaches to a guest network, for example, its
information can be collected and aggregated in an
endpoint characterization record.
Issue 39 - Attribute and Endpoint Characteristic
(Adam)
Some confusion about attribute being an
attribute/value pair IM has 2 priority
constructs (container and leaf): leaf is an AVP?
Nancy: We've had lots of debate, we just need
to stick to one. Attribute is the atomic, we
were referencing it as an AVP. Can have a
composite-set element ("Subject"), but the AVP
is supposed to be the "atomic one". Would like
us to move on; argued this for many
sessions/meetings.
Adam: If adam is the only person with an issue
on this
Bret Jordan: Too often when we get into this
stuff, we get really pedantic on it, and forget
the higher-level things. Slightly less
pedantic terms that are more generally readable
and understandable by the masses. "bubble it
up".
Dave Kemp (NSA): Want to make things
understandable/intuitive.
Bret Jordan is willing to help
Frank Xia is willing to help
Problems working in GitHub vs working on the list
Adam: GitHub will automatically send messages
to the list from GitHub Bret: Make sure
there's good labeling and intuitive to
understand what's going on for new people
looking at the repo
5. Architecture (Montville/Munyan)
https://datatracker.ietf.org/doc/draft-mandm-sacm-architecture/
Adam: Made 1 update since the last IETF
Focus on discovery of the architecture, centered on hackathons
SaCM roles, components, capabilities, etc
Completed appendix mappings to Use Cases
Taxonomy of components right?
Workflows labeled and starting to be defined - Are they right?
Use Case mappings useful?
Adopt the draft?
Henk: We are in dire need of an architecture.
(Roles) Sad to see only very specific roles for components. The
elegance of provider/consumer roles enabled a flexible use of SACM
components. Revive the control-plane concept to discover sacm
components. Apply p/c to both data and control plane? Dont want to
force people to write another RFC just to add a role.
Adam: current draft is very xmpp-centric. MILE working group document
- Section 10: Providers and consumens need shared knowledge of
available topics. We would need to define those capabilities here in
SACM. We want a mechanism that someone can define a new role/topic and
ppl can interact with that.
( Nancy mosies over to the mic :-) )
Nancy: The way nancy interprets this draft is an instantiation of the
parked draft. You've got collectors, evaluators, etc. Not being
explicitly called out in this draft. Would put more context of the
whole intent into this draft.
Adam: Looking to take best specificity from old draft and integrate
into the redux draft Nancy: "How do we begin to do the posture
assessment", "How do we begin to do the posture collection"
You have snippets of it, but not the full picture of "both
sides of the story"
Stephen: Like it, readable. Theres stuff to add, stuff to do, we
could get a lot of value out of it
Question from Chair: Nancy, are you good with moving this into a WG
draft.
Nancy: Current stuff is a lot about SW inventory, now what do we do
with all of that stuff.
What are the other capabilities, workflows. Come up with the taxonomy
for all of these so we dont need new RFCs for new capabilities.
Extensible architectural model
Adopt as a WG document? No objections - Will do a call for adoption on
the list!
5. Endpoint Compliance Profile (Schmidt) (remote)
https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/
Charles: Subbing for Danny and Jess - Documenting questions probably
not answering
Status:
Fair amount of feedback on and off the list
new version published
updated scope
more stuff on netmod, restconf, yang, etc
took out a bunch of TCG-specific stuff
interactions/capabilities with the NEA stack
more on collection
some evaluation but not as much
Next Steps -
More feedback to integrate.
Still more removal of TCG references
further iterate on NETMOD ECP implementation section
Stephen: Congrats to Charles on RFC publishing
Karen: Whats the rough timeline for the next update?
Frank: Does the NETMOD ECP implementation include some YANG models?
- Not creating a new YANG model for ECP
- Integrating how YANG can be included in the data collection
process - Frank can do some review as well
6. Concise Software Identifiers (Birkholz)
https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/
Stephen lost this coinflip to Henk - Channeling Dave
Draft 06 posted in July
CDDL improvements - Enums, extension points, etc
Firmware extension improvements
close to WGLC
[Henk moves to the mic]
Henk: Draft basically complete, 3 issues
issue with an "any" attribute in CDDL
3 weeks from now - document complete.
Remove the firmware extension from CoSWID draft and into its own
document, maybe in SUIT
- manifest just a COSE envelope
- CPE concept in SCAP is going away, SWID taking that over
- will require SUIT manifest to use CoSWID
IANA registrations
CDDL cleanup
include example CDDL and verify content against latest
definitions
Chris (Chain Question): How stable is the CDDL specification?
Henk: "very stable". 3 months for WGLC on CDDL. The nits
addressed at the moment have nothing to do with CoSWID stuff.
The CDDL in CoSWID is stable enough...
Jarrett: CPE going away? When?
- Organizationally, NIST will be phasing out CPE over the next
3-5 years - Stephen talk to Jarret offline
7. ROLIE Software Descriptor Extension (Banghart)
draft-ietf-sacm-rolie-softwaredescriptor-02
Stephen:
-03 version published
more readable, clearer requirements
as interoperable as possible
media-type of "SWID" - Talking with ISO to create this media
type - will keep the group informed on progress of adding the
media type ISO in contact with IANA to add the media type and
then we'd standardize on ISO's stuff
Frank:
clarify SWID extension
Inside of the ROLIE entry, there is metadata - There's a link
that points to the SWID tag How to "talk SWID" using ROLIE
Request to do a last call to elicit feedback
8. ROLIE configuration Checklist Extension (Montville/Banghart)
draft-mandm-sacm-rolie-configuration-checklist
Added stephen as 3rd author
formatting and style changes throughout - matches other extensions
some still TODOs in there
updates for next IETF or some interims perhaps
9. Data Model of Network Infrastructure Device (Xia/Lin/Dong/Zheng)
- https://datatracker.ietf.org/doc/draft-lin-sacm-nid-mp-security-baseline/
- https://datatracker.ietf.org/doc/draft-xia-sacm-nid-dp-security-baseline/
- https://datatracker.ietf.org/doc/draft-dong-sacm-nid-infra-security-baseline/
Yue:
Recap of Objectives and Classification
define a minimum set of configuration and status
parameters of security related functions/services on a
network device that can be collected bu SACM collectors
and consumed by evaluator to assess device security
posture
Application, Network and Infrastructure Layers
Updated configuration attributes for VSI broadcast
traffic suppression Naming rule modifications derived
datatypes validated yang modules
[ talking fast, cant keep up as fast as I type ]
Infrastructure Layer:
Updated introduction
optimized data model - deleted redundant parts
integrity measurement updates
delete key store information
delete crypto engine information
Crypto algorithm updates
structural changes - Containers become
groupings
Continue to optimize data model
Complete data-plane baseline blocks
Seek more comments and co-authors
Adam: 3 drafts in total; Makes us think of CIS
benchmarks. Have tree of configuration items, that are
updated frequently.
If they are updated frequently, is there a more
dynamic method of updating without having to
always rev and RFC?
Frank: Good point; Network device configurations are
relatively stable. Most configuration specified in
their documents are relatively stable.
Ben Kaduk: Glad elliptic curve has been added
Adam: How applicable to other devices (Juniper, Cisco,
Barracuda), not just Huawei devices?
Response: Need to think about it; More research
needed
Adam: We have stuff at CIS (benchmarks). How does
this stuff map to SACM configuration baselines Frank:
Internal security baseline for their devices. Welcome
more contribution Nancy: Trying to understand;
Different baselines for different planes; Within each
capability, there are different security capabilities.
How that can become relevant to SACM. Are the
baselines relevant to SACM or I2NSF? Frank: Not a
security FUNCTION model, its a security POLICY model
Nancy: Looking at endpoint posture, services are more
complex Adam: Included network devices as an endpoint.
Network devices have a security configuration.
Posture assessment of a network device treated the same
as any other connected endpoint. See this as being
important in SACM. How are we going to organize what
to collect in an abstract way. This stuff describes
more specific attributes that are collected. Karen:
Time check. From a chair's perspective, its been a
"one-vendor" thing. Want to include other vendors to
ensure applicability. Frank: True - need more vendors
included in the process
Qiushi:
Management Plane baseline
4 submodules
updates to descriptive text in submodules
Administrator Security Policy
password complexity
password security policy
login failed limit
Login Security
controls on different login channels - SSH,
Telnet, etc
AAA
schemes, RADIUS, TACACS+
Admin access stats
Next steps - Update the other 3 submodules
collaboration from other vendors
adapt to YANG push mechanisms
10. Next Steps - (Chairs/WG)
Charter Dates Discussion
Adoption of ROLIE checklist draft
Week of Aug 20/27th
Week of Oct 8/15th
YANG Push - Bundled notification methods
*** HUM for 1 virtual interim in SEPT
FIN.