Method and device for providing an analysis report

Abstract

The invention relates to a method for providing an execution report, said method being implemented by a providing device and characterized in that it comprises: - a first step of obtaining a list of at least one terminal identifier present within a local network and associated with at least one action; - a second step of obtaining at least one proof of execution of said at least one action; - a step of transmitting a report comprising said at least one proof associated with said at least one identifier.

Description

Method and device for providing an analysis report.

[0001] 1. Scope of the invention

[0002] The invention belongs to the field of telecommunications, and relates more specifically to the cybersecurity of a local network.

[0003] 2. Prior Art

[0004] For security reasons, a telecommunications operator must continuously monitor and analyze its telecommunications networks (network load, traffic, data type, etc.) to anticipate and prevent attacks launched by hackers. When an anomaly is detected originating from one of its customers' local networks, the operator informs them and asks them to cease their activities. However, most often the customer is not the source of the detected anomaly. In fact, it is quite common for one or more terminals located within their local network, that is, behind the interconnection gateway, to be infected by malware (software capable of carrying out cyberattacks) remotely controlled by a third party, i.e., a hacker. It should be noted that the local network in question can be a home network or a business network.Furthermore, malware can be "dormant" and therefore difficult to detect. For example, it can be a zombie machine (also known as a botnet) that performs fraudulent activity on an ad hoc basis, such as cryptocurrency mining. Since the owner of the equipment doesn't notice any direct impact, locating and detecting the problem becomes virtually impossible.

[0005] When a client becomes aware that an anomaly has been detected on their local network, they must investigate to identify the source of the malfunction(s) or problem(s). Most often, this involves manually reviewing all devices on the local network. This task is generally performed by a specialized technician capable of detecting and identifying malware. Such an intervention is inherently costly and can be very time-consuming. Therefore, clients are not always proactive in analyzing and securing their local network.

[0006] 3. Description of the invention

[0007] The invention improves upon the state of the art and to this end proposes a method for providing an execution report, said method being implemented by a supply device and characterized in that it comprises: a first step of obtaining a list of at least one terminal identifier present within a local network associated with at least one action; a second step of obtaining at least one proof of execution of said at least one action; a step of issuing a report including said at least one proof associated with said at least one identifier.

[0008] Advantageously, according to the invention, the method allows the automatic generation of an action execution report to resolve security problems of terminals / equipment within a local network identified as suspicious, i.e., capable of hosting malicious software.

[0009] In practice, the process first obtains a list of actions and terminal identifiers located within a local network, each identifier being associated with one or more actions. Secondly, the process obtains one or more proofs of execution of all or part of the received actions.

[0010] The process then generates a report including / integrating the execution proofs and all or part of the received terminal IDs, each terminal ID in the report being associated with one or more execution proofs of one or more actions associated with it. Note that the report may also contain, for each terminal ID, the action(s) in question (i.e., the action(s) associated with it in the received list).

[0011] A terminal identifier is a string of characters that allows for the partial (e.g., its type such as a camera, printer, computer, etc., but not its version) or complete identification of a terminal. The identifier can include, for example, a MAC (Media Access Control) address, an IP (Internet Protocol) address, a serial number (e.g., an IMEI for International Mobile Equipment Identity), a cryptographic key, a software version, an identifier entered by the user via a human-machine interface (graphical or voice) of the terminal, etc.

[0012] According to a particular embodiment of the invention, a process as described above is characterized in that the second step of obtaining comprises: sending, to a user, said at least one action; receiving, from said user, said at least one proof.

[0013] This implementation allows obtaining proof from a user for an action that can only be performed manually. For example, the process asks the user (e.g., via SMS, a chatbot, or a personal assistant) to change the password of their connected camera to a stronger password that complies with password recommendations (e.g., more than 10 digits, including special characters, etc.). This action inherently requires user intervention, as they are presumably the only one who knows their password. In return, the user provides proof that the password has been changed, such as a screenshot showing that the password change was successful.

[0014] According to a particular embodiment of the invention, a process as described above is characterized in that the second obtaining step is conditioned by the result of a user validation step.

