Integrating Security Badges
Security badges are used throughout the enterprise as ID badges
and for door access. Like a system account, each badge should have
only the necessary rights and should be canceled as soon as the
worker is terminated. The badge system should be integrated into
the same process used to manage system users and accounts.
When the security badge system was first installed, the security
department felt strongly that the security badge system should be
isolated from all other systems to ensure maximum security. None
of the computers server or workstation were added
to the corporate domain, and IT had no role in maintaining the system.
The server was placed in the security office instead of the data
isolation had some serious liabilities, which in the end posed greater
risks for the organization than any theoretical risk from having
the system integrated into normal IT workflows.
The server was being used as a workstation by security
officers, using the administrator account as the local login.
The server and workstations were not included in the normal
patching process for Windows updates.
The security hardware fell into a sort of "no-man's
land" because IT didn't support it.
The database lacked an adequate maintenance plan, causing
data loss from lack of proper backups.
source of worker data
Security had no reliable source of data about new workers,
changes in worker roles, or terminated workers.
labor-intensive badge process
For every badge made, all the information about the worker
was typed into the system, and was not validated against other,
"master" sources of employee data.
a couple years of observing the new IT team in action, the security
department felt confident enough to let us connect them with the
world and automate their process in a fairly radical way.
Now that we had solid data about all workers (Who
Works Here?), we felt confident taking over the updating of
the security badge system database. This would have several advantages:
time spent by security inputting worker information
updating of status and inactivation of badges for terminated workers
consistent spelling of names, titles and departments
duplicate badges except where specifically authorized
of workers who lack a badge
developed an automated process to directly update the security badge
adding new workers;
titles/departments for current workers; and
status and inactivating badges for terminated workers.
when making a badge, security staff
identity with either a photo ID or a printed copy of the badge
request provided by their supervisor,
the worker from the list in the badge system, and
rights for the badge have already been defined and approved with
our Security Badge Request application. If no approved badge request
exists, no badge is made. It couldn't be simpler.
The server and related workstations were upgraded as necessary and
added to the domain. This ensured that
are locked down,
enterprise security policies are enforced, and
are included in routine, enterprise desktop patching.
addition, our SQL Server database administrator set up a maintenance
plan for the production databases and ensured that everything was
routinely backed up.
Until fairly recently, it was impractical to move the security badge
server to the data center because several remote, analog controllers
were hardwired to the server. Now, digital controllers allow connections
to a server anywhere on the network. We are in the process of moving
the security badge server to a virtual machine on the blade frame
in the data center, providing the appropriate level of security
and reliability for a critical system.
Reliable, current data about the workforce enables an organization
to better manage everything related to that workforce.
always worth the time and effort required to build trust between
other departments and IT.
critical system, such as security badges, should ever be allowed
to exist in isolation without proper support and management.
20 March 2008