Secure Configuration - How to Maintain and Baseline Your Systems

As the trusted partner for over 200 schools worldwide, 9ine has helped many organisations assess their systems and services for security weaknesses that, if left unsecured, could have led to a network compromise.

Some of the assessments have highlighted operational weaknesses or strengths that could be improved upon to reduce the probability of a socially engineered attack. Other tests have involved the identification of software and system vulnerabilities that unnecessarily open up the organisation to potential exploitation and possible exfiltration of data.

In this the tenth and final blog in the series which builds upon every stage of the National Cyber Security Centre’s (NCSC) 10 Steps to Cyber Security, we outline how ensuring the ongoing maintenance and management of your systems and services is paramount in protecting your network. Continually assessing and implementing secure configurations against a defined security baseline can reduce the likelihood and impact of a security event.

What does your security baseline look like?

Before we start, let's define what we mean by a security baseline. You will notice the term security baseline appearing in various contexts. In this context, it relates to the minimum acceptable operational or technological security to be implemented across your devices, systems or services. 

If we take your organisation’s security baseline for an organisational owned laptop, it could include the following standards:

• All devices will have full disk encryption
• All devices will run Windows 10 (or later)
• All devices will use the organisation’s build image
• All devices will be added to the appropriate VLAN
• Only authorised software/apps will be installed
• All devices will auto-lock after 5 minutes of activity
• All devices will have the latest security patches installed
• All devices will be added to the organisation’s asset register
• The organisation will manage the device
• No personally identifiable information (PII) will be stored locally

In the above example, you are mandating that any laptop that is owned by your organisation meets a minimum set of security standards. If a member of staff has an organisation owned laptop and wanted to use it in a manner that would not fit with your defined security baseline, it would need to be logged as an expectation and a risk analysis performed. The risks associated with an exception against the security baseline would be added to the organisation's risk register and appropriate mitigating measures put in place. In this scenario, you end up with a few known exceptions to the rule and can manage the risk. The same rules apply to any hardware or software that you wish to introduce into your organisation. You define your minimum security baseline and assess new hardware, systems and services against that security baseline logging and evaluating the exceptions.

Let’s take the example of a minimum security baseline for a new online platform that would process sensitive data within your organisation: it could be that the new online platform does not currently offer two-factor authentication (2FA), and 2FA is on your minimum security baseline for platforms that have access to sensitive data. You would then perform a benefit vs risk analysis, and if the organisation determines the benefits outweigh the risks, you log the risks. Then you apply appropriate mitigating technical and operational actions until the residual risk is in line with the businesses risk appetite. In this scenario where 2FA is unavailable, you could:

• Increase password complexity
• Limit the number of administrative users
• Manage who has access and the access rights and privileges provided
• Configure additional monitoring and altering features
• Apply pressure to the vendor and their product roadmap
• Add other technological and operational compensating security controls

Read 9ine's article on How to Improve Your School Security Posture Using Security Frameworks and Annual Testing. 

What are the common weaknesses in school networks that 9ine has encountered ?

When conducting security assessments, the common areas where we find vulnerabilities are often areas where the organisation already believes they have good practices in place. In most cases, this is true, and the vast majority of the devices, systems or services are maintained successfully by the local IT Team or by third parties. It is the devices that are forgotten about, the ones that have fallen off the radar, shadow IT or the legacy systems that are waiting to be replaced or decommissioned where we find the bulk of vulnerabilities. It is these forgotten or unknown backdoors that the attacker is looking to exploit. 

Equally, some day-to-day systems are not in the limelight and once installed are forgotten about. Over time these “set it and forget it” systems become vulnerable to attack. Settings and configurations that were once considered secure are no longer secure as new vulnerabilities, and exploits get discovered and crafted every day.

The following is a list of the most common vulnerabilities identified:

1. 1. Default System Accounts (with original passwords)
   2. Unpatched systems or services (with known vulnerabilities)
   3. Legacy systems (with known vulnerabilities and unsecured)
   4. Passwords stored in clear text or password hash (crackable)
   5. Weak passwords (cracked by free password cracking tools)
   6. Excessive user privileges and rights (with acquired credentials)
   7. Unnecessary enabled features/integrations (allowing reconnaissance)
   8. Poorly secured remote access to internal systems

What are the risks associated with not maintaining your security baseline?

Once you have defined the minimum security standards (your baseline), you need to ensure that people will not circumvent them. As you add new hardware and software onto the network against your defined baseline, you are ensuring a minimum security standard. If and when you come across devices or systems that do not meet your requirements, you can make a risk-based decision on how to move forward. This approach allows you to put in additional measures necessary to further secure that device or system, whilst at the same time being fully aware where risk lies, even though it may have been reduced. 

If you do not have a defined baseline and approach the introduction of devices and systems in an ad-hoc manner, you will not have an accurate picture of your weaknesses. Over time you will accumulate a series of devices, systems and services whereby the overall cumulative security impact on your network is unknown.

As a minimum, a security baseline should include (but not be limited to):

1. 1. Removing / renaming / disabling default system accounts
   2. Changing default passwords, increasing their complexity
   3. Adding two-step authentication where possible and appropriate
   4. Limiting administrative access / using named accounts
   5. Installing the latest system and security patches
   6. Adding new devices or systems to your patch management regime
   7. Adding new devices or systems to your asset register
   8. Disabling unnecessary features
   9. Disabling unnecessary ports, peripherals, connectivity options
   10.  Adding the device or systems into your asset lifecycle planning

In summary, by defining and maintaining a minimum security standard across your network, you will vastly reduce your organisation's attack surface. Limiting the entry points for an attacker will reduce the probability or the success of an attack on your organisation. Following the guidelines outlined in the NCSC 10 Steps to Cyber Security will provide your organisation with a strong defence against malicious attacks.

ABOUT THE AUTHOR:

Dan Cleworth has worked in education for over 20 years. He is a Senior Technical Consultant and certified GDPR practitioner. Dan heads up 9ine's cyber security team and currently works with schools in the UK, Europe and the Middle East to evaluate and secure systems and services to meet data protection and cyber security compliance.

 

---

 

Share this blog