I’m gonna stop you little phishie….

Posted on 2023-05-25 by robbie

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. Here’s some thinking from the National Cyber Security Centre…

https://www.ncsc.gov.uk/blog-post/im-gonna-stop-you-little-phishie

Posted in Uncategorized | Leave a comment

LastPass Leak: What You Need to Do to Protect Your Passwords (CNET article)

Posted on 2023-01-17 by robbie

For anyone using LastPass…
In late December, LastPass announced that a security incident had allowed an unauthorised party to steal customer account information and vault data.

What should LastPass subscribers do?
Unfortunately, LastPass have not revealed how many users were affected by the breach, and LastPass didn’t respond to CNET’s request for additional comment on the breach.
If you’re a LastPass subscriber, you need to operate under the assumption that your user and vault data are in the hands of an unauthorised party with malicious intentions. Though the most sensitive data is encrypted, the problem is that the threat actor can run “brute force” attacks on those stolen local files. LastPass estimates it would take “millions of years” to guess your master password — if you’ve followed its best practices.

If you just want total peace of mind — you’ll need to spend time and effort changing your individual passwords.

Here’s what you need to do right now if you’re a LastPass subscriber:

1. Find a new password manager. Given LastPass’ history with security incidents and considering the severity of this latest breach, now’s a better time than ever to seek an alternative.

2. Change your most important site-level passwords immediately. This includes passwords for anything like online banking, financial records, internal company logins and medical information. Make sure these new passwords are strong and unique.

3. Change every single one of your other online passwords. It’s a good idea to change your passwords in order of importance here too. Start with changing the passwords to accounts like email and social media profiles, then you can start moving backward to other accounts that may not be as critical.

4. Enable two-factor authentication wherever possible. Once you’ve changed your passwords, make sure to enable 2FA on any online account that offers it. This will give you an added layer of protection by alerting you and requiring you to authorize each login attempt. That means even if someone ends up obtaining your new password, they shouldn’t be able to gain access to a given site without your secondary authenticating device (typically your phone).

5. Change your master password. Though this doesn’t change the threat level to the stolen vaults, it’s still prudent to help mitigate the threats of any potential future attack — that is, if you decide you want to stay with LastPass.

Ref: https://www.cnet.com/tech/services-and-software/lastpass-leak-what-you-need-to-do-to-protect-your-passwords/

Posted in Uncategorized | Comments Off on LastPass Leak: What You Need to Do to Protect Your Passwords (CNET article)

Locating Java Installs

Posted on 2022-09-14 by mike

In some cases vulnerability scanners will tell you that there is a vulnerable version of Java installed but not tell you where it is. This is a short post on solving that problem – for Linux machines.

Run the following code :-

for j in $(find / -type f -executable -name java)
do
echo $j, $($j -version 2>&1 |head -n 1)
done 2> /dev/null

And you will get a list of pathnames to java binaries with the version shown after the comma :-

/opt/java_splunk/jdk1.8.0_212/bin/java, java version "1.8.0_212"
/opt/java_splunk/jdk1.8.0_212/jre/bin/java, java version "1.8.0_212"
Posted in General, Technical | Comments Off on Locating Java Installs

Phishing Attacks Against Academics with an Interest in Russia/Ukraine

Posted on 2022-08-18 by mike

We have been alerted to the activities of a politically-motivated phishing “crew” targeting (amongst others) the Higher Education sector with particular reference to academics with interests in Russia and Ukraine.

The attacks look to be targeted to specific individuals with reconnaissance being carried out in advance using social media (specifically LinkedIn) or other public information (OSINT). The attacker will then create email accounts at consumer email providers with email addresses configured to resemble known contacts.

The attacker will then contact the target very often with an initially benign email before mentioning a missing attachment (with a topic of interest). A reply will result in a “weaponized” email being sent which may consist of the following forms :-

  1. A website link to malicious content.
  2. An attached PDF with a website link to malicious content.
  3. A link to a Microsoft OneDrive share containing a PDF with a website link to malicious content.

The website link is usually a link to a credentials acquisition site – i.e. it will capture usernames and passwords. And then will show some innocuous (and relevant) information.

To defend against such attacks :-

  1. If you are working, turn on the GlobalProtect VPN. There are some additional defences against phishing when you go through the University firewall (which includes the VPN).
  2. Be suspicious of new contacts – does the email address match previously published email addresses? Does it look like a personal address rather than an academic address?
  3. Be suspicious of old contacts who exhibit a change – are they using their usual email address? Has the tone of their language changed?

