Method for securely assessing a device configuration

Abstract

Method for Securely Assessing a Device Configuration A method for securely assessing device configuration is provided. Configuration data of a device is compared with a set of security configuration requirements. The set of security configuration requirements is retrieved based on the configuration data. Based on the comparison, it is determined whether the set of security configuration requirements is met. In response to the determination, a result is generated and sent. A validation check is performed for the result and, if the result fails the validation check, the result is prevented from being sent.

Description

[0001] Method for Securely Assessing a Device Configuration

[0002] FIELD

[0003] The disclosure relates generally to device configurations. More particularly, the disclosure relates to a method for securely assessing a device configuration, a computer program for securely assessing a device configuration and a computer-readable storage medium having the computer program stored thereon.

[0004] BACKGROUND

[0005] Devices can often be configured to operate in one or more of a number of different ways and can have a number of different settings. This configuration and / or settings can be defined by configuration data. Configuration data may include, for example, a default password of the device. Default passwords and other default configuration settings can be a great security issue, as these are typically implemented across a large number of devices and often are not updated by device users. Furthermore, default configuration settings are often not sufficiently secure. Default configuration data thus allows a malicious party to easily exploit a number of potential device security weaknesses.

[0006] In view of this, configuration data is typically changed before a device is used or implemented. For example, device configuration data may be changed during an onboarding process. Onboarding may mean the process of connecting a new device to a network and / or services that the new device is intended to access (for example, via the network). However, there are a number of issues with current methods for checking device configuration data.

[0007] For example, in current methods, device configuration data may be collated in spreadsheets. Storing and reviewing this data was feasible when networks comprised a small number of dial-up modems, a limited number of cells sites and relatively few different device types. However, since the early 2000s, the number of different device types, as well as the number of devices, has increased significantly, as is illustrated in Figure 1 . Furthermore, networks nowadays typically cover a much wider area and have a greater number of cell sites. Thus, spreadsheets are required to store greater amounts of device configuration data than ever before. This is not easily scalable to the current level of device usage, which results in a large number of devices with default device configuration data (for example, due to slow device onboarding). As the number of devices and their implementations increases in the coming decades, security is therefore of increasing concern.

[0008] Another issue is that current methods of onboarding devices require a device provider and / or service provider (for example, an entity providing network devices) to instruct a third party implementing a case management system to check the configuration data. If the device configuration data is not sufficiently secure, the device and / or service provider must instruct the third party as to how to change the configuration data to meet the security requirements of the device and / or service provider. This can lead to further security issues. For example, the communication channel via which the device provider instructs the third party may not itself be secure. Thus, a malicious party may be able to see which particular security configurations are being implemented, which makes it easier for the malicious party to figure out ways to work around the security configurations. Furthermore, the third party is typically not themselves a device and / or service provider, and so lacks expertise in how to implement the security requirements. Thus, the third party may not correctly implement and / or fully implement the security requirements. This may leave security weaknesses for a malicious party to exploit.

[0009] Overcoming the issues noted above is desirable.

[0010] SUMMARY

[0011] Against this background, there is provided a method for securely assessing device configuration. Additional aspects appear in the description and claims.

[0012] A device is configured in a manner defined by configuration data of the device. The configuration may be a default configuration, and may or may not meet certain security requirements, which may be defined by a service provider. The security requirements may depend on the configuration data of the device, such as a type of the device, software installed on the device or hardware of the device, for example. The security requirements are obtained based on the configuration data and may be obtained from a server or another device external to the device, or may be stored on the device. The security requirements define certain configuration parameters of the configuration data that should be implemented before the device can be used or added to a network. By comparing the configuration data with the security requirements, it is determined whether the security requirements are met. If the security requirements are met, the device passes the security check. Otherwise, if the security requirements are not met, the device fails the security check. The result of the security check (pass / fail, success / failure, approval / disapproval or another set of binary values) is sent from the device to another device, but the reason(s) for the result are not sent.

[0013] Since the result is sent as a binary value without any reason for the result, a malicious party is not made aware of which security requirements have or have not been met. This frustrates the ability of the malicious party to exploit any security weaknesses that may be caused by, for example, misconfigurations, default settings or inadequate security protocols. Thus, potential vulnerabilities and risks associated with unauthorised access or cyber threats are reduced. The security of the device and / or a network including the device can be improved.

[0014] The present disclosure also relates to another consideration of a method (which may be combined with the earlier discussion). A device is configured in a manner defined by configuration data of the device. The configuration may be a default configuration, and may or may not meet certain security requirements, which may be defined by a service provider. The security requirements may depend on the configuration data of the device, such as a type of the device, software installed on the device or hardware of the device, for example. The security requirements are obtained based on the configuration data and may be obtained from a server or another device external to the device, or may be stored on the device. The security requirements define certain configuration parameters of the configuration data that should be implemented before the device can be used or added to a network. By comparing the configuration data with the security requirements, it is determined whether the security requirements are met. If the security requirements are met, the device passes the security check. Otherwise, if the security requirements are not met, the device fails the security check. The result need not be a binary value but may include, for example, the configuration parameters that do not meet the security requirements, an indication of the security requirements not met and / or other result information. An additional check is performed for the result to ascertain whether the security requirements, result and / or configuration data (particularly the configuration parameters) are as expected and that no tampering has occurred. If the additional check is failed, the result is not sent to another device.

[0015] The additional check may thus enable it to be determined that, although a device is indicated as meeting the security requirements, the device may nevertheless be compromised. The device may thus be prevented from being used or added to a network, which may improve the security of the network. Furthermore, since the result is not sent over any communication channel, a malicious party is not made aware of which security requirements have or have not been met. This frustrates the ability of the malicious party to exploit any security weaknesses that may be caused by, for example, misconfigurations, default settings or inadequate security protocols. Thus, potential vulnerabilities and risks associated with unauthorised access or cyber threats are reduced. The security of the device and / or a network including the device can be improved. There may also be network and computer resource efficiencies associated with preventing the result from being sent when a device has failed the additional check.

[0016] In accordance with a first aspect, there is provided a method for securely assessing device configuration comprising steps of: comparing configuration data of a device with a set of security configuration requirements, the set of security configuration requirements being retrieved based on the configuration data; determining, based on the comparison, whether each of the set of security configuration requirements is met; and generating, in response to the determination, a pass or fail result and sending, via a communication channel and to an external device, the pass or fail result without any reason for the pass or fail result.

