1. An established field
Changing a system's observable configuration to undermine an attacker's reconnaissance — moving-target defence (MTD) — has been an active area of academic and government-funded research for over a decade, with a substantial published literature and several surveys. ACSE-PME is a contribution to that field. It is not the invention of surface rotation, and it is not a replacement for the field's other techniques.
This page sets out the established work we build on, says plainly what is not new, and states our specific contribution — limited to what is recorded as measured in our claims ledger.
2. Established approaches
| Approach | What it changes | Representative work | Relation to ACSE-PME |
|---|---|---|---|
| Random host / IP address mutation | The IP address a host answers on, over time | Jafarian, Al-Shaer & Duan, "OpenFlow Random Host Mutation", ACM HotSDN 2012 | ACSE-PME's address surface rotates the address a service answers on; the mechanism and intent are the same class of idea. |
| Network configuration randomisation (mutable networks) | Network-level configuration parameters | E. Al-Shaer, "Toward Network Configuration Randomization for Moving Target Defense", in Moving Target Defense (Springer), 2011 | Related: configuration-level randomisation. ACSE-PME focuses on host-observable protocol/cryptographic identity rather than network fabric configuration. |
| Port hopping / service-port randomisation | The TCP/UDP port a service listens on | A recurring technique in the MTD literature (described generically here) | ACSE-PME rotates listening ports as one of several surfaces; not novel on its own. |
| Address-space layout randomisation & software diversity | In-memory code/data layout of a process | Shacham et al., "On the Effectiveness of Address-Space Randomization", ACM CCS 2004 | Different layer (process memory, not network-observable identity). Its key lesson — low effective entropy is brute-forceable — directly informs our entropy requirements. |
| Short-lived workload identities & automated certificate rotation | Service identities and X.509 certificates, on a short lifecycle | SPIFFE / SPIRE (SVIDs); ACME (RFC 8555) | Overlapping intent for certificates and identities. ACSE-PME rotates certificate keys and TLS presentation as part of a broader, externally-verified surface set. |
| Rotating session tokens / credentials | Session tokens and credentials, on expiry/rotation | Established practice (described generically) | ACSE-PME rotates session/identity material where built; see the scope page for what is verified today. |
| Surveys of the field | — | Okhravi et al., "Survey of Cyber Moving Targets", MIT Lincoln Laboratory TR-1166, 2013; Cho et al., "Toward Proactive, Adaptive Defense: A Survey on Moving Target Defense", IEEE Communications Surveys & Tutorials, 2020 (arXiv:1909.08092) | These catalogue the techniques above and the field's open problems, several of which we also face. |
| Commercial MTD products | Varies (e.g. endpoint memory MTD) | Commercial products exist (e.g. Morphisec, endpoint memory MTD) | We have not performed a feature-by-feature comparison and make no comparative claim. |
Citation rule for this page: only the works named above, or ones verifiable from a primary source, are cited. Where a specific programme or product could not be verified from a primary source, it is described generically rather than named.
3. What is not new
Stated plainly: rotating IP addresses, ports, certificates, keys and tokens to shorten the useful life of reconnaissance is established practice, explored in the works above and in commercial products. ACSE-PME does not claim to have invented surface rotation.
4. What ACSE-PME contributes
Our contribution is a specific combination, and each item below is stated only as far as the claims ledger records it as measured. Which surfaces are verified today, and on which platforms, is on the scope page.
a. The rotated object is protocol / cryptographic identity. The surface is the host's observable protocol identity: the TCP/IP stack fingerprint, the TLS server's preference classes and certificate, and listening ports — together with the further surfaces added in Wave 8 (for example the service address and its published DNS name, and the management-plane credentials of network devices) that the ledger marks as verified. We list only the verified ones on the scope page.
b. The change is verified from outside, not self-reported. An independent verifier observes each protected host the way an external attacker would. The Control Plane decides the Kali-Invariant verdict from those signed observations — never from the node's own claim about itself. An agent that lies about what it rotated is detected, because the verdict is formed off the node. This external-verification property is, to our knowledge, the part of the design least represented in the prior work above.
c. A signed, hash-linked audit chain. Every surface transition is recorded in a per-node audit chain whose records are signed and hash-linked, so any removal or reordering breaks the chain at the point of tampering.
d. A small coordination protocol (ASMP/1.0), formally analysed. Estate-wide coordination uses a small protocol whose handshake, estate-wide "Defensive Leap", and node-granted protected-action designs were analysed in ProVerif under a Dolev-Yao adversary. The exact scope: handshake secrecy and mutual authentication, leap origin authentication (with the relay checking a per-node envelope), and node-granted protected actions are established for the modelled protocol. Not modelled: a single-acceptance property (shown by tests, not ProVerif), a zero-knowledge property (none was claimed), and forward secrecy — which the protocol does not provide. See WP-07.
5. Open problems we are working on
- Measuring time-to-compromise in the field, not only in the lab.
- Forward secrecy for the coordination protocol (a future ASMP revision).
- Reducing the trust placed in the Control Plane (it is currently the most sensitive component — see the scope page).
- Independent assessment: external penetration testing and third-party review.
Patentability is determined by the patent office on examination. ACSE-PME is the subject of Indian patent application IN202641070690 (published 19 June 2026; pending examination). This page describes our technical positioning relative to the field, not a legal opinion on novelty.
References
- J. H. Jafarian, E. Al-Shaer, and Q. Duan. "OpenFlow Random Host Mutation: Transparent Moving Target Defense using Software Defined Networking." ACM HotSDN, 2012.
- E. Al-Shaer. "Toward Network Configuration Randomization for Moving Target Defense." In Moving Target Defense, Springer, 2011.
- H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh. "On the Effectiveness of Address-Space Randomization." ACM CCS, 2004.
- SPIFFE / SPIRE — Secure Production Identity Framework for Everyone (SVIDs). spiffe.io.
- R. Barnes, J. Hoffman-Andrews, D. McCarney, and J. Kasten. "Automatic Certificate Management Environment (ACME)." RFC 8555, IETF, 2019.
- H. Okhravi, M. A. Rabe, T. J. Mayberry, W. G. Leonard, T. R. Hobson, D. Bigelow, and W. W. Streilein. "Survey of Cyber Moving Targets." MIT Lincoln Laboratory, Technical Report TR-1166, 2013.
- J.-H. Cho et al. "Toward Proactive, Adaptive Defense: A Survey on Moving Target Defense." IEEE Communications Surveys & Tutorials, 2020. arXiv:1909.08092.