Visitor Management for Stakeholders
Visitor Management is a community thing! Good Visitor Management takes a team with a common playbook to which everyone understands and agrees. Team members work for different departments within the organization but all of them are part of the overall security team. Each team member will have requirements that must be met for them to do their job effectively. Since they are all part of the security team that has different but related requirements, I refer to them as “stakeholders.”
Stove Pipe Applications vs. Integrated Applications
I started working with security systems back in 2001. These systems were directly related to the events of 2001. Before that time, I was just another consultant focused on large-scale enterprise web applications. I helped many large customers, mostly federal government agencies, convert lots and lots of separate stovepipe applications into single integrated enterprise applications. A stovepipe application is an application that is standalone and does not interconnect to any other application. An integrated application serves many different users in different departments. A major goal of creating an integrated application is so that everyone is seeing and using the same data. No data has to be copied or rekeyed from one application to another because it is already there as shared data.
Visitor Vetting and Management Systems (VVMS) is probably unique in that it employs a really interesting set of skills and experiences. VVMS has employees with skills in large scale web-based databased applications, VVMS has experience creating enterprise applications that replace separate stovepipe applications (including law enforcement systems and criminology), VVMS has experience in cybersecurity, which is necessary to protect Personally Identifiable Information, VVMS has experience at vetting individuals through various watchlist databases, and last but not least VVMS has multiple employees educated in psychology. VVMS has built systems for both law enforcement and departments of corrections. From our beginning VVMS has had these focuses (or foci if you are a student of Latin):
- Moving applications from mainframes to the inter- or intranet.
- Redeveloped databases to take advantage of improvements yielded by making it relational third normal form.
- Combined the functionality of several different but related applications used by different stakeholders into one interactive application used by different stakeholders within the same organization.
- works with end-users to understand how they use the application. The end result was that VVMS is able to redesign the graphical user interface (GUI) to make them more intuitive as well as easier and faster to use.
VVMS’ forte has also included Business Process re-engineering and Data Modeling. Our focus was on converting stovepipes into integrated solutions that at the very minimum satisfied all of the stakeholders. Better still we wanted to exceed the stakeholder’s expectations.
Prior to 9/11, getting into government facilities was typically fairly painless. Many facilities did not even have any sort of perimeter protection. What protection they had was mostly at the building level. A visitor or badge holder could not get into some buildings, or areas within a building unless they had the correct badge. Badges were often referred to as “flash badges.” Guards just looked at them, often quickly, and waved the person into the facility.
Immediately after the events of 9/11 lots of facilities, particularly government agencies and government contractors clamped down on their security requirements. But the bulk of the security was placed in two groups when it came to processing visitors:
Group 1: Was the security group that protected the perimeter. They checked the visitor’s identification at the entry control point to make sure it looked valid.
Group 2: Was the sponsor that invited someone to visit with them. The visitor would get to the entry control point controlled by “Group 1” and then call the sponsor to meet them there. The sponsor would join with their visitors at the entry control point. The sponsor would show the guard their own ID to prove that they worked there and then they would vouch for the visitor as having been invited.
A visitor pass was created if the visitor’s identification was in order and the sponsor had vouched for them. The sponsor would countersign the visitor pass after which the visitor was allowed to enter.
The only interaction between these two groups is when the sponsor went to the entry control point to vouch for their visitor.
One of the security weaknesses in this process is that there was no way for the guard issuing the visitor pass to know if the sponsor actually had the authority to approve a visitor or to approve the visitor to visit the stated destination.
The process for security badges used by employees, contractors, and vendors was a little different. An additional group managed the issuance of plastic security badges (sometimes referred to as “hard passes”). This process required the sponsor to approve the issuance of a badge by the badge office. This process typically took place before the arrival of the prospective badge holder and then was completed when the prospective badge holder arrived.
The Need for Visitor Management Teams
All of us can see a lot of focus on doing things as “teams.” Microsoft has an application named Teams that is designed to facilitate communications between people. There are CRM applications that focus on turning all sorts of different functions performed within an organization into collaborative functions performed by “teams.” The direction of many applications is in turning heretofore separate functions performed by separate people into a homogeneous “team effort” performed by people working towards a common goal.
This is a list of functional groups used in the process of issuing visitor passes and security badges. Every organization is different. These functions may be performed by separate departments or some of these functions may be combined into the same department. Different organizations will have varying amounts of interaction between these functions. No two organizations are the same. Consider the following groups and compare them to your organization:
|Guard Staff:||In this context, these are the people that are the first line of defense guarding your entry control points. These are the people who ensure that everyone entering the facility has a proper badge or visitor pass.|
|Badge Office Staff:||The badge authority is responsible for producing badges and visitor passes. They make sure that the badge or pass holder meets all of the criteria. For example, they make sure that the proper vetting has taken place prior to issuing any visitor passes or security badges. They also make sure that all departmental managers and/or sponsors have properly signed off on the issuance of the badge or pass.|
|Sponsors:||The sponsor is the person who has requested that the badge or pass holder be issued. The sponsor is the person who is responsible for the badge or pass holder while he or she is visiting the facility.|
|Department Managers:||Department managers have the ability to approve or disapprove badges and visitor passes to the individuals identified by sponsors.|
|Security Staff:||Security staff members perform the necessary vetting and make sure that the person has passed all of the checks. In some cases, the person may be flagged by the security application which will require additional checks before being ultimately passed or denied access.|
|Contracting Officer:||In some cases, the person receiving a badge may be doing so because they are performing some work under the terms of a contract. A contracting officer may take on the role of sponsor or may merely communicate with the sponsor.|
Shortly after the events of 9/11, I and my company were called upon by a large organization to provide our MAX Security Portal to streamline both the process of issuing visitor passes and the process of issuing plastic security badges. All of the stakeholders shown above were present. But the system that existed before we arrived was very manual in nature. In some cases, multiple groups were called upon to perform the same function. These groups worked from their own systems, which were often paper forms or in some cases Excel™ Spreadsheets. We were being asked to turn each of these groups using stovepipe processes into a security team of stakeholders. Our Process Reengineering goals included the following:
- Maximize the establishment of a “team effort” between all of the groups providing a portion of the effort to make the facility a secure place.
- Standardize all security processes.
- Record the completion of each security step in a common database that is accessible to all stakeholders.
- Make sure that no steps are required to safely issue visitor passes and security badges are skipped thereby maximizing security.
- Make sure that all stakeholders have visibility of the security data to which they need to perform and/or review their portion of the security duties.
- Make sure that all stakeholders are alerted in a timely manner when they are needed to perform their part of the visitor pass and/or security badge processes.
Prior to Re-engineering
Communication between these groups prior to our reengineering efforts had been minimal or non-existent. Once a group completed their assigned work and pushed the paper forms forward to the next group, there was no knowledge whether or not the next group did anything. In one case, a very high-level VIP arrived but was denied access for several hours because the “right” paperwork had fallen behind a desk and was trapped between the desk and the wall. Because there was no overarching central database tracking the progress, there was no way to “fix” the problem except to find the paperwork.
The only “database” was a set of file cabinets in the badge office that was mostly just available to the badge office personnel, not to all of the stakeholders. Nothing was filed into the file cabinets until the paperwork was completed. If the paperwork became lost, there was nothing to file. Without a database, there was no way to query and report on anything accurately.
The badge authority, a/k/a badge office, used multiple desktop badge applications. They had a common database engine but nobody outside of the badge office had any access to it. The only function of the desktop application was to print security badges. None of the approvals leading up to the issuance of a security badge was entered into this database.
The badge office received a signed paper form from the sponsor authorizing the production of the badge. It was assumed that the person had been vetted and that any departmental approvals had also been provided as well when the sponsor provided the paper form. Those actions may or may not have been performed. When things were busy, steps could be skipped and there was no real audit of whether or not they were done. Skipping steps did not interfere with the printing of the security badge.
Visitor passes were produced by a completely manual process. The only record was a carbon copy that was stored for 90-days and then they were destroyed.
Reengineering – Going from Stovepipes to Teams
Our goal was to bring all of these “stovepipes” together into a “community” thereby making each group a true stakeholder in a true security team. This is how we accomplished this:
Installation of an Enterprise Application
We installed our MAX Security Portal in their data center. We set up user accounts for each of the stakeholders. [Note this step is much easier and less expensive now that MAX operates in a secure cloud. Users just need a subscription to our cloud-based MAX. Nothing needs to be installed in the customer’s own data center.]
We set up user accounts for sponsors. Sponsors are the people who will be inviting people to come into the facility. Sponsors are restricted to specific departments to which they belong. They cannot invite people to departments for which they have no authority or connection. Sponsors are responsible for visitors while they are on the premises. Sponsors are also the people who request longer-term badges for long-term visitors, contractors, and even vendors.
The MAX Security Portal functions are controlled by roles. A user is therefore restricted to the types of things they can do by which roles they are assigned. They are restricted for whom they can perform functions by the department(s) to which they are assigned.
Next, we set up the accounts for the security staff. Our MAX Security Portal will automatically vet visitors and badge holders before the approval of the issuance of the passes and badges. How they are vetted depends on the customer and what they are authorized to check. Vetting is divided into three (3) categories. The first check to be made is to ensure that the person has not been barred from access for some reason. Barrments are a local decision by the customer’s own organization. The second check is made against public domain watchlists and fee-based services. The third check is made for users that are authorized checks against law-enforcement agency databases.
Vetting is generally a transparent background process that is performed automatically. Under normal conditions, a prospective badge or pass holder is vetted and approved without any intervention from a member of the security team.
Check results are of two types, exact and fuzzy. An exact match is when the match between the visitor (or prospective badge holder) and watchlist data is very certain. An example of an exact match occurs when the name of a visitor and his passport number matches a record in a watchlist.
A fuzzy match occurs when the match is not necessarily certain. An example of a fuzzy match is when the visitor’s name and date of birth match a record in a watchlist. This is a possible match but is by no means definite. There may be lots of people with the same name and date of birth.
The security staff is notified when either an exact match or a fuzzy match has been made. The system will provide any of its source information and Security will determine if the prospective badge or pass holder should be kept off of the premises.
An example of how this works, if a fuzzy match is made which resulted from a record sourced by the FBI, the person responsible for approving the badge or pass will be directed to the FBI wanted poster. Security can examine the wanted poster and determine if it is the same person or a different person with the same name.
A member of security can approve or disapprove an individual from being allowed to enter the facility based on the results of the vetting. When security approves the person, that means that a badge or pass may be approved by a department manager of the issuing department. The department manager that provides the approval is often referred to simply as the “Approver.”
But if security has disapproved the individual then no further approvals may be made and the individual may not enter the facility.
We set up accounts for department managers who on behalf of the department for which the badge or pass will be issued will be able to approve or deny the issuance of the badge. Note that these managers may not approve any badges or passes that have not passed the security checks. They also will not have any visibility of any badges or passes belonging to any departments for which they have no authority.
Badge Office Staff
We set up accounts for the badge office staff. Badge office staff prints visitor passes and plastic security badges after they have been approved by both security and the department managers. Although different departments may have their own badge office staff, typically that is not the case. A single badge authority prints badges for all departments. The MAX Security Portal does not permit any badges or passes to be produced unless the issuance has already been approved by both security and the department managers.
We set up user accounts for select contracting officers. Contracting officers are generally not involved with visitor passes but they are often involved with contractor and vendor badges. In this specific case, contracting offices were not part of the approval authority, but they monitored badge holder information where the badges were issued to personnel that were working on contracts over which they had authority. They were instrumental at recovering badges once the personnel no longer worked on the contract. Sometimes a contract may be terminated before the original end date. In this case, all of the personnel that were issued badges to work on that contract had to be recovered. Unrecovered badges that are no longer needed but have not yet reached the expiration date are a security risk.
Recovering unneeded badges can sometimes be a problem. Contracting officers are often better suited at recovering unneeded badges than the sponsor. We found that it is easier to recover badges at the termination of a contract when a stipulation is made in the contract that prohibits making final payment to the contracting firm until all of the security badges have been returned.
We set up accounts for the guard staff. They are the first line of defense to block unauthorized people from entering the facility. Guards can scan a MAX badge or visitor pass each time that a person is entering the facility. The system will instantly indicate if the badge or pass is still valid. This is superior to just checking the expiration date as sometimes people are no longer authorized to enter even though their badge may have not yet reached its expiration date. This happens when the badge holder voluntarily or involuntarily leaves their job before the expiration of the badge. This can also happen when a contractor is provided a badge based on a contract, that is then terminated early which can happen for a variety of reasons.
We now provide a mobile handheld unit known as MobileMAX that can scan badges and passes produced by our system, driver licenses, PIV and CAC cards, and VA chards. We can cross-check driver licenses and other ID types against the MAX database to see if the person has permission to enter. The handheld MobileMAX can also resubmit the identity of the badge holder or pass holder to the vetting system one more time to make sure that they are still okay to enter.
The system can be configured to enforce additional security requirements such as special handling for foreign visitors, foreign visitors from designated countries, US citizens who work for foreign-owned companies, ITAR requirements, etc.
The Team of Stakeholders
The bottom line is that all of the stakeholders work together to provide the best security possible. There is no longer any dependence on paper forms so any of the stakeholders can access the enterprise system (the MAX Security Portal in this example) and check statuses at any time. The system sends out alerts to the appropriate people whenever a status changes or whenever a team member needs to be made aware of something or needs to perform a task.
In the old days, team members had to log into the application from their desks to see what the current statuses were and to see if they had any pending tasks. But these days, between the various alerts and the ability to use mobile devices to do much of their jobs, security requirements can be handled in near real-time from handheld devices or their desktop application.
No two organizations have the same security requirements when it comes to security badges and visitor management. Historically due to the complex nature of managing security and the required flexibility, different departments providing security functions have been focused on their security duties and not that of the adjacent departments. The goals are to bring all of the various security groups together into a single team focused on the same overarching goals. Doing this properly requires a single enterprise security application with the business rules that ensure that each department performs its assigned duties in a timely manner. That no credentials (visitor passes or security badges) are issued without all of the necessary permissions and vetting having been performed.
Please feel free to contact me if you would like to discuss the security needs of your organization. I would be glad to assist in any way that I can.