Phishing is an old technique – I mean, really old in internet age. I first got an email address in 1996 while studying engineering. And the phishing technique was described in detail in a paper and presentation delivered nine years prior to that. Yes, in 1987! A program called AOHell included a function for stealing the passwords of America Online users and, according to its creator, contains the first recorded mention of the term "phishing."
User education helps, but you can’t depend on it
Organizations often attempt to contain the success of phishing attacks with user education, which should be a core part of your cybersecurity strategy. But despite some verified industry successes, phishing still remains a big challenge. According to the Verizon Data Breach Investigation Report 2016, there were “9,576 total incidents, 916 with confirmed data disclosure” that fell under the category of phishing.
So what can you, the security practitioner, do to protect your organization, given that some users will continue to fall prey to phishing attempts despite efforts to educate users?
Users have been phished. Now what?
Protecting the organization must always start with the WHAT, and only then proceed to the HOW. In other words, start with the question: what high-risk assets are you trying to protect? Is it the source code of your software organization, the student information of your school, the patient health records of your healthcare organization, or the documents pertaining to the pending merger of your enterprise? Once you know what you are trying to protect, you can determine how to protect it. That starts with the question: how can you create a high degree of protection against a data breach even if users have been phished?
5 ways to blunt the success of phishing attacks
- Implement the principle of least privilege. The assets you are trying to protect must not be open to all employees. This principle seems simple, but is not always followed. In a high-profile data breach at a large U.S. retailer, the attackers stole a third-party vendor’s login credentials and were then able to install memory-scraping malware on over 7,500 self-checkout POS terminals. This vendor should not have had access to thousands of POS terminals. To follow the principle of least privilege, identify who needs access to your sensitive assets. Review the list with leaders in the organization to make sure it is accurate. Then use role-based access management to make sure the controls are implemented. In addition to implementing access controls in each application, add user controls to your next-generation firewall. Why? Because the firewall is the one security device that sees all network traffic. Implementing user-based access policies in your firewall can protect your sensitive assets, whether those assets are in your data center, in a private cloud, or in the public cloud.
- Strive for high “fidelity” of user identification. Access control is implemented at several places. For example, users first identify themselves to the endpoint, and then authentication and authorization checks are performed at the VPN gateway, the WLAN controller, the firewall and, ultimately, the application. Make sure you have high “fidelity” of user identification at each level. What do I mean by high fidelity? Two things. One, the speed of acquisition of identity; that is, from the time users connect to the network, how quickly are they identified? Two, in case of dynamic environments, the speed of updates as users move from one IP address to another. You, as the security practitioner, must work with the IT teams to increase the fidelity of user identity. As an example, deploying certificates on user endpoints is a way to increase fidelity. You must then make sure that the firewall gets this user identity with very little latency so that it is able to enforce user-based access control.
- Define access to applications, not server IP addresses. Traditionally, access to applications has been defined using IP addresses. In today’s environment, where applications move around and may even move from your private cloud to the public cloud, it is necessary that you define access to applications, not IP addresses. To do this, make sure your security equipment, like the firewall, can actually identify well-known applications and gives you the capability to define custom applications.
- Leverage user groups. Define access to applications using user groups instead of specific, named users. Why? It’s scalable and secure. For example, when you define a group that must have access to the pipeline data, you can easily add or remove users to that group without changing the access policy on your security device. Note that the groups you need for this purpose may or may not exist in the directory servers. If they don’t, work with the directory services administration team to define a best practice. Sticking to the pipeline example, you can create a sub-group of a small number of named individuals based on specific attributes, like the title, OU and location that must have access to the pipeline data. That way, as the security practitioner, you don’t need to maintain the group. As soon as someone leaves the organization, the directory services team removes the user from the group, and the user automatically loses access to the sensitive asset.
- Regularly audit and review access rules. Policies change. Old applications get retired and new applications are onboarded. Organizations get acquired and assimilated. How do you make sure the access policies you defined several months ago are still relevant and up-to-date? Put in place regular review processes, which must involve the business leadership. You can also invest in internal audits or spot testing of certain assets to make sure you remain protected.
Call to action for all security practitioners
As a first step, educate yourself and your users on the threat landscape, especially in the phishing area, and learn how to protect yourself. Here are some useful resources:
As a second step, identify at least one way out of the five listed above to implement change in your organization this quarter. Create a 1 to 3-month plan for how you are going to implement it.
Lastly, if you’re a Palo Alto Networks security practitioner, use our technical documentation to discover a step-by-step approach for enabling User-ID.