[0017] In accordance with a second aspect, there is provided a method for securely assessing device configuration comprising steps of: comparing configuration data of a device with a set of security configuration requirements for the device, the set of security configurations being retrieved based on the configuration data; determining, based on the comparison, whether the set of security configuration requirements is met and generating, in response to the determination, a result indicating whether the set of security configuration requirements is met; and performing a validation check for the result and, if the result fails the validation check, preventing the result from being sent to an external device.

[0018] The above methods may be implemented by a server and / or a computing device.

[0019] The methods described above may be implemented as a computer program comprising instructions to operate a computer or computer system (or other hardware and / or software configured to implement the method). The computer program may be stored on a computer-readable medium (for example, a non-transitory computer-readable medium).

[0020] It should be noted that any feature described herein may be used with any particular aspect or embodiment of the invention. Moreover, the combination of any specific apparatus, structural or method features is also provided, even if that combination is not explicitly disclosed.

[0021] The invention will now be described with reference to the attached drawings depicting different embodiments thereof, the drawings being provided purely by way of example and not limitation.

[0022] BRIEF DESCRIPTION OF DRAWINGS

[0023] The invention may be put into practice in a number of ways, and preferred embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

[0024] Figure 1 illustrates historical network infrastructure compared to more current network infrastructure; Figure 2 illustrates a flowchart diagram of a method for securely assessing a device configuration in accordance with the present disclosure;

[0025] Figure 3 illustrates an exemplary implementation of a method for assessing a device configuration in a secure manner; and

[0026] Figure 4 shows a flowchart diagram of a method for securely assessing a device configuration in accordance with the present disclosure.

[0027] It should be noted that the Figures are illustrated in schematic form for simplicity and are not necessarily drawn to scale. Like features are provided with the same (or similar) reference numerals.

[0028] DESCRIPTION OF PREFERRED EMBODIMENTS

[0029] With reference to Figure 2, there is illustrated a flowchart of a method 200 for securely assessing a device configuration. In other words, a device configuration, which may be a default device configuration, may be assessed in a secure or security-aware manner. For example, the assessment may be performed in a manner that prevents or limits the ability of a malicious party to exploit the device configuration prior to and / or after being changed. In particular, weak network device configurations can create security vulnerabilities, making it easier for unauthorized individuals or malicious actors to gain unauthorized access to the network. Misconfigurations, default settings, or inadequate security protocols can leave the infrastructure exposed to cyber threats, data breaches, and unauthorized access. Configuring network devices properly may require specialized knowledge and skills. Identifying issues of poor configurations is the first step in hardening (improving) network defences.

[0030] In addition, inadequate network device configurations can impact the overall efficiency and performance of the infrastructure. Misconfigurations or suboptimal settings may cause network disruptions, slow down data transmission, or result in system outages. These issues can in turn lead to decreased productivity, increased downtime, and customer dissatisfaction.

[0031] Assessing the configuration of devices may be important for other reasons. For example, companies often operate within regulatory frameworks and industry standards that require specific security measures and configurations. Weak network device configurations can lead to non-compliance, potentially resulting in legal and financial consequences. Meeting compliance requirements is essential to protect sensitive data and maintain the trust of customers and partners.

[0032] Moreover, as companies grow and expand their networks, managing network device configurations becomes more challenging. Ensuring consistency and proper configuration across numerous devices can be time-consuming and prone to errors. Inconsistencies or overlooked configurations may create security gaps or operational issues.

[0033] In addition, in organizations with decentralized IT operations or a lack of standardized processes, network device configurations may vary widely. Inconsistent configurations make it difficult to enforce security policies and create a cohesive security framework across the infrastructure. This lack of standardization can lead to a higher risk of security breaches and inefficient management.

[0034] In short, proactively addressing weak network device configurations is crucial for maintaining a secure and resilient infrastructure.

[0035] The method 200 may be performed prior to adding a device to a network (or otherwise making the device visible to the network). Additionally or alternatively, the method 200 may be performed prior to enabling the device to be used. The device may be disabled for use by, for example, not being subscribed to a service, which may prevent certain actions from being taken such as, for example, accessing the Internet or making or receiving calls and / or texts. Other actions may be prevented and may be prevented in other ways.

[0036] The method 200 may thus enable security vulnerabilities to be identified before the device is included in the network and / or enabled for use, which may prevent malicious parties from exploiting the security vulnerability. Furthermore, this may simplify the complexity, effort, time and cost involved in onboarding a device to a network. Existing methods that require configuration information to be updated via spreadsheets or case management systems can take years to onboard fewer than 500 devices. In contrast, the present method may enable significantly more devices to be added to a network and / or enabled for use in a shorter time frame, as the method 200 may enable insufficiently secure device configurations to be identified (and rectified) more quickly.

[0037] In other examples, the method 200 may be performed after a device has been added to a network and / or enabled for use. The method 200 may thus be used to strengthen the security of the device if it is determined that the device provides security vulnerabilities. The method 200 may enable these security vulnerabilities to be identified and targeted for fixing in a straightforward manner. Furthermore, the method 200 may enable the identification of security vulnerabilities of a large number of devices to be identified more quickly and more straightforwardly. Thus, the method may enable the security of a network and / or the device to be improved.

[0038] The method 200 comprises, at step 201 , comparing configuration data of a device with a set of security configuration requirements. The security configuration requirements are requirements by an entity (for example, a service provider or a user workplace) for the configuration of a device that aim to provide or improve device security. The security configuration requirements may also be referred to herein as security requirements or configuration requirements.

[0039] The configuration data may be retrieved from a configuration file, which may be stored locally on the device or may be retrieved from another device. The configuration data may comprise device information and configuration parameters that can be adjusted. The device information may, for example, indicate a type of device, an operating system (or other software) of the device, hardware of the device and / or other information about the device. The type of device may include a computing device (including a mobile device). For example, the device may be a server, a desktop computer, a cellular device, a tablet computer or another computing device. The configuration parameters may include parameters defining which communication protocol to implement, which ports are open / closed, whether authentication is required for an action, a username and / or password, and so on.

[0040] In another example, the type of device may be a network device. A network device (which may also be referred to as networking hardware, network equipment, a network component or a computer networking device) may be a device which allows communication and / or interaction between devices on a computer network. For example, networking hardware may mediate data transmission between devices in a computer network.

[0041] Network devices can be classified into a number of categories, usually based on the location and role of the network device in the network. For example, a core network component may interconnect other network components. A hybrid component may be implemented in a core or border of a network. A border component may be hardware or software components that typically lie on the connection point of different networks (for example, between an internal and an external network). End stations may be hardware devices that sit at the end of a network.

