Recommodation for a CI-Class for Hardware & Software Tokens (OneTime Password Generators)

[Sven Heide]

Hi there!

can someone please recommend me a good Default CI-Class were I can store Hard and Software Tokens (I mean these SecureID OneTimePassword Generators).

I would like to use a default CI Class...

But I only found the CI Class (Security Device) which is a Sub Class of IoT.

But it seems like Security Card Readers and stuff like this should be saved in here.

Any recommodation from one Servicenow Customer to the other? 🙂

[Jacques Clement]

Hi - I can't see anything obvious out of the box, even after loading all the plugins with extra CMDB classes. Are you planning on using them with ITSM processes (e.g., creating an incident against them) and/or do you need any specific OTP device attributes?

If not, then another option could be to use assets instead, which can be used against cases if you're using CSM (reference to asset does not exist out of the box on task, incident, problem, etc.).

[peterdelf]

Have you considered just tracking these are Hardware Assets [alm_hardware]?  Is there much configuration variance possible on them to warrant them being part of the CMDB, and would they be linked to other Configuration Items to form an Application Service, or do you just need to track who they are assigned to and location/stock room etc. i.e. as an Asset.

[Chris Hagy · Accepted solution]

We actually generated our own CI Classes for these as they didn't seem appropriate anywhere else..

 CI Hardware

 - > Hardware Token

 - - > Security Token

 We figured there are many kinds of tokens that may be appropriate to track and outside of things like model/serial/people/state there is probably not lot to track uniquely per type but had a focus on security tokens specifically though we did have not added any additional attributes to the subclasses at this time.

With this we can generate other classes for non-security tokens that may have similar attributes but different processes without having to overcomplicate things. If you were going to track soft tokens this way it may be worth adding something like a 'virtual' flag to Hardware Token, similar to the distinction made between Physical and Virtual computers.. 

[Sven Heide]

Thank you for your Inputs / Informations!

We want to use them within our Processes…

at least in Request Terms… well… within our ITSM Processes they might also be used later…

The Main Reason we would like to have then in Servivenow, is to store them centrally and to be able to track the assigments…

Token is assigned to Person „Peter Parker“ and got requested by… at date...

Would it make sense to Store Virtual Tokens as Assets? / Can someone please provide me with some kind of small descision matrix / when I should use assets? thank you in advance!

We always have to consider, that we have Hardware and Software (Virtual) Tokens…

Off course….

each Item costs Money… What would be your recommodations for storing them as assets?

Hmm…

this would mean we needed to create one asset  "type" for each Token „type“

One for Hardware Security Tokens and one for Software Security Tokens…

and based on these Assets we then create Configuration Items for Every Single Token which will be used or requested by an employee… And each CI would get stored in an CI-Class since I was unable to find a suitable out-of-the-Box Servicenow CI-Class, I would follow Chris Hagys example and create a new CI-Class… Thank you for Sharing your approach Chris!!! This is helpful for me 🙂 

I always prefer out-of-the-Box CI-Classes but if there is  to be no suitable out-of-the-Box CI Class avialable… so this would mean to take a non suitable out-of-the-Box CI-Class and modify them… Instead of this, I then prefer to create a new CI-Class which will fullfill our needs, Even of it is a non out-of-the-Box CI-Class