Computersight -

Here in Part 5 of the Physical Security Guide we continue our exploration of physical security by learning how to build our own naming convention structures, the implications of doing so and what not to do.

Introduction

Having already covered physical presence intrusion, detection, monitoring, surveillance, logging and privacy issues and the reason why we sometimes need to take a step back and view the situation from another perspective it is time to continue our through the eyes of a machine view of physical security.

Naming Conventions

The planning of your naming conventions for infrastructure and other network devices and assets in a logical and meaningful way is an aspect of network infrastructure that is too often not given just due care and attention. One of the most important reasons as to why you should do this is simply “so things don’t get out of hand”.

“Stay on top of your devices; don’t let them get on top of you”, is a theme that you will come across many times in the world of security, communications and networking. And it all starts with names.

The question that I am going to challenge you with here is what does the following string mean “F1R4S2S3CCS29501425P11F”? Read on and all will become clear.

Why Names?

Because we are humans and humans like to give things names in order to make some sort of meaning out of the world around us. Take the Internet for example: we get from place to place on the Internet by using a naming convention known as the Domain Name System or DNS for short.

Domain Name System (DNS)

Think of it as a telephone book that lists a whole pile of “human friendly” names and matches them to corresponding Internet address or IP Addresses pretty much in the same way as the white pages telephone directory that we all have come to know over the years. We humans find it easier to think of names rather than numbers. It’s just the way we are.

There is no doubt about it; computersight.com is definitely more manageable than 200.184.219.176 for example. No!! This is not the IP Address for computersight.com; I just made it up, so to whoever actually owns it I apologize if a whole bunch of people get a wrong number. I will be covering DNS in another article.

Building Your Own Naming Convention

When it comes to naming conventions the question I get asked most is “How do you do it?” By “it” the enquirer wants to know how I go about creating a naming convention. It’s not really that hard and I will show you now one way in which you can begin to build your own structured secure naming conventions.

Breaking the problem down I have found that most people really only want to know one basic thing and then they are quite fine to finish the job on their own. It’s the big question of “Where do I start?” The best way to answer this is by using an example; so here we go:

Defining the Situation

Suppose you have 4 domain controllers, 10 web servers, 6 routers, 20 high-end switches, 100 workgroup switches that use transparent bridging, 3 mail servers, 5 file servers, 2 database servers and untold numbers of workstations and peripherals.

The first question that pops into the minds of most people; including network administrators, especially those without experience of this type of situation is: “Naming and naming conventions, where do I start?”

Defining the Beginning

Well as stupid as it may at first sound, the answer is of course at the beginning.

Which brings us to “How do I find and define the beginning?”

In this case the beginning is a physical thing. This means that we will be able to construct our new naming convention based on physical properties. The reasons for doing this are partly for ease of reference and partly for solidarity.

Physical infrastructure and devices have a tendency to be relatively stable in terms of their outward physical characteristics and location. Routers and servers do not go on walk-about all of their own volition. Rack-mounted devices are even more unlikely to wander. The rack itself; if bolted to the floor and/or wall or ceiling also makes it hard for physical infrastructure and devices to wander.

So what are the types of physical characteristics that we can take advantage of to make our naming systems and conventions easier to create and administer?

Defining the Physical Basics

The first thing to do is; as mentioned above, bolt and lock all physical infrastructure and devices down securely. Once done this has been done you can be confident that they will remain where they are. You now have your starting-point; that is, you have now created a “center-of-the-universe” reference base at least for this network.

The next thing to do is to find suitable aspects and physical attributes of our devices that would be suitable to use in our new naming convention. The question that we need to ask ourselves at this point is “What attributes should I use and where do they fit into the big picture?”

Defining a Hierarchy

In the example that we are working with here we have a number of different classes and types of devices as well as a whole bunch of physical infrastructure components such as cabling, racks, shelves etc. We also have communications and networking devices including routers and switches. In addition they are a number of servers. So let’s put them into some form of structured order.

Humans find it easiest to address and manage large numbers and large numbers of individual items when they are given some sort of structured order and when that structured order inherently defines the relationships between the individual units, groups of units and the entire system of units as a collective entity.

So let us build our naming convention on a device and physical location hierarchal structure. At the top of this hierarchy are the core and infrastructure components of our network. The next layer down will be the distribution devices and infrastructure and then comes the local and peripheral devices and infrastructure components.

The biggest distinguishing feature between all of these assets is the type of service(s) that they deliver. Never forget networking and communications are all about the delivery of services when requested.

Top Level Entities

The devices that will be placed at the top level of a physical naming convention are those components that house other components. In our scenario this means the racks, their shelves and slots. At this point our most pressing concern is with the identification of specific physical locations.

Creating a naming convention that has the built-in capabilities of locating a device without even knowing the type of device that is physically located at this site will deliver your first layer of physical level naming convention security and redundancy. We will add the more device specific attributes shortly.

So Rack number 4, Shelf number 2, Slot number 3 definitely and unambiguously defines a specific physical location within our network but let’s face it. This is a clumsy cumbersome name but its meaning is clear. Our next task is to make this clear and precise name less unwieldy. We shall do this by using the age old technique of contraction.

