Project Charter for SIGVI R3

Hello world!

Finally, after ages of being away the SIGVI project. Now, after 3 years taking care of my three children, I can resume this project where I left it off.

I would like to continue it towards the 3rd major release: sigvi r3.

I have received some requests for new features, it's great, but I would like to have as much as possible.

Please, let me know what do you expect from a vulnerability management system. And better: if you are using SIGVI, or if you tried it, what would you like to add or modify.

Thanks to all, and take care.

[SecMgr]

A batch interface to upload all software and configuration data would be very helpfull needed to be able to manage und import the different inputs from e.g. information on software CIs from an existing CMDB / Inventory scan, to upload information on open source libraries in use from the dependency check (see https://github.com/jeremylong/DependencyCheck), or reference list from software packages installed on operating systems. If the database table is defines and stays stable defining the format and tooling would be the first step.

[tiochan]

Good idea. In fact, I plan to add a HTTP/HTTPs API.

[SecMgr]

There is one more thing: To make use of existing ticketing systems at corporate environments and make use of the work order, tracking and reporting process provided by the ticketing it would be of interest if outbound email Messages generated by SigVi could be customized to add key words as part of the email body. Ticketing system supporting an inbound email interface will makes use of the key words generating an associated ticket. Routing, tracking and escalation is then performed through the ticketing system.

[tiochan]

That's cool!

We have been using something like that, but instead this solution, we used our ERP API to create the tickets directly from SIGVI.

Your proposal is much better, so this could fit more situations.
I take note of this as a possible new feature.

Thanks a lot.

[Stephane Grundschober]

Hi Sebastian,
nice to see you around! I also got stuck with Kids, n°1 is 2yo, and n°2 is 3 months old now! :-)

Back to sigvi: Based on the experience gained with R2, I can give you this input:
- CPE matching was in practice really difficult to do correctly
- Documenting the initial inventory was less than trivial: what is the name as known by NVD? What about open source? There was multiple naming convention in the historical data of CPE, and NVD went forward with naming whereas CPE lagged behind...
- maybe with CPE v2.3 it is more stable, but I still see it as the main difficulty
- Maintaining the inventory up to date proved to be too fastidious for sysadmins, they actually never updated their entries.
- This lead over time to less and less relevant alerts...

-> My proposition:
- as mentionned above, plan different import capabilities (OCSP Inventory may be another popular one)
- CPE matching: leave the possibility to have very broad "regexp". For example, one team would like to receive anything with "cisco" in it...
- Workflow: sysadmins do not have much time available, so it would be great if they could give feedback on the alerts in "one" click (especially to discard non-relevant alerts, this must be really easy to do).
- Login: consider LDAP/SSO (ntlm) login capabilities

If I come up with more, I will let you know!