DESC:Method and System for Detecting Malware Threats via Adaptive Immune Response in an Ecosystem of Networked Devices

This Complete Specification is filed in pursuance to the Provisional Specification filed on 9th November 2018 in respect of Patent Application No. 201841042281.

FIELD OF THE INVENTION
The present invention provides a method and system for detecting multifarious malware threats in an ecosystem of networked devices. In particular the present invention discloses a method and system for detecting disparate and varied malware threats in an ecosystem of networked devices using a mechanism of adaptive immune response. An ecosystem of networked devices (hereinafter referred to as “ecosystem”) includes but is not limited to an enterprise network, a smart home, a smart office, a smart mall, etc., containing heterogeneous (i.e., different purpose) devices with varied platforms/OS connected to the same network(s), including but not limited to LAN, WAN, VPN and the internet.

BACKGROUND AND PRIOR ART
Without limiting the foregoing our example Ecosystem shall be any one of the following:
Example 1 Enterprise network: A typical enterprise network includes, but is not limited to, devices such as desktop, laptop, server and virtual machine (VM) computers running operating systems including but not limited to Windows, Linux, and MacOS, and mobile devices including, but not limited to, Smart phones and tablets running operating systems including, but not limited to, Android and iOS.
Example 2 Smart homes: A typical smart home includes, but is not limited to, a Smart TV, a Smart Fridge, Smart door locks, a Smart thermostat, a Smart camera/CCTV, a Smart washing machine, a Smart coffee maker, Smart light bulbs, etc.
Example 3 Smart offices: A typical smart office includes, but is not limited to, Smart phones, laptops, Smart printers/copiers, Smart door locks, Smart light bulbs, Smart thermostats, Smart cameras/CCVT, Smart access control systems, Smart meeting/conference rooms, Smart chairs, etc.
Example 4 Smart industries: A typical smart industry includes, but is not limited to, Smart phones, laptops, Smart printers/copiers, Smart door locks, Smart thermostats, Smart cameras/CCTV, Smart assembly lines, Smart access control systems, Smart industrial control systems, etc.
All these devices which can be operated/controlled via a network (LAN, WAN, VPN, intra/internet) may exchange data with other devices to operate based on context and may have cyber security products installed on them.
Providing robust multi-platform and heterogeneous device security is often a complex challenge for vendors of cyber security products. A security breach in an Ecosystem involving a malware infection occurs within mere milliseconds and could lead to the loss of sensitive data or could spread to other devices within the Ecosystem and result in downtime for business critical infrastructure, thus causing direct or indirect financial losses and damage to the user’s reputation (an enterprise entity’s reputation if the Ecosystem is an enterprise network) amongst other consequences. Modern enterprise Ecosystems include mobile and other connected smart devices in addition to traditional workstations and laptops.
This increases the complexity of the security solution to be provided for several reasons. Smart devices are available in a variety of hardware and software combinations which are significantly different from those for standard PCs. Security software needs to support and provide protection for many of the most popular devices.

Mobile smart devices are exposed to more malware threats from outside the Ecosystem since they tend to regularly leave and re-enter the Ecosystem. For example, devices owned and controlled by employees in an enterprise Ecosystem, assuming “Bring Your own Device” (BYoD) is permitted, may not necessarily follow strict security protocols, especially at home.
In order for a security vendor to help remediate a breach it must first be provided with the suspicious sample object for which manual intervention of user/enterprise IT staff is generally required. The security vendor’s research lab would then analyze the object and provide a malware identifier (henceforth referred to as “Malware Identifier”) including but not limited to anomaly rules (structural anomaly and/or behavioural anomaly), behavioral patterns, or system environmental change rules, signatures (file specific, generic or heuristic), etc. However, in the interest of expediency, speed and to avoid false positives, i.e., incorrect identification of non-malware as malware, the malware identifier would typically be designed to detect and remove only the specific sample object submitted for analysis. The entire remediation process takes a few hours to complete, which is quite a long time, and it is possible for other similar malware objects to sneak past the defenses in the future given that the Malware Identifier created was not designed to catch them.
In order to avoid these kinds of damaging breaches in the first place it is important for security vendors to provide aggressive protection mechanisms, e.g., generic malware identifiers which can stop never-seen-before “zero-day” malware before they can do any damage. Unlike hash-based, specific signatures which detect only the specific target malware objects for which they were created, each generic malware identifier is designed to detect the specific target malware object as well as other malware objects which exhibit characteristics similar to the target object. Thus, generic malware identifiers are deemed to be more aggressive than hash-based signatures because they are able to detect zero-day malware whereas hash-based, specific signatures are not. However, generic malware identifiers do entail a greater risk of false positives, i.e., incorrect identifications of legitimate objects as malware.
In fact, Ecosystems vary from one site to another such that a global aggressive malware identifier from a security vendor which is effective for one Ecosystem causes false positives at other ecosystems based on the respective context. These false positives can lead to false alarms and chaos and may themselves even lead to downtime of critical business infrastructure. It is possible to provide generic malware identifiers based on a critical object’s characteristic data, extracted from potential target malware objects to be generically detected. For this, however, extracted required data or the entire object itself must be transmitted back over a network from an ecosystem to the security vendor’s infrastructure. This transmission of extracted data leads to serious privacy concerns for the owners of an Ecosystem and is governed by strict legislative data privacy controls in several countries, e.g., the General Data Protection Regulation (GDPR) and others in the European Union.
Hence there is a need for providing robust ecosystem-specific protection.

