Implementing Social Engineering Attack-Resistant Policies

Identifying vulnerable workflows

Although organizations have different threat profiles, they all have workflows that are vulnerable to social engineering attacks, so best practices will differ from organization to organization. When considering how and where to implement social engineering-resistant processes, organizations can start by evaluating three common areas of vulnerability:

• Points where money or financial information is transferred
• Points where existing authentication methods are changed or could be bypassed
• Points where data is transferred

Points where money or financial information is transferred

Finance departments represent a common target for social engineering attacks. These departments are vulnerable to compromise because they have direct access to the organization’s funds and generally issue external payments daily.

Frequently, attacks targeting finance departments come in the form of phishing emails or phone calls regarding fraudulent invoices, updated banking information for a vendor, or missed payments. Threat actors use the names or even invoice numbers from third-party vendors. They can obtain this information by compromising the vendor’s email account via social engineering calls or publicly available information. When these social engineering attacks take the form of an email, they often come from lookalike domains that appear remarkably similar to the legitimate vendor’s email domain.

A second form of social engineering attack aimed at finance departments involves threat actors impersonating high-level executives and demanding, with great urgency, the transfer of funds. These attacks range from obviously fake requests for gift cards to convincing deepfake audio or video calls. While these attacks can be very convincing – and targets are often fooled into handing over information – organizations can implement simple, effective processes to foil them.

For example, organizations can maintain a list of trusted contact numbers for vendors or internal employees with the power to authorize payments and require that any change of payment information or new payment information must be validated via an outbound call to the number on file for the requestor, no matter how the original request is received.

Points where typical access controls are changed or bypassed

Changing or bypassing existing access controls is another frequent objective of threat actors in social engineering attacks. These attacks might come in the form of requests to register or join new devices on cloud-based device management applications, requests to replace or add multifactor authentication devices, requests to increase permissions on an account, and requests to reset passwords.

The most frequent targets of these attacks are IT help desks and IT admins, depending on the objectives of the threat actor and the structure of the organization. When targeting help desks, threat actors rely on at least three specific factors. First, IT help desks often have far-reaching permissions to make changes for users. Second, help desks frequently need to make changes for users quickly in situations such as lost or broken devices, forgotten passwords, and account lockouts.

Third, and perhaps most importantly, help desks and IT admins are particularly vulnerable to social engineering because of the pressures and psychological aspects of their roles. Help desk employee key metrics are most often based on the satisfaction of their users and the time required to resolve issues. Social engineers exploit this pressure by knowing that help desk employees do not want to upset callers and by focusing on time-sensitive issues that need to be resolved as fast as possible. Further, help desks and IT admins generally work in a part of an organization’s hierarchy in which upsetting management or causing delays with ongoing projects can be stressful.

Any policies put in place to limit the impact of successful social engineering attacks targeting help desks and IT admins must keep the job pressures and psychological aspects of these roles in mind. Help desk employees must be aware of the policies and procedures in place and understand that they will not be penalized for adhering to organization policies, even if that adherence causes issues with legitimate requests.

Organizations can implement a variety of different policies to protect help desks and IT admins, including:

• Requiring new device enrollment to be completed in person, where feasible
• Requiring visual verification of users via video call for authentication-related requests, though with the rise of AI deepfake technology, this method likely will become less effective over time
• Maintaining a list of alternate contact numbers for employees and requiring outbound calls to verify
• Establishing a unique code word or phrase for each employee ahead of time to which only the help desk or IT admins have access, which differs from asking security questions because any question with answers that can be externally determined diminishes security

Organizations should establish a tracking method for denied requests. Threat actors often call help desks multiple times to request additional information they need to obtain or to connect with someone who will bypass the existing policies for them. Having a tracking method for these events – which can be as simple as a group chat for help desk techs and supervisors for small organizations or ticket correlation logic for larger organizations – can help stop these attacks. Additionally, tracking can help identify if there are any recurring pain points with legitimate requests affected by these policies.

Points where data is transferred