[0042] Examples of network devices include a hub, a firewall, a load balancer, a proxy, a switch, a concentrator, a repeater, an access point, a modem and a router. The term network device may include computing devices such as, for example, cellular devices, tablet computers and devices associated with the Internet of Things. Other network devices are also possible. The network device may also comprise a combination of one or more of these types of devices.

[0043] The set of security configuration requirements in step 201 are retrieved based on the configuration data, which may be achieved in one of a number of different ways. In one example, the set of security configuration requirements may be retrieved via an API. In another example, the set of security configuration requirements may be retrieved from information stored on the device. The configuration data may comprise device information that indicates which set of security configuration requirements to retrieve in step 201 . The device information may be compared with a list of device definitions, wherein one or more of the device definitions in the list are associated with a respective set of security configuration requirements, to determine a set of security configuration requirements corresponding to the device information. The associated set of security configuration requirements may thus be selected or retrieved based on the device information. The device definitions may be associated with the respective set of security configuration requirements by a user, a computer program or otherwise predetermined. For example, one or more machine learning or artificial intelligent (Al) algorithms may be used to identify one or more trends between device information and security configurations to associate device information with a set of security configurations.

[0044] Comparing the device information with the list of device definition may comprise determining a device definition in the list that is the same as the device information. In cases where the device information does not (fully) correspond to a device definition in the list, the comparison may comprise determining a device definition in the list that is most similar to the device information. A device definition may be determined to be most similar where the greatest amount of information is the same for the device definition and the device information. In other cases, certain device information may be weighted more strongly than other device information, such that the device definition determined to be most similar does not correspond to the greatest amount of information in common. For example, the operating system of the device may be deemed more important for determining the similarity of the device definition and the device information than the type of device. The weightings may be determined by a user or by one or more machine learning or Al algorithms.

[0045] In another example, a machine learning or artificial intelligence algorithm may be used to identify trends between configuration data (which may include device information) and security configurations. A machine learning model may be generated based thereon to select the set of security configurations based on the configuration data.

[0046] In a further example, a user may provide the set of security configuration requirements based on the configuration data. The user may provide the set of security configuration requirements in response to a request from the device.

[0047] Step 202 comprises determining, based on the comparison at step 201 , whether the set of security configuration requirements is met. The determination may comprise generating a reason why the set of security configuration requirements is or is not met. The reason may be generated for each of the security configurations requirements, or for the set of security configuration requirements as a whole.

[0048] In some examples, the determination in step 202 may be performed for each of the set of security configuration requirements. In this case, even where the device does not meet one or more security configuration requirements, the determination for each configuration requirement may be completed. This may allow the determination, configuration information and / or other information to be used in subsequent checks. For example, this may allow the information to be determine whether a subsequent device is similar to the device, which may be used as part of a validation check, as will be discussed with respect to step 205.

[0049] In other examples, the determination may be performed until one of the set of security configuration requirements is not met. In response to a determination that the one of the set of security configuration requirements is not met, the method 200 may proceed to step 203. This may improve the efficiency of the computer resources used to perform the determination, since the whether the remaining security configuration requirements are met may be rendered moot. That is, the device may be determined not to pass the security assessment check and so there may be no reason to check the remaining security configuration requirements.

[0050] Either or both of steps 201 and 202 may be performed by applying a trained machine learning model to the configuration data and the set of security configuration requirements. The machine learning model may have been trained on historical configuration data and security configuration requirements and generated by one or more machine learning algorithms configured to identify one or more trends in the historical configuration data and security configuration requirements.

[0051] At step 203, the method 200 comprises generating, in response to the determination at step 202, a result indicating whether the set of security requirements is met. The result may be referred to herein a security assessment result or security check result.

[0052] In one example, the result is (or comprises) a pass or fail result. The pass result may indicate that the set of security configuration requirements was determined to be met and the fail result may indicate that the set of security configuration requirements was determined not to be bet. It will be appreciated that although a pass or fail result is described, any other binary set of values may be used instead such as, for example, approved / disapproved, approved / not approved, success / failure, and so on.

[0053] The pass or fail result may comprise a single pass or fail result for the set of security configuration requirements. For example, if one requirement of the set of security configuration requirements is not met, a fail result may be generated, even though the remainder of the set of security configuration requirements are met. In another example, the pass or fail result may comprise a pass or fail result for each requirement of the set of security configuration requirements. The pass or fail result for each requirement may include a non-descriptive label (for example, “security requirement 1 ”, “MR1”, or another description) so that a network engineer may know which security requirements have been met / not met (although they still may not be aware of the reason why). In another example, the pass or fail results may be provided in a list that may be unordered, random, pseudo-random or arbitrarily arranged. This may enable a network engineer to know how many security requirements were met / not met without providing any information about the specific security requirements that were met / not met. This may further limit the ability of a malicious party to exploit security weaknesses and / or replicate pass results.

[0054] In examples where the result is a pass or fail result, the method may proceed to step 204, which comprises sending, via a communication channel and to an external device (which may be a server and, optionally, an API or database server), the pass or fail result without any reason for the pass or fail result. In other words, whilst a pass or fail result may be sent, the specifics of which security requirement(s) has / have not been met and / or how is not sent over the communication channel. Thus, even if the communication channel is not secure, a malicious party can only obtain limited information about the device and / or configuration data. This prevents, or at least limits, the ability of the malicious party to exploit any security weaknesses that may be present (for example, if a fail result is generated because one or more of the security configuration requirements is not met). Furthermore, in cases where pass result is generated, since the malicious party may not know why the set of security requirements has been met, this may make it more difficult for the malicious party to determine ways around the security requirements (for example, for subsequent device security assessments). Thus, a secure method for assessing a device configuration may be provided.

[0055] Although no reason for the pass or fail result is sent in step 204, the method 200 may comprise generating, for each of the set of security configuration requirements that is not met, a reason for the pass or fail result. The reason may comprise information indicating a difference between the configuration data and a respective security configuration requirement of the set of security configuration requirements.

[0056] Steps 201 , 202, 203 and 204 may be performed at the device. Additionally or alternatively, steps 201-204 may be performed at a server. This will be discussed in more detail with reference to Figure 4, which illustrates one exemplary implementation of the method 200.

[0057] In another implementation, the result need not be (although may still be) a pass or fail result. For example, the result may comprise an advisory warning, configuration data that has not met a security requirement of the set of security requirements, a list of differences between a respective security configuration requirement and the configuration data, a pass or fail result for each of the set of security configuration requirements, or other information. In either case (that is, whether the result is a pass or fail result or comprises another result), the method may proceed to step 205, which comprises performing a validation check for the result. The validation check may output a validation result, which may comprise a pass result, fail result, advisory warning or another result.

