It's been a while since I last did a rant post. Mostly because as I write the rant my mind starts to make the counter arguments against all the things I rail about. But this is something I need to vent about. Even if there are exceptional cases to all rules, the following is fairly generic enough to apply to the majority.
I am sick of the cop-out that the user is of course the weakest link and anything in a similar vein. Oh look at that silly bugger who went and done did click on that malware; well shucks I surely wouldn't have done it but you know 'em end users. Oh did you hear bout that one human that had faith in their fellow humans and trusted some folks online?! Yeah can you imagine! They were just begging to be robbed blind. Like seriously!
NO. Just. stop.
The fact is very simple: we as a whole have failed if we allow people to make uneducated decisions about things whose complexity is overwhelming in the end. There are so many different points along the path of any kind of fraud, social engineering or misclick that could have security controls in place that prevent trouble.
Case example: Phishing and payload execution
Simple case. Attacker sends a user an email with a legit sounding pretext that gets the user to click on a link and either download a file that they then open or provide credentials.
Let's move step by step through all the things that could help save or recover from an unintended action.
Attacker sends the email. The company's email gateways have multiple different mechanisms that can provide detection and maybe prevention of such emails. Checks for domain black lists, domain reputation, grey listing, SPF, AV, throttling. Best case scenario: the email is just refused entry into the organization. Alternatively, it is directly sent to a spam folder where the user will not easily stumble upon it or the bulk phishing gets flagged for review due to amount of emails suddenly being sent etc.
Labelling external email
Then you have the first user interaction, they see it in their inbox. Pretending to be a co-worker in the same organization or being an automated message from an internal system are common scenarios. Another security control to help the user assess the situation is to clearly categorize external emails - emails originating from the outside or emails containing external addresses in any field. So when the user gets an email that "John shared 'Surprise party for boss' with you" and it is flagged as an external email, the user's suspiciousness has at least a chance to be triggered.
Easy reporting of suspicious emails
And speaking of being triggered, second important security control in the user interface is to have a simple method of reporting suspected phishy emails.
It is crucial that there are no negative consequences to reporting emails.
Even if they end up being false positives as this would deter users from using the mechanism. Rather the user should be praised publicly for every single correct report. Equally crucial is that this mechanism is as simple as possible - preferably just a single button in the interface with maybe a dialogue asking for a brief note on why this seems suspicious to the user.
Personnel with skills, tools and authority
This requires investment in personnel on the IT security side who have the knowhow to determine false positives from true positives. This requires that there are tools for them to safely assess the potential phish without triggering any malicious actions themselves or alerting the attackers to an ongoing investigation as this would drive attackers to potentially burn their infrastructure and make it more difficult to investigate, only for them to resurface with another attack.
There also needs to be proper tools and authority given to the responding personnel to take swift action if they start getting multiple reports of an identical email which would indicate an active phishing campaign targeting their organization. This means there needs to be mechanisms in place to blacklist domains and IP addresses centrally. There also should be logs of previous activity to be able to determine if any non-reporting users have actually clicked on the link. This will help the IT personnel to contact the users and start working on quarantine and other incident response procedures.
If the user had clicked on the link another security control could have prevented further problems: outbound proxy forced by centralized management with domain categorization and filtering. This would prevent users from reaching uncategorized domains - i.e. any domain that the attacker have recently created using either typo squatting, letter look-a-likes, Unicode replacements or just simply authentic sounding names. If the domain is freshly created, companies offering filtering solutions such as Symantec, Palo Alto and McAfee, wouldn't have categorized the content yet. This would require the user to request access to the new address which is a relatively uncommon occurrence in actual business needs to not bother users using legitimate sites. The outbound filter thus gives the organization yet another chance to intervene and prevent the incident from going further.
Of course the attackers may create sites with fake content first and then later use them to spread malicious files, or use well-known services like Amazon AWS, Google Drive or Github to host their payloads. The organization may determine that using Google Drive is not permitted by company policy, or that downloading certain file types and extensions is not permitted in the same proxy, but this time in inbound rules.
End point protection
There are ways for attackers to bypass the filtering by using commonly used file types to envelop their payloads - be it Word or zip files. But this is where the end point protection (EPP) software could and should be in place to detect known bad payloads or payloads which exhibit bad behaviors in general. If the user is the first in the world to try to access this specific file, then it is fairly safe to block the file.
There are very few reasons for regular office workers or consumers at home to be accessing globally unique files over the Internet.
End point detection & response
If the EPP software wasn't confident enough to block the phishing payload because either its actions were not malicious enough or they are somehow time-delayed, all is not lost: using end point detection services, activities such as opening files, network connections and new processes can be sent en masse to backend security systems for analysis. These detection systems will be able to analyze large masses of computers and to be able to detect anomalous or malicious activity and alert either the end user or the organization's security personnel. These same systems will allow the organization to also find all of the users whose computers have performed similar actions and thus begin quarantine and incident response procedures.
These same systems should be kept updated with any emerging threats and new attack patterns that are disclosed. Then security can retroactively scan the aggregate history of their organization's actions and find malicious activity that previously wasn't detected.
Malware, that is being sent for execution on the victim's computer, often uses a command and control (C2) channel to communicate new orders to or return valuable information from the computer. Another security control that could prevent spreading of the incident: application whitelisting. This means that organization has a comprehensive list of trusted applications that are allowed to a) start and b) make network connections.
If a user's Notepad.exe is trying to make new network connections, there are probable causes to raise alarms.
There are methods for attackers to take over whitelisted processes, but it again makes it more difficult for the attackers.
The whitelisting can also be extended to whitelisting of domain names and IP addresses instead of reactively blocking. This would make it more difficult to form the C2 channel. Any attempts to connect to new non-whitelisted addresses should be logged and investigated for malicious activity.
Separate administrative account
Depending on the attack scenario, the attackers may want to exploit the machine further than just looting the user's Passwords.xlsx file or encrypting their home folder for ransom. For this, it is usually required that they gain at least local administrative privileges. In order to enable the user to stop the spreading, it is important that the normal user accounts which are used to log into the computer is not given administrative access. Any normal user's regular daily activities should not include constant prompts for administrative use and thus the majority of the people in an organization would do better without any admin privileges given to them. See also: Least privilege and Privilege separation.
If admin privileges are required, then it should be in the form of a separate local admin account that you cannot use to login. Anywhere. Most of us are conditioned to just press YES/OK to the Windows prompt for admin access when you are installing software etc. This is another place to provide more security, but at a slightly reduced usability: require a password every single time in the admin prompt. This helps prevent the knee-jerk reaction to allow access without reading which program or what it was doing.
Side note: the local admin password cannot be the same as the local user password. Because your organization should already be distributing some password manager and training users in its use, you can actually require the local password to be a lot more complex than the login password as it should be stored in the password manager and not something the user needs to remember by heart. See also: my thoughts on password security on Cyber Security Sauna.
The point about having only local admin privileges is to make it more difficult for the attacker's payload to immediately spread across the network. On that note, any IT personnel in a Domain Administrator role should have multiple accounts: non-privileged regular login user account for their day to day activities of email, browsing, document creation etc.; one for administering their own local machine; one for logging in remotely to machines and, depending on feasibility, one for having administrative access to servers but without login access.
Login accounts shouldn't have admin privileges and admin accounts shouldn't have (remote) login privileges.
In addition, the attempted login use for admin accounts and vice versa should cause security alarms that security personnel can investigate.
Single Sign-on & Multi-factor authentication
So the user clicked the email and instead of a payload, there was a page requesting them to login to see the content. The page might even have prefilled the user's username or phone number which were gathered from somewhere else. Security control: holistic deployment of single sign-on (SSO) across your IT environment could have helped the user make an informed decision. If your users don't need to provide their login details to anywhere except when they are actually logging into their computer, it would be very easy for the user to determine that this is abnormal and I should not enter my credentials.
Well they entered their credentials despite being suspicious of the login form, and after all, they did get a cool cat video as a reward. What can the attacker now do with those credentials? Well in a secure world, not much. Because your organization has enabled multi-factor authentication (MFA, 2FA) for all of your services that can be accessed from the outside, like email (O365, GSuite, on-prem), VPN or VoIP.
With just a user-password pair the attacker should not be able to do anything besides physically log into the user's computer.
And every time someone tries to login to your externally available systems with just a username and password without providing the second factor correctly, it should be investigated by your security personnel. Check at least where the login attempt came from - is it from the same country or even continent as the last legit logins; is only a single user account being targeted or is someone enumerating your users. Remember to involve the user to investigate password reuse, resetting their passwords and finding the original email. Then check your systems for other users who have fallen prey to this credential harvesting.
Even though I do promote the idea that all increments in security are positive to the overall security level, I am extremely frustrated at how prevalent discussing end-user failings still is.
Yes. We humans are fallible. #metoo.
Stop resting your organization's security on our shoulders. Face the tough reality that you have a dozen or so different ways to prevent, detect and react to any incident and relying on user security awareness training once a quarter is. not. one. of. them.
As someone who has given security awareness training, I am not trying to cut the branch I'm sitting on no. As said: all increments are better than nothing. But the problem is that on paper "Organize Security Awareness Training" often reads "after this we can blame users."
Yes, as a security professional, I do understand that these things are difficult. Most of them require money and people. Tough. Cost of doing business and doing due diligence to secure it.
Just because we have been living in the wild west for the past decades, doesn't mean we can escape paying for the lack of security controls forever.
And as a consultant who has discussed this with a plethora of IT professionals, I also know that a whole lot of professionals are aware of many ways to make things more secure, but are usually lacking the money or personnel to implement things more securely. Yes, I feel your pain. But it's the management that should also be feeling it. I am glad of GDPR and similar things that provide at least some incentives to secure things.
There is no silver bullet in this post. I just want us, as a whole, to stop blaming users. Many times the malicious action is so well disguised that there is no way for even an informed user to discern any difference.
Focus on enabling your people to succeed and protect them from harm.
JW / Helsinki / 2018-09-30