Sometimes rather than attempting to gain network access to the data they are after, threat actors will simply ask for it. Requests might come from compromised accounts, spoofed emails or phone numbers, or lookalike domains. Threat actors often impersonate a high-ranking employee asking for data quickly for an urgent matter, such as an email from upper executives requesting data urgently be sent to them for an upcoming meeting. Once again, the sophistication level of these phishing attempts ranges from obviously fake, nonpersonalized emails sent from free, online email providers to well-researched, personalized emails from lookalike domains.

Threat actors are after a wide variety of information with these attacks. Some examples include:

• Information on outstanding invoices to use for financial fraud
• Contact information to use for further social engineering attacks
• Corporate espionage-oriented data targets, such as financial reports, intellectual property, research, and strategy documents
• Other methods and technologies to transfer sensitive data within and outside the organization

When considering potential policies to limit the impact of impersonation attacks, organizations should review methods of data exchange that work well with existing processes. Ideal policies allow strong controls that intentionally limit who can access the data and how it is accessed with independent request validation.

In many organizations, unfortunately, the go-to method for exchanging information is through email attachments. This method poses several issues, such as notification requirements from email syncing during email compromises, poor tracking of access to data, and, most relevant to social engineering attacks, improper recipient validation, which can lead to sensitive data transfer to threat actors.

Disallowing sharing sensitive information via email and requiring use of secure file exchange services can help reduce multiple risks, including the risk of data acquisition via social engineering. When evaluating file-sharing services to implement, organizations should seek reputable services that allow for clear restriction to internal accounts; targeted, account-based access for external accounts (not “anyone with the link” sharing); the ability to revoke or rescind access; and the ability to audit access events. Data loss prevention solutions can be a powerful tool to help prevent egress of sensitive data outside of the organization.

Developing effective security policies and processes

To establish effective security policies and processes, organizations can take the following actions.

• Codify and communicate policies and processes in writing. Processes mentioned only during initial user training are likely to be forgotten entirely, but written policies that are regularly reviewed are more likely to be remembered and enforced. Similarly, the codified policies and procedures should be accessible for team members so that they can easily reference the exact process when relevant situations arise.
• Enforce policies and processes. Organizations should regularly verify that policies are followed and confirm that they are not ignored in lieu of easier or more convenient workarounds. This enforcement can be done by reviewing ticket notes or other documentation of the targeted action and through practical tests to verify compliance, such as phishing simulation calls to a help desk.
• Empower employees to disrupt business if necessary. Given the position that frontline employees occupy, organizations must make it clear that these employees will not be penalized for following policies. It is not the responsibility of frontline employees to determine if the business impact of a delay justifies violating a security policy. By empowering employees to follow best practices, organizations can protect against social engineers presenting scenarios in which not giving in to their demands would cause a business disruption.
• Review and refine policies and processes. Security processes that regularly cause disruption in the day-to-day functionality of the organization likely will end up getting removed altogether. Therefore, to implement effective and long-lasting security policies, organizations should regularly review them and make adjustments if necessary to minimize business impact without compromising security.
• Track and report requests. So that security teams can be aware of potential attack campaigns and confident that policies and processes are effective, organizations should implement and consistently use a method to report prevented attacks. The security team can then review the data for trends to flag activity as particularly suspicious and to determine if additional user education is required to raise awareness about a specific ongoing attack.
• Identify other vulnerabilities. After organizations implement policies and processes for common, high-risk areas, they also should analyze other areas and processes. Identifying likely targets and the workflows around them can reveal critical areas in need of additional security policies.

Social engineering attacks – and beyond

Social engineering attacks can have tremendous and wide-ranging impacts. Organizations can – and should – develop and enforce robust security policies and processes to protect against the various methods threat actors use to compromise their targets and to prevent negative financial consequences and breaches of confidentiality.

Developing security policies and processes is one layer of security, but implementing a holistic, defense-in-depth model can establish multiple safeguards at every stage of a potential attack chain. In addition to helping organizations respond to social engineering attacks, such models can improve and mature an organization’s holistic security posture and mitigate the risk of compromise.