[0058] The validation check is a separate (additional) check to the result generated in response to the determination. That is, a device may pass the security check because the configuration data meets the set of security configuration requirements, but nevertheless fail the validation check.

[0059] The validation check may comprise checking whether the result differs from an expected result. Additionally or alternatively, the validation check may comprise determining whether the set of security configuration requirements differs from an expected set of security configuration requirements. The validation check may also or instead comprise determining whether the configuration data differs from expected configuration data.

[0060] The expected result / set of security configuration requirements / configuration data may be based on a minimum compliance standard (MCS). For example, the validation check may comprise a parameter check based on the MCS and may include a report on the MCS status. The validation check may fail in cases where the result, set of security configuration requirements and / or configuration data differs from (does not meet, for instance) the MCS. In the opposite case, the validation check may be passed where the result, set of security configuration requirements and / or configuration data meets and / or exceeds the MCS.

[0061] In another example, the expected result or set of security configuration requirements may be based on previous configuration data. For example, a (first) device configuration of a first device may be assessed and the first device configuration may not meet the set of security requirements. Subsequently, a (second) device configuration of a second device may be assessed. The validation check may comprise determining that the second device configuration is similar to or the same as the first device configuration. It may be determined that the second device configuration is similar in cases where more than 50% of the configuration data of the second device is the same as the configuration data of the first device, for example. The configuration data may be determined to be the same where the configuration data differs by less than a threshold tolerance.

[0062] Based on the determination that the second device configuration is similar to (or the same as) the first device configuration, it may be expected that the result indicates that the set of security configuration requirements is not met. Thus, if the result nevertheless indicates that the set of security configuration requirements is met (that is, does not match the expected result), the validation check may be failed.

[0063] Similarly, based on the determination that the second device configuration is similar to (or the same as) the first device configuration, it may be expected that the retrieved set of (first) security configuration requirements for the first device is the same as (or similar to) the retrieved set of (second) security configuration requirements for the second device. Thus, if the sets of first and second security configuration requirements differ (that is, the set of second security configuration requirements does not match the expected set of first security configuration requirements), the validation check may be failed. In some cases, the validation check may only fail if the sets of first and second security configurations differ by more than a threshold amount. For example, the validation check may fail if two or more security configuration requirements present in the first set are missing in the second set.

[0064] In other examples, the validation check may only fail if particular security configuration requirements of the two sets differ. These particular security configuration requirements may be indicated in the set of security requirements as critical, mandatory or otherwise more significant than other security configuration requirements. For example, one security configuration requirement may be that Telnet (short for “teletype network”) is disabled, and this requirement may be indicated in the set of security configuration requirements as a critical security configuration requirement. If the second set of security requirements does not include a critical security configuration requirement present in the first set, the validation check may be failed.

[0065] Similarly, the set of security requirements and / or result may correspond to expected configuration data. If the configuration data of the second device does not match the expected configuration data (or differs more by than a threshold amount), the validation check may be failed. Thus, even if the result indicates that the set of security requirements is met, the device may not be onboarded onto the network. In cases where retrieving the set of security configuration requirements comprises comparing the device information with a list of device definitions, the validation check may comprise determining whether one or more device definitions in the list differ from an expected one or more device definitions. For example, it may be determined that fewer device definitions are present in the list than during a previous assessment, which may indicate that an outdated list of device definitions is being used. This may be indicative of a malicious party attempting to circumvent the security check. Thus, the validation check may be failed and the device may not be onboarded onto the network.

[0066] Additionally or alternatively, the validation check may comprise determining whether the list has been modified. Similarly, the validation check may comprise determining whether the result (for example, the pass or fail result) and / or the set of security configuration requirements has been modified. The determination may be based on a check of whether the list and / or a file including the result and / or set of security configuration requirements has been edited (for example, after the creation date / time). In another example, the determination may be based on a check of whether any edits were performed by a nonauthorised party. It may be determined that a party was not authorised where authentication credentials (for instance, a username and / or password) were not used when the edit was performed. In another example, a party may be determined to be unauthorised when the edit originated from an unknown IP address. Other methods of determining whether or not a party was / is authorised to edit may be used.

[0067] Similarly, the validation check may comprise determining whether a computer program (for instance, software described with reference to Figure 4) comprising instructions that cause a device to perform steps of the method 200 has been modified. The determination may be based on any of the checks described above. In another example, the determination may be based on a determination that a version number of the computer program is older than a previously used computer program version number (for example, version 2.2 compared to version 2.4).

[0068] After generating the results in step 203 and prior to performing the validation check in step 205, the method 200 may comprise adjusting the configuration data. For example, where a fail result is generated or where the result otherwise indicates that one or more of the set of security requirements is not met, the configuration data may be modified to meet the set of security configuration requirements. The modification may be performed by the device or may be enforced by another entity (for example, by sending an updated configuration file to the device). The another entity may be the entity performing the steps of (or at least some steps of) the method 200. Adjusting the configuration parameters prior to performing the validation check may enable more efficient device security assessment.

[0069] If the result fails the validation check, the method proceeds to step 207 of preventing the result from being sent to an external device. The external device may be a server and may optionally be an API or database server.

[0070] Preventing the sending of the result may mean that a malicious party is unaware that the device has been identified as compromised or tampered with. Even if the malicious party does become aware (for example, because the device is not onboarded onto the network), the malicious party may not be informed of how the identification was achieved, since the result (which may include reasons for the result, such as, for example, a list of which security configuration requirements were not met) is not sent. Thus, the network security may be maintained or improved, as the malicious party may not be informed of how to circumvent the security assessment. Examples of preventing the result from being sent include storing the result in volatile memory and, in response to failing the validation check, removing the result from the volatile memory; or preventing generation of an API. These examples will be discussed in further detail in respect of Figure 4.

[0071] Otherwise, if the result passes the validation check, the security check result may be sent in step 206. The sending in step 206 may be via a communication channel, which may be a wireless or wired communication channel, and the result may be sent to the external device. The external device may be a server and may optionally be an API server or database server. Where the security check result is a pass or fail result, step 206 corresponds to step 204. In other words, although steps 205 and 204 are shown in Figure 2 as distinct steps, both steps may be present in the method 200. Furthermore, although the validation check and the security assessment result are separate checks, the validation check result may be sent with / as part of sending the security assessment result.

