Restructuring MSTICPy

[petebryan]

Hi all,

Since its first inception MSTICPy has grown and evolved a lot. The initial folder structure we had do longer captures all of the elements we currently include and want to include in future. To address this we have been discussing updating the folder structure and with recently changes we feel now is the right time to implement this.

Our proposed new folder structure is as follows:

We are looking for feedback and suggestions on the is proposed structure. Does it make sense? Is it intuitive from a user perspective? Are there areas we might not have considered?

Any change would be implemented with backwards compatibility initially followed by a major release at a later date with breaking changes in.

[FlorianBracq]

Nice proposal!

My 2 cents:

• Context Providers might get crowded fast if additional providers are added, it might make sense to segment them a bit more? Currently the only category is "TIProvider", maybe we could have "CMDBProvider", "OSINTProvider", etc.
• I'm not sure yet on how would a provider that could be at the same time a QueryProvider and a ContextProvider be implemented: some tools such as Antivirus, EDR or Vulnerability scanners could be at the same time a DataProvider (throught the alerts they are raising) or seen a a CMDB wiht IP, OS, CPU/Memory, last user connected, etc. Based on the current design each feature should be implemented as its own Provider, but it would be nice to be able to reuse the same code for both.

[ianhelle]

Discussion now closed

[juju4]

Folder structure seems good.
My concern would be more on ensuring granular modules import/install to minimize supply chain and resources load.
This is valid for TI/Context Provider or Data Provider.
If I don't use one, why have it installed.