sacmwg / vulnerability-scenario Goto Github PK

Makefile 0.90% Python 99.10%

vulnerability-scenario's Introduction

SACM Vulnerability Assessment Scenario

This is the working area for the SACM working group internet-draft, "SACM Vulnerability Assessment Scenario".

Editor's copy
[Individual Draft] (https://tools.ietf.org/html/draft-ietf-sacm-vuln-scenario)
[Compare Working Group and Editor's Drafts] (https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/id/draft-ietf-sacm-vuln-scenario&url2=https://sacmwg.github.io/vulnerability-scenario/draft-ietf-sacm-vuln-scenario.txt)

The official copy of this document is now posted on the SACM WG wiki page (https://trac.ietf.org/trac/sacm/wiki/SacmVulnerabilityAssessmentScenario). There are no plans to publish subsequent Internet-Drafts for this document and all updates will be made to the wiki page.

Status

The document has been adopted as a working group document and is under active developement.

Building the Draft

Formatted text and HTML versions of the draft can be built using make.

$ make

This requires that you have the necessary software installed. See the instructions.

Contributing

Before submitting feedback, please familiarize yourself with our current issues list and review the working group documents and mailing list discussion. If you're new to this, you may also want to read the Tao of the IETF.

Be aware that all contributions to the specification fall under the "NOTE WELL" terms outlined below.

The best way to provide feedback (editorial or design) and ask questions is sending an e-mail to our mailing list (info). This will ensure that the entire Working Group sees your input in a timely fashion.
If you have editorial suggestions (i.e., those that do not change the meaning of the specification), you can either:

a) Fork this repository and submit a pull request; this is the lowest friction way to get editorial changes in.

b) Submit a new issue to Github, and mention that you believe it is editorial in the issue body. It is not necessary to notify the mailing list for editorial issues.

c) Make comments on individual commits in Github. Note that this feedback is processed only with best effort by the editors, so it should only be used for quick editorial suggestions or questions.

For non-editorial (i.e., design) issues, you can also create an issue on Github. However, you must notify the mailing list when creating such issues, providing a link to the issue in the message body.

Note that github issues are not for substantial discussions; the only appropriate place to discuss design issues is on the mailing list itself.

NOTE WELL

Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to:

The IETF plenary session
The IESG, or any member thereof on behalf of the IESG
Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices
Any IETF working group or portion thereof
Any Birds of a Feather (BOF) session
The IAB or any member thereof on behalf of the IAB
The RFC Editor or the Internet-Drafts function
All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).

Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice.

Please consult RFC 5378 and RFC 3979 for details.

A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements.

A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

vulnerability-scenario's People

Contributors

Stargazers

Watchers

Forkers

jimsch adammontville djhaynes stephenbanghart-backup jedi-5

vulnerability-scenario's Issues

defining targeted collection

http://www.ietf.org/mail-archive/web/sacm/current/msg04046.html

storage of collected data

http://www.ietf.org/mail-archive/web/sacm/current/msg03990.html

Get XMPP-Grid server (OpenFire +) set up on VM

I think this is done.

capture vulnerability assessment scenario information needs into the information model

We need to capture the vulnerability assessment scenario information needs into the information model so that data models will properly support the scenario.

Add XMPP-Grid information to documentation

Update https://github.com/sacmwg/vulnerability-scenario/tree/strongswan/ietf_hackathon/strongSwan with updated XMPP-Grid server information

typo Vulnerability rememdiation

Vulnerability rememdiation
should be
Vulnerability remediation

Confirm broker exists

We need to confirm that the broker is software that exists before we can rely upon it for our IETF 100 hackathon.

Kick off charter discussion and finalize

Publish the v2 charter for discussion, and get discussion going on it, so that we can really do it.

Flash Cisco 3850

