As appeared in the Security Frontline newsletter and published on SecurityInfoWatch.com
Although access control technology has improved over the years, many deployment still suffer from the same or similar weaknesses in system design and in technology management practice.
Over the years, wrongdoers have used physical access control system (PACS) weaknesses to commit bad acts, some of a serious criminal nature. Some vulnerabilities in these incidents were due to system design flaws, while others could be attributed to poor data security practices. Here are several true stories that highlight the real world consequences of failing to address security holes in the use and management of your access control system followed by the steps you take to fix them.
Headline: Pharmaceutical Company Employee Selling Drugs on Street Corner
Two different companies experienced this problem, which occurred because individuals who had no business being in their warehouse and shipping areas were given access to them. They were able to steal small quantities of high-street-value drugs, and had been selling them on the streets for months.
Most organizations don’t audit the physical access privileges that are assigned to their personnel. Often there isn’t a basis for performing the audit—there are no policies, procedures or rules against which to audit them.
Typically access levels and definitions are appropriately defined when the system is first installed. After that, access levels are expanded ad hoc for specific and often temporary needs, and are left in place, forgotten after the need is over. Thus, access levels named “Marketing” can include access to areas having nothing to do with marketing, such as a warehouse and shipping area. That was the case with the Marketing access level at one of the two pharmaceutical manufacturers.
There should be one person who approves physical access privilege requests for any area of the business, and another person who implements them in the system. Modern workflow systems can establish this capability easily; for unknown reasons, many organizations usually don’t include security processes and procedures in the business workflow systems, but they should.
Headline: Heroin disappears from police evidence locker prior to trial
The officer managing the access control system colluded with another officer, to secretly give him card access to the evidence locker. This required two actions. First, he temporarily gave access to the locker to an officer who did not normally have access. Second, he then removed the access privilege after the theft.
The PACS so-called “audit trail” of operations actions was not an actual audit trail at all, providing only a record of when an operator logged into and out of the system. There was no record that the officer accessed the personnel record of the thief, or that he changed his access level privileges. There were no cameras in the evidence locker area, an issue that was soon remedied after the incident.
Headline: Police lose critical evidence from several high-profile prosecutions
This is a case where the police officer managing the access control system had an IT background, which is one of the reasons why he was put in charge of the system. The PACS database was installed using the default SQL database passwords, published on the manufacturer’s website. The officer colluded with another officer who had access to the evidence storage room, and immediately after each access performed for theft, he logged into the SQL database and deleted the access granted records, including the “door opened” and “door closed” transaction record.
Security personnel responsible for PACS deployments, and their system providers, must make certain that default passwords are changed, and that computer system configurations include securing access to core operating system and database capabilities, which—per separation of duties and least privilege rules—are not available to users of the PACS systems. This includes forbidding the use of shared passwords, especially for access to system core components.
Headline: Disgruntled Contractor Releases Personal Credit Card Information
An IT contractor working with a company who prints credit cards became disgruntled when his contract ended. He did not return his access card upon termination. Because the access level assigned to him included several areas that he did not need to access, he was able to enter the building after hours and steal the personal information of credit card holders. He attempted to extort additional payment from the client company by threatening to publish the stolen material. The company refused, and before he was arrested, he gave the credit card information to a newspaper, who published the fact that they received the personal information of thousands of credit card holders.
Even though the contractor’s card should have been reclaimed, and even though his access should have been terminated upon the end of his contract, an application of the least privilege rule would still have prevented the theft. If he had not been given access to the unneeded areas, he would not have been able to access the information. Even had his access privileges been limited to the company’s normal office hours, he could not have gained after-hours access.
Sound Physical Access Management
There are many such stories of physical access management failures, the incidents above being a few of the more egregious cases. Corporate or facility security directors and managers who are ultimately responsible for seeing that facility access control is appropriate and effective, would be well-served by downloading a copy of SP 800-14 and applying the relevant sections. The material in this guideline is high-level and easily understandable by anyone with general consumer knowledge of computers, laptops or tablet devices. Its application can prevent a range of physical access management failures from occurring.
A foundational document regarding the security of IT systems—which is what our electronic access control systems are—is the NIST Special Publication 800-14. While this guideline is well-known in the IT domain, most managers of electronic physical access control systems are unfamiliar it. It contains 8 generally accepted system security principles, which address computer systems security from a very high-level viewpoint. It also contains 14 common security practices that apply to the deployment or management of electronic physical security systems.
Just reading the first three pages of this document will provide you with an excellent perspective and several concepts that will help put you in a better position to secure your deployed PACS systems. Once you have this understanding, of course, you’ll naturally want to pursue things further—which you may do directly, through delegation, or perhaps by collaboration with your organization’s IT group. Paraphrasing a statement from the NIST document, the eight principles contained in it provide an anchor on which you should base your program for securing your electronic security systems, including PACS.
People, Process and Technology
Securing your security systems requires a combination of people, process and technology. PACS vulnerabilities in all three aspects of physical access control management. Central to many of the incidents described in this article are two long-established general security rules, which are described in many security books and guidelines, including ASIS international’s Protection of Assets Manual. These rules are separation of duties and least privilege. It is usually a simple matter to apply these rules to physical access management, but it is rarely given sufficient thought.
Security system providers should realize that helping their customers apply these two rules is an important value-add to the sale and installation of the system. Doing so will strengthen them against the kinds of incidents described herein. The PACS customers involved in these incidents have one thing in common: they all learned of their problems by reading the newspaper accounts of them.
Security Rules and Audit Trails
These incidents that occurred took place because two security rules, and the use of audit trails, were not in place in the organizations who had the trouble.
Two Security Rules
The definitions below are from page 27 of SP 800-14, from section 3.5.1 Staffing, regarding the defining of a staff job position for any job position, not just within IT or the security department. Position Definition is the first of four steps, well-worth consulting the document for.
Position Definition. Early in the process of defining a position, security issues should be identified and addressed. Once a position has been broadly defined, the responsible supervisor should determine the type of computer access needed for the position. There are two general security rules to apply when granting access: separation of duties and least privilege.
Separation of duties refers to dividing roles and responsibilities so that a single individual cannot subvert a critical process. For example, in financial systems, no single individual should normally be given authority to issue checks. Rather, one person initiates a request for a payment and another authorizes that same payment.
Least privilege refers to the security objective of granting users only those accesses they need to perform their official duties. Data entry clerks, for example, may not have any need to run analysis reports of their database.
Anyone responsible for managing a facility’s physical access should see that these two security rules are applied and that their application is formally verified via a periodic audit or review process.
The definition below is from page 50 of SP 800-14, from section 3.13 Audit Trails.
Audit trails maintain a record of system activity by system or application processes and by user activity. In conjunction with appropriate tools and procedures, audit trails can provide a means to help accomplish several security-related objectives, including individual accountability, reconstruction of events, intrusion detection, and problem identification.
If your PACS software does not have an audit trail feature that records not only when an operator edits access privileges, but also records the “before” and “after” state of the data record, you should upgrade it to a software application that does. Anyone responsible for managing a facility’s physical access has the right to insist on having a PACS system that contains a proper audit trail capability, and that period reviews of the audit trail information are performed.
Security system providers should realize that selling a customer a PACS system that doesn’t have detailed audit trail capabilities is performing a serious disservice to that customer.
Reader image courtesy of cookie__cutter at FreeDigitalPhotos.net