Broken Access Control

Access control has many facets. Access control can permit or deny incoming traffic from the internet based on its defined rules. Access control can limit who can access a resource and what that individual can do with the accessed resource. Access control can determine who can log into a system and maybe even who can log in at a certain time or day. And access control can allow or prevent individuals from entering an area, building, or campus. These are all examples of access control.

Access control combines two levels of what is known as the AAA model, which represents authentication, authorization, and accounting. An authentication process determines that the person requesting entry access has proven that he or she is who they claim to be. An authorization process then applies the rights and permissions to computer and data resources that the authenticated person can access. The accounting process should be called the accountability process in that it tracks, logs, or records the actions of the authenticated person.

If the elements of access control are misconfigured or not configured at all, the threat of an unauthorized agent gaining access, physically or logically, to a restricted space exists. Assuming that everyone who might access a system or a facility is honest may not be the best security policy, although it is human nature for many people. However, many data breaches and destructions are unintended or the result of discovered access to previously unavailable resources.

The principle of least privilege, if applied, limits a user or group account to only the folders or files and only the actions required to perform assigned tasks of the individual or the members of the group. For example, a receiving dock employee has access to post goods received data to purchase orders in the Accounting system. That employee can only enter the specific data into an existing record. He or she cannot perform any other actions not associated with the receipt of goods. The principle of least privilege prevents inadvertent errors to accidently accessed records or data.

Cryptographic Failures

The threats related to cryptography concern the open exposure of sensitive or confidential data. This includes both misapplied cryptography and not-applied cryptography and applies to data at rest and data in transit.

Privacy laws, such as the Family Education Rights and Privacy Act (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), and the Children’s Online Privacy Protection Act (COPPA) at the federal level, and the privacy laws of the states of Alaska, Arizona, California, Florida, Hawaii, Illinois, Louisiana, Montana, South Carolina, and Washington state, with more to come, establish the what, how, and to whom of sharing the private data of their citizens. Private data are defined to include, for example, computer passwords, credit card account numbers, medical health records, and all other PII. Privacy laws also protect some business-related data, including business secrets, proprietary designs, and any other private or proprietary data not covered by other laws, such as legal documents, tax records, etc.

The practices that can create threats to private, sensitive, and confidential data, include, among others, the following:

• Data in transit are transmitted in the clear, meaning unencrypted, beyond a local network.

• Older, weak, or deprecated encryption algorithms in use by older application software or as defaults in older equipment.

• Encryption is not included in data storage or transmission procedures and policies.

• User account passwords are in use as encryption keys.

• Deprecated or weak hashing algorithms in use, such as MD5 or SHA1, or unencrypted hashing functions are in use when encryption is required.

Injections

The threat of injections is a web issue in which an attacker can insert (inject) malicious code statements into a webpage document. Commonly injected code is in SQL, NoSQL, Object-relational Mapping (ORM), and Lightweight Directory Access Protocol (LDAP). A DAPA web document is vulnerable to an injection attack if user-entered data is not examined to be valid within the limits of the data type and noncontextual data is entered into a webpage and used with ORM to map meta-based search parameters to a database to extract records.

Weak Security Design

The OWASP advises that “there is a difference between an insecure design and an insecure implementation.” The difference is that a weak design based on false assumptions that result in security flaws manifests different vulnerabilities and risk than a system that is poorly configured and implemented with security defects. Each has its own set of vulnerabilities that are different from the other. An insecure design cannot be fixed with a great implementation. Neither can a very secure design overcome a poor implementation.

A primary cause of a security plan leading to an insecure system is a lack of understanding of the normal operations and business rules of an organization. Without knowing its mission, how it operates, and the threats and risks that exist in the organization, security rules and plans would not have a clear objective of what is being protected and from what. In other words, if you do not have a clear understanding of what possibly needs protection, it is difficult to know the level of security to apply.

Misconfiguration

The configuration of hardware, system software, security devices, and even application software can play a very important part in the overall security of a system or network. A common mistake made by system and network engineers is misunderstanding how one setting may impact one or more other settings.

We discussed hardening earlier in this chapter and its effect on the security performance of both software and hardware, but hardening can also extend into the cloud. Misconfiguring the security settings on one or more related applications could create vulnerabilities in the applications. The same is true of misconfigured permissions and user access rights on applications in the cloud.

Sometimes the configuration problem is not an erroneous value on a setting. Sometimes it is a forgotten or unnecessary port, program, or service. The configuration of a hardware device or the settings of an operating system or an application is crucial to the security of the entire system. Much of the actions we discussed about hardening are the same for getting the configuration correct, including the following:

• Removing or disabling unused or unnecessary software and utilities

• Disabling unnecessary TCP/UDP ports on networking devices

• Changing default user and group account passwords