Facility number 1, Rack number 4, Shelf number 2, Slot number 3 becomes: F1R4S2S3. Definitely a lot easier to use at a glance and for those in the “know” a very precise physical location has been defined. Yet those not in the “know” are going to start having difficulties figuring this out. Given time they just might.

So we are going to make their job of cracking our simply naming convention system a lot harder by adding some extra detail that will assist us in knowing that the device that is currently at any given physical location is in fact the device that is meant to be there.

In this example physical naming convention the label; or tag if you prefer, of F1R4S2S3 would most definitely allows us to identify and locate in a very short period of time any specific device that is housed in this facility without prior knowledge of the device or even what type of device it is.

You will also note; that in Table 1 Naming Convention Hierarchy (above), I have not used building or room numbers that may be displayed publically. Instead I used “F1” to mean facility one which could be located anywhere within your organisation’s complex. The communications, networking and security staff will all know that the “F1” refers to major central facility one.

You could of course have called it “N1” indicating that it is networking center one. The reason that I have not done so in this example is because we are looking to the future and I do mean the very near future.

Unified Communications and Network Convergence

Unified communications and networking convergence mean that it won’t be too long before there will be no really clear demarcation point between networking and communications devices and infrastructure. Devices will be capable of and actually performing both functions.

IP telephony (VoIP) enabled LANs technologies and rollouts also add more weight to this being the norm rather than the exception in the years to come. So we might as well start thinking about this now and design our naming conventions to suit. Anyway I think you will be able to come up with your own system now that you have the knowledge of how and where.

Adding the Detail

In our example naming convention we have started with the entity that contained the most other entities: The Facility. Then we used the next sub-entity which also contained many other entities but with fewer sub-entities than the parent: The Rack. Then came: The Shelf, followed by: The Slot. Table 1 above shows this and how a Top-Down hierarchal system such as this works in the practical sense.

It is important that at the moment it makes absolutely no difference is actually located at the physical location of F1R4S2S3. Simply going here will get you to the device currently located here. But is it the “right” device?

This is where the next part of our naming convention comes into play. From a physical security stand-point it would be nice if we could not only get to the correct location but identify the device that should be there and compare this with the device that is actually there. In other words; what we need is a naming convention with a built-in cross-check, cross-referencing system. Here is how this can be done.

Built-In Device Confirmation

We are going to take advantage of the physical naming and labeling systems used by the manufacturer of the device and work them into our naming convention in this way will be able to distinguish any specific device from among the hordes that we are administering. In this aspect “human friendly” is a must.

Don’t get me wrong. I do not mean friendly to every human just those “in-the-know”. We really don’t care how much confusion we create for those not “in-the-know” because we don’t want them to know. This is where the art and experience of creating naming conventions lies.

Mixing Alpha-Numeric Characters

You have already seen part of the way that I use most often to do this by creating a naming convention that uses a mix of alpha-numeric characters. Pretty much like they say you should do when creating authentication passwords.

Here is where we get to the device specific element of our name. We could identify a Cisco® Catalyst 2950 switch for example by using CCS29501. Here the CCS = Cisco® Catalyst Switch, the 2950 tells us that it is a 2950 series model and the last 1 tells us that it is switch 1. Remember we may have a number of the same series devices so it is handy to be able to tell them apart. I usually just use the last three or four digits from the devices serial number.

If you wanted to identify a specific port then I would use the same port identification convention as the manufacturer. Once again most manufacturers including Cisco® print this information on the device either above, below or next to the actual port.

So our new device name using our new naming convention would be F1R4S2S3CCS29501425P11F. I will write this out in full and then I think you will have the basic idea of what we have just done.

F1 = Facility 1, R4 = Rack 4, S2 = Self 2, S3 = Slot 3, CCS29501425 = Cisco Catalyst Switch 2950 series unit 1425 and P11F = Port 11 of the Front module.

Depending on your specific situation you can change this to suit yourself and your situation as desired. Now that you know the meaning behind the naming convention F1R4S2S3CCS29501425P11F seems as plain as day.

To someone; not-in-the-know, this jumble of alpha numeric characters is really quite formidable. Most of the time; those with malicious intent would simply give up and not even try to decipher the meaning of this string of characters.

It is in this way that we can quickly locate specific resources and components of resources. If you now the device name you can quickly go to it and check to may sure that the correct peripheral in another building is plugged into the correct port.

Network Convergence Implications

This is becoming even more important considering the convergence of networking and communications technologies that we are seeing today. Now the network administrator is performing a lot of tasks that were once the providence of the telephone guy. Not so anymore.

Develop and Maintain a Naming Convention Policy

The final task will as always be to create thorough documentation as you go. On the other hand the development and implement of an appropriate Physical Naming Convention Policy would be the first thing that you would do.

Coming up in the Physical Security Guide series are the following topics and concepts:

• Labeling, Checklists and Label and Checklist System(s) Security
• Drilling, Rehearsal, Role Playing Scenarios and Proof-of-Concept Implementations
• Surviving an Audit and Surviving Users
• The Physically Static Nature of Core Network Infrastructure Components
• Physical Location and Placement of Wiring Closets, Infrastructure Cabling and Cabling in General
• Mission Critical Systems, Rack Mounted Systems and Servers

So until next time enjoy!!