Posted in Active Attacks, Email | Tagged , , | Comments Off on Phishing Attacks Against Academics with an Interest in Russia/Ukraine

Detecting Suspicious Emails

Posted on 2022-08-17 by mike

This blog post is going to be somewhat longer and more technical than usual. It is intended as documentation for the use of IS staff, but may be more widely useful (at least in parts). To start with emails come in two parts – a header section, and one or more body parts.

You can do some analysis of the body of the email, but what can be done there is rather limited and has been covered before. However to go for a deep dive into the technicalities we need to have access to the full headers of the email.

Another thing to remember is that there is no guarantees on any of the signs in the headers (or the body) of faked/malicious emails; it’s a game of probabilities – if you get one or two indications that things are a bit “off” then it could well be legitimate; if you get many signs then it is most likely not legitimate.

The Raw View

This is a legitimate email … and the headers are rather scary :-

Delivered-To: someone@port.ac.uk
Received: by 2002:a4a:80c4:0:0:0:0:0 with SMTP id a4csp5624563oog;
        Thu, 7 Jul 2022 07:01:05 -0700 (PDT)
X-Google-Smtp-Source: AGRyM1txkbSraTKe9LYdHuciBI/kNXNlcAgkNZT9pxAwqYxVJeD0ZhOER+04vWiJl4T99ZxoHX7b
X-Received: by 2002:a17:90b:1b41:b0:1ec:747c:5d1 with SMTP id nv1-20020a17090b1b4100b001ec747c05d1mr5435707pjb.213.1657202464930;
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1657202464; cv=none;
        d=google.com; s=arc-20160816;
        b=tMx01iiG936FOOZW5sN4b6L7hQYIzEt6DinePrQYAeefM9UQEGLxQyKYSPZ5KSFfjx
         fPwykDUtXaKnEQUiReiI52M3vhBAVmRl1DTwX+xJjdp17TkDshWioq3vsKtowSBt7eju
         ztnU7xyS2g2XsRkp0L8NGtA6kIW1LZvUUD6OfN3dsFOZMRFmLXjMvWOCn+A2k87mon2z
         rEMXX+zU+g4j5/7R9dl9qb+v5MkXylcgKVrXx3/akTDVbfk8BADejiM20FXGN4XDqrOA
         z6azs/14qkvvZiH1vhrVhIMgbzy8si864lirE2J2YKcgWK5MXcy3zrY2t4IO0HMbONZK
         tt8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:list-unsubscribe:reply-to:mime-version:date:to:subject
         :message-id:from:dkim-signature;
        bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
        b=fF/FBqI+dHHhJwXP73exu7pVALIgXYesFYKQMn9u2tmT27K69Ok53dqwQ9a0NOeIMO
         n0Eke4dfIBELZLB7FahLAL8QoFFysPjAGNduqfE//K18+86n7Wg/jMbBr4BJGL9ltloH
         f5IzlIz2HOp12XCcyAy+WVsUhDDy8zuInUlyUrIF+5mnf9NPPVCaIsHI7N9MLXkgbsZX
         UpS6x5GYJOhFlFe+QvR7/pfqhbP0ciKBrPN49TVSJF2EeH9/SewYuJlh5dZoZpsydD8L
         AxiqPBH+3tqdnMaaOnQSZ26KBrsnCCBFAaZ8re51JwVdO8p3C/bGWOXraExrpH1WP+JY
         5NFQ==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com
Return-Path: <bounce-1657185485459.475823232258128637708151@i.drop.com>
Received: from mta-215-244.sparkpostmail.com (mta-215-244.sparkpostmail.com. [147.253.215.244])
        by mx.google.com with ESMTPS id s144-20020a632c96000000b0041160e45f31si305281pgs.97.2022.07.07.07.01.04
        for <someone@port.ac.uk>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)
Received-SPF: pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) client-ip=147.253.215.244;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com
X-MSFBL: 6Li1OAD6jdxrnkaoy/Hp4l4bxHUhsaA7/9w1iFnYAa4=|eyJjdXN0b21lcl9pZCI
 6IjEiLCJyIjoibWlrZS5tZXJlZGl0aEBwb3J0LmFjLnVrIiwic3ViYWNjb3VudF9
 pZCI6IjAiLCJ0ZW5hbnRfaWQiOiJtYXNzZHJvcCIsIm1lc3NhZ2VfaWQiOiI2Mjk
 4ZjdhNGM2NjJlNWRjNTBlZSJ9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i.drop.com;
 s=scph0618; t=1657185527; i=@i.drop.com;
 bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
 h=From:Message-ID:Subject:To:Date:Content-Type:From:To:Cc:Subject;
 b=fZScuZfVPkO10/ytHgvYkX2WAWsxyqr5QejjTPzYZAwCFcUlGH014uocHgPrgS05I
  KxUT2cm2BPQSd1ikShdeswe8MptNWMkE4fqIna17w3+CDinB5hRJ426ojqUHORMjB7
  R0jADRfBZF+GDuRCMSKBOxKTCTEgPZzj/H+ddS0M=
