To tolerate exploits on multiple attributes, we need to construct cores such that, for subsets of attributes possessed by members of a core, there must be a core member that does not have these attributes. We call a -resilient core a group of hosts in such that, for every attributes of members of , there is at least one host in that does not contain any of these attributes. In this terminology, the cores we have been considering up to this point have been -resilient cores.
To illustrate this idea, consider the following example. Hosts run Windows, Linux, and Solaris as operating systems, and IIS, Apache, and Zeus as Web servers. An example of a -resilient core is a subset composed of hosts with configurations: ; ; . In this core, for every pair of attributes, there is at least one host that contains none of them.
As before, every host builds a -resilient core Core(). To build Core(), host uses the following heuristic:
In Table 4, we show simulation results for this heuristic for . The first column shows the values of load limit () used by the Uniform heuristic to compute cores. We chose values of based on an argument generalized from the one given in Section 5.2 giving the lower bound of . In the second and third columns, we present our measurements for coverage with standard error in parentheses. For each computed core Core, we calculate the fraction of pairs of attributes such that at least one host Core contains none of attributes of the pair. We name this metric 2-coverage, and in the table we present the average across all hosts and across all eight runs of the simulator. 1-coverage is the same as the average coverage metric defined in Section 5.2. Finally, the last column shows average core size.
According to the coverage results, the heuristic does well in finding cores that protect hosts against potential pathogens that exploit vulnerabilities in at most two attributes. A beneficial side-effect of protecting against exploits on two attributes is that the amount of diversity in a -resilient core permits better protection to its client against pathogens that exploit vulnerabilities on single attributes. For values of greater than seven, all clients have all their attributes covered (the average -coverage metric is one and the standard error is zero).
Having a system that more broadly protects its hosts requires more resources: core sizes are larger to obtain sufficiently high degrees of coverage. Compared to the results in Section 5.2, we observe that we need to double the load limit to obtain similar values for coverage. This is not surprising. In our heuristic, for each host, we search for two -resilient cores. We therefore need to roughly double the amount of resources used.
Of course, there is a limit to what can be done with informed replication. As increases, the demand on resources continues to grow, and a point will be reached in which there is not enough diversity to withstand an attack that targets attributes. Using our diversity study results in Table 2, if a worm were able to simultaneously infect machines that run one of the first four operating systems in this table, the worm could potentially infect of the population. The release of such a worm would most likely cause the Internet to collapse. An approach beyond informed replication would be needed to combat an act of cyberterrorism of this magnitude.