Notice of Pilot Activity in CVE Auto WG

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Notice of Pilot Activity in CVE Auto WG

Booth, Harold (Fed)

Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.

 

The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.

 

Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).

 

Reply | Threaded
Open this post in threaded view
|

RE: Notice of Pilot Activity in CVE Auto WG

Waltermire, David A.

Thank you Harold for providing this opportunity for feedback.

 

As I raised on the last board call, I have concerns with using GIT as a content management solution for CVE entries, since it has some limitations.

1)  It is unknown if the CNA community will want to use this solution. If they won’t adopt the approach eventually, then a pilot is a non-starter.

2) A centralized solution for content management may not fit a hierarchical organization of CNAs. We generally want CVE information to flow towards the root CAN and then to the list. Not all CNA hierarchies may wish to publish centrally. It might be better to look at a syndication approach which might better align with this type of organizational structure. Perhaps this should be piloted at the same time, allowing for a comparison to be made?

3) GIT requires a copy of the repo to be downloaded, with all the history which can be quite large. Some pruning of history may be possible, mitigating this issue. This should be investigated as part of the pilot. If GitHub is used I believe there is a 100 MB file size limit and a 1GB soft limit and a 2 GB hard limit on all repos, with a we have a 2TB limit. This could also pose a problem.

4) GIT does not have a way to search entries. A separate service will need to be built on top to support this, which complicates deployments.

 

I am sure there are other concerns I am missing.

 

I’d like to see the following occur before moving forward with this pilot:

1) Discussion of the GIT approach on the CNA list to explore if there are major concerns with its use before moving forward.

2) Discussion within the automation WG / board lists about alternate approaches that may be piloted as well. These should also be discussed on the CNA list before moving forward with a pilot.

 

Thanks,

Dave

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Booth, Harold (Fed)
Sent: Monday, May 08, 2017 5:09 PM
To: [hidden email]
Cc: cve-board-auto-list <[hidden email]>
Subject: Notice of Pilot Activity in CVE Auto WG

 

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing

Feedback

Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.

 

The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.

 

Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).

 

Reply | Threaded
Open this post in threaded view
|

Re: Notice of Pilot Activity in CVE Auto WG

Kurt Seifried-2


On Tue, May 9, 2017 at 12:27 PM, Waltermire, David A. (Fed) <[hidden email]> wrote:

Thank you Harold for providing this opportunity for feedback.

 

As I raised on the last board call, I have concerns with using GIT as a content management solution for CVE entries, since it has some limitations.

1)  It is unknown if the CNA community will want to use this solution. If they won’t adopt the approach eventually, then a pilot is a non-starter.


I know in the open source community we're all git all the time basically, there are also various things to git gateways. 
 

2) A centralized solution for content management may not fit a hierarchical organization of CNAs. We generally want CVE information to flow towards the root CAN and then to the list. Not all CNA hierarchies may wish to publish centrally. It might be better to look at a syndication approach which might better align with this type of organizational structure. Perhaps this should be piloted at the same time, allowing for a comparison to be made?


Another aspect is do the CNA's do quality control/enforce their own rules, e.g. there's the minimum CVE specification, and chances are other CNA's may require more (e.g. DWF will require IMPACT explicitly, and URL's MUST be publicly accessible with no login/gateway to access them). So I assumed we'd have a publishing model where CNA's just publish to their parent until it hits MITRE.
 

3) GIT requires a copy of the repo to be downloaded, with all the history which can be quite large. Some pruning of history may be possible, mitigating this issue. This should be investigated as part of the pilot. If GitHub is used I believe there is a 100 MB file size limit and a 1GB soft limit and a 2 GB hard limit on all repos, with a we have a 2TB limit. This could also pose a problem.


We can easily shard the repos (already done by DWF, into blocks of 1000 per year).
 

4) GIT does not have a way to search entries. A separate service will need to be built on top to support this, which complicates deployments.


That is out of the scope as far as I'm concerned. For me the requirements boil down to:

1) Must support version control (who did what to which entry when and why?)
2) Must support signing so we have a strong chain of ownership (and I don't want to commit to JSON signing yet as many of those solutions make the JSON not human readable)
3) Must support collaboration (e.g. multiple CNA's using the same system, I'm not setting up one data storage thing per CNA) 
4) Must support some degree of delegation (e.g. I can allow a CNA to further grant access so I'm not a chokepoint)
5) MUST SUPPORT PUSHING OF DATA, I don't want to have to go hunting for CVE entries! (MITRE knows how much fun that is)

git fulfilled all the above, and has the bonus of a free hosting provider (github) and multiple other hosting providers (gitlabs) and the ability to easily self host (using software like gitlab for example, or setting it up myself if absolutely needed). 
 

 

I am sure there are other concerns I am missing.

 

I’d like to see the following occur before moving forward with this pilot:

1) Discussion of the GIT approach on the CNA list to explore if there are major concerns with its use before moving forward.


The main concern I had was git repo size, solved by sharding.
 

2) Discussion within the automation WG / board lists about alternate approaches that may be piloted as well. These should also be discussed on the CNA list before moving forward with a pilot.


What are the actual alternatives being proposed? I've heard of some sort of atom/rss syndication deal, but that means people have to run a system with a server that will periodically pull the data. 
 

 

Thanks,

Dave

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Booth, Harold (Fed)
Sent: Monday, May 08, 2017 5:09 PM
To: [hidden email]
Cc: cve-board-auto-list <[hidden email]>
Subject: Notice of Pilot Activity in CVE Auto WG

 

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing

Feedback

Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.

 

The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.

 

Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).

 




--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Notice of Pilot Activity in CVE Auto WG

Art Manion
On 5/9/17 3:02 PM, Kurt Seifried wrote:

> So I assumed we'd have a publishing model where CNA's just publish to
> their parent until it hits MITRE.

I'd suggest a model where every CNA publishes, in at least the CVE MVP
format (but more is OK, such as DWF requirements).  I guess this is pull
not push?  Parent CNAs would be required to pull/aggregate from their
children.

This way, anybody can pull from any CNA, MITRE or NVD can pull from
all/lots of CNAs.  This allows a lot more flexibility in aggregation,
possibly at the cost of more effort for a central aggregator (MITRE).

I think Atom/PubSub is more than this, but I haven't read up on it.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: Notice of Pilot Activity in CVE Auto WG

Kurt Seifried-2


On Tue, May 9, 2017 at 1:09 PM, Art Manion <[hidden email]> wrote:
On 5/9/17 3:02 PM, Kurt Seifried wrote:

> So I assumed we'd have a publishing model where CNA's just publish to
> their parent until it hits MITRE.

I'd suggest a model where every CNA publishes, in at least the CVE MVP
format (but more is OK, such as DWF requirements).  I guess this is pull
not push?  Parent CNAs would be required to pull/aggregate from their
children.

To be clear when we talk about publishing there are two very different aspects of this:

1) publishing the CVE publicly (e.g. in a security advisory)
2) publishing the CVE so that it somehow ends up in the MITRE database

and I was talking about #2 only. As for #1 I don't care really (e.g. they may simply use the CVE # in a commit/issue tracker and not have an advisory per se, but as long as they publish the CVE to their parent and ultimately to MITRE who cares). I don't want to start dictacting security process/etc to anyone using CVE (e.g. can MUST they publish the minimum CVE format in either the CSV or JSON format? what if that data is in their advisory format, which is a PDF?). 
 

This way, anybody can pull from any CNA, MITRE or NVD can pull from
all/lots of CNAs.  This allows a lot more flexibility in aggregation,
possibly at the cost of more effort for a central aggregator (MITRE).

I think a central aggregation model is the only way to go. Or else we admit we're giving up on MITRE having a full view of the database. Note: blockchain would solve a pile of these problems... just saying =). 
 

I think Atom/PubSub is more than this, but I haven't read up on it.

 - Art



--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Notice of Pilot Activity in CVE Auto WG

Art Manion
In reply to this post by Waltermire, David A.
On 5/9/17 2:27 PM, Waltermire, David A. (Fed) wrote:

> I’d like to see the following occur before moving forward with this pilot:
>
> 1) Discussion of the GIT approach on the CNA list to explore if there
> are major concerns with its use before moving forward.

