The National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) Vignettes series focuses on findings from recent security assessments that highlight the importance of different NIST CSF objectives. The NIST CSF provides a comprehensive framework for complex organizations to break out of the “Swiss Cheese Model.” The series seeks to demonstrate how the correct application of NIST CSF can prioritize and mitigate real risks to your organization.

Phishing is a common, if not ubiquitous, tactic used by attackers and red teams alike to gain initial access to an organization’s resources. Outside of open-source intelligence research, phishing is often the first active step during our Red Team engagements. Phishing is a reliable way to gather credentials, exploit web application flaws (such as CSRF or XSS attacks), or to convince a user to execute commands. Even with advanced defensive tools, machine learning, and security analysts on the job, phishing still plagues organizations of every size and industry. 

Phishing attacks come in many shapes and sizes and current events continually provide convincing fodder for phishing ruses. Praetorian engineers have used email, phones, contact forms, video conference platforms, and more to convince unsuspecting victims to act on our behalf. We have used ruses such as being a recruiter, IT admin, an alumnus from the victims’ alma mater, and others to make ourselves appear believable. The options are endless and therefore can become increasingly difficult to detect when spear phishing is utilized in conjunction with open source intelligence gathering. 

For even moderately secure organizations, phishing is often the only viable method to gain access to the network and company resources. This attack method is not going anywhere soon and is often difficult to mitigate given the highly human nature of these attacks. 

So, where can organizations apply resources to better combat this tricky attack path? The NIST CSF provides several sub-categories designed to directly address this.

• ID.AM-3: Organizational communication and data flows are mapped
• ID.GV-2: Cybersecurity roles and responsibilities are coordinated and aligned with internal roles and external partners
• ID.RA-2: Cyber threat intelligence is received from information sharing forums and sources
• ID.RA-3: Threats, both internal and external, are identified and documented
• PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions
• PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks)
• PR.AT (all sub-categories) – Awareness and Training
• DE.CM-4: Malicious code is detected
• RS.RP-1: Response plan is executed during or after an incident

To further describe how each of these categories could have prevented a phishing attack (add a layer of cheese to the Swiss Cheese Model), we will explore each of the applicable categories in greater detail.

ID.AM-3 Organizational communication and data flows are mapped

By mapping organizational communication and data flows, employees can more easily weed out unexpected or unwarranted communication. If a (supposed) business leader requests a wire transfer of funds with significant urgency, but this is not part of a normal business process, employees should understand that such a request is not normal and should be subject to additional scrutiny. Without proper mapping of communications and data flows, an employee may not have any way of knowing that this action is not normal or have the needed justification to reject the request.

Having a mapping (a diagram or document) with which to compare expected and actual communications can help employees discern the level of suspicion to apply to any request.

ID.GV-2 – Roles and Responsibilities

Many employees in large organizations assume that cybersecurity is the sole responsibility of the security team. The employee, as non-security personnel, may assume they have no responsibility for the security of the organization. Cybersecurity defenders are not omniscient and cannot detect everything. Therefore, organizations must make clear that ALL employees are part of security and detection processes for an organization. Organizations must also enable and encourage employees to speak up and report any suspicious activity that they notice.  In the case of phishing, this might be a phishing reporting mailbox or email client plugin that can easily, quickly, and securely notify security personnel of the suspicious activity.

Organizations must seek to make roles and responsibilities regarding identification and reporting of suspicious activity clear to all employees. Enabling employees to identify and report suspicious activity through tooling and easy-to-follow processes will increase the likelihood that an employee will apply more scrutiny to abnormal interactions and report phishing attacks.

ID.RA-2 and ID.RA-3: Threat Intelligence and Identification

Open-source and paid threat intelligence sources aid organizations in identifying the most likely threats to the organization. In the realm of phishing, organizations can use threat intelligence information to determine the most common types and goals of phishing attacks that are likely to impact them. Whether targeting a specific industry or organization, attackers have specific goals in mind, including from pure financial gain to expanding access into an organization’s network, among many others. 

Although threat intelligence is often an art rather than a science, the broad availability of information can help defenders predict common phishing vectors and methods before they experience them firsthand. Take the banking industry as an example; several high-profile banking trojan malware variants are known to target the financial sector via phishing. Defenders can use this information to ensure that their tooling can appropriately detect and mitigate this style of attack. If an organization does fall victim to a phishing attack, having threat intelligence on specific attack vectors can help accelerate response activities. 

PR.AC-6: Identity Verification