SUMMARY OF THE INVENTION
A system for detecting multifarious malware threats in an ecosystem of networked devices, also called the Adaptive Immune Response System (AIRS), comprises of Agent installed within all the participating devices, Server and a custom Ecosystem Threat Intelligence repository. The participating devices have one or more security protection layers. Each protected device within the ecosystem is provided with a compatible software or hardware Agent which registers with a security product already installed on the device upon installation. The Server is run within the ecosystem on hardware that is completely controlled by the owner of the ecosystem, thus preventing any data sent to Server from leaving the ecosystem environment in order to conform to Global Data Privacy Regulation (GDPR) and other data privacy norms.
The ecosystem is either an enterprise network or a smart home or a smart office or a smart industry.
Agents submit required data for an object such as URL, network packets, system environmental changes, application data, supporting object data or objects used by applications to Server for both legitimate and malware objects based on contextual trigger conditions.
Server requires data on known legitimate objects so that the malware identifiers it creates does not cause false positives on the legitimate objects anywhere within the ecosystem.
Server provides device inventory, device to security-layer mapping, data processing, security analysis, generic malware identifier generation and testing, protection update, security alert, security dashboard and external security server communication.
A method of submitting required data for legitimate objects by the Agent in the AIRS as described above comprises of the steps of:
- Agent registering with the preinstalled security product and Server upon its first installation;
- Agent requesting the preinstalled security product for the required data for all objects deemed to be legitimate; and
- Agent receiving notification of objects deemed to be legitimate by the preinstalled security product when new objects are introduced onto the device.
A method of detecting a malware object at any of the plurality of security protection layers in the AIRS as described above comprises of the steps of:
- the preinstalled security product(s) examining all objects at the multifarious security protection layers and evaluating them for the presence of malware, a threat event occurring when an object is classified as malware, resulting in a new log entry being added for the object and a prescribed action being performed on it and the preinstalled security product(s) evaluating objects for the presence of malware using static scanning of objects and/or dynamic behaviour verification;
- sending the required data for the reported malware objects to Server by Agent for creating multi-layer generic malware identifiers for the reported malware objects and/or their variants by Server to detect them at all possible security protection layers or for other malware objects participating in coordinated and/or multi-stage attacks;
- submitting required data for malware objects by Agent immediately after being notified of a threat event reported by the preinstalled security product; and
- Agent collecting data such as AgentID, device type, architecture, OS and OS version, etc., security product(s) with full version information and delivering this data to Server and simultaneously maintaining a local cache of all required data for optimized performance to avoid duplicating submissions to Server.
In the method of detecting a malware object, Agent notifies Server of a threat event for a malware object along with data such as AgentID, device type, architecture, OS and OS version, security product(s) with full version information, type of threat event, required data extracted from the malware object and also delivers malware identifiers from Server to preinstalled security product on the same device.
In the method of detecting a malware object, the malware identifier generator utility assigns a generic level rating to the generated malware identifier to differentiate between different malware identifiers on their ability and range to detect zero-day objects.
A method for detection of a new threat in the AIRS as described above comprises of the steps of:
I. Agent notifying Server of new threat event which entails an implicit request for generic malware identifiers for all supported security protection layers by making available malware object’s required data from the corresponding device;
II. Server receiving Agent’s notifications along with object data and processing the data. The data processing activity includes, but is not limited to, removing duplicate requests from the same Agent within a configurable (by privileged users only) time frame, the Server also checking its local cache for any duplicate requests from other Agents and discarding duplicate requests while recording such requests from other Agents for correlation purposes, e.g., in the case of a malware outbreak within the ecosystem;
III. checking object’s required data in ETI repository and initiating Step V. below if found;
IV. inserting object’s required data into ETI repository;
V. conducting Security analysis which includes, but is not limited to, correlation of required data of one or more Agents’ relevant malware object(s) with respective ETI data and static and/or dynamic malware object analysis, said correlation comprising URL data, behaviour data, system environment change data, threat family data, shared data among objects, IP address and specific packer/obfuscation/custom encryption;
VI. based on security analysis, data being extracted from submitted object(s) and/or respective similar object(s) ETI data for all possible security protection layers based on the security product(s) specifications;
VII. based on extracted data, generating generic malware identifiers along with varying GL values for each security protection layer and each registered RCR depending on the object type;
VIII. selecting the malware identifier with the highest GL value for each unique security protection layer, RCR pair discarding all others including any selected malware identifiers which are already present in the ETI cache;
IX. testing all generated generic malware identifiers for false positives, false negatives and/or performance issues, when malware identifiers have any issues, regenerating generic malware identifiers based on other extracted data, by initiating Step VII;
X. repeating on test failure until all possibilities of malware identifiers for a given security protection layer and RCR threshold value have been generated and tested or suitable malware identifiers for a given security protection layer and RCR threshold which passes the test criteria have been found;
XI. adding malware identifiers which passed the test criteria to ETI cache;
XII. sending notification from Server on malware identifier update to eligible Agent list; and
XIII. invoking update process by eligible Agents for respective security protection layers for the security product to apply the malware identifier update, providing all possible security protection layer immunity from a given malware threat on the respective device.

OBJECTIVES OF THE INVENTION
The main objective of the present invention is to provide a completely self-contained method and system for generically identifying malware threats in an Ecosystem thus providing proactive protection from such threats.
It is another objective of the present invention to significantly reduce the turnaround time to provide generic protection to an Ecosystem.
It is a further objective of the present invention to provide generic detection at multifarious security protection layers for malware objects based on object data, behavioral data and respective system environmental change data including, but not limited to, contextual data.
It is another objective of the present invention to provide generic detection based on data correlation from multiple suspicious or malicious events from a single malware object or multiple malware objects including, but not limited to, multi-stage, coordinated attack in an Ecosystem.
It is another objective of the present invention to minimize false positive risk in proactively detecting malware threats in an Ecosystem.
It is yet another objective of the present invention to provide conformity to stringent Ecosystem data privacy policies regardless of international jurisdiction in providing proactive protection from malware threats in an Ecosystem.
It is yet further an objective of the present invention to provide proactive malware protection in an Ecosystem which is tailored to suit the risk profile of target devices and target security protection layers by employing Ecosystem Threat Intelligence (ETI).
It is another objective of the present invention to provide a malware protection method and system in an Ecosystem which is fully automated, i.e., without any need for manual human intervention.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 is a schematic diagram of an example Ecosystem with heterogeneous, multi-platform devices with Agent, Server and ETI repository for the present invention.
Figures 2a and 2b show a basic Agent workflow at install time on a clean device.
Figures 3a and 3b show a basic Agent workflow for new legitimate objects introduced into the participating devices.
Figures 4a and 4b illustrate a basic Agent workflow for a new threat event.
Figure 5a and 5b illustrate a basic Server workflow for a threat event.