[0072] In some examples, the validation check result may include one or more reasons for the validation check result. The reasons may be sent with the validation check result as part of step 206. This may enable a user or network engineer to investigate the cause of the result in a straightforward manner. In other examples, the validation check result may be a binary value result (for example, pass or fail). This may prevent a malicious party from being informed of why the validation check failed, which may prevent the malicious party from exploiting this information in future attempts to access the device and / or network. The validation check result being a binary value may be particularly advantageous in examples where the security check result is also a binary value. A malicious party may therefore be provided with minimal information regarding the security assessment, which may further limit their ability to exploit the device and / or network.

[0073] In cases where the set of security requirements is not met (for example, a fail result is sent) and / or the validation check is not passed, the method 200 may return to step 201 . Prior to returning to step 201 , the method 200 may further comprise adjusting configuration data (for example, configuration parameters) of the device to meet the set of security requirements. In other examples, the method 200 may include a step of adjusting the configuration parameters of the device to meet the security requirements and may not return to step 201 . Adjusting the configuration parameters may improve the security of the device before it is allowed to be used and / or implemented in a network. Following the adjustment, the device may be included in, added to or otherwise made visible to a network. In some examples, following the adjustment, the device may be enabled to perform be used - for example, by being subscribed to a service or being allowed to perform actions that were previously prevented.

[0074] Figure 3 illustrates an exemplary implementation 300 of the method 200. A device 301 , which may be a network device, is configured according to configuration data 302 comprising device information. The device information is compared with a list of device definitions 303, where one or more of the device definitions in the list are associated with a respective set of security configuration requirements 304.

[0075] The list of device definitions 303 may include broader and narrower device definitions. For example, a first device type may be associated with a first set of security configuration requirements, irrespective of the specific hardware and / or software on a device of the first device type. In another example, an operating system may be encoded according to semantic versioning (for example, version 3.2, version 4.6.1 , and so on). The major version number (in the example above, 3, 4 and so on) may have a set of security configuration requirements associated with it, whilst the more specific version number including the minor and optional patch number may have a more specific set of security configuration requirements associated with it. Other device definitions are possible.

[0076] In some examples, the device 301 may be configurable as more than one type of device. For example, the device 301 may be configurable as either a router or a switch. The device information may thus indicate which configuration of the device 301 has been implemented. In this case, although one of the configurable device types may have a different (for example, more rigorous) set of security requirements, the device information may indicate that another configurable device type has been or is to be implemented. Thus, the set of security requirements associated with the another configurable device type may be retrieved. That is, if the device 301 is not configured to be used as a router, then at least some of the set of security configuration requirements associated with the router may be irrelevant to the use of the device 301 . Checking for and / or implementing security configuration requirements that are not needed unnecessarily increases the time and complexity involved in assessing (and updating) device configurations. Thus, identifying the purpose of the device 301 when assessing the configuration of the device 301 may allow the number of devices assessed to be increased, which may in turn allow a greater number of device configurations to be updated to meet security configuration requirements.

[0077] In the implementation illustrated in Figure 3, the configuration data 302 includes device information indicating that the device 301 is a first device type having hardware X. The configuration data may not specify the operating system of the device 301 . This may be the case where the device 301 does not implement an operating system, for example.

[0078] The first device type having hardware X is associated with the set of security configuration requirements 304. The set of security requirements 304 may be retrieved, based on the device information, via an application programming interface (API). In another example, the set of security configuration requirements 304 may be retrieved from information stored on the device 301 .

[0079] As discussed above in respect of Figure 2, the set of security requirements 304 is compared to the configuration data 302 and it is determined whether the set of security requirements 304 is met. In response to the determination, a pass or fail result is generated and the result is sent, via a communication channel and to an external device, without any reason for the pass or fail result. The communication channel may be a wireless communication channel. In other examples, the communication channel may be a wired communication channel. Referring to Figure 4, there is illustrated a flowchart of a method 400. The method 400 is similar to method 200 described with reference to Figure 2.

[0080] At step 401 , a computer program or software included in a client device (for example, device 301 ) is run or otherwise implemented. The computer program may be downloaded by the client device or may be included in the client device during production. The software may comprise a computer file including definitions and statements. For example, the software may comprise a Python module. It will be appreciated that other computing languages may be used.

[0081] The software may include the device definitions 303 and a parser. The software may thus operate offline. That is, the client device may not require a network connection to implement steps of the method 400. In other words, the steps may be performed locally at the client device. In another example, the software may not include the device definitions 303. The device definitions 303 may instead be retrieved via an API from a server using an HTTP(S) connection.

[0082] At step 402, the software (which may also be referred to as a client) may receive or retrieve the configuration data. The configuration data may be stored locally on the client device and is preferably stored in a configuration file. The client parses the configuration files line by line using the device definitions 303. The client may parse the configuration files using a hybrid language of, for example Python and YML.

[0083] The parsing includes retrieving the set of security configuration requirements based on the configuration data and comparing the configuration data with the set of security configuration requirements. During the parsing, it is determined whether the set of security configuration requirements is met and, in response to the determination, a result is generated. The result may be a pass or fail result or may include additional or different information.

[0084] At step 403, a validation check may be performed. The validation check may be as described with reference to Figure 2. For instance, in cases where the validation check is failed, the method 400 may comprise a step of preventing sending of the result to an external device.

[0085] Preventing the result from being sent may comprise storing the result in volatile memory during step 402 and, in response to failing the validation check, the result is removed from the volatile memory. Thus, a malicious party may not be able to identify the reason why a device was not onboarded onto the network, which may prevent or limit their ability to circumvent the security assessment. This may also improve memory storage usage, since the results for failed validations are not stored.

[0086] In cases where the validation check is passed, the results may be compressed whilst in the volatile memory. For example, the results may be stored in a .zip file format, which may also be encrypted. The encryption may be performed according to an AES-256 techniques. In another example, the results may be generated in a data interchange format (for example, in a .json format).

[0087] In other examples, preventing the result from being sent may comprise preventing generation of an API. For example, in response to failing the validation check, a POST API request may not be sent. This may mean that the result is not sent over any communication channel, which may improve security, as a malicious party may not be informed of which security requirements have / have not been met. The malicious party is thus not enabled exploit security vulnerabilities by being given a list of which security requirements are not met. Network and computer resource efficiencies may also result, since there may be no reason to send the result to an external device server to repeat the security and / or validation check when the device has identified itself as failing validation.