I'm OK running the GIT pilot more or less now, I'd suggest we discuss
after we have some actual experience.  Dave raises some valid issues,
but I'm of the mind to try GIT and see how it works.

> 2) Discussion within the automation WG / board lists about alternate
> approaches that may be piloted as well. These should also be discussed
> on the CNA list before moving forward with a pilot.

I never assumed we would only run one pilot (GIT) or even one at a time
(depending on resources).  I'd also like to design and test a
publish/pull model, which may or may not be what Dave is calling
syndication.

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: Notice of Pilot Activity in CVE Auto WG

Art Manion
In reply to this post by Kurt Seifried-2
On 5/9/17 3:15 PM, Kurt Seifried wrote:

>     > So I assumed we'd have a publishing model where CNA's just publish to
>     > their parent until it hits MITRE.
>
>     I'd suggest a model where every CNA publishes, in at least the CVE MVP
>     format (but more is OK, such as DWF requirements).  I guess this is pull
>     not push?  Parent CNAs would be required to pull/aggregate from their
>     children.
>
> To be clear when we talk about publishing there are two very different
> aspects of this:
>
> 1) publishing the CVE publicly (e.g. in a security advisory)
> 2) publishing the CVE so that it somehow ends up in the MITRE database
>
> and I was talking about #2 only. As for #1 I don't care really (e.g.
> they may simply use the CVE # in a commit/issue tracker and not have an
> advisory per se, but as long as they publish the CVE to their parent and
> ultimately to MITRE who cares). I don't want to start dictacting
> security process/etc to anyone using CVE (e.g. can MUST they publish the
> minimum CVE format in either the CSV or JSON format? what if that data
> is in their advisory format, which is a PDF?).

I'm also only talking about #2.  My assumption is that CNAs submit or
publish a CVE entry when the vulnerability becomes public, using the
proper MVP or MVP+.  A CNA might also publish an advisory (#1), but the
CVE record (#2) is required.

>     This way, anybody can pull from any CNA, MITRE or NVD can pull from
>     all/lots of CNAs.  This allows a lot more flexibility in aggregation,
>     possibly at the cost of more effort for a central aggregator (MITRE).
>
> I think a central aggregation model is the only way to go. Or else we
> admit we're giving up on MITRE having a full view of the database. Note:
> blockchain would solve a pile of these problems... just saying =).

Why can't MITRE just pull from all of its immediately subordinate CNAs
(who in turn are required to pull from theirs)?  That'd give MITRE a
full view.

I won't claim to be a blockchain expert, but I've talked with colleagues
at CERT/CC about a model to sign assertions about vulnerabilities (e.g.,
Red Hat claims a blob of vulnerability information is correct, CERT/CC
agrees and signs, somebody else disagrees and signs...).

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: Notice of Pilot Activity in CVE Auto WG

Kurt Seifried


On Tue, May 9, 2017 at 1:23 PM, Art Manion <[hidden email]> wrote:
 

Why can't MITRE just pull from all of its immediately subordinate CNAs
(who in turn are required to pull from theirs)?  That'd give MITRE a
full view.

One thing I want to note is that PULL means I need to check ALL my sub CNA's (and I will hopefully have hundreds) meaning I need to do X hundred PULLS every Y minutes, vs. PUSH where we only do it as needed. 
 
I won't claim to be a blockchain expert, but I've talked with colleagues
at CERT/CC about a model to sign assertions about vulnerabilities (e.g.,
Red Hat claims a blob of vulnerability information is correct, CERT/CC
agrees and signs, somebody else disagrees and signs...).

So without getting to in depth there's a bunch of different properties you can have in blockchains for various use cases (e.g. a currency vs. a land title vs. an insurance records blockchain). The main thing would be defining what we want with respect to CVE, do we want to be able to roll back transactions and "delete" data? or do we make it inviolate? how many entities have to vote/what weighting is used? do we want side chains for privacy (e.g. embargoed issues)? and so on. Part of my current goal is to get operational experience sharing the data so we can figure out what properties we actually need (e.g. in picking git one aspect is we can get rid of stuff, but it's not "deleted", but I think this is ok because once you publish stuff on the Internet, well, you can't really scrub it off any ways). 
 

 - Art



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
Reply | Threaded
Open this post in threaded view
|

blockchain for CVE (was re: Notice of Pilot Activity in CVE Auto WG)

Art Manion
On 5/9/17 3:41 PM, Kurt Seifried wrote:

>     I won't claim to be a blockchain expert, but I've talked with colleagues
>     at CERT/CC about a model to sign assertions about vulnerabilities (e.g.,
>     Red Hat claims a blob of vulnerability information is correct, CERT/CC
>     agrees and signs, somebody else disagrees and signs...).
>
> So without getting to in depth there's a bunch of different properties
> you can have in blockchains for various use cases (e.g. a currency vs. a
> land title vs. an insurance records blockchain). The main thing would be
> defining what we want with respect to CVE, do we want to be able to roll
> back transactions and "delete" data? or do we make it inviolate? how
> many entities have to vote/what weighting is used? do we want side
> chains for privacy (e.g. embargoed issues)? and so on. Part of my
> current goal is to get operational experience sharing the data so we can
> figure out what properties we actually need (e.g. in picking git one
> aspect is we can get rid of stuff, but it's not "deleted", but I think
> this is ok because once you publish stuff on the Internet, well, you
> can't really scrub it off any ways).

I'd say keep all the transactions, there's value in saying that
something was assigned/claimed and later revoked or changed.

And CVE should stay out of embargos/non-public vulnerability
coordination.  There might be a state for "CVE assigned but not public
yet," or perhaps just a little more, to support CNAs that do work with
emgbargos, but that's about it.  Vulnerability identification is a big
enough problem :)

 - Art
Reply | Threaded
Open this post in threaded view
|

Re: blockchain for CVE (was re: Notice of Pilot Activity in CVE Auto WG)

Kurt Seifried-2


On Tue, May 9, 2017 at 2:11 PM, Art Manion <[hidden email]> wrote:
On 5/9/17 3:41 PM, Kurt Seifried wrote:
>     I won't claim to be a blockchain expert, but I've talked with colleagues
>     at CERT/CC about a model to sign assertions about vulnerabilities (e.g.,
>     Red Hat claims a blob of vulnerability information is correct, CERT/CC
>     agrees and signs, somebody else disagrees and signs...).
>
> So without getting to in depth there's a bunch of different properties
> you can have in blockchains for various use cases (e.g. a currency vs. a
> land title vs. an insurance records blockchain). The main thing would be
> defining what we want with respect to CVE, do we want to be able to roll
> back transactions and "delete" data? or do we make it inviolate? how
> many entities have to vote/what weighting is used? do we want side
> chains for privacy (e.g. embargoed issues)? and so on. Part of my
> current goal is to get operational experience sharing the data so we can
> figure out what properties we actually need (e.g. in picking git one
> aspect is we can get rid of stuff, but it's not "deleted", but I think
> this is ok because once you publish stuff on the Internet, well, you
> can't really scrub it off any ways).

I'd say keep all the transactions, there's value in saying that
something was assigned/claimed and later revoked or changed.

And CVE should stay out of embargos/non-public vulnerability
coordination.  There might be a state for "CVE assigned but not public
yet," or perhaps just a little more, to support CNAs that do work with
emgbargos, but that's about it.  Vulnerability identification is a big
enough problem :)

 - Art

Right but we also want to make technology choices that ideally don't force people to create entirely separate systems to handle embargoed flaws, e.g. I'd rather have one CNA in a box solution that handles both public and embargoed, instead of 2 (a public and a private) system. Basically I'd like to have my cake, my hidden cake, and be able to eat them both. =)


--
Kurt Seifried
[hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Notice of Pilot Activity in CVE Auto WG

Coffin, Chris
In reply to this post by Waltermire, David A.

Dave,

 

Maybe this all just comes down to terminology and intent. Your response focuses on GIT, but I don’t think this is the focus of the pilot at all.

 

What do we actually mean when we say “pilot” in this case. Harold and George can correct me if I am wrong, but this is really just a test that happens to use GIT. Harold made the statement in the beginning of this thread that “All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot.” This means that GIT isn’t the chosen solution and shouldn’t be the focus at this point. However, if it works well as an option then maybe we might be open to using it as a part or even a major part of the solution. We won’t know until we give it a try right?

 

Additionally, the intent of the pilot is to “investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data.” Also stated was ‘We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation.’ Are there other alternatives to support this intent, yes. A couple have been raised and I would agree that the Automation WG should investigate those as well. IMO though, I don’t think the WG should wait on identifying those alternatives before trying out the current one.

 

Last, This approach has already been developed in cooperation with a handful of CNAs as they are on the Automation WG. Based on the language of Harold’s email, the pilot would be limited to those CNAs and would not be broadly applicable to all CNAs. Again, Harold or George can correct me if I am wrong on this.

 

Chris

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Waltermire, David A. (Fed)
Sent: Tuesday, May 9, 2017 1:28 PM
To: Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
Cc: cve-board-auto-list <[hidden email]>
Subject: RE: Notice of Pilot Activity in CVE Auto WG

 

Thank you Harold for providing this opportunity for feedback.

 

As I raised on the last board call, I have concerns with using GIT as a content management solution for CVE entries, since it has some limitations.

1)  It is unknown if the CNA community will want to use this solution. If they won’t adopt the approach eventually, then a pilot is a non-starter.

2) A centralized solution for content management may not fit a hierarchical organization of CNAs. We generally want CVE information to flow towards the root CAN and then to the list. Not all CNA hierarchies may wish to publish centrally. It might be better to look at a syndication approach which might better align with this type of organizational structure. Perhaps this should be piloted at the same time, allowing for a comparison to be made?

