At least it is if the password to decrypt the ZIP file is contained within the email – when you’re sending something secret you would send an encrypted ZIP file as an email and then send the password through some other means. Such as a phone call, or a text message.
If you get an email with an encrypted ZIP file with the password in the email, in all likelihood it is malware inside the attachment. There are plenty of email services that virus check attachments but they can’t make much headway with an encrypted archive containing the malware.
Some organisations put a lot of effort into training their staff to detect and evade phishing attacks. Some even punish them if they slip up.
It’s easy to see why the user has been identified as a central factor in phishing prevention – successful phishes after all depend on an attacker persuading a user to click on something they shouldn’t. So if bad guys can persuade users to click, it must be equally possible for us good guys to persuade users NOT to click. Right?
Wrong. It’s not a level playing field, and users can’t solve the phishing problem all by themselves. Trying to make your users invulnerable to phishing does nothing but waste your organisation’s time and money.
Some phishing emails are very competently executed to the extent that they are impossible to tell apart from genuine emails just by inspection. No amount of training, or punishment for getting it wrong, will change this. Furthermore, phishing attackers deliberately appeal to us emotionally. They say “Quick! Someone’s trying to steal your money! Come with me if you want to live.” Often we naturally respond to such appeals instinctively, without really thinking. Training tries only to develop our intellectual ability to spot phishes – it can’t stop us reacting to things designed to push our emotional buttons.
Furthermore, asking users to spot phishes means asking us to deliberately go against our normal working habits. Anti-phishing training teaches us to be suspicious of opening emails, clicking on links and opening attachments. But if we don’t do this, we can’t do our jobs. Most of us struggle to meet these two contradictory goals at the same time. The risk of attracting a sanction for falling for a phishing attack might mean we fear to open legitimate emails – which will have business costs. These costs are usually hard to see and measure – but they are there. We end up having to choose between the possibility of getting phished, or the certainty of harming our productivity. Many of us receive dozens of emails a day and must make these decisions every time, in a split-second, amid dozens of other pressures and distractions. At some point, we will inevitably make a bad call.
Rather than burdening users with impossible demands that leave them stuck between a rock and a hard place, we recommend that phishing is best tackled by implementing good technical defences and combining these with reasonable levels of user awareness, education and training. Setting up and maintaining your systems in accordance with our guidance will mean many phishing attacks are stopped before they do any harm, and the NCSC continues to develop and implement new anti-phishing measures that stop phishing emails getting to users’ inboxes in the first place.
It is worth telling users about common types of phishing attacks, particularly those that tend to be targeted at high-value users within organisations (a technique known as whaling).
And you should also encourage users (in a positive, blame-free manner) to report any emails or websites they are unsure about, even if they have already clicked.
However, trying to eradicate every single bad click is an unrealistic and harmful goal. As we’ve said elsewhere, users have a limited amount of time and effort to spend on security. Let’s make sure they put that effort in the places where it gets the best results.
Emma W People-Centred Security Lead, Sociotechnical Security Group, NCSC
Posted inUncategorized|Comments Off on Why foiling phishing attacks means much more than just punishing users for falling for them.
The Government approved Cyber Essentials scheme includes five technical controls that help protect organisations from the majority of cyber attacks. A team of experts review the scheme at regular intervals to ensure it stays effective in the ever-evolving threat landscape.
The scheme was introduced by the UK Government in 2014 as a way to help make the UK the safest place to do business. On January 24th 2022, some of the technical control requirements will change in line with recommended security updates. The evolution of Cyber Essentials allows UK businesses to continue raising the bar for their cyber security.
WHAT ARE THE CHANGES? HOME WORKING DEVICES ARE IN SCOPE, BUT MOST HOME ROUTERS ARE NOT. Anyone working from home for any amount of time is classified as a ‘home worker’. The devices that home workers use to access organisational information, whether they are owned by the organisation or the user, are in scope for Cyber Essentials.
Home routers that are provided by Internet Service Providers or by the home worker are now out of scope and the Cyber Essentials firewall controls are now transferred to the home worker’s device (computer, laptop, tablet and/or phone). However, a router supplied by the applicant company is in scope and must have the Cyber Essentials controls applied to it.
The use of a corporate (single tunnel) Virtual Private Network (VPN) transfers the boundary to the corporate firewall or virtual cloud firewall.
ALL CLOUD SERVICES ARE IN SCOPE Cloud services are to be fully integrated into the scheme.
If an organisation’s data or services are hosted on cloud services, then the organisation is responsible for ensuring that all the Cyber Essentials controls are implemented. Definitions of cloud services have been added for Infrastructure as a Service, Platform as a Service and Software as a Service. Whether the cloud service provider or the user implements the control, depends on the type of cloud service.
WHY? People commonly assume that cloud services are secure out of the box, but this is not the case. It is necessary for users to take responsibility for the services they use and spend time reading up and checking their cloud services and applying the Cyber Essentials controls where possible. Previously, Platform as a Service (PaaS) and Software as a Service (SaaS) were not in scope for Cyber Essentials, but the new requirements now insist that organisations take responsibility for user access control and the secure configuration of their services which would include securely managing access to the different administration accounts and blocking accounts that they do not need. Where the cloud service is in charge of implementing one or more of the controls ( eg security update management or anti-malware), the applicant organisation has the responsibility to seek evidence that this is done to the required standard.
MULTI FACTOR AUTHENTICATION MUST BE USED FOR ACCESS TO CLOUD SERVICES As well as providing extra protection for passwords that are not protected by other technical controls, multi factor authentication should always be used to provide additional protection to administrator accounts and accounts when connecting to cloud services.
The password element of the multi-factor authentication approach must have a password length of at least 8 characters with no maximum length restrictions.
WHY? There has been an increasing number of attacks on cloud services, using techniques to steal users passwords to access their accounts.
Multi-factor Authentication requires the user to have two or more types of credentials before being able to access an account. There are four types of additional factor that may be considered:
A managed enterprise device An app on a trusted device A physically separate token A known or trusted account THIN CLIENTS ARE IN SCOPE WHEN THEY CONNECT TO ORGANISATIONAL INFORMATION OR SERVICES A thin client is a ‘dumb terminal’ that gives you access to a remote desktop. It doesn’t hold much data, but it can connect to the internet.
ALL SERVERS INCLUDING VIRTUAL SERVERS ON A SUB-SET OR A WHOLE ORGANISATION ASSESSMENT ARE IN SCOPE Servers are specific devices that provide organisational data or services to other devices as part of the business of the applicant.
DEFINITION OF A ‘SUB-SET’ AND ITS IMPACT ON SCOPE A sub-set is defined as a part of the organisation whose network is segregated from the rest of the organisation by a firewall or VLAN. A sub-set can be used to define what is in scope or what is out of scope of Cyber Essentials. Use of individual firewall rules per device are no longer acceptable.
DEFINITION OF ‘LICENSED AND SUPPORTED’ Licensed and supported software is software that you have a legal right to use and that a vendor has committed to support by providing regular patches or updates. The vendor must provide the future date when they will stop providing updates. The vendor does not have to be the original creator of the software, but they must have the ability to modify the original software to create updates.
ALL SMART PHONES AND TABLETS CONNECTING TO ORGANISATIONAL DATA AND SERVICES ARE CONFIRMED IN SCOPE WHEN CONNECTING TO CORPORATE NETWORK OR MOBILE INTERNET SUCH AS 4G AND 5G. However, mobile or remote devices used only for voice calls, text messages or multi-factor authentication applications are out of scope.
DEVICE LOCKING Biometrics or a minimum password or pin length of 6 characters must be used to unlock a device.
PASSWORD-BASED AND MULTI-FACTOR AUTHENTICATION REQUIREMENTS When using passwords, one of the following protections should be used to protect against brute-force password guessing:
Using multi-factor authentication Throttling the rate of unsuccessful or guessed attempts. Locking accounts after no more than 10 unsuccessful attempts. Technical controls are used to manage the quality of passwords. This will include one of the following:
Using multi-factor authentication in conjunction with a password of at least 8 characters, with no maximum length restrictions. A minimum password length of at least 12 characters, with no maximum length restrictions. A minimum password length of at least 8 characters, with no maximum length restrictions and use automatic blocking of common passwords using a deny list People are supported to choose unique passwords for their work accounts.
New guidance has been created on how to form passwords. It is now recommended that three random words are used to create a password that is long, difficult to guess and unique.
There is an established process to change passwords promptly if the applicant knows or suspects the password or account has been compromised.
ACCOUNT SEPARATION Use separate accounts to perform administrative activities only (no emailing, web browsing or other standard user activities that may expose administrative privileges to avoidable risks)
THE SCOPE OF AN ORGANISATION MUST INCLUDE END-USER DEVICES WHY? If an organisation certifies their server systems only, they ignore the threats that come from their administrators who administered those server systems. The change to this requirement closes the loop-hole where organisations were able to certify their company without including any end user devices. Cyber Essentials must now include end point devices.
ALL HIGH AND CRITICAL UPDATES MUST BE APPLIED WITHIN 14 DAYS AND REMOVE UNSUPPORTED SOFTWARE All software on in scope devices must be:
Licensed and supported Removed from devices when it becomes un-supported or removed from scope by using a defined ‘sub-set’ that prevents all traffic to/from the internet. Have automatic updates enabled where possible Updated, including applying any manual configuration changes required to make the update effective, within 14 days of an update being released, where: – The update fixes vulnerabilities described by the vendor as ‘critical’ or ‘high risk’
– The update addresses vulnerabilities with a CVSS v3 score of 7 or above
– There are no details of the level of vulnerabilities the update fixes provide by the vendor
WHY? Previously, there was a set criteria that the vulnerabilities which had to be applied had to meet which were laid out in the requirements. These criteria have now been dropped and organisations need to apply all high and critical updates on all their systems. This is raising the bar because organisations can no longer be selective about which patches they apply and leave themselves weak and vulnerable.The reason for these changes can be illustrated by a high profile example this year. A vulnerability in the Microsoft Exchange System came out very publicly and was reported by numerous news outlets. That attack went from being a complex state actor attack to a commodity attack within seven days. It was commoditized into a ransomware attack only 12 hours later. This proves that a high complexity attack can be commoditized in hours and for this reason, all high and critical updates, need to be applied within 14 days, both for Cyber Essentials and Cyber Essentials Plus.
GUIDANCE ON BACKING UP Backing up your data is not a technical requirement of Cyber Essentials, however there is now guidance on backing up important data and implementing an appropriate backup solution is highly recommended.
TWO ADDITIONAL TESTS HAVE BEEN ADDED TO THE CYBER ESSENTIALS PLUS AUDIT Test to confirm account separation between user and administration accounts
Test to confirm MFA is required for access to cloud services.
HOW THE CHANGES WILL WORK There will be a grace period of one year to allow organisations to make the changes for the following requirements:
MFA FOR CLOUD SERVICES The requirement will apply for administrator accounts from January 2022
The MFA for users requirement will be marked for compliance from January 2023
THIN CLIENTS Thin Clients need to be supported and receiving security updates, the requirement will be marked for compliance from January 2023
The new question will be for information only for first 12 months.
SECURITY UPDATE MANAGEMENT Unsupported software remove from scope will be marked for compliance from January 2023
Posted inUncategorized|Comments Off on Cyber Essentials is changing – we have 10 months to adapt
A warning has been made about US businesses receiving “bad” USB memory sticks in the post. Although not a new form of attack, what is new is that the USB sticks may contain mass ransomware malware.
If you receive items in the post, be especially wary of USB memory sticks – if the stick is unexpected, it comes from a sender you haven’t received anything from before, or if there are other reasons to suspect it, pass it along to IS for inspection.
That’s a genuine “bad USB” stick from my collection of tools; real “bad USB” sticks won’t be quite as obvious.
Whilst a USB memory stick is just a memory stick, an attacker can build (or buy) something that looks like a memory stick but can be programmed to act as almost any kind of USB device – a keyboard, a mouse, or something else.
A keyboard is quite common because an attacker can insert fake keystrokes that will install malware and then take over full control of the system you are using.
Posted inUncategorized|Comments Off on On Receiving USB Memory Sticks In The Post
In the January 2022, the NCSC will introduce an updated set of requirements for the Cyber Essentials scheme (v3.0). This update is the biggest overhaul of the scheme’s technical controls since it was launched in 2014 and is in response to the evolving cyber security challenges that organisations now face.
The way we work has changed dramatically over a short period of time. The speed of the digital transformation and the adoption of cloud services are driving factors here, as well as the move to home and hybrid working, accelerated by the COVID-19 pandemic, which is now routine for many people.
The refresh of Cyber Essentials reflects these changes and also signals a more regular review of the scheme’s technical controls.
The University passed the annual Cyber Essentials – Plus recertification on 29 November 2021. In late November 2022, we will have to be ready to re-certify to v3.0. An assessment of the impact of any changes is underway and plans to adapt our working practices will follow.
Please contact Rob Walker (email@example.com) if you have any questions.
You want to send an email to a long list of people; perhaps that list should remain private, or perhaps you just want to avoid the inconvenience of people seeing a huge “To” field with tons of other addresses in. What do you do?
Use the “Bcc” field.
When composing a new message in Google Mail :-
Click on the little “Bcc” at the top right :-
The window changes to show the “Bcc” header into which you can enter addresses to send the email to – which won’t be visible to those receiving the mail.
“Bcc” is short for “blind carbon copy” a reference to an ancient office technology that most of us are too young to remember (even me!). But it can be regarded as the same as “To” except that addresses listed within it are not sent to the recipient.
Why is this important?
For a start, it is a lot neater for those reading the message without seeing a whole mess of additional recipient addresses.
Due to a certain episode around Easter this year, a number of changes were made to the firewall security policy to make it more secure. Since then a great deal of work has gone into identifying web-based applications that are in use and making sure they’re allowed through the firewall.
But in all likelihood, we’ve missed a few.
So it makes sense to test everything that you use for teaching (or anything else) to see if it works properly. If it doesn’t :-
Connect to the VPN (whether you are at home or on campus).
Raise a servicedesk job requesting that “it” be allowed. To make it easier the following would be helpful :-
What username you logged into the VPN with.
Around what date and time did you try – the more accurate and precise you can make this, the better.
A description of the application and why it is required.
If you received an error, what was the text of the error message?
Don’t worry if it’s just a “nice to have” application – whilst there are security reasons for saying no, that is relatively rare and we’re not inclined to say no to something that looks like entertainment (for example).
Posted inFirewall|Comments Off on Firewall Blocking Essentials?
Recently we have become aware of an issue in relation to one of our cloud service providers which is weakening one of our email security measures – specifically the mechanism put in place to make it harder to impersonate UoP senders (i.e. any @port.ac.uk email address). This has allowed a recent increase in the amount of spam being received.
As of late in the afternoon of the 24th February, the cloud vendor has fixed the issue so there relevant spams should stop arriving. Leaving just ordinary spams!
We are in contact with the vendor to resolve this issue, but in the meantime you very well may receive spams with a sender address (“From”) of firstname.lastname@example.org.
Two quite common varieties of spam that are cropping up are mentioning mail quotas (“your mail quota is exceeded”) and bitcoins (“pay us bitcoin or we’ll leak your secrets”).
In relation to the mail quota spams :-
We do not have mail quotas; anyone offering to increase your mail quota is offering to do the impossible … or more likely ask you for your password so they can use it nefariously.
If you “hover” (move the mouse pointer to where the clickable link is, but don’t click it), you can see where the link really takes you too at the bottom of the browser window. In the case of this spam, it will say something like https://port.ac.uk/mail-quota/ but will in fact take you somewhere else.
This is a standard phishing spam email – the link will take you to a page that looks like a login window and you will be prompted for your password. Don’t fill it in!
In the case of the bitcoin extortion spams, the main characteristic is that they say something that amounts to “send us bitcoin or we’ll leak all your secrets”. Sometimes they will claim to have broken into your account; sometimes they will claim to have recorded you indulging in activities that you won’t want others to know.
Whilst this could be alarming, it is exceptionally unlikely to be the truth. Extortion spams are widespread and known to have no truth behind them; although the latest ones don’t appear to be “sextortion”, it remains a possibility.
If you are wondering what “bitcoin” is, a link to the Wikipedia article can be found earlier in this article, but in summary it is a “crypto-currency” which is form of money without a backing government/central bank implemented using cryptographic mechanisms. Criminals appear to like it because they (falsely) believe it to be anonymous.
Whilst this is an ongoing situation with a special wrinkle, the advice is still pretty standard :-
If it sounds too good to be true, it probably is.
Does the email “ring right”? If it came from an @port.ac.uk address :-
Does it look like it was composed in Gmail
Do you normally receive emails from that sender?
Is the writing standard what you would expect?
Before you click on a link, check (by “hovering”) if that link takes you to where you expect.
If you click on the link, does the page appear to be in the usual UoP style? Most of our authentication pages go through the same “identity provider” and although there are two main ones with different appearances, they do have a standard “look”.
Because of the current issue (which we expect to resolve in a day or two), be wary of emails from @port.ac.uk addresses that you haven’t corresponded with before.
We have recently started using a new-to-us web server security scanner that amongst other things will highlight the absence of a file – security.txt – in the root of the web server. And thus this blog entry explaining what it is, why we need it, and what the contents should be.
Note that this is not a HTML page but a plan text page and must be installed as such.
The intention behind security.txt is to provide a mechanism by which those who encounter security issues with a web site can make contact in an approved manner. To those who argue that the information is available elsewhere, the counter-argument is that it is a lot more helpful to have information available in a standardised location.
The minimum file should contain :-
You can add a second line for an additional contact if you wish :-
The file must be named as precisely security.txt and must be either in the root of the web server “document root” or within a standard subdirectory (/.well-known/security.txt) (compliant with RFC8615).