[0015] This implementation makes it possible to condition the receipt of one or more proofs of execution of all or part of the received actions on the result of an explicit validation request issued to a user (user consent). Note that validation can also correspond to the user's selection of an action from among a plurality of actions rendered graphically and / or audibly by the process.

[0016] According to a particular embodiment of the invention, a method as described above is characterized in that said at least one action is associated with an execution index and in that the execution of said at least one action is triggered according to the value of said index.

[0017] This implementation method allows for the sequencing / ordering of actions based on an index associated with each action. Thus, all actions related to a given piece of equipment / terminal are processed / performed before moving on to the next piece of equipment in the list. An index is defined as an element in an organized list of elements (a distinctive marker assigned to an action, allowing it to be classified within a plurality of actions).

[0018] According to a particular embodiment of the invention, a method as described above is characterized in that the execution of said at least one action is triggered based on the result of at least one other action from said list.

[0019] This implementation method allows, for example, the sequencing / ordering of actions to be performed in the form of a graph. Indeed, the actions associated with a terminal can be organized in an action graph such that the graph constitutes a remediation scenario. The actions in the graph are ordered in such a way as to allow a logical path that maximizes the chances of resolving the situation.

[0020] According to a particular embodiment of the invention, a process as described above is characterized in that the emission step is carried out to a database and / or a blockchain.

[0021] This implementation allows the report to be stored / archived so that it can be consulted later. Thus, a supervisory authority (for example, the user's telecommunications operator) capable of using such a report can, after processing, provide feedback / summary to the user or take coercive measures (for example, shutting down the user's network) if the report reveals significant security vulnerabilities.

[0022] According to a particular embodiment of the invention, a process such as described above is characterized in that said at least one action is associated with a duration of execution.

[0023] This method of implementation allows us to arbitrarily determine that an action has failed (or succeeded) after a certain period of time (i.e., when the duration associated with the action has expired).

[0024] This is the case, for example, when a network request remains unanswered or if a user action is not performed in time (case of an unavailable user).

[0025] The various modes or embodiments mentioned above can be added independently or in combination with each other to the process of providing an execution report defined above.

[0026] The invention also relates to a device for providing an execution report, characterized in that it comprises: a first module for obtaining a list of at least one terminal identifier present within a local network associated with at least one action; a second module for obtaining at least one proof of execution of said at least one action; a module for issuing a report including said at least one proof associated with said at least one identifier.

[0027] The term "module" can refer to a software component, a hardware component, or a set of hardware and software components. A software component itself corresponds to one or more computer programs or subprograms, or more generally, to any element of a program capable of implementing a function or set of functions as described for the modules in question. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module in question (integrated circuit, smart card, memory card, etc.).

[0028] According to a particular embodiment of the invention, a supply device as described above is included in a terminal and / or a server.

[0029] The invention also relates to a computer program comprising instructions for implementing the above method according to any of the particular embodiments described above, when said program is executed by a processor. The method can be implemented in various ways, including in hardwired or software form. This program can use any programming language and be in the form of source code, object code, or code intermediate between source and object code, such as in a partially compiled form, or in any other desirable form.

[0030] The invention also relates to a computer-readable recording or information medium containing instructions for a computer program as described above. The aforementioned recording media can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM (e.g., a CD-ROM or a microelectronic circuit ROM), or a magnetic recording means, such as a hard drive. Furthermore, the recording media may be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The programs according to the invention can, in particular, be downloaded from a network such as the Internet.

[0031] Alternatively, the recording media may correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0032] This supply device and computer program have characteristics and advantages similar to those described previously in relation to the supply process.

[0033] 4. List of figures

[0034] Other features and advantages of the invention will become clearer upon reading the following description of particular embodiments, given by way of simple illustrative and non-limiting examples, and the accompanying drawings, among which:

[0035] This illustrates an example of an implementation environment according to a particular embodiment of the invention,

[0036] This illustrates the hardware architecture of a device configured to implement the supply process according to a particular embodiment of the invention.