DETAILED DESCRIPTION OF THE INVENTION
The Adaptive Immune Response System (hereinafter referred to as AIRS for brevity) of the present invention allows an ecosystem of heterogeneous, multi-platform networked devices to develop immunity to previously-identified malicious objects at any security protection layer on any device in the ecosystem and their unseen variants without any external input.
AIRS is specifically designed to provide multi-layered generic detection, called “Malware Identifiers”, a type of cyber security program to detect malware objects at multifarious security layers including, but not limited to, the network layer (viz. Firewall, Network Intrusion Detection/Prevention System (NIDS/NIPS), URL filtering etc.), host layer (Anti-Malware, Host Intrusion Detection/Prevention (HIDS/HIPS), Anti-Ransomware protection, Application control, etc.), based on the data of one or more malware object(s), behaviour data of malware object(s), correlation of multiple malware objects’ data and behavioural data.
As shown in Fig 1 AIRS of the present invention has three primary components, viz., Agent (A) installed within all the participating devices (note, the participating devices may have one or more security protection layers), Server (S), and a custom Ecosystem Threat Intelligence (ETI) repository.
Each protected device within an Ecosystem, regardless of specific hardware type and operating system, has a compatible software or hardware Agent, which, upon installation, registers with a security product already installed on the device. If a given device doesn’t support Agent, then the immediate router’s Agent will act as the device Agent.
Server runs on-premise, i.e. within an ecosystem and on hardware completely controlled by the owner of the ecosystem. This prevents any data sent to Server from leaving the ecosystem environment in order to conform to Global Data Privacy Regulation (GDPR) and other data privacy norms.
At a basic level the Agent-Server interaction method may be defined by the steps of (i) all Agents register with Server; (ii) based on corresponding triggers, Agents send required data to Server for both legitimate and malware objects; (iii) Server provides generic detection for malware objects, i.e., “Malware Identifiers”, to all Agents eligible to receive them, typically inclusive of the Agent(s) for which malware object data/behavioral data and/or correlation of multiple malware object data/behavioral data were submitted; and (iv) Agent receives Malware Identifiers for all eligible security protection layers from Server to be applied to the security products which are responsible for device protection at multifarious security protection layers.
As mentioned above Agents (A) submit required data for an object including, but not limited to, URL, network packets, system environmental changes, application data, supporting object data or objects used by applications, to Server (S) for both legitimate objects as well as malware objects based on contextual trigger conditions. Agent would typically only send required data to Server for objects classified as legitimate or malware by the preinstalled security products on the participating devices but yet unknown to itself, i.e., new (“zero-day”) objects. In an embodiment, for performance optimization reasons and to avoid duplication, Agents would maintain a cache of object data which has already been submitted to Server, and only submit new data.
Server (S) requires data on known legitimate objects so that the malware identifiers it creates would not cause false positives on these legitimate objects anywhere within the ecosystem.
In an embodiment Agent would submit required data for legitimate objects under the following circumstances:
(i) When Agent (A) is first installed, it registers with the preinstalled security product and Server (S). At this point Agent requests the preinstalled security product for the required data for all objects which have been deemed to be legitimate, i.e., not declared as malware or suspicious, and/or would send OS details along with known applications installed on the device. The process flow for such a situation is illustrated in Figs 2a and 2b.
(ii) When new objects are introduced onto the device, e.g. during new installation of apps, Agent would receive notification of objects deemed to be legitimate by the preinstalled security product. The process flow for such a situation is illustrated in Figs 3a and 3b.
The workflow for malware object triggers can be described as follows.
Whenever a security product detects a malware object at any of the plurality of security protection layers, Agent (A) sends the required data for the reported malware objects to Server (S), so that Server can create multi-layer generic Malware Identifiers to detect them at all possible security protection layers and/or their variants or other malware objects participating in coordinated and/or multi-stage attacks. Agent (A) would typically submit required data for malware objects immediately after being notified of a threat event reported by the preinstalled security product. Figures 4a and 4b illustrate such a workflow.
The preinstalled security product(s) examine(s) all objects at the multifarious security protection layers and evaluate(s) them for the presence of malware. A threat event occurs when an object is classified as malware, resulting in a new log entry being added for the object, and a prescribed action, typically object reporting, blocking, quarantining and/or deletion, being performed on it. Typically, the preinstalled security product(s) evaluate(s) objects for the presence of malware using various methods including, but not limited to, (i) static scanning of objects, i.e., before invoking them, using a variety of Malware Identifiers including, but not limited to hash or fingerprint or signature on an object, generic detection mechanisms, including, but not limited to, generic signatures, heuristics signatures, device and/or system environmental signatures, regular expressions on malicious object’s contents, resource signatures (e.g. based on images) on the respective security protection layer; (ii) dynamic behaviour verification, i.e., upon invoking objects and examining their run-time activities, using a variety of rule-based criteria including, but not limited to, firewall alerts and/or NIPS/NIDS for suspicious network connectivity attempts and HIPS/HIDS for host-based malware activity.
Typically, zero-day malware may trigger threat events under various circumstances such as in the event of heuristic signature detections, firewall alerts and HIPS detections.
In the AIRS of the present invention, Agent collects data on all current and new legitimate objects on the device and then delivers data to Server such as AgentID, device type, architecture, OS and OS version, etc., Security Product(s) (with full version information), required data on legitimate objects and also maintains a local cache of all required data for optimized performance (to avoid duplicating submissions to Server).
Agent notifies Server of a threat event for a malware object along with data such as AgentID, device type, architecture, OS and OS version, etc., Security Product(s) (with full version information), type of threat event, required data extracted from the malware object.
Agent also delivers Malware Identifiers from Server to preinstalled Security Product on the same device.
Agent requires access to APIs provided by the preinstalled Security Product(s) including, but not limited to, callbacks for object-evaluation-complete notification, callbacks for threat event notification, object enumeration and required data extraction from target objects.
Agent further requires access to Server-side APIs including, but not limited to, those for submission of notification of and data for new legitimate object required data, submission of notification of and data for malware object required data due to new threat events, retrieval of available Malware Identifiers based on eligibility.
Agent further provides APIs for notification of available Malware Identifiers update and for retrieval of Malware Identifiers as notified (typically for preinstalled Security Product(s)).
Agent gets notification from Server for any Malware Identifiers relevant to it. Based on the risk profile of the corresponding device and its user, and the supported security protection layers, Agent may not be eligible for all available Malware Identifiers from Server. Server decides Agent eligibility for every Malware Identifier.
Agent calls preinstalled Security Product components to extract required data for both legitimate and malware objects. Required data extracted from legitimate objects helps reduce the possibility of Malware Identifiers causing false positives in the Ecosystem.
Functionalities of Agent as depicted in Fig 1a include, but are not limited to:
• Data Enumeration: Enumerate target object required data for both legitimate and malicious objects. Enumerate data from OS/system environment of a given device in an Ecosystem for a target event.
• Data Cache: Local cache for storing required data on device to avoid data duplication and used for future data processing.
• Data Correlation: Correlation of data on multiple suspicious/malicious events from one or more objects on a given device in an Ecosystem.
• Data Transfer: Send and receive data with respective Server in an Ecosystem and installed security product(s).
• Data Analyzer: Data classification determined by security product(s) as legitimate or malicious or unknown (indeterminate status).
• Data Protection: Data stored in local cache on a given device is accessible only by authorized process/human and is encrypted. Data transferred to and from Agent is encrypted.
The specific required data extracted from an object depends on the nature of the object. For example, the required data extracted from a Portable Executable (PE) object on a Windows operating system installed on a PC would be fundamentally different from that for an Application Package (APK) object on an Android operating system installed on a smart phone device.
For the purposes of illustration, the potential required data extracted from a PE object on a Windows operating system would include, but would not be limited to, entropy profile, static import API profile, selected embedded strings, selected PE header field entries, full object path, object size and object file attributes such as hidden, system and read-only. Required dynamic data would include, but would not be limited to, URL from where the PE object was downloaded, other objects created (dropped from PE object or downloaded from malicious URL) on the systems by respective PE object, network packets, Internet Protocol (IP) address with port details which are contacted by respective PE object, system changes made by the PE object on a given device, any other coordinating PE object(s) like process watchdog, data sharing, etc.
Indeed, as malware evolves, the specific required data to be extracted is likely to change to maintain the efficacy of Malware Identifiers generated on Server based on the security protection layer, platform, device type, etc.
The Server of the AIRS performs tasks including, but not limited to, retrieving, indexing and storing all data submitted to it by all registered Agents into the central ETI repository, intelligently using the indexed data repository to generate all possible security protection layer Malware Identifiers for a given threat event designed to detect target malicious objects and their variants, coordinating protection against malware objects on participating devices in the respective Ecosystem with optimized scan performance and avoiding detection of any known legitimate objects in the Ecosystem. The exemplary Server workflow is shown in Fig. 5a.
Functionalities of Server as depicted in Fig 5b include, but are not limited to:
1. Device Inventory: Maintain and update protected device inventory in an Ecosystem
2. Device to Security-layer Mapping: Details on all possible security protection layers available for a given device with Agent’s details in an Ecosystem
3. Data Processing: Receive required data from Agent(s), eliminate duplicates among Agents' data within a specific timeframe, lookup/update threat details from Agents’ data in ETI repository and Malware Identifier’s Generic Level (GL) assessment of each request
4. Security Analysis: Correlation with one or more Agent’s relevant malware object(s) data and with respective ETI data, static and/or dynamic malware object analysis. Correlation includes, but is not limited to, same URL (full/domain level), object required data, behaviour data, system environment change data, threat family data, shared data among objects, IP address, specific packer/obfuscation/custom encryption, etc.
5. Generic Malware Identifier Generation and Testing: Based on security analysis data, generate all possible security protection layer generic Malware Identifiers for a given threat event, i.e., generic anomaly rule/behavioural rule or signature/file based generic or heuristic signature or HIPS/HIDS/NIPS/NIDS/Firewall rule, and testing for false positives, false negatives and/or suitable performance
6. Protection Update: Update and dispatch of Malware Identifier to all eligible Agents using device inventory and device to security layer mapping
7. Security Alert: Security log on all security incidents in an Ecosystem and alert mechanism on critical incidents (could be configured by privileged users)
8. Security Dashboard: Privileged users have access to all security incidents for a given device or Ecosystem and which is customizable with report generation facility
9. External Security Server Communication: to get latest security updates (default is one-way communication towards Server and strictly optional is two-way between Server and external global ETI repositories)
Server Workflow for New Threat Event:
Step 1: Agent(s) notifies Server of new threat event which entails an implicit request for Generic Malware Identifiers for all supported security protection layers by making available malware object(s)’ required data from the corresponding device.
Step 2: Server receives Agent(s) notifications along with object data, and processes data. Process data activity includes, but is not limited to, removing duplicate requests from the same Agent within a given time frame. This time period is configurable, but only by privileged users. It also checks local cache of Server for any duplicate requests from other Agents and discards duplicate requests but records such requests from other Agents for correlation purposes, e.g., in the case of a malware outbreak within the Ecosystem.
Step 3: Object’s required data is checked in ETI repository. If found, go to Step 5.
Step 4: Insert Object’s required data into ETI repository.
Step 5: Security analysis includes, but is not limited to, correlation of one or more Agents’ relevant malware object(s) required data and with respective ETI data, static and/or dynamic malware object analysis. Correlation includes, but is not limited to, URL (full/domain level) data, behaviour data, system environment change(s) data, threat family data, shared data among objects, IP address, specific packer/obfuscation/custom encryption.
Step 6: Based on security analysis, data is extracted from submitted object(s) and/or respective similar object(s) ETI data for all possible security protection layers based on the security product(s) specifications.
Step 7: Based on extracted data, generic Malware Identifiers along with varying GL values for each security protection layer and each registered RCR is generated depending on the object type.
Step 8: Select the Malware Identifier with the highest GL value for each unique (security protection layer, RCR) pair. Discard all others, including any selected Malware Identifiers which are already present in the ETI Cache.
Step 9: Test all generated generic Malware Identifiers for false positives, false negatives and/or performance issues. If Malware Identifiers have any issues, regenerate based on other extracted data, i.e., go to Step7. Repeat on test failure until all possibilities of Malware Identifiers for a given security protection layer and RCR threshold value have been generated and tested or suitable Malware Identifiers for a given security protection layer and RCR threshold which passes the test criteria has been found.
Step 10: Add Malware Identifiers which passed the test criteria to ETI Cache. These Malware Identifiers are now ready for dispatch and will be consumed by eligible Agents. Eligible Agent list is fetched from the device inventory data which contains Agent details along with available security product list along with supported security protection layers on that device and its RCR.
Step 11: Notification from Server on Malware Identifier update is sent to eligible Agent list.
Step 12: Eligible Agents will invoke update process for respective security protection layer for the security product to apply the Malware Identifier update. This provides all possible security protection layer immunity from a given malware threat on the respective device.
Step 13: End of process.
In an embodiment, the Malware Identifier Generator utility strategically reorders the components of the compound object required data (feature fingerprint), thus optimizing for scan performance on devices hosting Agents, and generates the correct generic Malware Identifier format understood by the respective security protection layer’s preinstalled Security Product, utilizing technique’s including, but not limited to, Inverted Indices and Frequent Pattern mining. Optimization is required in order to avoid slowing down participating devices which use Malware Identifiers to develop cyber threat immunity.
In an embodiment, the Malware Identifier Generator utility also assigns a Risk Coefficient Rating (RCR) to the generated Malware Identifier to determine which Agent is eligible for the corresponding update. RCR is a measure of the level of aggression of a Malware Identifier such that the more generic it is, the higher would be its RCR value. Higher RCR values imply greater ability to detect variants of the target malware object, but also entail greater risk of false positives with respect to legitimate objects which may be introduced to the Ecosystem in the future.
In an embodiment, the Malware Identifier Generator utility also assigns a Generic Level (GL) rating to the generated Malware Identifier to differentiate between different Malware Identifiers on their ability and range to detect zero-day objects. The GL rating is also a measure of the level of aggression of a Malware Identifier but provides a more granular value such that Malware Identifiers with different GL values would still conform to a single RCR value. Thus, for any given RCR value, it is possible to choose the Malware Identifier with the highest GL value. Note, higher GL values also imply greater ability to detect variants of the target malware object, with the corresponding greater risk of false positives with respect to legitimate objects which may be introduced to the Ecosystem in the future.
Server determines eligible Agents for generated Malware Identifiers using criteria such as:
If the Malware Identifier is compatible with Agent’s host OS and/or preinstalled Security Product(s) and its supported security protection layers. For example, a Malware Identifier for a Windows PE object will not be distributed to an Agent on an Android Smartphone device with a similar preinstalled Mobile Security product. However, for example, URL blocking functionality would be similar on multiple platforms and is therefore platform-independent. So, for a malware URL object, the Malware Identifier may be identical for security products across devices and platforms.
If Agent’s host user’s risk profile as measured by its RCR is greater than or equal to the Malware Identifier’s assigned RCR. For example, devices used by subsets of corporate staff who are more likely to be exposed to malware would have a higher RCR, thus ensuring that their devices’ Agents receive more aggressive Malware Identifiers. RCR for all devices would be configured by the Ecosystem owners.
In order to have access to a much larger, richer repository of data outside of the Ecosystem, Server could have a strictly optional external cloud lookup component enabled. Exposure to a larger dataset is likely to result in more robust Malware Identifiers which match a larger number of malware object variants and have a smaller risk of false positives on objects yet unknown to the Ecosystem. The decision on whether to enable the cloud lookup is solely the prerogative of the Ecosystem owners.
The preinstalled Security Product may be any trusted security product which supports generic detection, i.e., Malware Identifiers, on at least one supported security protection layer.
AIRS of the present invention is a practical solution designed specifically to secure diverse Ecosystems including, but not limited to, enterprise and smart networks in a completely self-contained fashion such that Data Privacy regulations are satisfied since no data is actually required to ever leave the corporate network (NB: the cloud lookup component is strictly optional). AIRS also takes into account different types of devices and platforms, avoids practical issues such as degraded performance on devices, and even provides more aggressive protection based on an ecosystem member’s risk profile.
The AIRS of the present invention is a practical solution to enhance the security of diverse Ecosystems including, but not limited to, enterprise and smart infrastructure. The AIRS of the present invention is a completely self-contained mechanism for an Ecosystem to develop immunity to external threats in an organic manner, without any human intervention.
The present invention has been described with the help of some preferred embodiments. However, various modifications are possible without departing from the scope of the invention.

,CLAIMS:We claim:

1. Adaptive Immune Response System (AIRS) for detecting multifarious malware threats in an ecosystem of networked devices, comprising of Agent (A) installed within all the participating devices, the participating devices having one or more security protection layers, Server (S), and a custom Ecosystem Threat Intelligence (ETI) repository, each protected device within the ecosystem being provided with a compatible software or hardware Agent which is adapted to register, upon its installation with a security product already installed on the device, the Server being run within the ecosystem on hardware that is completely controlled by the owner of the ecosystem, thus preventing any data sent to Server from leaving the ecosystem environment in order to conform to Global Data Privacy Regulation (GDPR) and other data privacy norms.
2. The AIRS as claimed in claim 1, wherein said ecosystem is either an enterprise network or a smart home or a smart office or a smart industry.
3. The AIRS as claimed in claim 1, wherein Agents (A) submit required data for an object such as URL, network packets, system environmental changes, application data, supporting object data or objects used by applications to Server (S) for both legitimate and malware objects based on contextual trigger conditions.
4. The AIRS as claimed in claim 1, wherein Server (S) requires data on known legitimate objects so that the malware identifiers it creates does not cause false positives on the legitimate objects anywhere within the ecosystem.
5. The AIRS as claimed in claim 1, wherein Server (S) provides Device Inventory, Device to Security-layer Mapping, Data Processing, Security Analysis, Generic Malware Identifier Generation and Testing, Protection Update, Security Alert, Security Dashboard and External Security Server Communication.