3) GIT requires a copy of the repo to be downloaded, with all the history which can be quite large. Some pruning of history may be possible, mitigating this issue. This should be investigated as part of the pilot. If GitHub is used I believe there is a 100 MB file size limit and a 1GB soft limit and a 2 GB hard limit on all repos, with a we have a 2TB limit. This could also pose a problem.

4) GIT does not have a way to search entries. A separate service will need to be built on top to support this, which complicates deployments.

 

I am sure there are other concerns I am missing.

 

I’d like to see the following occur before moving forward with this pilot:

1) Discussion of the GIT approach on the CNA list to explore if there are major concerns with its use before moving forward.

2) Discussion within the automation WG / board lists about alternate approaches that may be piloted as well. These should also be discussed on the CNA list before moving forward with a pilot.

 

Thanks,

Dave

 

From: [hidden email] [[hidden email]] On Behalf Of Booth, Harold (Fed)
Sent: Monday, May 08, 2017 5:09 PM
To: [hidden email]
Cc: cve-board-auto-list <[hidden email]>
Subject: Notice of Pilot Activity in CVE Auto WG

 

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing

Feedback

Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.

 

The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.

 

Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).

 

Reply | Threaded
Open this post in threaded view
|

RE: Notice of Pilot Activity in CVE Auto WG

Booth, Harold (Fed)

Chris,

 

  You read my mind. The intent is not to figure out if GIT is the answer it is find out what the requirements the answer must meet. GIT just happens to be the vehicle that we are using at the moment to find the answer. I think having a discussion on the CNA list about GIT would be premature since I am not convinced that it would even be appropriate as the eventual solution. And as for other pilots, this pilot does not necessarily preclude other pilots, join the list (or the calls) and start making suggestions.

 

Regards,

 

-Harold

 

From: Coffin, Chris [mailto:[hidden email]]
Sent: Tuesday, May 09, 2017 5:10 PM
To: Waltermire, David A. (Fed) <[hidden email]>; Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
Cc: cve-board-auto-list <[hidden email]>
Subject: RE: Notice of Pilot Activity in CVE Auto WG

 

Dave,

 

Maybe this all just comes down to terminology and intent. Your response focuses on GIT, but I don’t think this is the focus of the pilot at all.

 

What do we actually mean when we say “pilot” in this case. Harold and George can correct me if I am wrong, but this is really just a test that happens to use GIT. Harold made the statement in the beginning of this thread that “All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot.” This means that GIT isn’t the chosen solution and shouldn’t be the focus at this point. However, if it works well as an option then maybe we might be open to using it as a part or even a major part of the solution. We won’t know until we give it a try right?

 

Additionally, the intent of the pilot is to “investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data.” Also stated was ‘We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation.’ Are there other alternatives to support this intent, yes. A couple have been raised and I would agree that the Automation WG should investigate those as well. IMO though, I don’t think the WG should wait on identifying those alternatives before trying out the current one.

 

Last, This approach has already been developed in cooperation with a handful of CNAs as they are on the Automation WG. Based on the language of Harold’s email, the pilot would be limited to those CNAs and would not be broadly applicable to all CNAs. Again, Harold or George can correct me if I am wrong on this.

 

Chris

 

From: [hidden email] [[hidden email]] On Behalf Of Waltermire, David A. (Fed)
Sent: Tuesday, May 9, 2017 1:28 PM
To: Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
Cc: cve-board-auto-list <[hidden email]>
Subject: RE: Notice of Pilot Activity in CVE Auto WG

 

Thank you Harold for providing this opportunity for feedback.

 

As I raised on the last board call, I have concerns with using GIT as a content management solution for CVE entries, since it has some limitations.

1)  It is unknown if the CNA community will want to use this solution. If they won’t adopt the approach eventually, then a pilot is a non-starter.

2) A centralized solution for content management may not fit a hierarchical organization of CNAs. We generally want CVE information to flow towards the root CAN and then to the list. Not all CNA hierarchies may wish to publish centrally. It might be better to look at a syndication approach which might better align with this type of organizational structure. Perhaps this should be piloted at the same time, allowing for a comparison to be made?

3) GIT requires a copy of the repo to be downloaded, with all the history which can be quite large. Some pruning of history may be possible, mitigating this issue. This should be investigated as part of the pilot. If GitHub is used I believe there is a 100 MB file size limit and a 1GB soft limit and a 2 GB hard limit on all repos, with a we have a 2TB limit. This could also pose a problem.

4) GIT does not have a way to search entries. A separate service will need to be built on top to support this, which complicates deployments.

 

I am sure there are other concerns I am missing.

 

I’d like to see the following occur before moving forward with this pilot:

1) Discussion of the GIT approach on the CNA list to explore if there are major concerns with its use before moving forward.

2) Discussion within the automation WG / board lists about alternate approaches that may be piloted as well. These should also be discussed on the CNA list before moving forward with a pilot.

 

Thanks,

Dave

 

From: [hidden email] [[hidden email]] On Behalf Of Booth, Harold (Fed)
Sent: Monday, May 08, 2017 5:09 PM
To: [hidden email]
Cc: cve-board-auto-list <[hidden email]>
Subject: Notice of Pilot Activity in CVE Auto WG

 

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing

Feedback

Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.

 

The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.

 

Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).

 

Reply | Threaded
Open this post in threaded view
|

RE: Notice of Pilot Activity in CVE Auto WG

Coffin, Chris

Per discussion on the Automation WG call today, the pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data is beginning today. Dave Waltermire of NIST was present and in agreement with moving the pilot forward. It was also suggested that a notice be sent to the Board to let them know that the pilot has begun.

 

Regards,

 

Chris

 