Email, the most prolific phishing delivery mechanism, generally suffers from a lack of spoofing protections. Although the trained eye can easily spot spoofed emails, most users do not have the technical knowledge to notice many of these telltale signs. Email gateway technologies and proper email configurations (DMARC, DKIM, SPF) apply additional protections to email that limit the ability to spoof identities. Technology can be leveraged to help identify signs of email phishing that a user might not notice. Additional technologies, such as the use of PKI to digitally sign email messages, provide another way to prevent spoofing. 

Implementing such security measures can be burdensome – they also tend to be the most effective at combating phishing. Phishing relies on the victim believing the ruse of an attacker and believing the attacker is who they say they are. If attackers must start off at a disadvantage because they are not able to spoof an email in a believable fashion, their success rate falls drastically. Of course, attackers have found ways around these protections, but these methods are harder to execute and effectively weed-out less sophisticated attackers. 

PR.AC-7: Authentication Requirements

Although authentication requirements themselves do not directly impact phishing, the goal of phishing is often to gather credentials to authenticate to other systems. Multi-factor authentication helps thwart the use of harvested credentials by most often requiring a time-based authentication factor such as a code. While these codes are phishable themselves, the time-based nature of the codes requires more work and sophistication from the attacker to successfully pull-off the phish, thereby weeding-out less sophisticated attackers. 

Hardware tokens, such as the YubiKey or Google Titan, take this a step further by requiring a physical device and a hardwired key that verifies the user through a locally-presented challenge. The security industry considers these devices to be “unphishable,” as the MFA challenge requires that the token is physically present and verifies the originating source (that is to say, the verification response presented by a hardware token will differ between www.example.com and www.evil.com, even if the MFA challenge is the same). There are also other protections embedded in the U2F/FIDO standards behind these devices that aid in their unphishable nature. Finally, hardware tokens have the advantage of being a low-friction method of MFA, as users merely have to tap their hardware token to verify themselves, rather than dig out their smart phone and find a time-based code or wait for and accept a push-notification.

Although MFA technologies may be difficult to implement or burdensome to some users, the role of MFA in protecting critical business applications has almost become a necessity. Despite the protections against phishing mentioned in this article, the security industry is still far from a full proof solution. Hardware tokens act as a protection mechanism by adding another layer to the stack of anti-phishing technology; with the use of hardware tokens, preventing phishing attacks is less reliant on users to properly identify an attack in progress.

PR.AT: Security Awareness and Training

Likely no one reading this article is a stranger to security awareness and training. Training can be an effective method of educating users on the dangers of phishing. As email clients and browsers begin to build-in more phishing protections, user training on what these mechanisms mean and how to use them is a must. 

The days of “look for the green lock” are long past, but even better (if not more complicated) protections have replaced the green lock. To understand these frequent changes and updates to the cyber ecosystem, users require continuous training. Keeping users abreast of the most recent attack methods and defensive tooling can help them to more readily detect and mitigate attacks. 

DE.CM-4 and RS.RP-1: Detection of Malicious Code and Response Activities

For the purposes of discussing phishing, we will address these two categories together. Both detecting malicious code delivered via phishing and responding to phishing events happen within the same security operations group in most organizations. While the bulk of this article highlights IT admins and users as the primary defenders against phishing attacks, the security team still plays a major role. 

When phishing attacks utilize common malware, defensive mechanisms such as anti-virus or endpoint detection and response (EDR) platforms should alert security teams. Alternatively, users may report suspicious activity to alert the security team. Upon alert, security teams must have response processes in place to reduce the blast radius of a phishing attack. 

For every user who detects a phishing attack, there are likely many more who fell victim, and as we often say, it only takes one. Response plans should specifically address phishing in order to coordinate actions such as mass deleting offending emails, notifying users of ongoing attacks and methods, and tuning rules to detect similar activity. 

By having these actions pre-defined, response teams can quickly react in a predictable and effective manner. For a great example of a team that did this right, check out this blog from Coinbase.

Conclusion

Most organizations have several opportunities, as highlighted by the NIST CSF, to thwart phishing attacks: defining communications flow, defining roles and responsibilities, threat research, identify authentication requirements, awareness and training, and incident detection and response. The thirteen sub-categories detailed here represent a small percentage of the 108 total sub-categories in the NIST CSF, but they produce an outsized reduction in risk to organizations with regard to phishing.

Correct application of the NIST CSF can truly help organizations address risk in a systematic way. Using the NIST CSF objectives as a guide for control implementation within an organization maximizes the effectiveness of the security program. Each new control that an organization implements adds a layer to the Swiss Cheese Model or helps to close a hole in an existing layer. Used in an iterative manner, organizations can consistently improve their security program by making incremental improvements. This model points organizations in the right direction and helps ensure proper application of resources to primary business risks.