• Reviewing log files for errors in processing resources

• Ensuring that application security settings are configured properly

• Ensuring updates and fixes are timely and tested

Identification and Authentication Failures

Identification has been a part of the authentication process, but as dictionary and brute force attacks have become more common and persistent, the confirmation of the identity of a person requesting access should be confirmed as valid before that person is authenticated or authorized. Establishing the identity of the requestor, also referred to in security as a supplicant, can help to protect against any weaknesses in the authentication process that could lead to an attack.

One very good example of an identification services is Login.gov (https://login.gov). This service is being used by several federal government agencies in a single-identification-sign-on. A government employee or supplier creates an account and supplies a form of government issued picture-identification and other relevant PII. Login.gov then verifies the document(s) and PII with the issuing or assigning agency. If the information and documents provided are verified as valid, the person’s login credentials are flagged as verified. When the users log into the system supported by Login.gov, the credentials are checked for verification and the login process proceeds to authentication, which may require an additional identification step, such as a biometric scan, a one-time code, or the answer to a question.

Without an identification process, any weaknesses in the authentication process can become exploitable vulnerabilities that allow the following exploits, among others:

• Credential stuffing—An attacker is able to input usernames and passwords by hand or from a file that contains a list of company account credentials. This attack operates on the assumption that users typically create a password that is simple to remember.

• Brute force—A brute force attack is used by a hacker who is trying to gain access to a system or network for malicious purposes. There are several types of brute force accounts:

  • Simple—A hacker attempts to gain access by guessing a user’s login credentials and entering them manually, one guess at a time. A simple brute force attack succeeds when a user creates a password that has a simple construction, such as “password1234” or the name of a sports team, or their birthdate, or something more complicated, yet still very simple, “P@ssW0rd1234,” all of which are simple to guess.

  • Dictionary—A dictionary attack in the context of login attacks uses a list or file that contains possible passwords for a given username. While dictionary attacks are not technically a brute force attack, the process is very similar.

  • Hybrid—A hybrid brute force attack combines a simple brute force attack with a dictionary attack. The attacker knows a username and first attempts to guess the password, but if that fails to gain access, the attacker next uses a password dictionary to provide password guesses.

  • Reverse—If an attacker can learn a password but not its corresponding username, the attacker can attempt to guess the username to gain access. This is known as a reverse brute force attack. Organizations tend to use a standard format for login usernames, such as first initial.lastname (“j.doe” or “jdoe”), firstname.lastname (“jane.doe” or “janedoe”). Knowing a password for a user, it may not be difficult to determine the username format and begin trying username guesses. In a very large company, a dictionary of usernames would be necessary. A hacker can have several ways to learn a username format: email, business cards, stationary, public announcements, and more.

• Ineffective login credential recovery—If the process used to recover a forgotten username or password is overly simple or if user-supplied answers to personal characteristics are stored in the open, as most are, all an attacker needs to know is an email address to be able to change the password, which in effect makes the attacker the account owner.

• Session ID not invalidated—When a user requests to download a webpage, the website’s server assigns a session ID to the user. The session ID is meant to be valid only for the duration of the user’s interaction with that particular website. While the session ID can be in a variety of forms, including a cookie, a form field, or a part of a URL, the ID value is calculated from the date and time of the user’s initial request. Session IDs are used for continuity purposes for the server and are not encrypted. Not all browsers take down or invalidate session IDs the same way or at the same point. A hacker may be able to predict the session ID and spoof the original user in a session hijacking attack.

Application Software and Data Integrity Issues

Many applications use plug-ins, libraries, and modules to adapt to an operating system, a hardware configuration, or perhaps even to change the language used in the application. During the installation process and later during the update or patch processes, the required files may not come from the source intended. It is becoming common that larger applications are automatically updated or patched and tested using a CI/CD (continuous integration/continuous deployment) pipeline, which is an automated software delivery and installation process. A hacker could replace a valid CI/CD module with one that allows access to resources and is distributed to many systems. Examples are Jenkins (https://www.jenkins.io/) and Bamboo (https://www.atlassian.com/software/bamboo).

Insufficient Security Logging and Monitoring

An important security activity that is often performed infrequently, if at all, is log file review and access monitoring. Not reviewing system logs, especially the security logs, can let breaches, unauthorized access attempts, and intrusions go unnoticed in the short-term and noticed only when a resource is discovered to be missing. A system’s logging policy can be weak and provide little information for the investigation of possible intrusions. A weak security logging policy may be missing log entries for the following events:

• Successful and failed login attempts

• High-value or sensitive transactions

• Application logs not tracking unusual activities

• Thresholds for warning and action-required alerts

• Pen-tests and dynamic application security testing (DAST) tools, which are used to identify external security vulnerabilities, do not create log entries