TECH NICAL FI ELD

The present disclosure is generally related to software security, and is more particularly related to methods and systems for providing integrity protection for software modules. BACKGROU ND

Protection against high profile software-based security attacks, e.g. Advanced Persistent Threats, is becoming increasingly costly, due to the complexity of the attacks and the fact that attackers are constantly one step in advance of defense mechanisms. Zero-day attack detection and prevention systems try to address this issue by using techniques like heuristics, parallel execution and analysis, system resource usage monitoring, etc. However, no design is perfect and attackers are still able to exploit the increasing number of vulnerabilities.

Current architectures for the detection and protection against malware are typically based on the retroactive analysis of security attacks and of potential vulnerabilities in third-party platform (3PP) software. When performing this retroactive analysis, security researchers try to identify the component affected, the entry point or points, and the software fault that allowed the attacker to perform the attack. By getting an insight into the attack scenario, researchers are then able to extrapolate and discover new vulnerabilities which are handled through, for example, the well- known Common Vulnerabilities and Exposures (CVE) & National Vulnerability Database (NVD processes. In this "cat and mouse" game, the attacker often has the initiative since even if security researchers reveal publicly a security vulnerability, 3PP companies do not immediately patch their products. For example, there are often vulnerabilities known by the security community months - and in some cases years - before the 3PP companies patch their software. Hence, this security patching practice gives no assurance that software is up-to-date with the latest vulnerabilities, and therefore protected.

One category of software-based attacks is referred to as Advanced Persistent Threats (APTs). APTs typically exploit an unknown 3PP vulnerability for installing the attack framework. Since the objective of APTs is often the collection of information, they stay undetected for long periods of time. When they are publicly disclosed, it is usually too late. Some companies offer APT protection/detection systems. In essence, these systems analyze in real time - by using a cloud- based machine, the software being installed on the machine is protected. However, this architecture does not protect against delayed attacks and largely depends on the "intelligence" of the automatic detection system. Given that security attack scenarios change continuously, it is practically impossible to keep such an intelligent engine up to date.

Another problem is that many software development processes do not have a structured approach for embedding security into design. Further, security may be lowered in priority, during the development process, in favor of increased functional features. To overcome this status quo, it is necessary that software be designed to allow automatic detection of malware.

SUMMARY

According to several of the embodiments disclosed herein, software embeds, similarly to humans, unique "trademarks," referred to herein as "genetic markers." Systems according to the techniques described herein allow variations of these "trademarks" or genetic markers only if there's no security impact.

Methods for providing integrity protection for software modules include a method in a marker management system, the method comprising receiving, from a submitting entity, a software module for genetic marking, and generating a genetic marker for the software module, the genetic marker comprising an identifier of the software module, an identity of a first software developer corresponding to the first software developer, and a software fingerprint derived from a runtime image of the software module. The method further comprises generating a signature for the genetic marker with a private key of a public-private key set for the marker management system and appending the signature to the genetic marker, and returning the signed genetic marker, including the appended signature, to the submitting entity. The software fingerprint may be derived, for example, using a hash function. The submitting entity may be, for example, the first software developer or an entity associated with the first software developer.

Another example method, also implemented in a marker management system, includes receiving, from a first software system, a verification request, where the verification request comprises an originating genetic marker corresponding to a second software system from which the first software system received a message and further comprises a terminating genetic marker corresponding to the first software system. The originating genetic marker and terminating genetic marker each comprise, with respect to originating and terminating software modules in the second and first software systems, respectively, an identifier of the respective originating or terminating software module, a software fingerprint derived from a runtime image of the respective originating or terminating software module, and a signature corresponding to the marker management system. The method further includes verifying, based on the originating and terminating genetic markers and based on a model of trusted software interactions, that a transaction between the first and second software systems is a trusted interaction. The marker management system then responds, to the first software system, with an indication that the transaction is a trusted interaction.

Another example method according to the techniques disclosed herein is suitable for

implementation in a software system, and includes verifying that a first software module to be executed or being executed by the first software system is trusted, by (a) determining that a first genetic marker for the software module is signed by a trusted genetic marking system, and (b) generating a software fingerprint from a run-time image of the software module and confirming that the generated software fingerprint matches a fingerprint included in the first genetic marker. This method further comprises installing or continuing to execute the first software module, responsive to said verifying.

In some embodiments, this latter method further includes, for each outgoing message generated by the first software module, attaching the genetic marker to the outgoing message. In some embodiments, the method may include receiving an incoming message for the first software module, the incoming message comprising a second genetic marker corresponding to a source of the incoming message, and sending a first verification request to a marker management system, the verification request comprising the first genetic marker and the second genetic marker. These embodiments further include receiving, in response to the first verification request, an indication that the incoming message corresponds to a trusted transaction, and processing the incoming message, wherein said processing is conditioned on receiving the indication that the incoming message corresponds to a trusted transaction.

Processing nodes and/or cloud-based systems for carrying out one or more of the methods summarized above, and variants thereof, are also detailed herein. An example marker management system according to one or more embodiments comprises one or more nodes comprising respective processors and associated memories, where the respective processors and associated memories are collectively configured to receive, from a submitting entity, a software module for genetic marking, and generate a genetic marker for the software module, the genetic marker comprising an identifier of the software module, an identity of a first software developer corresponding to the first software developer, and a software fingerprint derived from a runtime image of the software module. The respective processors and associated memories in these embodiments are further configured to generate a signature for the genetic marker with a private key of a public-private key set for the marker management system and appending the signature to the genetic marker, and return the signed genetic marker, including the appended signature, to the submitting entity. Again, the software fingerprint may be derived, for example, using a hash function. Likewise, the submitting entity may be, for example, the first software developer or an entity associated with the first software developer.

Another example marker management system according to some of the presently disclosed embodiments comprises one or more nodes comprising respective processors and associated memories, where the respective processors and associated memories are collectively configured to receive, from a first software system, a verification request, the verification request comprising an originating genetic marker corresponding to a second software system from which the first software system received a message and further comprising a terminating genetic marker corresponding to the first software system. The originating genetic marker and terminating genetic marker each comprise, with respect to originating and terminating software modules in the second and first software systems, respectively, an identifier of the respective originating or terminating software module, a software fingerprint derived from a runtime image of the respective originating or terminating software module, and a signature corresponding to the marker management system. The respective processors and associated memories in these embodiments are further configured to verify, based on the originating and terminating genetic markers and based on a model of trusted software interactions, that a transaction between the first and second software systems is a trusted interaction, and respond, to the first software system, with an indication that the transaction is a trusted interaction. Still other embodiments disclosed herein include a software processing system comprising one or more processors and associated memory, where the one or more processors and associated memory are configured to verify that a first software module to be executed or being executed by the software processing system is trusted. This is done by (a) determining that a first genetic marker for the software module is signed by a trusted genetic marking system, and (b) generating a software fingerprint from a run-time image of the software module and confirming that the generated software fingerprint matches a fingerprint included in the first genetic marker. The one or more processors and associated memory are further configured to install or continue to execute the first software module, responsive to said verifying.

In some embodiments, a software processing system like that summarized above, or variants thereof, is further configured to receive an incoming message for the first software module, the incoming message comprising a second genetic marker corresponding to a source of the incoming message, and send a first verification request to a marker management system, the verification request comprising the first genetic marker and the second genetic marker. These embodiments are further configured to receive, in response to the first verification request, an indication that the incoming message corresponds to a trusted transaction, and process the incoming message, where said processing is conditioned on receiving the indication that the incoming message corresponds to a trusted transaction. BRI EF DESCRIPTION OF THE FIGU RES

Figure 1 illustrates an example deployment of a genetically marked software unit.

Figure 2 is a process flow diagram illustrating an example training algorithm for a self-adaptive software genome analyzer (SASGA).

Figure 3 illustrates an example interaction using genetic markers in a self-adaptive architecture. Figure 4 is a process flow diagram illustrating an example method for providing integrity protection for software modules, as implemented, for example, in a marker management system.

Figure 5 is a process flow diagram illustrating another example method for providing integrity protection for software modules, again as implemented, for example, in a marker management system. Figure 6 is a process flow diagram illustrating another example method for providing integrity protection for software modules, as implemented, for example, in a software processing system that is installing or executing a software module with a genetic marker.

Figure 7 is a block diagram illustrating components of an example marker management system. Figure 8 is a block diagram illustrating components of an example software processing system. DETAILED DESCRI PTION

The molecular unit of heredity in humans is the gene. Genes encode genetic information in long strands of Deoxyribonucleic Acid (DNA). Two chains of DNA twist around each other to form a DNA double helix. The genome of an organism or cell is stored in one or more chromosomes, the chromosomes consisting of a long DNA helix. Viruses or microbes representing the cause of many diseases are made of some of these genes. So, how does the human organism recognize them and then build defense mechanisms? The answer to this question is very complex, but in essence it involves a checking for matches in genetic patterns, at various levels.

The techniques disclosed herein transpose some concepts from genetics into software development and integrity management, for improved security against attacks of various types. A genetic marker is introduced into the design of software units (functions, procedures, applications, etc.). This marker has a unique identity with a dual structure. Its value reflects the integrity of the software unit and it cannot be faked by an entity other than a trusted verification system. A software unit processing data sent by another internal or external software units forwards its own genetic marker, as well as the marker associated with the originator of the input data, to a software genome analyzing unit. The analyzing unit builds a self-adaptive model of the genetic markers (interaction pattern), which is used to infer whether the interaction pattern is an attack. Upon verifying that the transaction between the software units is a trusted interaction, the analyzing unit sends an appropriate indication to the requester. The techniques disclosed herein may use a self-organizing neural network to detect security attacks, where the self-organizing processes the genetic marker information provided by software units receiving incoming data from another software unit/s.

According to some embodiments of the presently disclosed techniques, when a software developer releases a new version of a software unit, it forwards the executable to a Genetic Marker

Management System (GM MS). This central node, which may be a cloud deployed system, for example, generates a genetic marker for the software unit. In addition to the information typically found in a digital certificate, genetic markers contain some specific attributes. These attributes may include, for example, several of the following:

1. Identity of the GM MS system generating the genetic marker for the software unit 2. Identity of the software unit

3. Identity of the software developer who modified the software unit being signed with a genetic marker

4. Fingerprint of the runtime image of the software unit (e.g., SHA512 hash of the memory image)

5. Signature of the Genetic Marker Management System.

Genetic markers produced in this manner are unique, since, for example, they are based on the fingerprint of the runtime image of the software and are generated and signed by the GMMS network node/s. The GM MS nodes each generate and store securely a set of public/private keys, In a manner similar to that used for Certificate Authorities in a Private Key Infrastructure (PKI). The private key is used by the G M MS node for signing the genetic marker. The public key is used when installing the software unit on the target system, for validating that the genetic marker was not modified and thus contains an accurate fingerprint of the runtime image of the software unit. The fingerprint included in the genetic marker can be compared with a version of the fingerprint generated, by an installing system, from the software unit being installed.

The operation of updating a genetically marked software unit may be referred to as a mutation. Mutations are tracked through the developer part of the genetic marker, which keeps a cumulative record of the developers that have changed the software.

Mutations, as well as the first released version - called mutation 0 - may have security

vulnerabilities. To exploit these vulnerabilities, an attacker must access the software unit via input data, memory (buffers, stack, code segment etc.), disk access, etc. According to some of the techniques described herein, secure software units trust the input received from other trusted units. Input received from trusted units carries a genetic marker, which can be validated by the Genetic Marker Management System to prove the trust relationship.

When installing a software unit which is signed using a genetic marker on a target system, the operating system (OS) of the installing system performs the following operations, according to some embodiments:

1. checks whether the genetic marker of the software unit is genuine, i.e., it is signed by a known G M MS system.

2. registers the software unit to a local Genetic Marker Handler (GM H). The following information is saved :

• identity of the software unit (e.g. executable name),

• genetic marker of current mutation of the software unit, and

• fingerprint of the runtime image of the software unit

3. registers the Genetic Marker Handler as promiscuous IP driver for outgoing I P traffic sent by applications on the target system. This allows the GM H to intercept outgoing traffic from the genetically marked software unit and append the Genetic Marker of the software unit to the body of a protocol data unit in a lower layer of the protocol statck, e.g., to the IP body or the TCP/U DP body. In addition to this, when notified by a Software Integrity Handler (SI H) that the software unit was compromised, it stops appending the Genetic Marker to the outgoing traffic sent by the software unit.

4. creates a Software Integrity Handler (SIH) for the genetically marked software unit.

This handler retrieves from the OS the memory address where the software unit is loaded. After the software is loaded into the memory, the Software Integrity Handler retrieves from the Genetic Marker Handler the fingerprint/s of the genetically marked software unit and checks, from time to time, whether the code segment of the software unit was modified. This may be done periodically, for example, or on a per-message basis, or according to some combinations of these approaches. If the SIH detects a modification, it notifies the Genetic Marker Handler that the software unit has been compromised. Figure 1 shows an example of the components interacting as per the description above, in a target system 100 interacting with a Genetic Marker Management System 110. It should be noted that the GM H and SIH components in the target system 100 are running at the kernel level (e.g., as drivers); hence, they have the same security protection level as the OS.

Some embodiments of the presently disclosed techniques may employ neural network capable of real-time learning, which builds a model of the trusted software units interacting one another. This neural network may be referred to, for example, as a Self-Adaptive Software Genome Analyzer (SASGA). Input data used during the learning and the recognition phases can be represented by the tuple (oGeneticMarker, tGeneticMarker), where "oGeneticMarker" and "tGenetic Marker" refer, respectively to the genetic markers of a software unit that initiates a message or other transaction, i.e., the originating software, and the target of the message or other transaction, i.e., the terminating software unit. Note that the originating and terminating software units may be in the same node or in different nodes, in various embodiments. The SASGA may be implemented, for example, as a cloud based component capable of learning from a large set of training examples.

Figure 2 describes the steps of an example SASGA learning algorithm: 1. The method shown in Figure 2 begins with a SASGA training step, which includes training based on an initial set of input tuples, as shown at block 210. Next mutation 0 markers are accepted during a friendly testing phase, as shown at block 220. These markers are associated to the first released version of the software units interacting one another. The SASGA component generates clusters, according to artificial neural network clustering, based on the input tuples, e.g., (oGeneticMarker, tGeneticMarker), used during the training phase.

2. The SASGA then learns the first order mutations, e.g., where only the originating side suffers mutations. This is shown at block 230. The clusters modeling these mutations are labeled distinctively, allowing the SASGA neural network to be subsequently rolled back, in case of false positives. In this phase, the network learns the mutations generated by the trusted developers on the originating side. 3. Next, the SASGA learns the second order mutations, e.g., where only the terminating side suffers mutations. This is shown at block 240. As with the previous step, the clusters modeling the mutations of the terminating side are labeled distinctively, for allowing to roll back the SASGA neural network in case of false positives. In this phase, the network learns the mutations generated by the trusted developers of the terminating side.

It will be appreciated that the steps shown in blocks 230 and 240 can be repeated, for subsequent mutations, with each mutation being labeled to allow for rolling back the SASGA neural network. Rolling back the SASGA neural network allows the system to correct itself after learning false positives. Criteria for rolling back may include, for example, the detection of a mutation where the developer does not have a genetic marker, or the detection of a mutation where one of the sides in a transaction has received input from a source not sending a genetic marker. The trust in the genetic marker chain is ensured by the fact that the genetic markers are appended by a protected component in the operating system of a node executing the techniques, i.e., a Genetic Marker Handler as described. Therefore, an outgoing request from a software unit genetically marked would only contain a genetic marker if the component received genetically marked incoming requests. Software units which do not receive inputs are inherently secure, since the Software Integrity Handler described above ensures that the memory image of the software unit does not change.

Once the initial training of the SASGA is completed, the network can become operational. Any mutation not learned is rejected, according to a validation process described below. This conservative behavior protects the analyzer from generating false positives. To address this issue, it is possible to run customized learning phases during the operational phase. Whenever a new mutation is advertised for the originating side or the terminating side, the SASGA is then re-trained. The neural network can be rolled back in case a non-valid mutation is learned, as per the procedure described above.

Figure 3 illustrates an example use of genetic markers for detecting compromised software units, as might be used, for example, in a client-server architecture in the context of a telecommunications network. The client and server nodes can be, for example, any node in the telecom network's Packet Core or in the IMS architecture, interacting with each other over the trusted domain. However, since the software deployed in the trusted domain is typically maintained by the telecom operator, it is unlikely to be attacked internally. What is considered high risk and hence particularly suitable for the presently disclosed techniques, is the interface between an external system, e.g., a mobile terminal ("user equipment" or "U E" in the LTE architecture) and an entry system to the network, e.g., a base station (the "eNodeB," in LTE terminology). An example interaction between the client and the server is described below, with the numbered steps below corresponding to the same numbers in Figure 3:

1. The originating software (SW) unit 310 sends an arbitrary request to the terminating SW unit 320. The Genetic Marker Handler of the originating SW unit 310 intercepts the I P traffic and retrieves from its OS the name of the application that has originated the request. Using this information, it appends the genetic marker of the originating software unit 310, i.e., (oGeneticMarker), to the IP packet or, more generally, to the body of a lower level protocol in the protocol stack, such as the I P protocol, the TCP protocol, the U DP protocol, etc. Additional parameters, are included in the request i.e. operation name, data. An example of the construction of the request is illustrated in block 315, in Figure 3. In the illustrated example, the genetic marker is added to the TCP/U DP body; in other embodiments, it might instead be added to the I P body, for example.

2. The terminating system 320 retrieves the genetic marker of the terminating

software unit 320, i.e., (tGeneticMarker), from the terminating Genetic Marker Handler. It uses, for this purpose, information such as the terminating port, I P address, etc. It queries the SASGA 330, which may be, for example, implemented as a cloud-based application, to verify whether the tuple (oGeneticMarker, tGeneticMarker) is a learned (and thus trusted) SW interaction.

3. SASGA 330 answers to the terminating SW unit 320 that the SW interaction is trusted.

4. The terminating SW unit 320 responds to the request from originating SW unit 310.

The Genetic Marker Handler of the terminating SW unit 320 intercepts the I P traffic and retrieves from the OS the name of the application that has generated the response. Using this information, it appends the genetic marker of the terminating software unit (tGeneticMarker) to the IP packet or to the body of some other lower level protocol in the protocol stack, such as the TCP protocol, the U DP protocol, etc. The construction of this response with the genetic marker for the terminating SW unit 320 is shown in block 325 of Figure 3. Again, the illustrated example shows the genetic marker being added to the TCP/U DP body; it might be added at a different layer of the protocol stack in other embodiments. The presence of this genetic marker indicates that the terminating SW unit 320 has either generated the answer internally or, if the terminating side used information from external systems, the incoming data was genetically marked.

5. The originating SW unit 310 retrieves the genetic marker of the originating software unit (oGeneticMarker) from the originating Genetic Marker Handler. It uses for this purpose information such as the originating port, I P address, etc. It queries the

SASGA 3330 to verify whether the tuple (oGeneticMarker, tGeneticMarker) is a learned (and thus trusted) SW interaction.

6. SASGA 330 answers to the originating SW unit 310 that the SW interaction is trusted, thus verifying that the response from the terminating SW unit 320 may be processed.

Explanatory callouts in Figure 3 provide details on the software layers involved in the interaction flow. The SW unit (i.e., the application) may be unaware of the fact that the Genetic Marker Handler will append a genetic marker. Since the Genetic Marker Handler runs at the OS kernel level, in the event the SW unit is compromised, it cannot hijack the kernel for appending a fake genetic marker into the outgoing request/response.

Genetic markers are transparently appended to the outgoing requests/responses by the Genetic Marker Handler, e.g., by appending the genetic markers to the body of a lower level protocol data unit in the protocol stack, for example, at the IP protocol layer, the TCP protocol layer, the U DP protocol layer, etc. This design ensures that all existing application programming interfaces (APIs) exposed by the SW unit are backwards compatible. As the Genetic Marker Handler runs at OS kernel level, is has the required permissions for acting as a filtering driver for the data packets sent by applications to the TCP/U DP and I P stacks.

Technical benefits that may be realized using some or all of the techniques described herein include that the techniques can be used to ensure that data transferred between SW units is part of a trust chain. SW version changes are accommodated by various embodiments of these techniques, which also provide solutions for false positives, i.e., transactions that are determined to be untrusted.

In view of the detailed examples and description provided above, it will be appreciated that the presently disclosed techniques may be understood to include methods for providing integrity protection for software modules. These methods include, for example, several methods implemented in a marker management system, referred to above as a Genetic Marker Management System. Such a marker management system may be implemented in the "cloud," for example, i.e., in one or more servers accessible to a client via the Internet or other network, or in a standalone node known to the clients.

Figure 4 illustrates a first example method for providing integrity protection for software modules, with the method comprises receiving, from a submitting entity, a software module for genetic marking, and generating a genetic marker for the software module. This is shown at blocks 410 and 420. The genetic marker comprises at least an identifier of the software module, an identity of a first software developer corresponding to the first software developer, and a software fingerprint derived from a runtime image of the software module. The submitting entity may be, but is not necessarily, the first software developer. In some embodiments, the first software developer is a known trusted developer, to the marker management system, and the method comprises verifying that the software module was received from the first software developer, prior to generating the genetic marker.

The method further comprises generating a signature for the genetic marker with a private key of a public-private key set for the marker management system and appending the signature to the genetic marker, as shown at block 430. The marker management signature then returns the signed genetic marker, including the appended signature, to the submitting entity, as shown at block 440. The software fingerprint may be derived, for example, using a hash function applied to the runtime image of the software. The submitting entity may be, for example, the first software developer or an entity associated with the first software developer. In some embodiments or instances of the method shown in Figure 4, the software module comprises modifications performed by the first software developer and further comprises previous modifications performed by a second software developer. In these embodiments, generating the genetic marker comprises including an identity of the second software developer in the genetic marker. Changes to a genetically marked software unit are thus tracked through the software developer identity attribute in the genetic marker. This attribute contains the list of all developers who made changes to this SW unit. Every mutation (change) of the SW unit leads to an update of this attribute.

The GM MS must learn all mutations. Since a developer can make changes at different points in time, the G M MS can perform a strict learning (i.e., mutations are learned in sequence, therefore they must carry a timestamp as well) or a non-sequenced learning. In the non-sequenced learning, what matters is just that the developer is known, but not when he performed the change. Figure 5 illustrates another example method, also implemented in a marker management system, includes receiving, from a first software system, a verification request, where the verification request comprises an originating genetic marker corresponding to a second software system from which the first software system received a message and further comprises a terminating genetic marker corresponding to the first software system. This is shown at block 510, and corresponds generally to step 2 of Figure 3. The originating genetic marker and terminating genetic marker each comprise, with respect to originating and terminating software modules in the second and first software systems, respectively, an identifier of the respective originating or terminating software module, a software fingerprint derived from a runtime image of the respective originating or terminating software module, and a signature corresponding to the marker management system. As discussed above, the genetic markers may also include one or more identifiers for software developers that produced and/or modified the software modules.

The method shown in Figure 5 further includes verifying, based on the originating and terminating genetic markers and based on a model of trusted software interactions, that a transaction between the first and second software systems is a trusted interaction. This is shown at block 520. The marker management system then responds to the first software system, as shown at block 530, with an indication that the transaction is a trusted interaction. This corresponds generally to step 3 of Figure 3. The model of trusted software interactions may be a neural network model, for example, as was described above. In some embodiments, the verification request includes an indicator of the transaction or type of transaction, where the verifying is based further on the indicator. This indicator may be the "OPER" parameter shown in Figure 3, for example, and allows the verification process to not only confirms that transactions in general are allowed between these two software systems, but also to confirm that a specific type of transaction is allowed or not, as the case may be.

In some embodiments, the method of Figure 5, or variants thereof, may further include receiving, from the second software system, a verification request, the verification request comprising an originating genetic marker corresponding to the first software system, from which the second software system received a response to the message, and further comprising the terminating genetic marker corresponding to the first software system and the originating genetic marker corresponding to the second software system. It will be appreciated that this corresponds generally to step 5 in Figure 3. The method, in these embodiments, further comprises verifying, based on the originating and terminating genetic markers and based on the model of trusted software interactions, that the response from the first software system is a trusted interaction, and responding, to the second software system, with an indication that the response is a trusted interaction. This latter indication corresponds generally to step 6 in Figure 3.

Figure 6 illustrates an example method, according to the techniques disclosed herein, suitable for implementation in a software system, such as in a system executing a client application. As shown at block 610, the method includes verifying that a first software module to be executed or being executed by the first software system is trusted, by (a) determining that a first genetic marker for the software module is signed by a trusted genetic marking system, and (b) generating a software fingerprint from a run-time image of the software module and confirming that the generated software fingerprint matches a fingerprint included in the first genetic marker. This method further comprises installing or continuing to execute the first software module, responsive to said verifying, as shown at block 620.

In some embodiments, the method further includes, for each outgoing message generated by the first software module, attaching the genetic marker to the outgoing message. In some

embodiments, the method may include receiving an incoming message for the first software module, the incoming message comprising a second genetic marker corresponding to a source of the incoming message, and sending a first verification request to a marker management system, the verification request comprising the first genetic marker and the second genetic marker. These embodiments further include receiving, in response to the first verification request, an indication that the incoming message corresponds to a trusted transaction, and processing the incoming message, wherein said processing is conditioned on receiving the indication that the incoming message corresponds to a trusted transaction.

It will be appreciated that one or several of the methods described above may be implemented in any of a variety of processing nodes and/or cloud-based systems. An example marker management system according to one or more embodiments comprises one or more nodes comprising respective processors and associated memories. Figure 7 illustrates an example marker management system comprising only a single such node 710, with respective processor 715 and memory 720 executing a marker management process 725, but it will be appreciated that the functionality provided by the marker management system of Figure 7 may be implemented in a distributed fashion, i.e., across several nodes. Whether implemented in one or several nodes, the respective processors 715 and associated memories 715 and 720 of the marker management system in some embodiments are collectively configured to receive, from a submitting entity, a software module for genetic marking, and generate a genetic marker for the software module, the genetic marker comprising an identifier of the software module, an identity of a first software developer corresponding to the first software developer, and a software fingerprint derived from a runtime image of the software module. The respective processors and associated memories in these embodiments are further configured to generate a signature for the genetic marker with a private key of a public-private key set for the marker management system and appending the signature to the genetic marker, and return the signed genetic marker, including the appended signature, to the submitting entity. Again, the software fingerprint may be derived, for example, using a hash function. Likewise, the submitting entity may be, for example, the first software developer or an entity associated with the first software developer.

In some embodiments of a marker management system, whether implemented in a single node or several, the respective processors 715 and associated memories 720 are collectively configured to receive, from a first software system, a verification request, the verification request comprising an originating genetic marker corresponding to a second software system from which the first software system received a message and further comprising a terminating genetic marker corresponding to the first software system. The originating genetic marker and terminating genetic marker each comprise, with respect to originating and terminating software modules in the second and first software systems, respectively, an identifier of the respective originating or terminating software module, a software fingerprint derived from a runtime image of the respective originating or terminating software module, and a signature corresponding to the marker management system. As discussed above, the genetic markers may also include one or more identifiers for software developers that produced and/or modified the software modules. The respective processors 715 and associated memories 720 in these embodiments are further configured to verify, based on the originating and terminating genetic markers and based on a model of trusted software interactions, that a transaction between the first and second software systems is a trusted interaction, and respond, to the first software system, with an indication that the transaction is a trusted interaction.

It will be appreciated that the functionality described above for the marker management system may be understood as being carried out by functional modules, e.g., hardware and/or software units in one or several nodes. Thus, for example, an example marker management system consistent with the embodiments described herein may comprise a first receiving module for receiving, from a submitting entity, a software module for genetic marking, and a marker generation module for generating a genetic marker for the software module, the genetic marker comprising an identifier of the software module, an identity of a first software developer corresponding to the first software developer, and a software fingerprint derived from a runtime image of the software module. This marker management system may further comprise a signature module for generating a signature for the genetic marker with a private key of a public-private key set for the marker management system and appending the signature to the genetic marker, and a transmitting module for returning the signed genetic marker, including the appended signature, to the submitting entity.

This or similar embodiments may likewise comprise a second receiving module for receiving, from a first software system, a verification request, the verification request comprising an originating genetic marker corresponding to a second software system from which the first software system received a message and further comprising a terminating genetic marker corresponding to the first software system, where the originating genetic marker and terminating genetic marker each comprise, with respect to originating and terminating software modules in the second and first software systems, respectively, an identifier of the respective originating or terminating software module, a software fingerprint derived from a runtime image of the respective originating or terminating software module, and a signature corresponding to the marker management system. This example marker management system may further comprise a verification module for verifying, based on the originating and terminating genetic markers and based on a model of trusted software interactions, that a transaction between the first and second software systems is a trusted interaction, as well as a responding module for responding to the first software system with an indication that the transaction is a trusted interaction. Figure 8 illustrates an example software processing system 800 configured to carry out one or more of the methods described herein. Software processing system comprises one or more processors 810 and associated memory 820, where the one or more processors 810 and associated memory 820 are configured to carry out an integrity verification processor 825, to verify that a first software module to be executed or being executed by the software processing system is trusted. This is done by (a) determining that a first genetic marker for the software module is signed by a trusted genetic marking system, and (b) generating a software fingerprint from a run-time image of the software module and confirming that the generated software fingerprint matches a fingerprint included in the first genetic marker. The one or more processors 810 and associated memory 820 are further configured to install or continue to execute the first software module, responsive to said verifying. In some embodiments, a software processing system 800 like that summarized above, or variants thereof, is further configured to receive an incoming message for the first software module, the incoming message comprising a second genetic marker corresponding to a source of the incoming message, and send a first verification request to a marker management system, the verification request comprising the first genetic marker and the second genetic marker. These embodiments are further configured to receive, in response to the first verification request, an indication that the incoming message corresponds to a trusted transaction, and process the incoming message, where said processing is conditioned on receiving the indication that the incoming message corresponds to a trusted transaction.

As was the case with the marker management systems described above, it will be appreciated that the functionality described above for the software processing system 800 may be understood as being carried out by functional modules, e.g., hardware and/or software units in one or several nodes. Thus, an example software processing system may comprise a verification module for verifying that a first software module to be executed or being executed by the first software system is trusted, by (a) determining that a first genetic marker for the software module is signed by a trusted genetic marking system, and (b) generating a software fingerprint from a run-time image of the software module and confirming that the generated software fingerprint matches a fingerprint included in the first genetic marker. The example software processing system may further comprise an execution module for installing or continuing to execute the first software module, responsive to the verifying performed by the verification module.

Additional embodiments of the presently disclosed invention include computer program products comprising program instructions for carrying out any one or more of the methods described above, and variants thereof, as well as carriers carrying or having stored thereon one or more of these computer program products, such carriers including for example, electronic signals, optical signals, radio signals, and computer-readable media, including non-transitory computer-readable media such as memories, optical disks, magnetic storage, etc.