MSSPs, like any other business, are a factor of it’s People, Process, and Product. This series will offer insight into each of those factors and offer practical ways to achieve success.
What’s in a name? A device by any other name, will work just as well… if not better
Now that you are past the information gathering phase and are about to deploy your new device, it’s time to look at what you might believe to be a rather insignificant part of the deployment: The Asset Name. While not the most enthralling aspect of a deployment, it will become increasingly important as your customer count increases. Often distracted by the excitement of starting up a new business or service line, the small things can often be neglected. What begins as “Just use the default” can quickly balloon into “How do I change a 100 hostnames?” Let’s look further at the intricacies of naming your assets.
Accepting the default hostname of a device is a time saver for sure, but the only people you’re helping is AlienVault’s Marketing department. A proper asset name will tell your engineers a great deal of information - information they can use to save time. A well-named asset should be able to tell you at glance:
- Customer Name
- Physical Location
- Device Type
- Service Type
It’s also important that you come to a format that is easily distinguishable from one customer to another. Similar names can lead to inadvertent rebooting of the wrong device (ask me how I know) or other possible simple mistakes that can cause interruption of service.
A well-named Asset should also be easy to parse. What does that mean? It means that a name should also be discernable to a computer. The ability to break apart a name into its components will be beneficial as your MSSP business grows and the number of devices you manage increases. Following is an example of a good name and how it can be parsed for fun and profit.
ALVT-AUS-AIO-SL3-01
Customer Code --^ ^ ^ ^---Service Type
Location-----| |----Device Type
In this example the customer is written as four letters (ALVT), giving you 26^4 or 456,976 possible unique names for customers, giving you lots of room for expansion. The second part (AUS) tells you the location in three letters, which is good enough for all the airports in the world. The third (AIO) indicates the device type, in this case an All-In-One. Lastly the service type (SL3) and the counter(01) ending the name will help you avoid duplicates. Now that we have a name let’s look at how it can be parsed.
When anyone mentions parsing, the first thing most of us think is regular expressions (You don’t?). In this example we can make a very basic regex to parse this naming convention:
(w{4}) - (w{3}) - (w{3}) - (w{3}) - (d{2})
If you’re curious about this specific regex, you can get an explanation here. However, let’s not get caught in the weeds, and instead examine the use case of the regex. The regex will ultimately help you display and search for assets quickly. The regex will help you transform ALVT-AUS-AIO-SL3-01 into:
| Customer | AlienVault |
| Location | Austin |
| Device Type | All-in-One |
| Service Type | Service Level 3 |
| Asset Number | 01 |
When you can break the components of the name out, you can perform some useful functions. For example:
- Find all assets by city/location: Impending weather may impact service
- Find all assets by customer: Useful for auditing
- DevOps: Find all IDS assets and update them; Update only customer X, etc.
Getting in the mindset of “What will be practical for a 100 customers?” will help change your perspective when thinking about these small decisions. While in general, you shouldn’t sweat the small stuff, this might be a case when you should put some critical thought into these seemingly small decisions, as making good decisions here will save you time in the long run as your customer base and business grows. you should definitely ponder it.