From: Booth, Harold (Fed) [mailto:[hidden email]]
Sent: Wednesday, May 10, 2017 7:29 AM
To: Coffin, Chris <[hidden email]>; Waltermire, David A. (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
Cc: cve-board-auto-list <[hidden email]>
Subject: RE: Notice of Pilot Activity in CVE Auto WG

 

Chris,

 

  You read my mind. The intent is not to figure out if GIT is the answer it is find out what the requirements the answer must meet. GIT just happens to be the vehicle that we are using at the moment to find the answer. I think having a discussion on the CNA list about GIT would be premature since I am not convinced that it would even be appropriate as the eventual solution. And as for other pilots, this pilot does not necessarily preclude other pilots, join the list (or the calls) and start making suggestions.

 

Regards,

 

-Harold

 

From: Coffin, Chris [[hidden email]]
Sent: Tuesday, May 09, 2017 5:10 PM
To: Waltermire, David A. (Fed) <[hidden email]>; Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
Cc: cve-board-auto-list <[hidden email]>
Subject: RE: Notice of Pilot Activity in CVE Auto WG

 

Dave,

 

Maybe this all just comes down to terminology and intent. Your response focuses on GIT, but I don’t think this is the focus of the pilot at all.

 

What do we actually mean when we say “pilot” in this case. Harold and George can correct me if I am wrong, but this is really just a test that happens to use GIT. Harold made the statement in the beginning of this thread that “All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot.” This means that GIT isn’t the chosen solution and shouldn’t be the focus at this point. However, if it works well as an option then maybe we might be open to using it as a part or even a major part of the solution. We won’t know until we give it a try right?

 

Additionally, the intent of the pilot is to “investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data.” Also stated was ‘We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation.’ Are there other alternatives to support this intent, yes. A couple have been raised and I would agree that the Automation WG should investigate those as well. IMO though, I don’t think the WG should wait on identifying those alternatives before trying out the current one.

 

Last, This approach has already been developed in cooperation with a handful of CNAs as they are on the Automation WG. Based on the language of Harold’s email, the pilot would be limited to those CNAs and would not be broadly applicable to all CNAs. Again, Harold or George can correct me if I am wrong on this.

 

Chris

 

From: [hidden email] [[hidden email]] On Behalf Of Waltermire, David A. (Fed)
Sent: Tuesday, May 9, 2017 1:28 PM
To: Booth, Harold (Fed) <[hidden email]>; cve-editorial-board-list <[hidden email]>
Cc: cve-board-auto-list <[hidden email]>
Subject: RE: Notice of Pilot Activity in CVE Auto WG

 

Thank you Harold for providing this opportunity for feedback.

 

As I raised on the last board call, I have concerns with using GIT as a content management solution for CVE entries, since it has some limitations.

1)  It is unknown if the CNA community will want to use this solution. If they won’t adopt the approach eventually, then a pilot is a non-starter.

2) A centralized solution for content management may not fit a hierarchical organization of CNAs. We generally want CVE information to flow towards the root CAN and then to the list. Not all CNA hierarchies may wish to publish centrally. It might be better to look at a syndication approach which might better align with this type of organizational structure. Perhaps this should be piloted at the same time, allowing for a comparison to be made?

3) GIT requires a copy of the repo to be downloaded, with all the history which can be quite large. Some pruning of history may be possible, mitigating this issue. This should be investigated as part of the pilot. If GitHub is used I believe there is a 100 MB file size limit and a 1GB soft limit and a 2 GB hard limit on all repos, with a we have a 2TB limit. This could also pose a problem.

4) GIT does not have a way to search entries. A separate service will need to be built on top to support this, which complicates deployments.

 

I am sure there are other concerns I am missing.

 

I’d like to see the following occur before moving forward with this pilot:

1) Discussion of the GIT approach on the CNA list to explore if there are major concerns with its use before moving forward.

2) Discussion within the automation WG / board lists about alternate approaches that may be piloted as well. These should also be discussed on the CNA list before moving forward with a pilot.

 

Thanks,

Dave

 

From: [hidden email] [[hidden email]] On Behalf Of Booth, Harold (Fed)
Sent: Monday, May 08, 2017 5:09 PM
To: [hidden email]
Cc: cve-board-auto-list <[hidden email]>
Subject: Notice of Pilot Activity in CVE Auto WG

 

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing

Feedback

Per discussion on the last board call it has been requested that all WGs send a brief notice to the board to both inform the board and provide an opportunity for the board to give input on any pilots.

 

The CVE Automation Working Group is proposing to run a pilot using a private MITRE-hosted GIT repository to investigate the requirements surrounding the automation of updating and retrieving the CVE JSON data. We hope to learn not only what features are necessary to support the “plumbing” of sending and receiving the data, but also what attributes and metadata are needed in the CVE format to support automation. Participants will be MITRE and members of the CVE Auto WG with the goal for participants to update their CVEs using the format in the GIT repo and for participants to update and receive updated information through the GIT repo. Participants will be the only ones with access to the GIT repository. All participants should understand that this is only a pilot and as such there is no guarantee that any eventual solution will look anything like the pilot. Initial proposed pilot is planned to run no later than through August 21st and if we need to extend the pilot we will come back to the board to request an extension.

 

Unless there are any sustained objections the pilot will start in earnest on May 15th (the next CVE auto WG call).