[0088] At step 404, based on the validation check at step 403, the client device may be approved or not approved (for example, disapproved). For example, although the client device may meet the retrieved set of security requirements, if the validation check is failed, the client device may not be approved. The client device may thus not be onboarded to the network. This may prevent an easy ingress point for potential compromises and hacking from being included in the network, which may improve security of the overall network. In some examples, disapproving the client device may prevent the device from being used in the network at all. That is, the method 400 may not return to step 402 (or, with reference to Figure 2, step 201) after the client device has been disapproved. Thus, a tampered client device may not be provided with an additional opportunity to infiltrate the network. As discussed above, the validation check may prevent sending the result to an external device, so the malicious party may not be made aware of the reason why the client device has been prevented from accessing the network. In another example, the client may not meet the retrieved set of security requirements. Again, this may prevent an easy ingress point for potential compromises and hacking from being included in the network, which may improve security of the overall network.

[0089] After the client device is approved at step 404, the device may be onboarded onto the network. In this case, steps 411 -414 may not occur, although steps 421 , 422, 431 , 405 and 406 may still occur.

[0090] Steps 401-404 need not be performed at the client device as part of the method 400. Instead, the configuration data may be received at or retrieved by a server and the validation check performed at the server. The client device may then be approved by the server. This may reduce risk of allowing a compromised device to use the network, as the server may be subject to more strict security requirements. The method may proceed after approval in step 404 to step 411 . At step 411 , a communication comprising the result (a submission) is received from the client device. The result may be received at a server and may be received via an API or an email, for example. In cases where the result has been compressed, the result may be uncompressed and stored on a server (for example, a cloud server). The result may also be unencrypted. In cases where a POST API request is received, the data may be included in a database model.

[0091] At step 412, the result may be analysed. Step 412 may be similar to step 402. The external device may receive a plurality of results (for example, from a plurality of client devices), and the plurality of results may be aggregated at step 412 by an aggregator. The aggregator may input the plurality of results into one or more database models for submission to a database. The aggregator may implement a queue system with a plurality of streams or workers that are configured to process submissions in the queue system. This may enable the aggregator to manage multiple submissions simultaneously. This may allow more efficient handling of large submissions, as it may not be required to wait for a submission to be fully aggregated before another submission aggregation can be started.

[0092] At step 413, a validation check may be performed at the external device. The validation check may be as discussed above in respect of step 403. Performing the validation check at the external device may provide a cross-check of the validation check at step 403. This may provide additional assurance that the client device is secure and may improve the overall security of the network, as a device incorrectly validated and approved at steps 403 and 404 may be identified at step 413. At step 414, the client device may be approved or not approved (for example, disapproved), similarly to as discussed in respect of step 404.

[0093] Following step 413 and / or step 404, the result may be stored in a database. The database may be implemented using a relational database management system and / or structured query language (SQL). For example, PostgreSQL or an Oracle database may be used.

[0094] At step 431 , a graphical user interface may be presented. The graphical user interface may be presented on the client device or another device. The graphical user interface may allow data in the database to displayed. For example, the graphical user interface may display reports (for example, relating to the results and / or client device), statistics and issues for network engineers to remediate. The graphical user interface may be implemented by a React.js webserver. The front end may use React.js to display the data, while the back end system may use Python3 and Flask. It will be appreciated that other programming languages may be used. The graphical user interface may be presented on the client device. For example, a user may navigate to the dashboard via a web browser or an application at step 405. The user may select a button (or another graphical interface element) to view the result at step 406.

[0095] Presenting the results of the compliance analysis via a graphical user interface may provide a clear and concise overview of the compliance status. This may make it easy for users or engineers to act upon the information effectively.

[0096] As illustrated in Figure 4, the method 400 may include steps performed by the client device and steps performed by an external device, which may be a server. In other examples, steps may be performed by the client device or the external device (that is, by one of the client device and external device, rather than by both).

[0097] For example, the steps of comparing the configuration data (steps 201 , 402), determining whether the set of security configuration requirements is met (steps 202, 402), generating the result (steps 203, 402) and, optionally, performing a validation check (steps 205, 403) and, in response to the validation check, either sending or preventing sending of the result (steps 206 and 207, 403) may be performed at the client device. In implementations where the validation check is not performed, the result may be sent as in step 204. Following the performance of these steps by the client device, the external device (which may be a server) may perform at least some of the same steps. For example, the external device may perform steps 201-204. In another example, the external device may perform steps 201-203, 205 and either step 206 or 207.

[0098] Thus, in some examples, the client device may generate and send a pass or fail result to the external device without any reason for the pass or fail result and the external device may perform a validation check. If the validation check is passed, the external device may send the result (which may include the validation check result) to another device, which may be a database server.

[0099] In other examples, the client device may generate a result, perform a validation check and, in response to passing the validation check, send the result (which may include the validation check result) to the external device. The external device may then perform steps 201-204, which may act as a cross-check of the result.

[0100] In yet further examples, the client device may perform steps 201-204, in response to sending a pass result to the external device, steps 201 -204 may be performed at the external device. This may also act as a cross-check of the result.

[0101] In another example, steps 201-204 and / or steps 201 -203 and 205-207 may be performed by the external device, rather than the client device. The external device may be subject to more restrictive security measures than the client device and so may be less likely to be compromised by a malicious party. Performing steps 201-207 at the external device may thus further improve security and may provide greater confidence in the result (for example, that the client device has not be tampered with if a pass result is received).

[0102] Additional benefits associated with the methods and systems disclosed herein are discussed below.

[0103] The approach discussed herein can be designed to work with a variety of network devices and configurations. It may thus offer flexibility in integrating with different hardware and software environments, making it adaptable to diverse networking setups. This compatibility may enable seamless integration into existing infrastructure and simplify the onboarding process for a wide range of devices. Furthermore, the extensive device coverage may allow organizations to assess compliance across various network devices. It may support a wide range of equipment, which may enable comprehensive compliance monitoring and evaluation. Furthermore, assessing the configuration of a device may allow any deviations from security configuration requirements to be identified. Devices that do not meet the necessary security and / or regulatory standards can thus be reported to the appropriate owners and audit bodies in a straightforward manner.

[0104] The estimated costs associated with traditional methods of security assessment and / or hardening are not required, allowing organizations to achieve compliance in a more cost-effective and expedient manner.

[0105] The approach discussed herein allows organizations to maintain complete autonomy over their compliance processes. There may thus be no need to share sensitive data at a central level, which may further improve security, ensure data sovereignty and control over compliance operations.

[0106] Furthermore, targeted non-compliance searches can be performed. This may allow a user or organization to identify specific areas where compliance requirements are not being met, which may enable them to focus their efforts and resources on addressing those specific concerns. Thus, the most critical security vulnerabilities can be addressed in an efficient manner.

[0107] The present approach may enable hostname granularity, which may allow an organization to assess the compliance status of individual devices. This level of detail enhances precision and enables organizations to identify and address compliance gaps on a granular level. This may further enhance security.

[0108] In summary, benefits associated with local autonomy, data sovereignty, comprehensive device coverage, targeted non-compliance searches, and hostname granularity can be provided without the associated costs and constraints of relying on external suppliers or vendors.

[0109] The following numbered clauses show further illustrative examples only. 1 . A method for securely assessing device configuration comprising steps of: comparing configuration data of a device with a set of security configuration requirements, the set of security configuration requirements being retrieved based on the configuration data; determining, based on the comparison, whether the set of security configuration requirements is met; and generating, in response to the determination, a pass or fail result and sending, via a communication channel and to an external device, the pass or fail result without any reason for the pass or fail result.

[0110] 2. The method of clause 1 , wherein the pass or fail result comprises a single pass or fail result for the set of security configuration requirements or the pass or fail result comprises a pass or fail result for each of the set of security configuration requirements.

[0111] 3. The method of clause 1 or 2, wherein determining whether the set of security configuration requirements is met comprises generating, a reason for the pass or fail result.

[0112] 4. The method of clause 3, wherein the reason comprises information indicating a difference between the configuration data and a respective security configuration requirement of the set of security configuration requirements.

[0113] 5. The method of any previous clause, wherein determining whether the set of security configuration requirements is met comprises determining whether each of the set of security configuration requirements is met.

[0114] 6. The method of any previous clause, wherein the steps of comparing the configuration data, determining whether the set of security configuration requirements is met, generating the pass or fail result and sending the pass or fail result are performed at the device and / or at a server.

[0115] 7. The method of clause 6, wherein the steps of comparing the configuration data, determining whether the set of security configuration requirements is met, generating the pass or fail result are performed at and sending the pass or fail result are performed at the device and, in response to sending a pass result, the steps are subsequently performed at the server. 8. The method of any previous clause, further comprising, in response to determining that one or more of the set of security configuration requirements is not met, adjusting configuration parameters of the device to meet the set of security configuration requirements.

[0116] 9. The method of any previous clause, wherein the configuration data comprises device information that indicates the set of security configuration requirements to retrieve, wherein the set of security configuration requirements is optionally retrieved via an application programming interface, API, or from information stored on the device.

[0117] 10. The method of clause 9, wherein the device information indicates a type of device, an operating system of the device and / or hardware of the device.

[0118] 11 . The method of clause 10, wherein the type of device comprises a network device, wherein the network device optionally comprises a hub, firewall, load balancer, proxy, switch, concentrator, repeater, access point, modem and / or router.

[0119] 12. The method of clause 10 or clause 11 when the device information indicates the type of device, wherein the device is configurable as one of two or more types of device and the device information further indicates a configuration of the device as the one of the two or more types of device, wherein the retrieved set of security configuration requirements corresponds to the one of the two or more types of device.

[0120] 13. The method of any of clauses 9 to 12, wherein retrieving the set of security configuration requirements comprises comparing the device information with a list of device definitions, wherein one or more of the device definitions in the list are associated with a respective set of security configuration requirements, to determine a set of security configuration requirements corresponding to the device information.

[0121] 14. The method of clause 13, wherein comparing the device information with the list of device definitions comprises determining a device definition that is the same as or most similar to the device information.

[0122] 15. The method of any previous clause, further comprising performing a validation check for the pass or fail result to generate a validation check result, wherein the validation check is failed if one or more of: the pass or fail result, the set of security configuration requirements, and / or the configuration data differs from a respective expected pass or fail result, set of security configuration requirements, and / or configuration data; when retrieving the set of security configuration requirements comprises comparing the device information with a list of device definitions, one or more of the device definitions in the list differ from an expected one or more device definitions and / or the list has been modified; the pass or fail result, the set of security configuration requirements and / or the device definition have been modified; and a computer program comprising instructions that, when the computer program is executed by the device, cause the device to carry out the method of any preceding clause has been modified.

[0123] 16. The method of clause 15, further comprising, in response to failing the validation check, preventing the pass or fail result from being sent to the external device.

[0124] 17. The method of clause 16, wherein preventing the pass or fail result from being sent comprises: storing the pass or fail result in volatile memory and, in response to failing the validation check, removing the pass or fail result from the volatile memory; or preventing generation of an application programming interface, API.

[0125] 18. The method of any of clauses 15 to 17, wherein sending the pass or fail result comprises sending the validation check result.

[0126] 19. The method of any of clauses 15 to 18, wherein the steps of performing the validation check and determining whether the set of security configuration requirements is met are distinct steps.

[0127] 20. The method of any previous clause, further comprising applying a trained machine learning model to the configuration data and the set of security configuration requirements to compare the configuration data and determine whether the set of security configuration requirements is met.

[0128] 21 . The method of any previous clause, wherein the configuration data is obtained from a configuration file. 22. The method of any previous clause, wherein the external device comprises a server, wherein the server is optionally an application programming interface, API, server or a database server.

[0129] 23. The method of any previous clause, wherein the communication channel is a wireless communication channel.

[0130] 24. A computer program comprising instructions that, when implemented by a computer, cause the computer to perform the steps of any previous clause.

[0131] 25. A computer-readable storage medium having stored thereon the computer program of clause 24.

[0132] The methods described herein may be implemented with computer system configurations including hand-held devices, microprocessor systems, microprocessor- based or programmable consumer electronics, minicomputers, mainframe computers and the like. The embodiments can also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked through a network.

[0133] The computer system may include a processor, such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer may contain a suitable operating system such as UNIX (including Linux) or Windows (RTM), for example.

[0134] Certain embodiments can also be embodied as computer-readable code on a non- transitory computer-readable medium. The computer readable medium may be any data storage device than can store data, which can thereafter be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. Although embodiments according to the disclosure have been described with reference to particular types of devices and applications (particularly mass spectrometers) and the embodiments have particular advantages in such case, as discussed herein, approaches according to the disclosure may be applied to other types of device and / or application. Each feature disclosed in this specification, unless stated otherwise, may be replaced by alternative features serving the same, equivalent or similar purpose. Thus, unless stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0135] All of the aspects and / or features disclosed in this specification may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. In particular, the preferred features of the disclosure are applicable to all aspects and embodiments of the disclosure and may be used in any combination. Likewise, features described in non-essential combinations may be used separately (not in combination).

[0136] The methods and apparatus of the present disclosure can be utilised with a variety of electrode structures. Electrodes of appropriate dimensions can be arranged into symmetrical or asymmetrical patterns upon substrates and if elongation of electrodes is beneficial for a particular application, the electrodes may be linear or curving. Individual electrodes can be planar, hemispherical, rectangular or of other shapes. The electrodes may be PCB printed electrodes.

[0137] It will be appreciated that there is an implied “about” prior to temperatures, concentrations, times, pressures, flow rates, cross-sectional areas, voltages, currents, etc. discussed in the present teachings, such that slight and insubstantial deviations are within the scope of the present teachings. Furthermore, values referred to as being “equal” may in fact differ by less than a threshold amount. The threshold amount may be 5%, for example. The threshold may also be greater than 5% (e.g., 10%, 20% or 50%) or less than 5% (for example, 2% or 1 %), depending on the context.

[0138] As used herein, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as “a” or “an” (such as an electrode) means “one or more” (for instance, one or more electrodes).

[0139] Throughout the description and claims of this disclosure, the words “comprise”, “including”, “having” and “contain” and variations of the words, for example “comprising” and “comprises” or similar, mean “including but not limited to”, and are not intended to (and do not) exclude other components. Also, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true, “B is true”, or both “A” and “B” are true.

[0140] The use of any and all examples, or exemplary language (“for instance”, “such as”, “for example” and like language) provided herein, is intended merely to better illustrate the disclosure and does not indicate a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure. The terms “first” and “second” may be reversed without changing the scope of the invention. That is, an element termed a “first” element (e.g., a first device) may instead be termed a “second” element (e.g., a second device) and an element termed a “second” element (e.g., a second pair device) may instead be considered a “first” element (e.g. a first device).

[0141] Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed.

[0142] It is also to be understood that, for any given component or embodiment described herein, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. It will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise.

[0143] In this detailed description of the various embodiments, for the purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the embodiments disclosed. One skilled in the art will appreciate, however, that these various embodiments may be practiced with or without these specific details. Furthermore, one skilled in the art can readily appreciate that the specific sequences in which methods are presented and performed are illustrative and it is contemplated that the sequences can be varied and still remain within the scope of the various embodiments disclosed herein.

[0144] All literature and similar materials cited in this application, including but not limited to patents, patent applications, articles, books, treaties and internet web pages are expressly incorporated by reference in their entirety for any purpose. Unless otherwise described, all technical and scientific terms used herein have a meaning as is commonly understood by one of ordinary skill in the art to which the various embodiments described herein belongs.

Claims

Claims:1 . A method for securely assessing a device configuration comprising steps of: comparing configuration data of a device with a set of security configuration requirements for the device, the set of security configurations being retrieved based on the configuration data; determining, based on the comparison, whether each of the set of security configuration requirements is met and generating, in response to the determination, a result indicating whether the set of security configuration requirements is met; performing a validation check for the result and, if the result fails the validation check, preventing the result from being sent to an external device.

2. The method of claim 1 , wherein preventing the result from being sent comprises: storing the result in volatile memory and, upon failing the validation check, removing the result from the volatile memory; or preventing generation of an application programming interface, API.

3. The method of claim 1 or claim 2, wherein the validation check is failed if one or more of: the result, the set of security configuration requirements, and / or the configuration data differs from a respective expected result, set of security configuration requirements, and / or configuration data; the result, the set of security configuration requirements and / or the device definition have been modified; and a computer program comprising instructions that, when the computer program is executed by the device, cause the device to carry out the method of any preceding claim has been modified.

4. The method of any previous claim, further comprising, in response to passing the validation check, sending, via a communication channel, the result to the external device.

5. The method of claim 4, wherein the communication channel is a wireless communication channel.

6. The method of any previous claim, wherein the steps of generating a result indicating whether each of the set of security configuration requirements is met and performing the validation check are distinct steps.

7. The method of any previous claim, wherein the result is a single pass or fail result for the set of security configuration requirements, the result comprises a pass or fail result for each of the set of security configuration requirements or the result comprises a list of differences between a respective security configuration requirement of the set of security configuration requirements and the configuration data.

8. The method of any previous claim, wherein the steps of comparing the configuration data, determining whether the set of security configuration requirements is met, generating the result and performing the validation check are performed at the device and / or at a server.

9. The method of claim 8, wherein when the steps of comparing the configuration data, determining whether the set of security configuration requirements is met, generating the result and performing the validation check are performed at the device and, in response to passing the validation check, the method further comprises sending the result to the server and repeating the steps of comparing the configuration data, determining whether the set of security configuration requirements is met, generating the result and performing the validation check at the server.

10. The method of any previous claim, further comprising, in response to determining that one or more of the set of security configuration requirements is not met and in response to passing the validation check, adjusting configuration parameters of the device to meet the set of security configuration requirements.11 . The method of any previous claim, wherein the set of security configuration requirements is retrieved via an application programming interface, API, or from information stored on the device.

12. The method of any previous claim, wherein the configuration data comprises device information that indicates the set of security configuration requirements to retrieve.

13. The method of claim 12, wherein the device information indicates a type of device, an operating system of the device and / or hardware of the device.

14. The method of claim 13, wherein the type of device comprises a network device.

15. The method of claim 14, wherein the network device comprises a hub, firewall, load balancer, proxy, switch, concentrator, repeater, access point, modem and / or router.

16. The method of any of claims 13 to 15 when the device information indicates the type of device, wherein the device is configurable as one of two or more types of device and the device information further indicates a configuration of the device as the one of the two or more types of device, wherein the retrieved set of security configuration requirements corresponds to the one of the two or more types of device.

17. The method of any of claims 12 to 16, wherein retrieving the set of security configuration requirements comprises comparing the device information with a list of device definitions, wherein one or more of the device definitions in the list are associated with a respective set of security configuration requirements, to determine a set of security configuration requirements corresponding to the device information.

18. The method of claim 17, wherein comparing the device information with a list of device definitions comprises determining a device definition that is the same as or most similar to the device information.

19. The method of claim 17 or claim 18, wherein the validation check is failed if one or more of the device definitions in the list differ from a respective one or more device definitions in the list of expected device definitions and / or the list has been modified by an unauthorised user.

20. The method of any previous claim, further comprising applying a trained machine learning model to the configuration data and the set of security configuration requirements to compare the configuration data and determine whether each of the set of security configuration requirements is met.21 . The method of any previous claim, wherein the configuration data is obtained from a configuration file.

22. The method of any previous claim, wherein the external device comprises a server.

23. The method of claim 22, wherein the server is an application programming interface, API, server or a database server.

24. A computer program comprising instructions that, when implemented by a computer, cause the computer to perform the steps of any previous claim.

25. A computer-readable storage medium having stored thereon the computer program of claim 24.

Images