Allow Managemet and Checkout of Physical Resources

[er4z0r]

When doing red-teams that involve breaching the physical perimeter you need a lot more gear (hardware implants, bypass tools etc.). If you have multiple projects going on at the same time that can create unforeseen issues, if both projects rely on the same equipment at the same time.

Describe the solution you'd like
I would love to be able to create physical items and use the check-out and check-in feature similar to what we can currently do with domains and hosts.

For starters these physical assets could have:

• name (e.g. espkey001)
• status (e.g. "operational", "maintenance", "decommissioned")
• picture
• category/type: (e.g. "hardware implant" )
• description (e.g. "hardware implant to intercept wiegand data")
• notes

[chrismaddalena]

I like this idea and will add it to the road map. Thanks for the suggestion!

[er4z0r]

Would you be open for a pull request for this feature assume I can find the time to implement it? Christopher Maddalena ***@***.***> schrieb am Mi., 19. Okt. 2022, 23:27:

…

I like this idea and will add it to the road map. Thanks for the suggestion! — Reply to this email directly, view it on GitHub <#260 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACF5XFNZRBT6ZRKNQAA7STWEBRSRANCNFSM6AAAAAARI4GVCI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[chrismaddalena]

@er4z0r Absolutely. I can also assist with it if you check the box to allow upstream maintainers (me) to commit to the branch for your PR. The base model and functionality shouldn't be too difficult to implement, but we'll need to add the checkouts to the ReportData serializer, write some test, find a place for you to view the information inside a project, and probably a few other little things.

[er4z0r]

Should this be implemented as a separate application like Shepherd or as part of Shepherd/Rolodex?

[er4z0r]

Some moer thoughts: We'd probably have to introduce two kinds of physical assets:

CountableHardwareAsset

• All made alike,
• their properties don't differ
• no need to identify individual instances.

Example: I don't need to label each Peterson Mini Knife or Traveler Hook. I just need to know how many we have and if one will be free during the planned time)

IdentifieableHardwareAsset

• Individual instances might differ in properties
• I might want to identify them one by one

Example: I might have two EspKeys that are on different FW versions.

What type you choose for an asset probably comes down to preference/circumstance but I think it'd be good to have this distinction.

[chrismaddalena]

@er4z0r This sort of tracking would fit inside the Shepherd application with domains and servers. The applications help organize the models and views. Rolodex is for clients and projects, Shepherd is for tracked assets/infrastructure, and so on. Since this will add only a model or two, I don't feel it's necessary to spin it out into a new app.

When I made the server tracking, I split it into two models: cloud servers and static servers. This seemed like the best plan at the time, but I regret it now. A single model for tracking all hardware assets might be best. The model could track individual instances of something and the more generic asset inventory. It also simplifies searching the library and handling checkouts.

The model might be something like this:

• id (BigInt) – the unique BigInt identifier
• name (Char) – descriptive name
• description (Text) – what this is, how it's used, where it's stored, etc.
• quantity (Integer) – how many you have
• configuration (JSON) – JSON blob for extending the model for unique characteristics (e.g., serial number, software version, hardware specs)

Let's say you have five hardware implants. Four are identical and have SIM cards for Google Fi, but the fifth has a Verizon SIM. You'd have two entries:

• Google Fi, quantity 4, configuration with {"sim": "Google Fi"}
• Verizon, quantity 1, configuration with {"sim": "Verizon"}

This is also flexible enough to allow someone to decide to track by serial number, software version, or some other characteristic and split that into five individual assets.

The model would also have a method that deducts checkouts from the quantity and returns how many are still available for a given time period. If the new quantity would be < 0, deny the checkout.

If that were two models, people might make CountableHardwareAsset entries with quantities of 1 when they should have made an IdentifieableHardwareAsset entry–like how people often mix up the server library with cloud assets.

[github-actions]

This issue has been labeled as stale because it has been open for 30 days with no activity.

[github-actions]

This issue is closed because it has been inactive for 14 days since being labeled stale. Feel free to re-open the issue with a comment. If this needs further discussion (e.g., a feature request), it might be better to open a topic under the Discussions tab.