From: "Drop" <info@i.drop.com>
Message-ID: <05.EE.19583.7F4A6C26@gy.mta2vrest.cc.prd.sparkpost>
Subject: Drop + MiTo Serenity Desk Mat, Phangkey Amaterasu Desk Mat, Drop GMK White-on-Black Custom Keycap Set and more...
To: "Someone" <someone@port.ac.uk>
Date: Thu, 07 Jul 2022 09:18:09 +0000
Content-Type: multipart/alternative; boundary="_----cGGBgCxDlmJHT7JNSry5qA===_E0/C1-29399-27466C26"
MIME-Version: 1.0
Reply-To: support@drop.com
List-Unsubscribe: <mailto:unsubscribe@i.massdrop.com?subject=unsubscribe:ch4jzusTih96iuHiPvllEJD8RtThf9s8fddYQJW3G8Q~|eyAicmNwdF90byI6ICJtaWtlLm1lcmVkaXRoQHBvcnQuYWMudWsiLCAidGVuYW50X2lkIjogIm1hc3Nkcm9wIiwgImN1c3RvbWVyX2lkIjogIjEiLCAic3ViYWNjb3VudF9pZCI6ICIwIiwgIm1lc3NhZ2VfaWQiOiAiNjI5OGY3YTRjNjYyZTVkYzUwZWUiIH0~>
List-Id: <massdrop.1.0.sparkpostmail.com>

We’ll go through some of the more interesting parts of that shortly, but the key thing to remember is that the original sender (or any “hop” along the way) can insert anything it wants into those headers, so they cannot be trusted.

Or rather there are variable levels of trust.

The Headers

From: "Drop" <info@i.drop.com>

So the first thing to say is that the “From” header is likely to be the least trustworthy header in there. Whilst you probably can’t change where your emails “come from”, anyone using custom software (or crafting their own emails by hand) can put anything they like in there. So if it says “someone@port.ac.uk” there is no guarantee that it was really me that composed it (although there is some measures in place to make forging @port.ac.uk email addresses harder but not impossible).

One thing to look for are whether the two parts of the “From” header match or make some kind of sense – in this case we have “Drop” and <info@i.drop.com> which does match (in the loosest sense of the word). An example from a different email doesn’t look quite the same: “SleepConnection” <info@makeupfling.co> (taken from a real spam message).

Reply-To: support@drop.com

The next header to look at is the “Reply-To” header which may or may not be present – it effectively redirects replies to a different address. If the address included (support@drop.com) has a different domain (the bit after the “@”) then it becomes a bit more suspicious. 

To: "Someone" <someone@port.ac.uk>

And onto the “To” header (and to a certain extent the “Cc” header). This doesn’t necessarily contain your email address; nor is the absence particularly suspicious – there is in addition to the “CC” header (which also contains email addresses the email is to be delivered to), there is also an invisible “Bcc” header.

Legitimate email takes the email addresses from the “To”, “CC”, and “Bcc” headers, and adds those addresses to the “envelope” (which isn’t shown in the headers). It will also remove the “Bcc” header to preserve privacy.

Malicious emails populate the “envelope” without reference to the headers; which basically means that if the “To” field contains a name you do not recognise there is a slightly more suspicious. But if it contains your own email address that doesn’t make it trustworthy – it’s neutral.

Date: Thu, 07 Jul 2022 09:18:09 +0000

Probably not the most significant header to inspect, but there is no harm checking for impossible dates – either in the future (watch out for time zones) or in the past.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=i.drop.com;
 s=scph0618; t=1657185527; i=@i.drop.com;
 bh=oMI0usDG210zNBNaRijk6ss9HEYFI5LreIegG7NV5VM=;
 h=From:Message-ID:Subject:To:Date:Content-Type:From:To:Cc:Subject;
 b=fZScuZfVPkO10/ytHgvYkX2WAWsxyqr5QejjTPzYZAwCFcUlGH014uocHgPrgS05I
  KxUT2cm2BPQSd1ikShdeswe8MptNWMkE4fqIna17w3+CDinB5hRJ426ojqUHORMjB7
  R0jADRfBZF+GDuRCMSKBOxKTCTEgPZzj/H+ddS0M=