[0037] Laillustre des étapes du processus depprovisionnement selon un mode d’animation particulière de l’invention.

[0038] The illustration shows the steps of an action graph traversed by the supply process according to a particular embodiment of the invention.

[0039] 5. Description of an embodiment of the invention

[0040] Laillustre an example of an implementation environment for the invention according to a particular embodiment of the invention.

[0041] The implementation environment comprises a local area network (LAN) 100 belonging to a user U1, interconnected with a telecommunications network 105 (e.g., a Wide Area Network (WAN)) via a gateway 101. Such a gateway is, for example, a residential or business modem-router. The LAN 100 includes multiple terminals, such as a mobile device 102, a camera 103, or a computer 104. Terminals 101, 102, 103, and 104 are capable of communicating with each other using state-of-the-art technologies (e.g., Ethernet or Wi-Fi via TCP / IP).

[0042] The implementation environment also includes a server 106, for example, operated by the telecommunications operator of user U1. The server 106 communicates with the gateway 106, for example, using TCP / IP technology.

[0043] The implementation environment further includes a server 107 of a trusted entity capable of providing a list / inventory of all or part of the terminals present within the local network 100. The server 107 communicates, for example, using TCP / IP technology.

[0044] The supply process can be executed in whole or in a distributed manner by gateway 101, server 106 or by one or more terminals located within local network 100.

[0045] The 105 communication network can be a mobile communication network with an access network of type GSM, EDGE, 3G, 3G+, 4G, 5G, 6G etc. or a fixed communication network with an access network of type ADSL, Fibre, VDSL, etc. The 105 communication network can be a public or private communication network.

[0046] Of course, this is a simplified representation of an implementation environment. The environment may include elements other than those described above. Furthermore, such an architecture is described as an illustrative example. This architecture is not limiting, and other architectures are suitable for implementing the invention. For example, the implementation environment may include one or more interconnection networks or servers capable of relaying requests between server 106 and gateway 101.

[0047] Figure 1 illustrates the hardware architecture of a DISP device configured to implement the supply process according to a particular embodiment of the invention. In the embodiment described here, this device has the hardware architecture of a computer. It includes, in particular, a PROC processor, a MV random access memory, a MEM read-only memory, and a MF non-volatile flash memory. Such components are known per se and are not described in further detail here. The read-only memory constitutes a storage medium according to the invention, readable by the PROC processor, on which a computer program PG according to the invention is stored. This program includes instructions for implementing the steps of the supply process as described above when the program is executed by the PROC processor.At initialization, the code instructions of the computer program PG are, for example, loaded into memory before being executed by the processor PROC. The processor PROC of the processing unit UT implements, in particular, the steps of the supply process according to any of the specific embodiments described in relation to Figures 1, 3 and 4, according to the instructions of the computer program PG.

[0048] The DISP device also includes an OBT1 receiving module capable of obtaining, for example from gateway 101 of network 100, a list of all or part of the terminal identifiers present within network 100, each identifier being associated with at least one action.

[0049] The DISP device also includes an OBT2 acquisition module capable of obtaining one or more proofs of execution of actions received by the OBT1 module, i.e. actions associated with the identifiers of terminals present within the network 100.

[0050] Furthermore, the DISP system includes an SND module capable of generating, based on the execution proofs obtained via the OBT2 module, a new list / report containing all or part of the terminal identifiers received by the OBT1 module along with said execution proofs of the associated actions. The SND module is also capable of issuing the report to a supervisory authority to verify that all actions have been processed.

[0051] Note that the new list may be empty if the actions have not been carried out.

[0052] According to a particular embodiment, the SND module enriches the report with actions associated with terminal identifiers.

[0053] According to a particular embodiment, the report is generated by a different module than the one that issues it (not shown).

[0054] Figure 1 illustrates the steps of the supply process according to a particular embodiment of the invention. The process described in Figure 2 is situated in the same environment as that described in support of Figure 3.