Ensure the Cisco 3850 is flashed with appropriate yang-push capabilities for target element acquisition (we'll need Eric for this).

Get xmpp-grid client code to the team

Henk needs to ship the xmpp-grid client library and documentation to at least Bill and Andreas, if not the whole crew working on this project.

incorporate feedback from opsec wg session at ietf 95

One piece of feedback that we received on the vulnerability assessment scenario during the OPSEC WG is that we should include information about side-channel attacks if we pull in Server Discovery and Validation specification into our work.

Set up account for Andreas on VM

Not sure if this is still needed given the separate setup Andreas has created, and that we'll have an on-site setup.

Fix wording in abstract

Last sentence should read: "Endpoints are assessed against the vulnerability description information based on a combination of examining known endpoint characterization information and collected endpoint information." (Emphasis added for the addition of the word "on".)

Define IETF 100 Hackathon Goals

We need to define a set of goals and outcomes for this hackathon effort.

processing vulnerability description information

http://www.ietf.org/mail-archive/web/sacm/current/msg03989.html

Develop SACM Component: Imperative guidance repository

At the last planning meeting Henk suggested that we develop an imperative guidance repository. What do we need to do to make this happen? What should such imperative guidance look like?

StrongTNC Push SWID + SWIMA

Andreas: strongTNC is now pushing complete SWID tags and SWIMA events in real-time to the sacm/swidtags and sacm/events topics, respectively. The current encoding of the push items is XML.

Experience gained:

It might be better to annouce new SWID tags by pushing either the tagID or the unique softwareID, only. Subscribers can then download the [potentially huge] SWID tag directly from the strongTNC publisher via the REST interface.
Should the REST URI be included in the push message for ease of use?
If yes, might a JSON encoding of the push messages be preferable?
Currently there is no persistence of the published messages. A subscriber can read them once and after that just the last message of each topic (node) which is cached. Should the Openfire XMPP server persist all messages?

Vulnerability Draft Needed Work

The vulnerability scenario draft contained all of the necessary information, but it also seemed to contain a lot of information not immediately relevant to understanding the scenario. I've submitted a pull request with my proposed changes, which some might view as hacking the draft to pieces. In reality, I just moved some things around, reworded some other things for clarity, and referenced the data table in the appendix rather than having that information repeated. (See #3)

Update on strongSwan XMPP-Grid service

I have updated the HOWTO on the use of the strongSwan XMPP-Grid server which will be available online during the IETF 100 hackathon. The example pubsub_client based on the Python sleekxmpp library which is installed with "sudo pip install sleekxmpp dnspython" now allows to modify the configuration of the Pubsub nodes e.g. by adding publishers and making the pushed items persistent.

Any Hackathon participant needing an user account for the strongSwan XMPP-Grid broker can drop me an email.

Andreas

clarifying the definition of vulnerability detection data

https://www.ietf.org/mail-archive/web/sacm/current/msg04045.html

integrate applicable definitions into the terminology draft

We need to integrate applicable definitions from the vulnerability assessment scenario into the terminology draft.

determine alignment of vulnerability assessment process with sacm tasks

We should examine the vulnerability assessment process outlined in the draft and determine the alignment with SACM tasks and update as necessary.

Cisco 3850 is on site

When we arrive and begin setting up for the hackathon, we need to ensure this device is available. If it's not, we'll have to modify our plans somewhat.

Consider xmpp topics to use for hackathon

Open for discussion on 2 November.

Document xmpp-grid broker interface(s)

Other developers will need to understand how they interact with the xmpp-grid broker.

where do vulnerability assessment attributes belong

http://www.ietf.org/mail-archive/web/sacm/current/msg03991.html

Put broker device online for client development

The broker device with px-grid running needs to be online before client development can really start happening.

Proposed wording change in last sentence of security considerations

Propose the last sentence to read: "As a result, organizations should consider properly protecting the vulnerability description data it ingests."

How much specification do we need in the data table?

On page 5 of the draft some examples of endpoint data are provided, and readers are directed to see "Data Attribute Tables and Definitions". There are many data attributes listed in that table, but some attributes seem too abstract. Specifically:

Operating system attributes (e.g., version, service pack level, edition, etc.)
Installed software attributes (e.g., version, patch level, install path, etc.)
Other software configuration information

Are we expecting that the software identification draft will provide the necessary level of detail?

Update Appendix E to reference Critical Controls version 6

I recommend referencing the latest version of the Critical Controls, which has undergone significant change from version 5.1. Doing so will require:

Updating the informative reference from version 5.1 to version 6.0
Changing references in Appendix E from "Council on Cybersecurity" to "Center for Internet Security"
Review each Critical Security Control and sub-control reference for accuracy.

Update README.md with 100-specific information

The README.md file needs to be updated to include IETF 100 hackathon information.

remove todo from security considerations section

Remove the todo from the security considerations section. See the following thread for additional information.

https://www.ietf.org/mail-archive/web/sacm/current/msg03893.html

review appendices and include references

We should review the appendices and include the appropriate references to them through the main body of the document.

change detection with an endpoint management capability

https://www.ietf.org/mail-archive/web/sacm/current/msg03992.html

Validate Hackathon (100) Scope

Use this issue to discuss the anticipated scope of the hackathon. During the last hackathon, we essentially had two tables working separately. Both efforts were successful, and then during the SACM session at IETF 99 there was in-room support for merging the two efforts in a continuation for the IETF 100 hackathon.

That's what this scope issue is about - what do you believe the scope of this hackathon effort ought to be? Be as precise as possible, be open and accepting in the discussion.