The significance of this header becomes relevant later on … as it is, it is a claim that the listed headers and the body of the email message have been digitally signed. Of course it has to be verified which comes later …

Received-SPF: pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) client-ip=147.253.215.244;

This is quite similar to the DKIM signature in that it is a test of whether the email comes from a mail server that the associated mail domain designates as a legitimate source. 

Authentication-Results: mx.google.com;
       dkim=pass header.i=@i.drop.com header.s=scph0618 header.b=fZScuZfV;
       spf=pass (google.com: domain of bounce-1657185485459.475823232258128637708151@i.drop.com designates 147.253.215.244 as permitted sender) smtp.mailfrom=bounce-1657185485459.475823232258128637708151@i.drop.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=drop.com

Now this claims to be a header added by Google (mx.google.com) giving the results of an authentication test – in this case we can see that the DKIM test passed – so the previous DKIM signature has been verified, the SPF test has passed, and the DMARC policy has passed – so there are good grounds for the sender of the domain is genuine.

This doesn’t mean that the email is genuine; just that the sender domain is valid. 

Received: from mta-215-244.sparkpostmail.com (mta-215-244.sparkpostmail.com. [147.253.215.244])
        by mx.google.com with ESMTPS id s144-20020a632c96000000b0041160e45f31si305281pgs.97.2022.07.07.07.01.04
        for <someone@port.ac.uk>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 07 Jul 2022 07:01:04 -0700 (PDT)

There’s quite a lot of information to be found in the “Received” headers – bearing in mind that headers can’t be totally trusted. In this example, the very first couple of lines claim that the message was received by mx.google.com (which looks legitimate) and was sent by mta-215-244.sparkpostmail.com.

The appearance of the hostname twice is because the first occurrence is what the sending mail server thinks it’s name is, and the second is Google’s (in this case) attempt at verification based on the network address. Matching is a good sign.

The Body

If you have read up to this point, you are probably already aware of the indications within the body of an email that make it look suspicious including but not limited to :-

  1. Links to sites labelled as one thing, but with the address of something else (i.e. looks like https://foo.com/ but actually goes to https://foo.com.bad.place).
  2. Impersonal salutations (“Dear Friend”) although personally addressed email isn’t a guarantee.
  3. Offers to good to be true – when was the last time you won a prize in a competition you didn’t enter?
  4. Strange wording. Either unnaturally good English or ridiculously bad English. Particularly from people you know or have corresponded with before.
  5. “Unusual” requests – especially requests to bypass standard procedures.

Final Assessment

As hinted at previously, an email may have suspicious indications but still be legitimate and an email may have no suspicious indications yet still be malicious. Determining which emails are legitimate and which are not, is not an easy thing to do – or it would be done automatically with total accuracy.

In fact a certain amount of illegitimate email is detected automatically and blocked; probably far more than we’re aware of. So we’re usually stuck determining the legitimacy of “edge cases”.

In assessing an email we look at the number of suspicious elements – if high enough we can judge it to be illegitimate. In areas of doubt, it is advised to verify the email contents “out of band” – with a phone call, checking with a colleague, or contact via an email address pulled out of a contacts database (and not the email).

Posted in Email, Malware | Tagged | Comments Off on Detecting Suspicious Emails

An Email With An Encrypted ZIP Attachment?

Posted on 2022-03-03 by mike

That’s suspicious!

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.

Posted in Active Attacks, Email | Tagged , , | Comments Off on An Email With An Encrypted ZIP Attachment?

Why foiling phishing attacks means much more than just punishing users for falling for them.

Posted on 2022-02-17 by robbie


Advice from the NCSC:

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 in Uncategorized | Comments Off on Why foiling phishing attacks means much more than just punishing users for falling for them.

Cyber Essentials is changing – we have 10 months to adapt

Posted on 2022-02-03 by robbie
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 in Uncategorized | Comments Off on Cyber Essentials is changing – we have 10 months to adapt

On Receiving USB Memory Sticks In The Post

Posted on 2022-01-17 by mike

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.

A “Bash Bunny”

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 in Uncategorized | Comments Off on On Receiving USB Memory Sticks In The Post

Cyber Essentials v3.0

Posted on 2021-11-30 by robbie

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 (robbie.walker@port.ac.uk) if you have any questions.

Posted in Uncategorized | Comments Off on Cyber Essentials v3.0