[0055] In the case described below, the provisioning process is executed by server 106. Generally, the provisioning process establishes a report including identifiers of terminals present within the local network 100 associated with evidence of action execution to correct security vulnerabilities (i.e., vulnerabilities caused by malicious software).

[0056] Prior to the first step 300, server 106 issues a request, for example to gateway 101 or to a server of a trusted entity (107), in order to obtain from it a list / inventory of all or part of the terminals present within the local network 100 (considered suspicious or not), each terminal identifier being associated with one or more remediation actions to correct security flaws of the terminal in question.

[0057] The curative action(s) are, for example, obtained from a memory of server 106 or from server 107.

[0058] Note that the server for trusted entity 107 may correspond to server 106.

[0059] In step 300, the process receives the requested list in response to the query. This list can typically be obtained via an API (Application Programming Interface), for example, exposed by server 107 and accessed using a username / password combination. Server 107 is, for example, operated by the telecommunications provider of user U1. The list can be in XML or JSON format, for example.

[0060] Each terminal in the list can be identified by one or more elements from the following list of identifiers: an equipment name (which may have been given by the user, or automatically by the gateway); a physical address of the MAC type which most often includes a prefix identifying the manufacturer; a serial number; a reference; a software version; etc.

[0061] The action(s) in the list can be automatic (i.e., executable directly by the process) or require the intervention of a third party (manual action) such as the owner of the local network 100.

[0062] An automatic action can correspond to:

[0063] - verification for a connected object that its "username / password" settings have not remained set to factory (default) values;

[0064] - the verification for a connected object that its firmware version is later than a certain value;

[0065] - verifying that the MAC address filtering or firewall configuration of gateway 101 is set to a certain security level.

[0066] - etc.

[0067] A manual action can correspond to:

[0068] - running a computer's antivirus software;

[0069] - the modification of the firewall protection level of gateway 101;

[0070] - turn off a connected device on the local network;

[0071] - etc.

[0072] In general, a manual action is characterized by: a communication channel (SMS, IM, email, voice / video, etc.) allowing contact with a user (for example, user U1) capable of performing the action; a description of the action; possibly parameters or values ​​to be used; the type / a description of the expected return result.

[0073] Once the list is obtained, the process analyzes and processes it. The process executes or causes the action(s) from the list to be executed and then obtains the proof(s) of execution associated with each executed action (step 301).

[0074] In the case of an automated action, the process invokes an API, possibly using parameters and / or one or more usernames / passwords. The process then retrieves, in response to the request, a result that serves as proof of the action's execution.

[0075] For example, when a firewall configuration request from gateway 101 with a value of "high" is issued, the "HTTP 200 OK" response obtained in return constitutes proof that the action was successfully completed.

[0076] The format of the action that allows obtaining such a response / proof could, for example, correspond to:

[0077] {

[0078] {

[0079] “action_name”:”firewall”,

[0080] “type”:“automatic”,

[0081] “target”:{

[0082] “local_name”:”Livebox”,

[0083] “local_type”:”gateway”,

[0084] },

[0085] “api”: “https: / 192.168.1.1:8080 / firewall / set”,

[0086] “params”:”level=high”,

[0087] “proof”:{

[0088] “type”: “automatic check”,

[0089] “expected_result”: “200 OK”

[0090] }

[0091] }

[0092] Optionally, the obtained response and / or result is compared with an expected value. For example, the result of comparing a obtained firmware version with an expected firmware version. This comparison operation can be simple, for example, in the case of alphanumeric values, or more complex when the evaluation process requires it, for example, by using generative artificial intelligence to determine the obtained result in relation to the expected result. The result of this comparison can constitute proof within the meaning of the invention.

[0093] In one particular embodiment, obtaining one or more proofs of execution of all or part of the received actions is conditional upon the outcome of an explicit validation request sent to a user (user consent). It should be noted that validation can also correspond to the user's selection of an action from among a plurality of actions rendered graphically and / or audibly by the process.

[0094] In the case of a manual action, the evidence corresponds to the feedback provided by a user. For example, a screenshot of the results of an antivirus software scan run on a computer can constitute evidence.

[0095] Alternatively, or in addition, this photo can be analyzed by Artificial Intelligence to verify / determine that the computer is protected. In this case, the assurance that the computer is protected constitutes the proof.

[0096] According to a first example, a manual action could correspond to:

[0097] {

[0098] “action_name”:”unplug”,

[0099] “type”:”user”,

[0100] “target”:{

[0101] “local_name”:”Equipment#3”,

[0102] “local_type”:”camera”

[0103] },

[0104] “channel”:”sms: / 0612233445”,

[0105] “description”: “You must unplug your camera”,

[0106] “timer”:{

[0107] “delay”: “24h”,

[0108] “Timeout”: “Failure”

[0109] },

[0110] “proof”:{

[0111] “type”: “automatic check”,

[0112] “api”: “https: / 192.168.1.1:8080 / devicelist / ”,

[0113] “success_factor”:” ^((?! Equipment#3).)*$”,

[0114] }

[0115] }

[0116] In this example, when the process handles this action, it deduces that it must contact the user by sending an SMS to the number "0612233445" with the following message: "You must unplug your camera," so that the user unplugs the equipment infected by malware, i.e., the camera.

[0117] Successful execution of the action is then evaluated via a request sent to an API of gateway 101, which provides a list of connected devices. The evaluation is performed, for example, using a regular expression specifying that the returned list must not contain the string "Equipment#3," i.e., the camera's identifier. Furthermore, a 24-hour delay is required to complete this action.

[0118] According to a second example, a manual action could correspond to:

[0119] {

[0120] “action_name”:”antivirus”,

[0121] “type”:”user”,

[0122] “target”:{

[0123] “local_name”: “AcerPC”,

[0124] “local_type”:”computer”

[0125] },

[0126] “channel”:”sms: / 0612233445”,

[0127] “description”: “You must run an antivirus scan on this device and take a picture of the result”,

[0128] “timer”:{

[0129] “delay”: “24h”,

[0130] “Timeout”: “Failure”

[0131] },

[0132] “proof”:{

[0133] “type”:”image”

[0134] }

[0135] }

[0136] }

[0137] In this example, when the process handles this action, it deduces that it must contact the user by sending an SMS to the number "0612233445" with the following message: "You must run an antivirus scan on this device and take a picture of the result." The expected proof is an image, for example, a screenshot of the scan results screen from the antivirus software on the "AcerPC" computer.

[0138] In a specific implementation, the process archives the evidence obtained, possibly along with a description of the action and / or the associated terminal identifier(s). Archiving is performed, for example, within a database or a blockchain. It should be noted that archiving can be secured through symmetric or asymmetric encryption of the archived data.

[0139] In one particular embodiment, the process can run over a long period (for example, several days), so that the user has time to complete complex or time-consuming actions. In this case, the process can send reminders to the user via a communication channel (email, SMS, instant messaging, etc.) to remind them that they have one or more actions to perform.

[0140] In a specific implementation, the actions in the resulting list are ordered. Each action in the list is then associated with an index that determines its execution rank, that is, its position or order of execution relative to the other actions in the list. Thus, all actions related to a given piece of equipment / terminal are processed / performed before proceeding to the actions associated with another piece of equipment / terminal in the list.

[0141] In a particular embodiment, the actions in the list are executed based on the result of another action. This allows the actions to be sequenced / ordered according to an action graph. Indeed, the actions associated with a terminal can be organized into a graph such that it constitutes a remediation scenario. Specifically, the graph is composed of links (transitions) and nodes, each node corresponding to an action as presented in the supporting documentation. This embodiment allows for a logical path that maximizes the chances of resolving the situation, that is, of fixing a security vulnerability in a terminal. In this case, for each device in the list, the process traverses the graph of associated actions. For each action reached, the process initiates a treatment that depends on the category of the action (automatic or manual) and the result of the previous action.Note that the result may require interpretation to derive a binary value indicating the success or failure of the action.

[0142] In one particular embodiment, once the execution of an action is complete, the process can either interrupt or continue the execution of the remaining actions. For example, if the process determines, based on the evidence obtained, that a cyber threat related to a terminal on local network 100 has been eliminated, it may prove unnecessary to proceed with the execution of further actions.

[0143] When the last action on the list has been completed and the evidence obtained, a complete report is generated by the process (step 302). This report includes, for each action, the evidence obtained associated with one or more terminal identifiers (each action being associated with one or more terminal identifiers). Optionally, a description of the action is also associated with the "terminal identifier(s) / evidence of action execution" pair.

[0144] The report could, for example, take the following form:

[0145] {

[0146] “report_date”:”2024-10-02:17:28”,

[0147] “report_content”: {

[0148] {

[0149] “local_name”:”Livebox”,

[0150] “macAddress”: “0023081E5F6F”,

[0151] “action_name”:”firewall”,

[0152] “result”: “success”,

[0153] “proof”: “automatic check”

[0154] },

[0155] {

[0156] “local_name”:”DLink network camera”,

[0157] “macAddress”:”001A3FF14CC6”,

[0158] “action_name”:”unplug”,

[0159] “result”:”success”,

[0160] “proof”:”automatic check”

[0161] },

[0162] {

[0163] “local_name”:”PC de Bob”,

[0164] “macAddress”:”6036DD1A3508”,

[0165] “action_name”:”antivirus”,

[0166] “result”:”unknown”,

[0167] “proof1”:<image1 encodée en Base64>

[0168] “proof2”:<image2 encodée en Base64>

[0169] }

[0170] }

[0171] }

[0172] The report is then transmitted (step 303) to a supervisory authority (for example, server 107) which can use it to, for example, verify that all actions have been processed, provide formal feedback to the user, or take enforcement action (if the report shows that the actions were not processed correctly). The report can also be sent to an entity that handles reports of detected anomalies (cyberattacks) originating from local networks.

[0173] Note that the transmission of the report can be carried out securely by encrypting the data via a symmetric or asymmetric encryption algorithm.

[0174] The illustration shows the steps of an action graph traversed by the supply process according to a particular embodiment of the invention.

[0175] In this example, we assume that the list obtained during step 300 includes a single piece of equipment / terminal, for example a printer, which has been identified as potentially being a victim of malware.

[0176] The process begins by traversing the graph (step 400) and proceeds to step 401, which involves verifying that the printer access settings have not been left at their factory defaults. The description of this automated action includes, for example, a URL / URI that provides access to configuration web pages (e.g., in HTML format) published by the printer. The description also includes a username / password pair corresponding to the factory-configured user account credentials (default values). The expected response is a connection error, thus confirming that the factory defaults have indeed been changed.

[0177] In the event that the process manages to connect to the printer's web portal, the result "KO" is added by the process to a report which is stored, for example, securely in a database / memory of the device that executes the process.

[0178] The process then proceeds to step 403, which involves an action requiring the user to change the printer's username / password. To do this, the process interacts with the user, for example, via an instant messaging session, to provide instructions. Optionally, a tutorial is offered to the user.

[0179] The evidence expected at this stage may be the same as that of stage 401, i.e., attempting to access the printer's web portal and verifying that an error is returned. Alternatively, the expected evidence may be a statement from the user regarding the successful completion of the action, for example, by using a "done" response button, in which case the user is presumed to be acting in good faith.

[0180] In the event that the action could not be performed by the user (for example when the web portal is inaccessible), the process adds the result "KO" to the report and proceeds to step 405.

[0181] For this step, the associated action requires the user to turn off the printer. The expected proof could be a list obtained from gateway 101 indicating that the printer is no longer connected (the printer ID is not present in the list). Once the user has performed the action, the process proceeds to step 406 (end of graph) and adds the result "OK" to the report.

[0182] At step 403, or after step 401, when the printer's username / password combination differs significantly from the factory default, the process proceeds to step 402. This step involves verifying that the printer's firmware is a sufficiently advanced version (the printer manufacturer may have patched a vulnerability in a more recent firmware version). The firmware version can be obtained, for example, via an API exposed by the printer. The proof can then be the result of comparing the character string of the printer's version with the character string of the expected version (i.e., the version that patches the security vulnerability(ies) associated with the malware detected / executed on the printer).

[0183] If the firmware version matches the expected version, the process adds the result "OK" to the report and proceeds to step 406 (the end of the graph). Otherwise, the process adds the result "KO" to the report and proceeds to step 404. For this step, the associated action is the firmware update. The firmware update is performed, for example, by sending a command to an API exposed by the printer. The proof can then be the verification (by comparison) that the new firmware version, obtained, for example, via an API exposed by the printer, is indeed the expected one.

[0184] When the firmware version matches the expected result, the process adds the result "OK" to the report and proceeds to step 406 (the end of the graph). Otherwise, the process adds the result "KO" to the report and proceeds to step 405. The process then continues traversing the graph as described previously.

[0185] The ratio established by the process can then correspond to:

[0186] {

[0187] “report_date”:”2024-10-02:17:28”,

[0188] “report_content”:

[0189] {

[0190] “local_name”: “Equipment #4”,

[0191] ”macAddress”: “0023081E5F6F”,

[0192] “brand”:“HP”,

[0193] “model”:”ENVY 6430E”,

[0194] “firmware”: “V13”

[0195] “action_report”: [

[0196] “action1”: {

[0197] “name”:”credential check”,

[0198] “type”:“automatic”,

[0199] ”API”:”http: / 192.168.1.15:80”,

[0200] “credentials”: {

[0201] “login”:”admin”,

[0202] “password”:”admin”

[0203] },

[0204] “expected”:”HTTP:401 | HTTP:403”,

[0205] “result”:”KO”

[0206] },

[0207] ”action2”: {

[0208] “name”:”password change”,

[0209] “type”:”user”,

[0210] “channel”:”chatbot: / address / token”,

[0211] “description”:”Vous devez modifier le mot de passe de votre imprimante HP Envy 6430E”,

[0212] “tutorial”:”https: / domain / videoURL”,

[0213] “expected”:”user ack”,

[0214] “result”:”OK”,

[0215] },

[0216] “action3”: {

[0217] “name”:”firmware check”,

[0218] “type”:”automatic”,

[0219] “API”:”http: / 192.168.1.15:9100”,

[0220] “expected”:”V10 | V11 | V12 | V13 | V14”,

[0221] “result”:”OK”

[0222] }

[0223] }

Claims

Method of providing an execution report, said method being implemented by a supply device and characterized in that it comprises: - a first step of obtaining (300) a list of at least one terminal identifier present within a local network associated with at least one action; - a second step of obtaining (301) at least one proof of execution of said at least one action, said at least one action being triggered according to the result of at least one other action from said list; - a step of issuing (303) a report including said at least one proof associated with said at least one identifier. The method according to claim 1 characterized in that the second step of obtaining it comprises: - sending, to a user, said at least one action; - receiving, from said user, said at least one proof. The method according to claim 2 characterized in that said reception is followed by a step of validation of said proof by inference of an artificial intelligence model taking said proof as input. A process according to claim 1 characterized in that the second obtaining step is conditioned by the result of a user validation step. A method according to claim 1 characterized in that said at least one action is associated with an execution index and in that the execution of said at least one action is triggered according to the value of said index. A method according to claim 1 characterized in that the transmission step is carried out to a database and / or a blockchain. Method according to claim 1 characterized in that said at least one action is associated with a duration of execution. Device for providing an execution report, characterized in that it comprises: - a first module for obtaining (OBT1) a list of at least one terminal identifier present within a local network associated with at least one action; - a second module for obtaining (OBT2) at least one proof of execution of said at least one action, said at least one action being triggered according to the result of at least one other action from said list; - a reporting module (SND) comprising said at least one proof associated with said at least one identifier. Server and / or terminal comprising a supply device according to claim 8 Computer program comprising instructions for implementing the method according to any one of claims 1 to 7, when the program is executed by a processor. Computer-readable information carrier containing instructions for a computer program according to claim 10.

Images