-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we remove the term "Asset Management"? #84
Comments
The editor's discussion concludes that assets and asset management respectively is a gateway for scope creep. SACM is "only" about a specific asset type - the endpoints. So, removing this definition does not seem to impact any document. Maybe a reference on how SACM integrates into existing Asset Management should be highlighted in the architecture document. |
SACM is about collecting assessing information about hardware and software assets, which is an asset type. Perhaps this can be addressed by more specific terms around “hardware inventory” and “software inventory”?
From: Henk Birkholz [mailto:[email protected]]
Sent: Tuesday, May 01, 2018 3:49 PM
To: sacmwg/draft-ietf-sacm-terminology <[email protected]>
Cc: Subscribed <[email protected]>
Subject: Re: [sacmwg/draft-ietf-sacm-terminology] Should we remove the term "Asset Management"? (#84)
The editor's discussion concludes that assets and asset management respectively is a gateway for scope creep. SACM is "only" about a specific asset type - the endpoints. So, removing this definition does not seem to impact any document.
Maybe a reference on how SACM integrates into existing Asset Management should be highlighted in the architecture document.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsacmwg%2Fdraft-ietf-sacm-terminology%2Fissues%2F84%23issuecomment-385770079&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C43cc6fda57774c52915708d5af9c89ec%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636608009218984740&sdata=YfI9N9uBNOCcJRgWq8dOXhK1QqNnXCIy12F%2Bddn3CSI%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJaiaAtnhhQmeDbNXK9zIDavMtF8FbfHks5tuLwXgaJpZM4RqRSJ&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C43cc6fda57774c52915708d5af9c89ec%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636608009218984740&sdata=bcUPXeXNEJM4VJVH8KATpKXRpsKcxKKdYbuA6a9vMXw%3D&reserved=0>.
|
Well....
I agree we need to make sure we limit our scope, however we would need an
asset model so we are ok with what we are trying to assess.
If you look at a single end point your will find that you are asessing
several layers and each has its own data models.
Example:
- For *a web application* you have objects such as http hostname/FQDN,
URL, header/body parameter, CWE, etc...
- For static analysis on software on top of endpoints you then have to
go the the app version, repo, file, line number, source/sink method(s).
- For *Infrastrucre vulnerabilities* you have the IP/MAC, CPE/SWID then
CVE
But finally you have ephemoral hosts, such as desktop VDI instances,
containers, virutal machines, cloud worload instances etc... for those
endpoints the model is more complicated. Think of the morbid "cattle vs.
pets" analogy between Cloud/Data center asstes.
<https://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/>
- You have a running instance, this can be owned by one team, but they
simply spin up a copy on an image from another team responsible for the
"gold image".
- The team responsibe for the gold image, would need to apply the fix
then notify their users that the latest.
- The users of that image would need to spin down those workloads and
spin up new ones with the latest image
- The gold images also might need to be versioned as there might be
instances were the image ower have done their job, but the customer has not
updated the image.
- Etc..
If there is a pre-existing one, we might just leverage that, but if there
isn't... well do we need one? Personally this is one area I am interested
in.
…-Sherif
On Tue, May 1, 2018 at 8:55 PM, David Waltermire ***@***.***> wrote:
SACM is about collecting assessing information about hardware and software
assets, which is an asset type. Perhaps this can be addressed by more
specific terms around “hardware inventory” and “software inventory”?
From: Henk Birkholz ***@***.***
Sent: Tuesday, May 01, 2018 3:49 PM
To: sacmwg/draft-ietf-sacm-terminology <draft-ietf-sacm-terminology@
noreply.github.com>
Cc: Subscribed ***@***.***>
Subject: Re: [sacmwg/draft-ietf-sacm-terminology] Should we remove the
term "Asset Management"? (#84)
The editor's discussion concludes that assets and asset management
respectively is a gateway for scope creep. SACM is "only" about a specific
asset type - the endpoints. So, removing this definition does not seem to
impact any document.
Maybe a reference on how SACM integrates into existing Asset Management
should be highlighted in the architecture document.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://na01.safelinks..
protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
2Fsacmwg%2Fdraft-ietf-sacm-terminology%2Fissues%2F84%
23issuecomment-385770079&data=02%7C01%7Cdavid.waltermire%40nist.gov%
7C43cc6fda57774c52915708d5af9c89ec%7C2ab5d82fd8fa4797a93e054655c6
1dec%7C1%7C0%7C636608009218984740&sdata=YfI9N9uBNOCcJRgWq8dOXhK1QqNnXC
Iy12F%2Bddn3CSI%3D&reserved=0>, or mute the thread<https://na01.safelinks.
protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
2Fnotifications%2Funsubscribe-auth%2FAJaiaAtnhhQmeDbNXK9zIDavMtF8
FbfHks5tuLwXgaJpZM4RqRSJ&data=02%7C01%7Cdavid.waltermire%40nist.gov%
7C43cc6fda57774c52915708d5af9c89ec%7C2ab5d82fd8fa4797a93e054655c6
1dec%7C1%7C0%7C636608009218984740&sdata=bcUPXeXNEJM4VJVH8KATpKXRpsKcxK
KdYbuA6a9vMXw%3D&reserved=0>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#84 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKbE0WcE2hro-sjyjs3wFX4m5syxBlc8ks5tuL2cgaJpZM4RqRSJ>
.
_______________________________________________
sacm mailing list
***@***.***
https://www.ietf.org/mailman/listinfo/sacm
|
I don't disagree with Dave and Sherif on how SACM relates to asset and asset management. Hardware/software inventory and multi-layered asset model both fit under RFC4949 "Asset" definition as mission critical system resources which need to be protected. The terms "Asset" and "Asset Management" in SACM terminology draft do not seem to add enough value to justify their presence there. I'm still for removing them. |
Asset just seems to be a tad bit broad. Our focus is Enterprise scope and PANIC automation. Alternatively, we could retain the term IT-Asset or Information-Asset (although that refers to a paper office, also. So I am not sure, we want to do that). I agree with Jarrett. A convincing usage-scenario (or even just a user story) that highlights why this term is vital, would be a good way to argue for retaining it. I hope it is okay to limit a submission of such an input to one day before the beginning of the next moratorium (2018-07-01(Sunday)). |
See #61 for background on "asset" (which is being dropped). Should we drop "asset management" for the same reasons?
The text was updated successfully, but these errors were encountered: