EP4690014A1

EP4690014A1 - Methods and apparatuses for determining a hardness metric representative of how difficult a decision tree model is to extract

Info

Publication number: EP4690014A1
Application number: EP23718078.1A
Authority: EP
Inventors: Michael Liljenstam; Jakob Sternby
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-04-05
Filing date: 2023-04-05
Publication date: 2026-02-11
Also published as: WO2024210777A1

Abstract

Embodiments described herein relate to methods and apparatuses for protecting against extraction of a first ML Model. A computer implemented method comprises receiving a query to utilize the first ML model; determining an alert level at least in part based on the query; comparing the alert level to a first detection threshold; and responsive to the alert level being greater than or equal to the first detection threshold, performing one or more protection actions in response to the query.

Description

METHODS AND APPARATUSES FOR DETERMINING A HARDNESS METRIC REPRESENTATIVE OF HOW DIFFICULT A DECISION TREE MODEL IS TO EXTRACT TECHNICAL FIELD Embodiments described herein relate to methods and apparatuses for determining a hardness metric representative of how difficult a decision tree model comprising a plurality of leaf nodes is to extract. Methods and apparatuses described herein also provide protection for ML models depending on how hard they are to extract. Further disclosed are a related risk assessment function, machine learning protection layer, computer program, and computer program product. BACKGROUND Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description. Machine Learning, ML, model stealing is a threat that can be motivated by: 1. A desire to steal the ML model to use it for its original purpose (inference serving) without having to make the investment in data acquisition, model training, etc. This amounts to theft of Intellectual Property (IP); or 2. As a stepping-stone towards launching other adversarial ML attacks against the system. It has been shown that evasion-, data inference-, and model inversion attacks against a blackbox system can be carried out more efficiently/easily by first replicating the ML model and crafting the attack against the replica. Thanks to transference properties, such attacks can work well also against the original target ML model. It will therefore be appreciated that it may be considered important to protect ML models from being stolen. ML model theft may be achieved either through traditional computer system attacks, such as access to software and/or parameter files, or even copying of parameter data from memory as the ML model inference is being executed. Many well-known techniques exist to address such threats, and more recent technology like confidential computing can also help to strengthen such protection. The latter is illustrated in Figure 1 which illustrates an ML model being held in a Trusted Execution Environment (TEE). In another type of attack, the adversary has or gets access to the inference API and issues queries to learn about the ML model. With a sufficient number of queries, the ML model may be replicated, either by finding the ML model parameters directly or by collecting training examples to train a new ML model. The issue of this type of attack has so far mainly been studied in the context of cloud inference APIs that are publicly exposed (see for example, F. Tramèr, F. Zhang, A. Juels, M. K. Reiter and T. Ristenpart, "Stealing machine learning models via prediction APIs," in 25th USENIX security symposium (USENIX Security 16), 2016). For scenarios where the ML model is deployed in a system with limited access, the risks are naturally reduced. But given that intrusions might occur, insider threats are possible, and someone may be able to bypass access controls, such threats cannot be ruled out. Existing approaches to dealing with the threat of model extraction largely fall into the following categories, referring to Figure 1: 1) During ML model training (or creation of the ML model) (e.g. stage 101) “model hardening” measures may be taken to try to make the ML model more difficult to extract. Examples include randomly perturbing the model responses in certain regions of the feature space to make it less “smooth”. Another approach that does not prevent extraction, but may help identifying a stolen model is to try to introduce a “watermark” in the model that can be detected in the replicated model (see for example, D. A. a. K. R. E. Quiring, "Forgotten Siblings: Unifying Attacks on Machine Learning and Digital Watermarking," in IEEE European Symposium on Security and Privacy (EuroS&P), 2018.) 2) Other proposals intercede at runtime, e.g. during stage 103 to, e.g., o Distorting responses by adding noise to make it more difficult for an adversary to use the responses to build a model. o Monitoring queries to detect if an extraction attack is going on and take action if that is the case. For example detection may comprise utilizing one or more of the following methods: ^ Extraction progress estimation (see for example, M. Kesarwani, B. Mukhoty, V. Arya and S. Mehta, "Model Extraction Warning in MLaaS Paradigm," in Proceedings of the 34th Annual Computer Security Applications Conference, New York, 2018) ^ Abnormal query pattern detection (see for example, Z. Zhang, Y. Chen and D. Wagner, "Seat: Similarity encoder by adversarial training for detecting model extraction attack queries," in Proceedings of the 14th ACM Workshop on Artificial Intelligence and Security, 2021) ^ Out-Of-Distribution, OOD, detection (see for example J. Yang, K. Zhou, Y. Li, Z. Liu “Generalized Out-of- Distribution Detection A Survey”, https://arxiv.org/abs/2110.11334, Oct.2021) In response to detecting an extraction attack, one of the following action may be performed: stopping responding to that user; or a more gradual response is provided by replacing the model by a surrogate model that may for example be adapted to what the adversary has already learned. Much, or even most, of the academic work on model extraction deals with Neural Network (NN)/Deep Learning (DL) models for image analysis or Natural Language Processing (NLP). It will be appreciated that while there are use cases for image analysis and NLP in telecoms, use cases dealing with tabular data collected from network nodes or business support systems dominates. SUMMARY Distorting model responses (aiming to confuse an adversary) also, by necessity, implies worsening the quality of the ML model responses for legitimate use. Consequently, it may not be beneficial to pursue this direction. Proposed extraction protection mechanisms that detect and react during runtime may need to be configured to a certain sensitivity. That is, detection will typically generate some signal indicating the likelihood of the presence of a threat, and a threshold needs to be set for when to invoke a response. Since a protective response following a false positive indication will generally have negative consequences, there is a tradeoff to be made when setting the threshold, but it is not evident what is a good setting. It is an object of the present disclosure to enable protection against the extraction of a machine learning model. According to some embodiments there is provided a computer-implemented method for determining a hardness metric representative of how difficult a decision tree, DT, model comprising a plurality of leaf nodes is to extract. The method comprises determining a first fraction of feature space associated with each leaf node in the DT model, wherein training samples were used to create the DT model; determining a second fraction of training samples captured by each leaf node in the DT model; and deriving the hardness metric from the first fraction and the second fraction. According to some embodiments there is provided a computer-implemented method for protecting against extraction of a first ML model. The method comprises receiving a query to utilize the first ML model; determining an alert level at least in part based on the query; comparing the alert level to a first detection threshold; and responsive to the alert level being greater than or equal to the first detection threshold, performing one or more protection actions in response to the query. According to some embodiments there is provided a risk assessment function for for determining a hardness metric representative of how difficult a decision tree, DT, model comprising a plurality of leaf nodes is to extract. The risk assessment function comprises processing circuitry configured to: determine a first fraction of feature space associated with each leaf node in the DT model, wherein the training samples were used to create the DT model; determine a second fraction of training samples captured by each leaf node in the DT model; and deriving the hardness metric from the first fraction and the second fraction. According to some embodiments there is provided a machine learning protection layer, MLPL, for protecting against extraction of a first ML model. The MLPL comprises processing circuitry configured to cause the MLPL to: receive a query to utilize the first ML model; determine an alert level at least in part based on the query; compare the alert level to a first detection threshold; and responsive to the alert level being greater than or equal to the first detection threshold, perform one or more protection actions in response to the query. Aspects and examples of the present disclosure thus provide methods and apparatuses for protecting against the extraction of ML models based on a representation of how hard a ML model would be to extract. For the purposes of the present disclosure, the term “ML model” encompasses within its scope the following concepts: Machine Learning algorithms, comprising processes or instructions through which data may be used in a training process to generate a model artefact for performing a given task, or for representing a real world process or system; the model artefact that is created by such a training process, and which comprises the computational architecture that performs the task; and the process performed by the model artefact in order to complete the task. References to “ML model”, “model”, model parameters”, “model information”, etc., may thus be understood as relating to any one or more of the above concepts encompassed within the scope of “ML model”. BRIEF DESCRIPTION OF THE DRAWINGS For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: Figure 1 illustrates an ML model being held in a Trusted Execution Environment (TEE) (0); Figure 2 illustrates a system for ML model training and deployment. The system comprises training data for use in training a ML model; Figure 3 illustrates a computer-implemented method for determining a hardness metric representative of how difficult a decision tree, DT, model comprising a plurality of leaf nodes is to extract; Figure 4 illustrates an example implementation of step 301 of Figure 3; Figure 5 illustrates an example DT model; Figure 6 illustrates an example implementation of step 302 of Figure 3; Figure 7 illustrates an example implementation of step 303 of Figure 3; Figure 8 illustrates two example results of a generated “hardness curve”; Figure 9 illustrates example results using this aforementioned hardness metric, which indicates that extracted model fidelity decreases corresponding to the increase in estimated extraction hardness metric; Figure 10 illustrates a computer-implemented method for protecting against extraction of a first ML model. Figure 11 illustrates an example for determining a first detection threshold to be used in the implementation of Figure 10; Figure 12 is a graph in which the hardness metric shows that a model classifying the attack type of the TON_IoT network dataset is a difficult model to extract; Figure 13 is a graph illustrated the progress of a random query attack against a simplified model for a public data set referred to as TON_IoT attack classification (see Description_stats_Network_dataset - Files - CloudStor (aarnet.edu.au)) with a hardness metric of 0.68; Figure 14 illustrates the progress of the random query extraction after automatic protection is performed which implements a surrogate model after a certain detected extraction progress; Figure 15 illustrates progression of an adversary running a random query-based extraction against the DT model in BSS; Figure 16 illustrates that by adding a detection mechanism that estimates how much of the model has been extracted and using the first detection threshold of d=0.83, the information leakage shown in Figure 15 is reduced; Figure 17 illustrates a single decision tree formed by connecting copies of estimators together; Figure 18 illustrates an example in which a machine learning protection layer (MLPL) is implemented in a Network data analytics function (NWDAF); Figure 19 illustrates an example in which a MLPL is implemented in a Business Support System (BSS); Figure 20 illustrates an example in which a MLPL is implemented in a base station; Figure 21 illustrates an example in which an MLPL is implemented in a Service Management and Orchestration node, SMO. Figure 22 illustrates a risk assessment function comprising processing circuitry; Figure 23 is a block diagram illustrating a risk assessment function according to some embodiments; Figure 24 illustrates an MLPL comprising processing circuitry; Figure 25 is a block diagram illustrating an MLPL according to some embodiments. DESCRIPTION Certain aspects of the present disclosure and their embodiments may provide solutions to, or at least mitigate, challenges discussed herein. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Particular embodiments are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Embodiments described herein relate to methods and embodiments for determining a hardness metric representative of how easy or difficult it is likely to be for an adversary to replicate an ML model. A protection mechanism may then be deployed with the ML model to which is dependent on the hardness metric. The embodiments described herein improve a tradeoff between risk of loss and risk of negative impact from false positive action by adapting the protection to the hardness metric for a specific model. The embodiments described herein are more time and resource efficient than a naïve approach of simulating many different attacks. Figure 2 illustrates a system for ML model training and deployment. The system comprises training data 200 for use in training a ML model 201. The training data 200 may comprise a plurality of training samples that are utilised to create a trained ML model 201. risk assessment of the ML model 201 may then be performed in a risk assessment function 202. The risk assessment function 202 may determine a hardness metric ℎ. The hardness metric ℎ may then be output to a user or owner of the ML Model 201. The hardness metric ℎ may also be utilised in a model protection layer, MLPL, 203 in a deployment phase of the ML model 201. In other words, the risk assessment function 202 may both output information to the ML model owner and directly configure the MLPL 203. In terms of implementation, the MLPL 203 and the risk assessment function 202 may be located together or separately. The output of the hardness metric ℎ to the model owner may, for example, be used by the ML model owner to decide that the risk is too high for a high value model in the particular scenario and choose not to deploy it or to limit distribution of access credentials. The function of the model extraction risk assessment function 202 will be described in more detail with reference to Figures 3 to 9. In the deployment phase, the ML model 201 may be deployed with the MLPL 203. A client or user 204 may access the ML model via an API 205. The user’s queries may be passed through the MLPL 203 before being input into the ML model 201. The function of the MLPL 203 will be described in more detail with reference to Figures 10 and 11. Figure 3 illustrates a computer-implemented method for determining a hardness metric representative of how difficult a decision tree, DT, model comprising a plurality of leaf nodes is to extract. The method 300 may be performed by a network node, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. The method 300 may be performed by a risk assessment function 202 as illustrated in Figure 2. The method of Figure 3 may be considered to estimate how hard it is to extract a Decision Tree model using random queries. Given the Decision Tree model, the hardness metric may be computed. The method of Figure 3 may be considered to comprise a depth first-traversal of the tree with computations of subspaces and fractions of training samples captured by different nodes in the DT model. The results from the traversal may be stored for each node in the DT model, and those results may be used to generate a curve. It will be appreciated that the DT model may represent an ensemble of DT models. In some cases, the DT model may represent one or more other types of ML model. For example, the DT model may be generated to represent a neural network. In these examples, the hardness metric for the DT model may be considered a representation of how hard the neural network is to extract using random queries. In step 301 the method comprises determining a first fraction of feature space associated with each leaf node in the DT model, wherein the training samples were used to create the DT model. During the training of a DT model, all training samples are considered at the root node and divided into subsets according to some comparison criteria resulting in a decision function for the root node. For each new child node created from a parent node, continuing from the root downwards, a subset of the training samples in the parent node are considered when using the comparison criteria on the subset to create a decision function for the child node. It will be appreciated that in the DT model a feature may be used to influence a decision between two child nodes of the parent node. A feature comprises values pertaining to the properties of the problem solved by the DT model. A DT model used to solve a problem based on network data, for example, may therefore utilize features that are derived from network data properties such as number of packets sent between a source and a destination, a number of inbound/outbound bytes transmitted in a connection, etc. Step 301 may be implemented as described with reference to Figure 4. Figure 5 illustrates a part of a simple example DT model which will be used to describe the methods of Figures 4 and 5. The DT model comprises a root node 500 and other nodes 501 to 504. In particular is will be appreciated that the nodes 503, 504 and 502 comprise leaf nodes (e.g. node that have no child nodes). It will be appreciated that leaf nodes are a type of child node. Node 501 is a child node (to node 500), but it is node a leaf node as it is also a parent node to nodes 503 and 504. Referring to Figure 4, in step 401 the method starts at the root node (e.g. node 500) In step 402, the method comprises determining a local space fraction for each child node of the parent node as a fraction of a range of the feature associated with the child nodes. This local space fraction is determined during training of the DT model. If feature A is utilized to make the decision between 501 and 502 from the root node 500, then if the 60% of the possible range of feature A results in the selection of node 501, then the local space fraction for node 501 is 0.6. The local space fraction for node 502 is 0.4. In step 403 the method comprises determining a first fraction of feature space for each child node as the local space fraction for each child node multiplied by a first fraction of feature space for the parent node. The first fraction of feature space for the root node may be initialized as 1. The first fraction of feature space for the node 501 may therefore be 0.6 x 1 = 0.6. The first fraction of feature space for the node 502 may then be 0.4 x 1 = 0.4. The method may pass to step 404 in which a next parent node is selected. It will be appreciated that a next parent node is selected for which the first fraction of feature space has been previously determined. In the example of Figure 5, the next parent node may be the node 501. After selection of a next parent node the steps 402 and 403 are repeated for the next parent node. In the next iteration of step 402, the if feature B is utilized to make the decision between 503 and 504 from the node 501, then if 55% of the of the possible range of feature B results in the selection of node 503, then the local space fraction for node 503 is 0.55. The local space fraction for node 504 is 0.45. In the next iteration of step 403 the first fraction of feature space for the node 503 may be determined as 0.6 x 0.55 = 0.33. The first fraction of feature space for the node 504 may be determined as: 0.6 x 0.45 = 0.27. It will be appreciated that the steps 402 to 404 may be repeated for every parent node in the DT, thereby determining a first fraction of feature space for each leaf node in the DT. In this example, the leaf nodes are the nodes 502, 503 and 504 that have the first fractions of feature space of 0.4, 0.33 and 0.27 respectively. It will be appreciated that the local space fractions and first fractions of feature space may instead be expressed as percentages. Returning to Figure 3, in step 302 the method comprises determining a second fraction of training samples captured by each leaf node in the DT model. Step 301 may be implemented as described with reference to Figure 6. In step 601 the method starts at the root node (e.g. node 500) In step 602, the method comprises determining a local sample fraction for each child node of the parent node as a number of training samples captured by the child node divided by a number of training samples captured by the parent node. For example, returning to the example DT model of Figure 5, if 1000 training samples were used to create the DT model then the number of training samples that passed through the root node is 1000. Consider an example where 550 training samples then passed through the node 501 and 450 training samples passed through the node 502. In this example, the local sample fraction for node 501 is 550/1000 = 0.55 The local sample fraction for node 502 is 450/1000 = 0.45. In step 603, the method then comprises determining a second fraction of training samples for each child node as the local sample fraction for each child node multiplied by a second fraction of training samples for the parent node. It will be appreciated that the second fraction of training samples for the root node may be set as 1. For examples, returning to the example DT model of Figure 5, the second fraction of training samples for the node 501 is 0.55 x 1 = 0.55 The second fraction of training samples for the node 502 is 0.45 x 1 = 0.45. The method then passes to step 604 in which a next parent node in the DT model is selected. It will be appreciated that the next parent node is selected for which the second fraction of training samples has been previously determined. In the example of Figure 5 node 501 may be selected as the next parent node. After selection of a next parent node the steps 602 and 603 are repeated for the next parent node. In the next iteration of step 602 the local sample fractions for the nodes 503 and 504 are calculated. Assume that of the 550 training samples than passed through the node 501, 300 passed through node 503 and 250 passed through node 502. The local sample fraction for node 503 is then 300/550 ~ 0.54 (2 significant figures) The local sample fraction for node 504 is then 250/550 ~ 0.45 (2 significant figures) In step 603 the second fractions of training samples for the node 503 is calculated as: 0.54 x 0.55 = 0.297 The second fraction of training samples for the node 504 is calculated as: 0.45 x 0.55 = 0.2497 It will be appreciated that the steps 602 to 604 may be repeated for every parent node in the DT model, thereby determining a second fraction of training samples for each leaf node in the DT model. In this example, the leaf nodes are the nodes 502, 503 and 504 that have the second fractions of training samples of 0.45, 0.297 and 0.2497 respectively. It will be appreciated that the local sample fractions and second fractions of training samples may instead be expressed as percentages. Returning to Figure 3, in step 303 the method comprises deriving the hardness metric from the first fraction and the second fraction. It will be appreciated that leaf nodes associated with higher values of first fraction of feature space may be considered easier to extract than leaf nodes with a lower value of first fraction of feature space. It will also be appreciated that the more samples that pass through the leaf node the greater the accuracy of the extraction of that node may be. An example of how the first fraction and the second fraction may be used to derive the hardness metric is given in Figure 7, however there may be other examples of how the hardness metric may be derived. It will be appreciated that other heuristics may be utilized to derive the hardness metric from the first fraction and the second fraction. Figure 7 illustrates an example implementation of step 303 of Figure 3. In step 701 the method comprises initializing an accumulated subspace parameter. For example, the accumulated subspace parameter may be initialized as: parameter; accumulated_subspace = 0. In step 702, the method comprises initializing an accumulated sample fraction parameter. For example, the accumulated sample fraction parameter may be initialized as: accumulated_sample_fraction = 0. In step 703, the method may comprise sorting the plurality of leaf nodes in the DT model by decreasing associated first fractions of feature space values. For example, referring to the example DT model in Figure 5, the leaf nodes may be listed as: list_leaf_nodes: {node 502, node 503, node 504}. Step 704 may comprise taking a first leaf node from the sorted plurality of leaf nodes. The first leaf node may be the leaf node with the highest first fraction of feature space value, first_fraction, in the list. In the example of Figure 5, this is node 502 with a first_fraction value of 0.4. After the first leaf node is selected it may be removed from the list of leaf nodes. For example, list_leaf_nodes: {node 503, node 504} In step 705, the method comprises updating the accumulated subspace parameter by adding the first fraction of feature space of the first leaf node to the accumulated subspace parameter. In other words, accumulated_subspace = accumulated_subspace + first_fraction. In the example of Figure 5 therefore accumulated_subspace = 0 + 0.4 = 0.4. In step 706, the method comprises updating the accumulated sample fraction parameter by adding the second fraction, second_fraction, of training samples captured by the first leaf node to the accumulated sample fraction parameter. In other words, accumulated_sample_fraction = accumulated_sample_fraction + second_fraction In step 707, the method then comprises setting accumulated subspace parameter by accumulated sample fraction parameter as a curve pair in a set of curve pairs. The method then passes to step 708 in which it is determined whether or not there are any elements remaining in the list of leaf nodes list_leaf_nodes. If elements are remaining, the method passes back to step 704. If not, the method ends in step 709. It will therefore be appreciated that steps 704 to 707 may then be repeated for all leaf nodes in the DT model. Once curve pairs are determined for each leaf node in the DT model, the method may then comprise determining a curve defined by the set of curve pairs. The method may also comprise determining an area under the curve, HAUC; wherein the hardness metric comprises a first hardness, h_s, equal to 1 minus the area under the curve h_s = 1 - HAUC. The pseudocode show in italic text below is an example of how the methods of Figures 3, 4, 6 and 7 may be implemented. root_feature_space_fraction <- 1.0 root_sample_fraction <- 1.0 NodeQ <- empty NodeQ.append(root_node) WHILE NodeQ not empty DO n <- NodeQ.removeFirst() IF n is not a leaf THEN NodeQ.append(n.leftChild()) NodeQ.append(n.rightChild()) FOREACH child of n DO COMPUTE_FRACTION_OF_SPACE(child) COMPUTE_FRACTION_OF_SAMPLES(child) DONE ENDIF subspace_hardness <- (1 - COMPUTE_HAUC(all nodes)) # compute fraction of feature space covered by node PROCEDURE COMPUTE_FRACTION_OF_SPACE(child) local_space_fraction <- fraction of child.feature range on this side of threshold child.space_fraction <- child.parent.space_fraction * local_space_fracton # compute fraction of training samples in node PROCEDURE COMPUTE_FRACTION_OF_SAMPLES(child) Local_sample_fraction <- samples in child / samples in child.parent() chile.sample_fraction <- child.parent.sample_fraction * local_sample_fraction # compute HAUC FUNCTION COMPUTE_HAUC(nodes) leaves <- FILTER leaves FROM nodes SORT leaves BY decreasing space fraction curve_pairs <- empty curve starts at 0,0 accumulated_subspace <- 0 accumulated_sample_frac <- 0 FOR all leaves l DO accumulated_subspace += l.space_fraction accumulated_sample_fraction += l.sample_fraction curve_pairs.append(CurvePair(x = accumulated_subspace, y = accumulated_sample_frac)) DONE hauc <- area under curve defined by curve_pairs RETURN hauc \\ Figure 8 illustrates two example results of a generated “hardness curve”. These curves may have been generated as described with reference to Figures 3 to 8. It will be appreciated that the accumulated_subspace parameter is effectively used as an estimate of an “Extraction Effort”, and the accumulated_sample_fraction parameter is effectively used to estimate the “Expected Approximate Accuracy” achieved by extracting that leaf node. As previously described ^^^^ is the area under this curve. The first hardness ℎ_^ (also referred to as “subspace hardness”), comprises an estimate of the difficulty to extract the model (using random queries), computed as ℎ_^ = 1 − ^^^^. In the examples of Figure 8, the data set “iris” results in a model with low complexity that is quite easy to extract. Consequently, as shown in the figure, the dashed line for data set “iris” shows a large area under the curve. Conversely, the “bank-marketing” data results in a model with high complexity and data points in subspace regions that are difficult to find by random guessing, so the solid line is low until a large effort has been expended and it has a very low area under the curve. In some examples, the hardness metric further comprises a number of features, f, used to perform decisions in the DT model. The number of features may be weighted in the hardness metric by a first weighting, w1. In some examples, the hardness metric further comprises a number of nodes, n, in the decision tree model. The number of nodes, n, may by weighted in the hardness metric by a second weighting, w2. It will be appreciated that the first hardness may be weighted in the hardness metric by a third weighting, w3. In other words, the hardness metric, ℎ, may be determined as: ℎ = ^_^^ + ^_^^ + ^_^ℎ_^ The weights ^_^ may be determined empirically by linear regression on experiments from multiple data sets. Figure 9 illustrates example results using this aforementioned hardness metric, which indicates that extracted model fidelity decreases corresponding to the increase in estimated extraction hardness metric. If one chooses not to include the additional factors and empirical weights, the hardness metric may be set to the first hardness, e.g. ℎ = ℎ_^. Figure 10 illustrates a computer-implemented method for protecting against extraction of a first ML model. The method 1000 may be performed by a network node, which may comprise a physical or virtual node, and may be implemented in a computing device or server apparatus and/or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. The method 300 may be performed by a MLPL 203 as illustrated in Figure 2. In step 1001, the method comprises receiving a query to utilize the first ML model. The query may be received from a client component (or a user) as illustrated in Figure 2. In step 1002, the method comprises determining an alert level at least in part based on the query. It will be appreciated that the alert level may be based on previous queries received in relation to the first ML model. In other words, there may be a “state” of extraction, either for a particular user or in total (for all users). The alert level may be determined utilizing one or more of the following extraction detection methods: extraction progress estimation, Out-of-Distribution queries, and adaptive query detection. In particular, these methods may be used in a weighted combination wherein the weighting values (e.g. ^, ^, ^) are determined based on a hardness metric associated with the first ML model. For example, the alert level may comprise a linear combination ^ = ^ ∙ ^ + ^ ∙ ^ + ^ ∙ ^ _where ^ ∈ [0,1] is an estimated extraction progress, ^ ∈ [0,1] is a fraction of Out-of- Distribution queries, ^ ∈ [0,1] is a degree of risk estimated by an adaptive query detection method, and ^, ^, ^ are tunable weights. In other examples, the alert level is equal to zero when p, where ^ ∈ [0,1] is an estimated extraction progress, is less than or equal to t, where t is a tolerance threshold. ^ may be chosen according to risk tolerance (e.g., ^ = 0.5) Determining the alert level in this manner avoids alerting early in the process when there is high uncertainty in the estimates. In other words, triggering a response to the alert level is avoided as long as the extraction progress is low, and the extraction progress may effectively be used as a threshold before considering the other factors. For example, the alert level may be calculated as: ^ = 1_^^^(^) ∙ ((^ ∙ ^) ∙ (^ ∙ ^) + ^ ∙ ^), where 1_^^^(^ ) is an indicator function equal to zero when p is ≤ t and 1 when p is > t, ^ ∈ [0,1] is an estimated extraction progress, ^ ∈ [0,1] is a fraction of Out-of-Distribution queries, ^ ∈ ^[0,1^] is a degree of risk estimated by an adaptive query detection method, and ^, ^, ^ are tunable weights. It will be appreciated that the alert level, φ, may be normalized to [0,1] to match other steps of the method. The tunable weights (e.g. as described with reference to Figure 11) may be set as “high”, “low” and “medium”. These ranges of value for the tunable weights may be thought of in comparison to an example in which ^ = ^ = ^. In some examples, (for simplicity) φ ∈[0,1], which can be easily done (given previous description of p, d ,a) by choosing ^, ^, and ^ such that ^ + ^ + ^ = 1. That is for equality, ^ = ^ = ^ = In these examples therefore, high” means 1/3 < tunable weight < 1, and low means 0 < tunable weight <1/3, and “medium” means 1/9 < tunable weight < 2/3. In step 1003, the method comprises comparing the alert level to a first detection threshold. The first detection threshold is derived from a hardness metric, and wherein the hardness metric, h, may be determined according to the methods as described above with reference to Figures 3 to 9. The first detection threshold ^, may be selected such that that ^ ≥ ^ triggers a mitigating action (see step 1004). A lower hardness threshold ^_^ determines when models that are easy to extract, and a higher hardness threshold ^_^ when models are hard to extract. Empirically, example values may be ^_^ ≈ 0.5 and ^_^ ≈ 0.95. The lower hardness threshold ^_^ and higher hardness threshold ^_^ may be set by a system owner. Depending on an assessment of model value and risk factors in the particular deployment/scenario (such as how easily accessible the inference API is to a potential adversary), the system owner may two extraction detection thresholds. A low detection threshold ^_^, for high sensitivity, and a high threshold ^_^, for low sensitivity. Reasonable configurations for ^_^ and ^_^ may be 40% and 95%, respectively. Figure 11 illustrates an example of determining a first detection threshold for use in the method of Figure 10. In step 1101, the method comprises determining a hardness metric for the DT model. The hardness metric may be determined as described with reference to Figures 3 to 9. In step 1102, the method comprises determining whether the hardness metric is less than a low hardness threshold, HL. Responsive to the hardness metric, h, being less than the low hardness threshold, HL, the method passes to step 1103 in which the first detection threshold is set to a low detection threshold, DL. In this case, random extraction of the DT model is easy and poses the main threat. Overall, protection of the DT model will be difficult. But detection methods using extraction progress estimation, supported by OOD detection, can offer some protection. In this example, a reasonable option for the alert level φ is to set the tunable weights as follows ^ high (e.g. > 1/3), ^ high (e.g. > 1/3), and ^ low (e.g. < 1/3). Responsive to the hardness metric, h, being greater than or equal to the low hardness threshold, H_L, the method passes to step 1104 in which it is determined whether the hardness metric, h, is greater than a high hardness threshold, HH. Responsive to the hardness metric, h, being greater than a high hardness threshold, H_H the method passes to step 1105 in which the first detection threshold is set to a high detection threshold, D_H. In this scenario, random extraction is hard and will take time. Therefore, direct extraction of adaptive methods is the main threat in this scenario. Detection using OOD and specialized techniques to detect adaptive queries may therefore be preferred. Therefore, a reasonable option for the alert level φ is to select the tunable parameters such that ^.is low (e.g. < 1/3), ^ is medium (e.g.1/9 < β < 2/3), and ^ high (e.g. > 1/3). If in step 1104 it is determined that the hardness metric h, is less than or equal to the high hardness threshold, HH, the method passes to step 1106 in which the first detection threshold is set proportional to the hardness metric. In other words, the first detection threshold, D may be determined as: In this scenario, a combination of extraction progress estimation, OOD, and adaptive query detection may be preferred. In this scenario, a reasonable option is the alert level ^ is to select equal values for the tunable parameters ^ = ^ = ^. Alternatively, the parameters ^ ^ and ^ may all fall within a predetermined range (e.g. approximately 1/3) In step 1004, the method comprises responsive to the alert level being greater than or equal to the first detection threshold, performing one or more protection actions in response to the query. The one or more protection actions may comprise one or more of: stopping responding to a user that sent the query, replacing the model responding to the query by a surrogate model, alerting the model owner of a possible extraction attack. In the case of a “surrogate model”, the idea is to continue to provide query responses (avoid disruption) while at the same time stopping leakage of model information. To that end, a “surrogate model” is trained using only query previous input vectors and responses for the client/user. It will therefore be appreciated, that, in practice, a combination of extraction progress estimation, OOD, and adaptive query detection may be used in all regimes, but the tunable weights may be changed per detection method to shift the focus according to what constitutes the main risk (as described above). Figure 12 illustrates an example, in which the hardness metric shows that a model classifying the attack type of the TON_IoT network dataset is a difficult model to extract (hardness metric = 0.99), and this is also verified by an example random query attack. In particular, Figure 12 illustrates the progress of a random query attack against a decision tree classifying IoT network attack traffic which has high hardness (0.9998) according to the proposed estimation method. The high hardness metric for this set will cause a high detection threshold meaning that the model may not need protection. In order to show a case where the tool will recommend protection a simpler DT model was created by simplifying the classification task: only the three features ‘src_pkts’ – a number of original packets which is estimated from source systems, ‘src_ip_bytes’ – a number of original IP bytes which is the total length of IP header field of source systems, ‘dst_pkts’ – a number of destination packets which is estimated from destination systems and three attack classes ‘xss’, ‘injection’, ‘scanning’, were kept which generated a model with hardness metric of 0.68. This is a relatively easy model to extract and it may be extracted by a persistent adversary as illustrated in 13. Figure 13 illustrates an example of the progress of a random query attack against a simplified model for TON_IoT attack classification with a hardness metric of 0.68. As can be seen from Figure 13, The adversary manages to get almost perfect fidelity with the target model after 550 queries. To protect a model that is relatively easy to extract like the simplified TON_IoT attack classification model previously described (hardness 0.68 with extraction progress shown in Figure 9) the proposed tool may activate a detection protection with moderately low detection threshold (0.4). Figure 14 illustrates the progress of the random query extraction after automatic protection is performed which implements a surrogate model after a certain detected extraction progress. Figure 14 therefore shows that the random query progress extraction of the DT model is much reduced (compared to Figure 13) when the protection is configured. For a second example, consider the use of ML in Business Support Systems (BSS), e.g., in predicting customer churn. Using a customer churn prediction data set consisting of 19 features (such as account length, area code, usage characteristics, and what plan features the subscription has) using 2828 records for training, the extraction hardness (without empirical fit) was estimated at 0.87. Using the method in Figure 11 with parameters of ^_^ = 0.5, ^_^ = 0.95 (as described earlier) and setting ^_^ = 0.5 and ^_^ = 0.9 the first detection threshold ^ = 0.83. ^_^ was chosen as a reasonable lower bound on detection, and ^_^ was chosen to reflect the maximum tolerated knowledge extracted from the model at roughly 90%. As a baseline for comparison, Figure 15 illustrates progression of an adversary running a random query-based extraction against the DT model in BSS. The adversary fidelity curve shows the fraction of answers from the adversary’s replica model that agree with the original model as the attack progresses. The figure shows how the adversary can achieve about 80% agreement after about 10000 attack queries and after that the agreement continues to improve more slowly. Figure 16 then illustrates that by adding a detection mechanism that estimates how much of the model has been extracted (similar to M. Kesarwani, B. Mukhoty, V. Arya and S. Mehta, "Model Extraction Warning in MLaaS Paradigm," in Proceedings of the 34th Annual Computer Security Applications Conference, New York, 2018 ) and using the first detection threshold of ^ = 0.83 the information leakage is reduced. Here, the protection was triggered when estimated fidelity ≥ ^ and the adversary’s model stops improving beyond about 70% fidelity. It will be appreciated that the hardness estimation methods described with reference to Figures 3 to 9 may be extended to produce a hardness metric for Gradient Boosted Decision Tree model, i.e., a type of ensemble of decision tree models, as follows. A Gradient Boosting ensemble comprises of “estimator” decision trees, where each tree provides a refinement on the tree preceding it in the ensemble. In other words, Tree 1 (T1) provides a first estimate. Tree 2 provides a refinement to T1, and so on. Thus, in principle, a single decision tree may be formed by connecting copies of estimators together, as illustrated in Figure 17. Copies of T2 replace each one of the leaves (L1) of T1, so that the root R2 of T2 becomes the leaf L1. The next estimator in the ensemble T3, is similarly attached to each leaf L2 in each copy of T2, and so on. As can be seen, for large numbers of estimators this method of combining DT models quickly leads to a combinatorial explosion in the size of the single combined tree. This is why the ensemble is a powerful model. However, for the purposes of determining the hardness metric, the hardness metric may be approximated by bounding the number of estimators we include in the calculation. A first example embodiment for a 5G mobile communication system is shown in Figure 18 below. In this example, the embodiments described herein may be used to determine and configure extraction protection for an ML model 1803 deployed in a Network Data Analytics Function (NWDAF) 1800 in the 5GC (which uses the Service Based Architecture (SBA)). During ML model development, following ML model training, the described method may be used to test the ML model 1803 to determine a hardness metric. As the NWDAF 1800 is packaged for deployment, e.g., as a container image, the ML model may be inserted together with a MLPL 1801 that may configured with a first detection threshold using the described method. In one embodiment, the configuration amounts to setting an appropriate attack detection sensitivity level according to how vulnerable the ML model 1803 is. The NWDAF 1800 is then deployed in the 5GC (e.g., as a cloud container). As the mobile system operates, it may be assumed that an arbitrary other Network Function (NF) 1802 access the NWDAF 1800 for model predictions through query/response exchanges. Queries received by NWDAF 1800 are inspected by the MLPL 1801, and a protection action may be triggered. It will be appreciated that the MLPL 1801 may be configured to perform the method as claimed with reference to Figure 10. Figure 19 illustrates an example in which an MLPL 1900 is implemented in a Business Support System, BSS, 1901. The BSS 1901 may receive queries for the ML model 1902, for example, from a core network 1902. The BSS 1901 may collect information from the core network node, and the information may be used to make query/responses to the ML model 1902. Queries to be sent to the ML model 1902may be inspected by the MLPL 1900, and a protection action may be triggered. It will be appreciated that the MLPL 1900 may be configured to perform the method as claimed with reference to Figure 10. Figure 20 illustrates an example in which an MLPL 2000 is implemented in a base station 2001. The base station 2001 may obtain queries for the ML model 2002 for example from a user equipment. The user equipment may access the base station 2001 for model predictions through query/response exchanges. Queries received by base station 2001 are inspected by the MLPL 2000, and a protection action may be triggered. In some examples, the queries may be obtained from other components within the base station, based on information about the UE activity and other things like radio environment and traffic load pattern. In the case of Cloud-RAN, it may be possible that the ML-model 2002 is conceptually outside the gNB components, with inference queries made from gNB components to some component holding the ML-model 2002. It will be appreciated that the MLPL 2000 may be configured to perform the method as claimed with reference to Figure 10. Figure 21 illustrates an example in which an MLPL 2100 is implemented in a SMO 2101. The SMO 2101 may receive queries for the ML model 2102 for example from rApps. The SMO 2101 may implement the ML model 2102 to support rApps running in the Non- Real Time RIC. Thus, queries for the ML model 2102 may come from rApps over the R1 interface. The rApp may access the SMO 2101 for model predictions through query/response exchanges. Queries received by SMO 2101 are inspected by the MLPL 2100, and a protection action may be triggered. Figure 22 illustrates a risk assessment function 2200 comprising processing circuitry (or logic) 2201. The processing circuitry 2201 controls the operation of the risk assessment function 2200 and can implement the method described herein in relation to an risk assessment function 2200. The processing circuitry 2201 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the risk assessment function 2200 in the manner described herein. In particular implementations, the processing circuitry 2201 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the risk assessment function 2200. It will be appreciated that the risk assessment function 2200 may comprise one or more virtual machines running different software and/or processes. The risk assessment function 2200 may therefore comprise, or be implemented in or as one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes. Briefly, the processing circuitry 2201 of the risk assessment function 2200 is configured to determine a first fraction of feature space associated with each leaf node in the DT model, wherein the training samples were used to create the DT model; determine a second fraction of training samples captured by each leaf node in the DT model; and derive the hardness metric from the first fraction and the second fraction. In some embodiments, the risk assessment function 2200 may optionally comprise a communications interface 2202. The communications interface 2202 of the risk assessment function 2200 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 2202 of the risk assessment function 2200 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 2201 of risk assessment function 2200 may be configured to control the communications interface 2202 of the risk assessment function 2200 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 2202 can use any suitable communication technology. Optionally, the risk assessment function 2200 may comprise a memory 2203. In some embodiments, the memory 2203 of the risk assessment function 2200 can be configured to store program code that can be executed by the processing circuitry 2201 of the risk assessment function 2200 to perform the method described herein in relation to the risk assessment function 2200. Alternatively or in addition, the memory 2203 of the risk assessment function 2200, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 2201 of the risk assessment function 2200 may be configured to control the memory 2203 of the risk assessment function 2200 to store any requests, resources, information, data, signals, or similar that are described herein. The risk assessment function 2200 may be configured operate in the manner described herein in respect of an risk assessment function. Figure 23 is a block diagram illustrating a risk assessment function 2300 according to some embodiments. The risk assessment function 2300 comprises a first determining module 2302 configured to determine a first fraction of feature space associated with each leaf node in the DT model, wherein the training samples were used to create the DT model. The risk assessment function 2300 comprises a second determining module 2304 configured to determine a second fraction of training samples captured by each leaf node in the DT model. The risk assessment function 2300 further comprises a deriving module 2306 configured to derive the hardness metric from the first fraction and the second fraction. The risk assessment function 2300 may operate in the manner described herein in respect of an risk assessment function. Figure 24 illustrates an MLPL 2400 comprising processing circuitry (or logic) 2401. The processing circuitry 2401 controls the operation of the MLPL 2400 and can implement the method described herein in relation to an MLPL 2400. The processing circuitry 2401 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the MLPL 2400 in the manner described herein. In particular implementations, the processing circuitry 2401 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the MLPL 2400. It will be appreciated that the MLPL 2400 may comprise one or more virtual machines running different software and/or processes. The MLPL 2400 may therefore comprise, or be implemented in or as one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes. Briefly, the processing circuitry 2401 of the MLPL 2400 is configured to receive a query to utilize the first ML model; determine an alert level at least in part based on the query; compare the alert level to a first detection threshold; and responsive to the alert level being greater than or equal to the first detection threshold, perform one or more protection actions in response to the query. In some embodiments, the MLPL 2400 may optionally comprise a communications interface 2402. The communications interface 2402 of the MLPL 2400 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 2402 of the MLPL 2400 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 2401 of MLPL 2400 may be configured to control the communications interface 2402 of the MLPL 2400 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The communications interface 2402 can use any suitable communication technology. Optionally, the MLPL 2400 may comprise a memory 2403. In some embodiments, the memory 2403 of the MLPL 2400 can be configured to store program code that can be executed by the processing circuitry 2401 of the MLPL 2400 to perform the method described herein in relation to the MLPL 2400. Alternatively or in addition, the memory 2403 of the MLPL 2400, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 2401 of the MLPL 2400 may be configured to control the memory 2403 of the MLPL 2400 to store any requests, resources, information, data, signals, or similar that are described herein. The MLPL 2400 may be configured operate in the manner described herein in respect of an MLPL. Figure 25 is a block diagram illustrating a MLPL 2500 according to some embodiments. The MLPL 2500 comprises a receiving module 2502 configured to receive a query to utilize the first ML model. The MLPL 2500 comprises a determining module 2504 configured to determine an alert level at least in part based on the query. The MLPL 2500 comprises a comparing module 2506 configured to compare the alert level to a first detection threshold. The MLPL 2500 comprises a performing module 2508 configured to responsive to the alert level being greater than or equal to the first detection threshold, perform one or more protection actions in response to the query. The MLPL 2500 may operate in the manner described herein in respect of an MLPL. There is also provided a computer program comprising instructions which, when executed by processing circuitry (such as the processing circuitry 2201 of the risk assessment function 2200 or processing circuitry 2401 of the MLPL described earlier), cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product, embodied on a non-transitory machine- readable medium, comprising instructions which are executable by processing circuitry to cause the processing circuitry to perform at least part of the method described herein. There is provided a computer program product comprising a carrier containing instructions for causing processing circuitry to perform at least part of the method described herein. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable storage medium. The herein disclosed embodiments or examples are provided for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as to not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS 1. A computer-implemented method for determining a hardness metric representative of how difficult a decision tree, DT, model comprising a plurality of leaf nodes is to extract, the method comprising: determining (301) a first fraction of feature space associated with each leaf node in the DT model, wherein training samples were used to create the DT model; determining (302) a second fraction of training samples captured by each leaf node in the DT model; and deriving (303) the hardness metric from the first fraction and the second fraction.

2. The method as claimed in claim 1 wherein a feature is used to influence a decision between two child nodes of a parent node, and wherein the step of determining the first fraction of feature space associated with each leaf node comprises: for each parent node in the DT model starting from a root node: determining (402) a local space fraction for each child node as a fraction of a range of the feature associated with the child node; determining (403) a first fraction of feature space for each child node as the local space fraction for each child node multiplied by a first fraction of feature space for the parent node, wherein for each child node that is a leaf node, the first fraction of feature space for the child node comprises a first fraction of feature space for a leaf node.

3. The method as claimed in claim 2 wherein the first fraction of feature space for the root node is 1.

4. The method as claimed in any one of claims 1 or 3 wherein the step of determining the second fraction of training samples captured by each leaf node in the DT model comprises: for each parent node in the DT model starting from a root node: determining (602) a local sample fraction for each child node of the parent node as a number of training samples captured by the child node divided by a number of training samples captured by the parent node; and determining (603) a second fraction of training samples for each child node as the local sample fraction for each child node multiplied by a second fraction of training samples for the parent node, wherein for each child node that is a leaf node, the second fraction of feature space for the child node comprises a second fraction of feature space for a leaf node.

5. The method as claimed in claim 4 wherein the second fraction of training samples for the root node is 1.

6. The method as claimed in any one of claims 1 to 5 wherein the step of deriving the hardness metric comprises: initializing (701) an accumulated subspace parameter; initializing (702) an accumulated sample fraction parameter; sorting (703) the plurality of leaf nodes by decreasing associated first fractions of feature space values; taking (704) a first leaf node from the sorted plurality of leaf nodes: updating (705) the accumulated subspace parameter by adding the equal first fraction of feature space of the first leaf node to the accumulated subspace parameter; updating (706) the accumulated sample fraction parameter by adding the second fraction of training samples captured by the first leaf node to the accumulated sample fraction parameter; and setting (707) accumulated subspace parameter by accumulated sample fraction parameter as a curve pair in a set of curve pairs; and determining a curve defined by the set of curve pairs.

7. The method as claimed in claim 6 further comprising: determining an area under the curve; wherein the hardness metric comprises a first hardness equal to 1 minus the area under the curve.

8. The method as claimed in any preceding claim wherein the hardness metric comprises a number of nodes in the decision tree model.

9. The method as claimed in claim 8 wherein the number of nodes is weighted with a first weighting.

10. The method as claimed in any preceding claim wherein the hardness metric comprises a number of features used to perform decisions in the DT model.

11. The method as claimed in claim 10 wherein the number of features is weighted with a second weighting value.

12. The method of any one of claims 1 to 11 wherein the decision tree represents an ensemble of decision trees.

13. The method of any one of claims 1 to 11 wherein the decision tree represents one or more ML models that are not decision trees.

14. A computer-implemented method for protecting against extraction of a first ML model, the method comprising: receiving (1001) a query to utilize the first ML model; determining (1002) an alert level at least in part based on the query; comparing (1003) the alert level to a first detection threshold; and responsive to the alert level being greater than or equal to the first detection threshold, performing (1004) one or more protection actions in response to the query.

15. The method of claim 14 wherein the first detection threshold is derived from a hardness metric, and wherein the hardness metric, h, is determined according to any one of claims 1 to 13.

16. The method of claim 15 wherein the first detection threshold is set (1103) to a low detection threshold, DL responsive to the hardness metric, h, being less than a low hardness threshold, HL.

17. The method of claim 15 or 16 wherein the first detection threshold is set (1105) to a high detection threshold, DH, responsive to the hardness metric, h, being greater than a high hardness threshold, H_H.

18. The method of claim 17 when dependent on claim 15 wherein responsive to the hardness metric being greater than the low hardness threshold, HL, and less than high hardness threshold, HH, setting (1106) the first detection threshold proportional to the hardness metric.

19. The method as claimed in claim 14 to 18 wherein the step of determining the alert level comprises utilizing one or more of the following extraction detection methods: extraction progress estimation, Out-of-Distribution queries, and adaptive query detection.

20. The method of claim 19 wherein the alert level comprises a linear combination ^ = ^ ∙ ^ + ^ ∙ ^ + ^ ∙ ^ _where ^ ∈ [0,1] is an estimated extraction progress, ^ ∈ [0,1] is a fraction of Out-of-Distribution queries, ^ ∈ ^[0,1^] is a degree of risk estimated by an adaptive query detection method, and ^, ^, ^ are tunable weights.

21. The method of claim 19 wherein the alert level is equal to zero when p, where ^ ∈ [0,1] is an estimated extraction progress, is less than or equal to t, where t is a tolerance threshold.

22. The method of claim 21 wherein the alert level is calculated as: ^ = 1_^^^(^) ∙ ((^ ∙ ^) ∙ (^ ∙ ^) + ^ ∙ ^), where 1_^^^(^ ) is an indicator function equal to zero when p is ≤ t and 1 when p is > t, ^ ∈ [0,1] is an estimated extraction progress, ^ ∈ [0,1] is a fraction of Out-of-Distribution queries, ^ ∈ [0,1] is a degree of risk estimated by an adaptive query detection method, and ^, ^, ^ are tunable weights.

23. The method of claim 19 or 21 wherein values of the tunable weights are selected based on the hardness metric.

24. The method of claim 23 when dependent on claim 16 further comprising, responsive to the hardness metric, h, being less than a low hardness threshold, H_L, setting the tunable weights as: ^. > 1/3, ^ > 1/3, and ^ < 1/3, where ^ + ^ + ^ = 1.

25. The method of claim 23 when dependent on claim 17 further comprising responsive to the hardness metric, h, being greater than a high hardness threshold, H_H, setting the tunable weights as: ^ < 1/3, 1/9 < ^ < 2/3, and ^ > 1/3 where ^ + ^ + ^ = 1.

26. The method of claim 23 when dependent on claim 18 further comprising, responsive to the hardness metric being greater than the low hardness threshold, HL, and less than high hardness threshold, HH, the tunable weights are set as ^ = ^ = ^ = 1/3.

27. The method of any one of claims 10 to 26 wherein the one or more protection actions comprise one or more of: stopping responding to a user that sent the query, replacing the model responding to the query by a surrogate model, alerting the model owner of a possible extraction attack.

28. A risk assessment function (2200) for for determining a hardness metric representative of how difficult a decision tree, DT, model comprising a plurality of leaf nodes is to extract, the risk assessment function comprising processing circuitry (2201) configured to: determine (301) a first fraction of feature space associated with each leaf node in the DT model, wherein the training samples were used to create the DT model; determine (302) a second fraction of training samples captured by each leaf node in the DT model; and derive (303) the hardness metric from the first fraction and the second fraction.

29. A risk assessment function (2200) as claimed in claim 28 wherein the processing circuitry is further configured to cause the risk assessment function to perform the method as claimed in any one of claims 2 to 13.

30. A machine learning protection layer, MLPL, (2400) for protecting against extraction of a first ML model, the MLPL comprising processing circuitry (2401) configured to cause the MLPL to: receive (1001) a query to utilize the first ML model; determine (1002) ban alert level at least in part based on the query; compare (1003) the alert level to a first detection threshold; and responsive to the alert level being greater than or equal to the first detection threshold, perform (1004) one or more protection actions in response to the query.

31. The MLPL (2400) as claimed in claim 30 wherein the processing circuitry is further configured to cause the MLPL to perform the method as claimed in any one of claims 15 to 27.

32. A computer program (2205, 2405) comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of claims 1 to 27.

33. A computer program product (2204, 2404) comprising non transitory computer readable media having stored thereon a computer program according to claim 32.