Access Control Failures
Every organization has sensitive areas and information that should be protected. If this information is left unsecured, it is hard to claim that access is unauthorized. Most responsible organizations implement some type of access control. Unfortunately, even the most thorough and vigilant system can fail. There are two primary causes of access control failures: people and technological factors.
People
Even the most strict and thorough access control policies are prone to human error. This was vividly demonstrated in 2010 when a Virginia couple slipped past security and into a state dinner at the White House. The couple was subjected to all of the normal security screening procedures and was never a threat, but they were not on the guest list. They got in due to human error—the guard at the entry gate did not follow proper procedure and verify the couple was on the guest list.
Although the couple was not a threat and the situation was humorous, this type of failure could pose a grave risk. They could have been spying for a foreign government or planning an attack on the dignitaries attending the event. This is a perfect example of failure in the human element of access control. An organization can have sound access control procedures, but without proper training and buy-in from all employees, the system can easily be defeated.
In the White House example, there were multiple layers of defense in place, including metal detectors and bomb-sniffing dogs. This ensured that even if someone got through, that person would not be armed. This does not mean that they could not be a threat. This is also true in computer security. Network antivirus solutions may keep malware from infecting other systems, but a connection from an unauthorized laptop could still be a threat.
The party crashers are also a good example of social engineering. They dressed properly and acted with confidence that they belonged. These types of attacks along an organization’s human vector are all too common.
In another example, a penetration testing team, called a tiger team, was testing the security and integrity of a major financial institution’s customer data. The corporation had an IT office in a major metropolitan skyscraper. The bottom floor had a publicly accessible restaurant, automated teller machines (ATMs), and washrooms. Dressed as a maintenance man, one of the tiger team members hung an out-of-service sign on the public washroom.
Another tiger team member, dressed as a businessman with a briefcase, talked his way past the security at the door into the secure area of the office complex under the pretext of needing to use the washroom. This was a clear violation of security protocol. This access control failure was compounded by allowing the man to go to the washroom unescorted. Once in the washroom, the intruder accessed network cables in the drop ceiling and inserted a wireless access point into the network. From there, another member of the team sitting in the restaurant used his laptop to access the wireless network.
While inside the network, the team didn’t have access to the system yet—but was able to access unencrypted data, like customer debit card numbers and Windows password hashes in the supposedly secure internal network. Although there were intrusion detection systems and network-based antivirus systems running, passively sniffing network data did not trip any alarms. They were able to compromise hundreds of customer card accounts in a few minutes and leave undetected, all because of a failure in the human element of physical access control procedures. Luckily, in this example, it was a tiger team working for the financial institution and not malicious data thieves. If this had been a real incident, it would have been a major problem for the institution. Needless to say, this caused the team in charge of securing this information to reevaluate its security assumptions.
NOTE
Penetration testing, especially using an independent third party, is an invaluable tool in assessing the robustness of an organization’s access controls. It allows an organization to take an honest look at its access control polices without excessive risk.
Rogue Internal Operatives
Another aspect in the human vector of access controls is rogue internal operatives. Disgruntled employees can pose a major threat to information security in the forms of theft, sabotage, vandalism, and more. The best way to handle these threats is by embracing a least-privileged access control policy. If you limit users to the least amount of access that they need to accomplish their tasks, the damage they can do is limited.
Other People-Related Threats
There are other internal threats besides disgruntled users; here are some other common threats:
- Phishing and spear phishing attacks: These are emails and websites crafted to trick a user into installing malicious code. They look like legitimate emails and websites but redirect the user’s information to the attacker. Spear phishing attacks are targeted at a specific individual or organization.
- Poor physical security on systems: A hard drive, flash thumb drive, and even an entire laptop can vanish quickly if left unattended.
- Physically stored passwords: A password stored on a slip of paper can easily allow for unauthorized access to an organization’s systems.
- File-sharing and social networking sites: As more and more people use these online services, they are becoming a major vector for social engineering attacks.
The best way to handle the human element in access control is through training and organizational buy-in. Every employee—at all levels of an organization—needs to adhere to security procedures or the access control system is useless.
Technology
Sometimes the best access control systems can be bypassed due to a failure in technology. No computer system is bug-free. Anything from an organization’s operating system to its choice in web browser or instant messaging client could be an access point for unauthorized access to its systems. Let’s look at some technological failures that could lead to unauthorized access.
Microsoft Windows operating systems prior to Windows Vista had the possibility of running very weak password encryption. Passwords in Windows NT, 2000, and XP of fewer than 15 characters long were stored in a file called a LAN Manager (LM) hash. This file employed Data Encryption Standard (DES) encryption; unfortunately, it did so in a predictable manner. This allowed for quick-and-easy brute-force attacks on the password files. Some systems could be accessed by brute force in a matter of seconds. Starting with Windows 2000, administrators have the ability to turn off LM passwords and use a more secure NT LAN Manager (NTLM) hash to handle user access.
UNIX/Linux systems had a similar issue in the late 1990s. Password hash files and the hash salt were stored together in an unencrypted file. Using that file, a malicious user could brute-force a password offline very quickly. The common acceptance of a more secure shadow password file, which provided an alternative by storing password hashes in a location unavailable to end users, solved the problem and is a very common element found in UNIX/Linux implementations today.
NOTE
Even in the realm of physical access control, technology can be the failure point. Recently, security researchers discovered that biometrics are not as secure as previously thought. The researchers demonstrated that most fingerprint scanners could be defeated with nothing more than a gummy bear.
Web browsers are a major vector for unauthorized access. Every major browser including Firefox and Internet Explorer has had bugs that allow for the arbitrary execution of code. These bugs have been exploited to allow malicious users access and elevated rights on compromised systems. A system could be compromised just by being used to view a contaminated website.
Servers, especially web servers and other public-facing systems, are another common entry point for unauthorized access. Not only are web servers a risk due to the possibility of unsecure code being hosted but some of the languages used on the web servers have also had security flaws. Both PHP and .NET have had arbitrary code execution bugs that allow malicious users to access the web server.
Radio Frequency Identification (RFID) badges can also be a vector for unauthorized access. A malicious user could use an inexpensive reader to pull information off an ID badge and then flash a new chip with the cloned information. Security researchers have already demonstrated this technique by cloning the new RFID-enabled U.S. passports.
You have seen how both technology and humans can be the cause of unauthorized access. It is important to take steps to mitigate these possibilities, never relying on just one method to secure sensitive information.
Access Control and Privacy Assessments
A privacy impact assessment (PIA) is a comprehensive process for determining the privacy, confidentiality, and security risks associated with the collection, use, and disclosure of personal information. It also describes the measures used to mitigate and, if possible, eliminate identified risks. The PIA process makes sure measures intended to protect privacy and security of personal information are considered at the beginning of a new program or initiative. A PIA also communicates to the public how their privacy is protected and information kept secure.
A PIA is required in the public sector for any new system that handles personally identifiable information (PII). To be successful, it is important that the PIA looks at the system in a systematic manner. It should:
- Identify the key factors involved in securing PII
- Emphasize the process used to secure PII as well as product
- Have a sufficient degree of independence from the project implementing the new system
- Have a degree of public exposure
- Be integrated into the decision-making process
NOTE
In the public sector, it is mandatory for all PIAs to be published.
An important aspect of a PIA is looking at the access controls that will be used to secure the data. The assessment needs to not only look at the physical and logical access controls that will be put into place but it also needs to look at how the access control policies are implemented. Questions like “Who has rights to the information?” and “How will access be granted and removed?” need to be asked. In a thorough PIA, the administrative, physical, and technological access control policies must be described. This is required in all PIA generated by governmental organizations.
Not only are access control systems vital to securing privacy but new access control systems should also go through the PIA process as well. This is especially true in the case of physical access control.
Let’s look at the example of an ID badge system. What information is stored on the ID—just name or name and ID number? Is the information electronically readable and if so by what means? What does the employee ID number consist of? Organizations should follow best practices for privacy protection. For example, they should never use PII, such as a Social Security number, as an employee identification number. Instead, best practice dictates using a random or sequential number as the employee ID. Starting an RFID badge project with a valid PIA ensures that the security of this information is addressed throughout the project.
Structure of a PIA. A typical PIA includes the following sections:
- Summary of the system under analysis: This section should include a physical or logical description of the particular system being analyzed, such as an RFID badge system, and its intended purpose. This section should also include the owner or stakeholders of the system, where the project is in its life cycle (planned, implemented, and so on), and how it will interact with the rest of the infrastructure.
- List of information to be collected: Include specific examples of all information that will be collected or affected by the system.
- Description of how the information will be collected: Include specific plans for collecting personal information. This section may contain copies of questionnaire forms, telephone scripts, or other tools.
- Explanation of why personally identifiable information is necessary: Use this section to justify the collection and use of personally identifiable information. If the organization’s goals could be achieved without the use of personally identifiable information, it should not be collected or used.
- Explanation of how the information will be used: Include a specific description of how each piece of information will be used. Information should not be used except in ways described in the privacy impact assessment.
- List any new information the system will create through aggregation: For example, if biometric data such as fingerprints or photographs are stored in database A and names, phone numbers, and addresses are stored in database B, and the proposed system will link the two databases, this needs to be explained in this section of the PIA.
- List of groups, organizations, and individuals with whom the information will be shared: Include both those within the organization and external entities.
- Opt-out opportunities: This should feature an explanation of all chances individuals will have to opt-out or object to the collection of information about themselves.
- Description of any information that will be provided to the individual: This section will generally include the privacy statement and specifics on how that information will be provided, such as a hard copy or in electronic format.
- Description of the access controls that will be adopted to secure the information: This section should include administrative policies, physical security, and logical access controls.
- Description of any potential privacy risks involved in collecting, using, and sharing information: This section should also include analysis of any risk involved in providing individuals the chance to opt-out, notifying individuals of the collection of information. Finally, this section should include an evaluation of the risks posed by the proposed security measures.
By carefully and thoughtfully completing each of these sections, you should have a thorough PIA that accurately assesses the privacy impact of a proposed access control solution.