6. A method of submitting required data for legitimate objects by Agent (A) in the AIRS as claimed in claims 1-5 comprises of the steps of:
- Agent registering with the preinstalled security product and Server (S) upon its first installation;
- Agent requesting the preinstalled security product for the required data for all objects deemed to be legitimate; and
- Agent receiving notification of objects deemed to be legitimate by the preinstalled security product when new objects are introduced onto the device.
7. A method of detecting a malware object at any of the plurality of security
protection layers in the AIRS as claimed in claims 1-5 comprises of the steps of:
- the preinstalled security product(s) examining all objects at the multifarious security protection layers and evaluating them for the presence of malware, a threat event occurring when an object is classified as malware, resulting in a new log entry being added for the object and a prescribed action being performed on it and the preinstalled security product(s) evaluating objects for the presence of malware using static scanning of objects and/or dynamic behaviour verification;
- sending the required data for the reported malware objects to Server (S) by Agent (A) for creating multi-layer generic Malware Identifiers and/or their variants by Server (S) to detect them at all possible security protection layers or other malware objects participating in coordinated and/or multi-stage attacks;
- submitting required data for malware objects by Agent (A) immediately after being notified of a threat event reported by the preinstalled security product; and
- Agent collecting data such as AgentID, device type, architecture, OS and OS version, etc., Security Product(s) with full version information, and delivering this data to Server (S) and simultaneously maintaining a local cache of all required data for optimized performance to avoid duplicating submissions to Server.
8. The method of detecting a malware object as claimed in claim 6, wherein Agent notifies Server (S) of a threat event for a malware object along with data such as AgentID, device type, architecture, OS and OS version, security product(s) with full version information, type of threat event, required data extracted from the malware object and also delivers malware identifiers from Server to preinstalled security product on the same device.
9. The method of detecting a malware object as claimed in claims 6 and 7, wherein the malware identifier generator utility assigns a generic level (GL) rating to the generated malware identifier to differentiate between different malware identifiers on their ability and range to detect zero-day objects.
10. A method for detection of a new threat event in the AIRS as claimed in claims 1-5 comprises of the steps of:
I. Agent (A) notifying Server (S) of a new threat event which entails an implicit request for generic malware identifiers for all supported security protection layers by making available malware object’s required data from the corresponding device;
II. Server receiving Agents’ notifications along with object data, and processing said data, the process data activity including, but not limited to, removing duplicate requests from the same Agent within a time frame which is configurable by privileged users, the Server simultaneously checking its local cache for any duplicate requests from other Agents and discarding duplicate requests while recording such requests from other Agents for correlation purposes, particularly in the case of a malware outbreak within the ecosystem;
III. checking object’s required data in the ETI repository and initiating Step V. below if it is found;
IV. inserting object’s required data into ETI repository;
V. conducting security analysis which includes correlation of required data of one or more Agents’ relevant malware object(s) with respective ETI data and static and/or dynamic malware object analysis, said correlation comprising URL data, behaviour data, system environment change data, threat family data, shared data among objects, IP address and specific packer/obfuscation/custom encryption;
VI. based on security analysis, data being extracted from data submitted for object(s) and/or respective similar object(s) ETI for all possible security protection layers based on the security product(s) specifications;
VII. based on extracted data, generating generic malware identifiers along with varying GL values for each security protection layer and each registered RCR depending on the object type;
VIII. selecting the malware identifier with the highest GL value for each unique security protection layer, RCR pair discarding all others including any selected malware identifiers which are already present in the ETI cache;
IX. testing all generated generic malware identifiers for false positives, false negatives and/or performance issues; when malware identifiers have any issues, regenerating generic malware identifiers based on other extracted data, by initiating Step VII;
X. on test failure, repeating until all possibilities of malware identifiers for a given security protection layer and RCR threshold value have been generated and tested or suitable malware identifiers for a given security protection layer and RCR threshold which passes the test criteria have been found;
XI. adding malware identifiers which passed the test criteria to the ETI cache;
XII. sending notification from Server on malware identifier update to eligible Agent list; and
XIII. invoking update process by eligible Agents for respective security protection layer for the security product to apply the malware identifier update, providing all possible security protection layer immunity from a given malware threat on the respective device.

Dated this 9th day of November, 2018.