Pith. sign in

REVIEW 4 major objections 5 minor 46 references

Space Cybersecurity Testbed: Fidelity Framework, Example Implementation, and Characterization

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper proposes a seven-attribute framework for characterizing the fidelity of space cybersecurity testbeds and shows it can guide construction of a working four-segment testbed that reproduces real-world satellite attacks.

desk verdict A genuinely useful fidelity vocabulary for space cyber testbeds, with a detailed testbed write-up; the attack demonstrations need data or softer claims. read the letter →

arxiv 2507.11763 v1 pith:NA2Q4C77 submitted 2025-07-15 cs.CR

Jose Luis Castanon Remy , Caleb Chang , Ekzhin Ear , Shouhuai Xu This is my paper · ORCID
classification cs.CR
keywords spacecybersecuritytestbedfidelitysatellitesecuritythreatmodelingmission-basedattackCubeSatRFjammingcyberriskanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper aims to give the space-cybersecurity community a systematic way to describe what a testbed can and cannot do, instead of comparing ad-hoc hardware lists. It proposes seven attributes that characterize the system models, threat models, and defenses a testbed can accommodate, and it claims this is the first such fidelity framework. To show the framework works, the authors used it to guide the design of a concrete four-segment testbed containing a CubeSat, a ground station, user terminals, and real RF links, then characterized that testbed with the same attributes. The payoff of the claim is a shared vocabulary for testbed design, fair comparison, and mission-specific cyber risk analysis.

What carries the argument

The load-bearing mechanism is the seven-attribute fidelity framework built on a segment-component-module-element hierarchy for hardware and an element-level function graph for missions. A function graph is a directed graph whose nodes are hardware or software elements and whose arcs show how commands or data move between them; one mission can be implemented by one function or several. This structure is what lets the framework map real-world attacks onto concrete paths: an attack is described by its point of entry, vector, exploited vulnerability, and consequence, and mission-based attack fidelity expresses the same attack as a disruption of specific arcs or nodes in a function graph. The seven attributes also serve as an iterative design checklist, with hardware and mission fidelity set first and firmware, software, and data collection developed to satisfy them.

What would settle it

Use the framework to describe two testbeds that differ only in that one has a single satellite and the other has a satellite constellation connected by inter-satellite links; if the seven attributes produce indistinguishable fidelity profiles, the framework misses a fidelity-relevant feature and the claim of systematic characterization fails.

Watch

Extended reading notes

Core claim

The central claim is that the fidelity of a space cybersecurity testbed is not a vague property but can be decomposed into seven attributes: hardware fidelity, firmware and software fidelity, data collection fidelity, mission fidelity, threat model fidelity, mission-based attack fidelity, and defense capability fidelity. Four attributes describe system models, two describe threat models, and one describes defenses. Under this view, hardware is organized into segments, components, modules, and elements, and missions are represented as directed graphs of functions whose nodes are elements and whose arcs are command or data flows. The authors demonstrate the framework by building a four-segment testbed with real components and showing that it accommodates two real-world attack classes against the 2008 NASA Terra incident: seizure of satellite control through the ground station and RF downlink jamming.

Load-bearing premise

The load-bearing premise is that the seven attributes built on the segment-component-module-element hierarchy are enough to capture the fidelity differences that matter among space testbeds; the paper itself concedes the attribute set may not be comprehensive and that threat-model fidelity has no quantitative measure yet.

Editorial extensions

If this is right

  • Space testbeds can be compared through a common seven-attribute profile instead of informal hardware descriptions.
  • The function-graph representation turns mission impact into something tangible: an attack's reach through elements and arcs shows which missions break and where hardening helps.
  • Open-source flight software such as the core Flight System, observed to have segmentation faults and memory-injection risk, becomes a concrete candidate for hardening in any testbed that uses it.
  • The testbed's real RF links and absence of simulated segments let it reproduce the two demonstrated threat classes, seizure of satellite control and downlink jamming, in a physically grounded way.
  • Mission-based attack fidelity can guide defense placement, for instance hardening the ground workstation and the satellite's on-board computer against control attacks and the software-defined radio elements against jamming.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the framework is adopted widely, the seven attributes could serve as a reporting standard for future testbeds, making different groups' hardware and threat coverage directly comparable.
  • The element-level function graphs are a natural substrate for quantitative mission risk: one could assign compromise probabilities to nodes and arcs and compute expected mission loss, a step the paper leaves qualitative.
  • Because threat-model fidelity is currently a count of accommodated threat models, the framework is more a taxonomy than a metric; turning it into numerical fidelity scores would require weighting the attributes.
  • The reported flight-software segmentation faults, if they generalize, imply that open-source flight software may widen the attack surface of small satellites even as it lowers cost; that is a testable hypothesis, not a claim of this paper.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes a framework for characterizing the fidelity of space cybersecurity testbeds, defined through 7 attributes: four system-model attributes (hardware fidelity, firmware/software fidelity, data collection fidelity, mission fidelity), two threat-model attributes (threat model fidelity, mission-based attack fidelity), and one defense attribute (defense capability fidelity). The framework introduces a segment-component-module-element hierarchy for hardware description and represents missions as element-level function graphs. The authors then present a concrete 4-segment testbed (space, ground, user, link) built under the guidance of the framework, characterize it via the attributes, describe two Terra-inspired threat scenarios (control seizure and RF jamming), illustrate how these threats map to functions (Attributes 5-6) and countermeasures (Attribute 7), and close with future research directions. The central claims are that this is the first fidelity framework for space testbeds and that the framework can guide testbed design, implementation, and comparison.

Significance. If validated, the framework would give researchers and practitioners a shared vocabulary and a structured way to describe and compare space cybersecurity testbeds, an area with very few prior characterizations. The paper's strengths include a concrete and unusually detailed testbed description, a systematic hierarchical decomposition of satellite hardware, a function-graph representation that connects missions to specific elements, and an honest acknowledgment of open limitations in Section IV. The claimed novelty as the 'first framework' for testbed fidelity is plausible relative to the three references surveyed. However, the central promise of enabling fair testbed comparison is weakened by the non-operational definition of Attribute 5 (threat model fidelity), and the empirical evidence supporting the framework's value is thin: the attack demonstrations are not backed by data, and Observation 1 generalizes from anecdotal observations. The framework is best regarded at present as a promising taxonomy and design checklist rather than a validated, quantitative characterization scheme.

major comments (4)
  1. [Section II.B, Attribute 5] The definition of threat model fidelity is not operational. The threat model is specified by a tuple (attack point, attack vector, vulnerability, attack consequence), but the attribute is said to describe 'the kinds of threat models that can be accommodated by a testbed.' Section IV then concedes that quantifying this attribute is 'nontrivial because there could be (infinitely) many threat models' and that the current method is 'counting the number of threat models that can be accommodated.' As stated, this count is undefined: the space of tuples is infinite, no finite representation or sampling procedure is given, and the term 'accommodated' is never defined (conceptually representable, partially demonstrated, or successfully executed with a given outcome). Since Attribute 5 is one of the two threat-model attributes, this undercuts the framework's stated purpose of enabling consistent, fair comparisons across testbeds. To make the claim load-bearing, the paper should provide an operational definition, e.g., finite vocabularies for each tuple component and a concrete rule for when a testbed 'accommodates' a tuple.
  2. [Section III.B.1 and Section III introductory paragraph] The paper states that Threat 2 was 'successfully demonstrated' and Threat 1 was 'partly demonstrated' in the testbed, but no experimental data, logs, measurements, or procedures are reported. There is no description of what was observed, what was recorded, or how success was determined (e.g., bit error rate, telemetry corruption, command execution). Without such evidence, these demonstrations cannot be reproduced or independently verified, and the claim that the framework guides attack/defense experiments remains anecdotal. Please include at minimum a repeatable protocol and summary metrics, or clearly label the demonstrations as illustrative walk-throughs rather than completed experiments.
  3. [Section III.A.2, Observation 1] Observation 1 ('The open-source cFS is prone to cyber attacks') is presented as a general finding, but the supporting evidence is limited to the authors' observation of 'many significant errors, such as segmentation faults' during testbed construction. Segmentation faults are software bugs, not evidence of exploitable vulnerabilities, and the generalization from one configuration to the entire cFS codebase is not supported without a concrete vulnerability analysis or an exploit demonstration. This observation should either be reformulated as a bounded observation about the authors' deployment or supported with specific fault reports, crash logs, and an argument for why those faults constitute cyber-attack susceptibility.
  4. [Section IV, 'Attributes Definition'] The paper acknowledges that the seven attributes 'may not be adequately comprehensive' and that additional attributes are needed for constellations and inter-satellite links. This is an honest limitation, but it directly qualifies the central claim of a systematic and fair characterization scheme. The paper should either explicitly scope the framework as a first-step taxonomy rather than a complete characterization, or provide criteria for what a comprehensive attribute set would require and a roadmap toward it. As written, the reader cannot determine whether applying the framework to two different testbeds would yield meaningful comparability or merely a checklist of arbitrary categories.
minor comments (5)
  1. [Section III.A.4, Function 4] The step numbering in the Message Transfer function skips from (v) to (vii); step (vi) is missing and should be renumbered for clarity.
  2. [Figure 1] The entry labeled 'SpaceSec (2024)' corresponds to reference [2] 'Merge/space', but the label uses the venue name rather than the testbed name; this is confusing when comparing testbeds and should be corrected.
  3. [Section II.A, Attributes 1 and 2] There is overlap between Attribute 1 (hardware fidelity) and Attribute 2 (firmware/software fidelity), since an element is defined as 'a hardware, a firmware, or a software implementation.' The paper should clarify how an element that runs firmware is counted under both attributes without double-counting.
  4. [Section III.A.3, Attribute 3] Data collection fidelity is described as a list of data types that can be generated, but no notion of fidelity scale (e.g., sampling rate, resolution, completeness, or ground truth availability) is given; consider defining at least ordinal levels or measurement dimensions for this attribute.
  5. [Section I, Contributions] The phrase 'a concrete a 4-segment testbed' contains an article error; it should read 'a concrete 4-segment testbed.'

Circularity Check

0 steps flagged · score 2.0 of 10

No circularity: the 7-attribute fidelity framework is a self-contained definitional scheme; minor self-citations are contextual, not load-bearing.

full rationale

The paper's central contribution is a set of definitions—the seven fidelity attributes and the segment-component-module-element hierarchy—followed by a concrete testbed description. There are no fitted parameters, no quantitative predictions, and no derived result that is equivalent to an input by construction. The claim that the framework can guide design is supported by a constructive example: the authors state they built the testbed 'under the guidance of the framework' and then characterize it using the same attributes, which is an existence demonstration rather than a circular derivation. The testbed characterization is descriptive, and the attack demonstrations for Threats 1 and 2 are concrete scenarios mapped onto function graphs, not statistical predictions forced from fitted values. Several references are to prior work by the same author group (e.g., Refs. [6], [14], [30], and the cybersecurity-dynamics papers cited as future directions), but these are used for background definitions, attack-case context, or suggested future research avenues; none of them is the load-bearing justification for the framework's definitions or for the testbed's characterization. The acknowledged limitation in Section IV—that the seven attributes 'may not be adequately comprehensive' and that quantifying threat model fidelity is nontrivial because there could be infinitely many threat models—is a completeness and operationalization gap, not a circular reduction. Accordingly, no specific circular step can be quoted, and the appropriate finding is no significant circularity; the score reflects only the presence of minor, non-load-bearing self-citations.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No numerical free parameters are used. The framework rests on modeling assumptions about the adequacy of the attribute set and the hardware hierarchy, plus an anecdotal inference about cFS security. No new physical or system entities requiring independent evidence are introduced.

assumptions (4)
  • domain assumption The segment-component-module-element hierarchy is a systematic and sufficient representation of space infrastructure hardware.
    Introduced in Attribute 1 as the basis for hardware fidelity; no evidence that this decomposition captures all relevant space infrastructure aspects, such as constellations or inter-satellite links.
  • ad hoc to paper The seven proposed attributes adequately characterize the fidelity of system models, threat models, and defenses of a space cybersecurity testbed.
    The authors state in Section IV that the attributes may not be adequately comprehensive and that quantifying threat model fidelity is nontrivial, so adequacy is an unproven premise.
  • domain assumption The 2008 Terra satellite attack narrative from news and commission reports accurately reflects the real event.
    Threat 1 and Threat 2 are derived from references [12]-[17], mostly secondary journalistic sources; the scenario is used to validate testbed accommodation.
  • ad hoc to paper Observations of cFS segmentation faults during testbed construction indicate the flight software is prone to cyber attacks.
    Observation 1 generalizes from informal build-time experience to a security claim without a systematic vulnerability assessment.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Space Cybersecurity Testbed: Fidelity Framework, Example Implementation, and Characterization." pith.science (2026). https://pith.science/paper/NA2Q4C77

@misc{pith2026250711763,
  author       = {Pith},
  title        = {Pith review of: Space Cybersecurity Testbed: Fidelity Framework, Example Implementation, and Characterization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NA2Q4C77}},
  note         = {Machine review of arXiv:2507.11763}
}
read the original abstract

Cyber threats against space infrastructures, including satellites and systems on the ground, have not been adequately understood. Testbeds are important to deepen our understanding and validate space cybersecurity studies. The state of the art is that there are very few studies on building testbeds, and there are few characterizations of testbeds. In this paper, we propose a framework for characterizing the fidelity of space cybersecurity testbeds. The framework includes 7 attributes for characterizing the system models, threat models, and defenses that can be accommodated by a testbed. We use the framework to guide us in building and characterizing a concrete testbed we have implemented, which includes space, ground, user, and link segments. In particular, we show how the testbed can accommodate some space cyber attack scenarios that have occurred in the real world, and discuss future research directions.

Figures

Figures reproduced from arXiv: 2507.11763 by the authors.

Figure 1
Figure 1. Related work comparison. NUC = Next Unit Computer; CSP = CubeSat Space Protocol; COSPAS-SARSAT = Space System for the Search of Vessels [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The fidelity framework with 7 attributes. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Our testbed consists of one CubeSat, one ground station (including [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: Hardware-fidelity in the segment-component-module-element representation. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Satellite Control Function. Function 1: Satellite Control. As highlighted in [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 7
Figure 7. Figure 7: Image Capture Function. how the ground station component controls, and receives data from, the camera on the satellite. The function can be understood as follows. (i) It originates at the WRKT element in the command and telemetry module of the ground station component …
Figure 6
Figure 6. Figure 6: Telemetry Downlink Function. Function 2: Telemetry Downlink. As highlighted in [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 8
Figure 8. Figure 8: Message Transfer Function. in [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Threat 1 against Function 1 (satellite control) [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: Threat 1 against Function 2 (telemetry downlink) [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 13
Figure 13. Figure 13: Threat 2 against Functions 2 and 3 rogue SDR element to transmit a malicious RF signal in the same frequency used between the SDR element of the satellite and the SDR element of the ground segment, which is referred to as victim SDR. (ii) The victim SDR receives the m…
Figure 11
Figure 11. Figure 11: Threat 1 against Function 3 (image capture) [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: Threat 1 against Function 4 (message transfer) [PITH_FULL_IMAGE:figures/full_fig_p008_12.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 42 canonical work pages

  1. [1]

    Satellite cybersecurity testbed to improve commercial space security,

    J. Finke, R. Thummala, R. Elbasheer, P. Hansen, W. Henry, D. Mamula, A. M. Noor, T. York, K. Zheng, and G. Falco, “Satellite cybersecurity testbed to improve commercial space security,” in ASCEND 2023, 2023

    work page 2023

  2. [2]

    Merge/space: A security testbed for satellite systems,

    M. P. Collins, A. Hussain, J. Walters, C. Ardi, C. Tran, and S. Schwab, “Merge/space: A security testbed for satellite systems,” in Proceedings of the 2nd Workshop on the Security of Space and Satellite Systems (SpaceSec’2024), 2024

    work page 2024

  3. [3]

    Towards a Unified Cybersecurity Testing Lab for Satellite, Aerospace, Avionics, Maritime, Drone (SAAMD) technologies and communications

    A. Costin, H. Turtiainen, S. Khandker, and T. H ¨am¨al¨ainen, “Towards a unified cybersecurity testing lab for satellite, aerospace, avionics, mar- itime, drone (saamd) technologies and communications,” arXiv preprint arXiv:2302.08359, 2023

    work page Pith review arXiv 2023

  4. [4]

    MITRE ATT&CK,

    MITRE Corporation, “MITRE ATT&CK,” https://attack.mitre.org/

  5. [5]

    SPARTA: Space Attack Research and Tactic Analysis,

    The Aerospace Corporation, “SPARTA: Space Attack Research and Tactic Analysis,” https://aerospace.org/sparta

  6. [6]

    Towards principled risk scores for space cyber risk management,

    E. Ear, B. Bailey, and S. Xu, “Towards principled risk scores for space cyber risk management,” arXiv preprint arXiv:2402.02635 , 2024

    arXiv 2024

  7. [7]

    Security and privacy controls for information systems and organizations,

    J. T. Force, “Security and privacy controls for information systems and organizations,” National Institute of Standards and Technology, Tech. Rep., 2020

    work page 2020

  8. [8]

    NASA, NASA-STD-1006A: Space System Protection Standard , NASA, Hampton, V A, 2022

    work page 2022

Show all 46 references
  1. [9]

    core Flight System,

    NASA, “core Flight System,” https://cfs.gsfc.nasa.gov/

  2. [10]

    GNU Radio,

    GNU Radio, “GNU Radio,” https://www.gnuradio.org/

  3. [11]

    Comprehensive Open-architecture Solution for Mission Operations Systems (COSMOS),

    Hawaii Space Flight Laboratory, “Comprehensive Open-architecture Solution for Mission Operations Systems (COSMOS),” https://hsfl.gi thub.io/cosmos-docs/

  4. [12]

    Satellite hacking: A guide for the perplexed,

    J. Fritz, “Satellite hacking: A guide for the perplexed,” Culture Mandala, 2013

    2013

  5. [13]

    Economic and S

    U.-C. Economic and S. R. Commission, Report to Congress of the US-China Economic and Security Review Commission . US-China Economic and Security Review Commission, 2019

    2019

  6. [14]

    Characterizing cyber attacks against space systems with missing data: Framework and case study,

    E. Ear, J. L. C. Remy, A. Feffer, and S. Xu, “Characterizing cyber attacks against space systems with missing data: Framework and case study,” in 2023 IEEE Conference on Communications and Network Security (CNS). IEEE, 2023, pp. 1–9

    2023

  7. [15]

    Satellite Hacking and China’s Role,

    satellitetoday.com, “Satellite Hacking and China’s Role,” https://www. satellitetoday.com/government-military/2011/12/01/satellite-hacking-a nd-chinas-role/

    2011

  8. [16]

    Hackers Interfered With 2 US Government Satellites,

    space.com, “Hackers Interfered With 2 US Government Satellites,” https: //www.space.com/13423-hackers-government-satellites.html

  9. [17]

    China key suspect in U.S. satellite hacks: commission,

    Reuters, “China key suspect in U.S. satellite hacks: commission,” https: //www.reuters.com/article/us-chinausa-satellite/china-key-suspect-in-u -s-satellite-hacks-commissionidUSTRE79R4O320111028/

  10. [18]

    Sok: Building a launchpad for impact- ful satellite cyber-security research,

    J. Pavur and I. Martinovic, “Sok: Building a launchpad for impact- ful satellite cyber-security research,” arXiv preprint arXiv:2010.10872 , 2020

    2010 arXiv

  11. [19]

    Lessons learned from applying cyber risk management and survivability concepts to a space mission,

    C. Knez, T. Llans ´o, D. Pearson, T. Schonfeld, and K. Sotzen, “Lessons learned from applying cyber risk management and survivability concepts to a space mission,” in 2016 IEEE Aerospace Conference. IEEE, 2016

    2016

  12. [20]

    Commercial satellites, critical information infrastructure pro- tection, and preventing today’s threat actors from becoming tomorrow’s captain midnight,

    B. Young, “Commercial satellites, critical information infrastructure pro- tection, and preventing today’s threat actors from becoming tomorrow’s captain midnight,” Strat Cyber Defense Multidisc Perspec , 2017

    2017

  13. [21]

    Cyber security awareness for smallsat ground networks,

    T. Vera, “Cyber security awareness for smallsat ground networks,” 30th Annual AIAA/USU Conference on Small Satellites , 2016

    2016

  14. [22]

    Developing scenarios sup- porting space-based ids,

    J. P. Thebarge, W. Henry, and G. Falco, “Developing scenarios sup- porting space-based ids,” in ASCEND 2022 . American Institute of Aeronautics and Astronautics, Inc., 2022, p. 4219

    2022

  15. [23]

    Jammer localization: From crowdsourcing to synthetic detection,

    D. Borio, C. Gioia, A. ˇStern, F. Dimc, and G. Baldini, “Jammer localization: From crowdsourcing to synthetic detection,” in Proceedings of the 29th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2016) , 2016

    2016

  16. [24]

    Real-time pre-correlation anti-jamming system for civilian gnss receivers,

    J. Querol and A. Camps, “Real-time pre-correlation anti-jamming system for civilian gnss receivers,” in Proceedings of the 30th International Technical Meeting of The Satellite Division of the Institute of Navigation (ION GNSS+ 2017) , 2017, pp. 1267–1288

    2017

  17. [25]

    Interference alignment for physical layer security in multi-user networks with pas- sive eavesdroppers,

    L. Hu, S. Tan, H. Wen, J. Wu, J. Fan, S. Chen, and J. Tang, “Interference alignment for physical layer security in multi-user networks with pas- sive eavesdroppers,” IEEE Transactions on Information Forensics and Security, vol. 18, pp. 3692–3705, 2023

    2023

  18. [26]

    Orbital war driving: Assessing transient gps interference from leo,

    D. M. LaChapelle, L. Narula, and T. E. Humphreys, “Orbital war driving: Assessing transient gps interference from leo,” in Proceedings of the 34th ION GNSS+ 2021 , 2021

    2021

  19. [27]

    Dual-satellite geolocation of terrestrial gnss jammers from low earth orbit,

    Z. Clements, T. E. Humphreys, and P. Ellis, “Dual-satellite geolocation of terrestrial gnss jammers from low earth orbit,” in 2023 IEEE/ION PLANS. IEEE, 2023

    2023

  20. [28]

    The space digital dome: Autonomous defense of space vehicles from radio frequency interference,

    G. Falco, N. G. Gordon, A. Byerly, A. Grotto, J. Siegel, and S. Zanlongo, “The space digital dome: Autonomous defense of space vehicles from radio frequency interference,” in 2022 IEEE Aerospace Conference (AERO). IEEE, 2022, pp. 1–8

    2022

  21. [29]

    Jamming-resistant communications via cryptographic secret sharing,

    J. Turner, S. Li, and S. Xu, “Jamming-resistant communications via cryptographic secret sharing,” in ICC 2024-IEEE International Confer- ence on Communications . IEEE, 2024, pp. 2682–2687

    2024

  22. [30]

    Towards principled risk scores for space cyber risk management,

    E. Ear, B. Bailey, and S. Xu, “Towards principled risk scores for space cyber risk management,” CoRR, vol. abs/2402.02635, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2402.02635

    2024 doi arXiv

  23. [31]

    A survey on systems security metrics,

    M. Pendleton, R. Garcia-Lebron, J.-H. Cho, and S. Xu, “A survey on systems security metrics,” ACM Comput. Surv., vol. 49, no. 4, pp. 1–35, Dec. 2016

    2016

  24. [32]

    Metrics and measurement of trustworthy systems,

    J. Cho, P. Hurley, and S. Xu, “Metrics and measurement of trustworthy systems,” in Proc. IEEE MILCOM , 2016

    2016

  25. [33]

    Stram: Measuring the trustworthiness of computer-based systems,

    J.-H. Cho, S. Xu, P. M. Hurley, M. Mackay, T. Benjamin, and M. Beaumont, “Stram: Measuring the trustworthiness of computer-based systems,” ACM Comput. Surv., vol. 51, no. 6, pp. 128:1–128:47, 2019

    2019

  26. [34]

    Sarr: A cybersecurity metrics and quantification framework,

    S. Xu, “Sarr: A cybersecurity metrics and quantification framework,” in Third International Conference on Science of Cyber Security (SciSec’2021), 2021, pp. 3–17

    2021

  27. [35]

    Quantifying the security effectiveness of firewalls and dmzs,

    H. Chen, J. Cho, and S. Xu, “Quantifying the security effectiveness of firewalls and dmzs,” in Proc. HoTSoS’2018, 2018, pp. 9:1–9:11

    2018

  28. [36]

    Statistical estimation of malware detection metrics in the absence of ground truth,

    P. Du, Z. Sun, H. Chen, J. H. Cho, and S. Xu, “Statistical estimation of malware detection metrics in the absence of ground truth,” IEEE T-IFS, vol. 13, no. 12, pp. 2965–2980, 2018

    2018

  29. [37]

    Metrics towards measuring cyber agility,

    J. Mireles, E. Ficke, J. Cho, P. Hurley, and S. Xu, “Metrics towards measuring cyber agility,” IEEE Transactions on Information Forensics and Security, vol. 14, no. 12, pp. 3217–3232, 2019

    2019

  30. [38]

    Cybersecurity dynamics,

    S. Xu, “Cybersecurity dynamics,” in Proc. Symposium on the Science of Security (HotSoS’14) , 2014, pp. 14:1–14:2

    2014

  31. [39]

    Cybersecurity dynamics: A foundation for the science of cybersecurity,

    S. Xu, “Cybersecurity dynamics: A foundation for the science of cybersecurity,” in Proactive and Dynamic Network Defense . Springer, 2019, vol. 74, pp. 1–31

    2019

  32. [40]

    The cybersecurity dynamics way of thinking and landscape (invited paper),

    S. Xu, “The cybersecurity dynamics way of thinking and landscape (invited paper),” in ACM Workshop on Moving Target Defense , 2020

    2020

  33. [41]

    A stochastic model of multivirus dynamics,

    S. Xu, W. Lu, and Z. Zhan, “A stochastic model of multivirus dynamics,” IEEE Transactions on Dependable and Secure Computing , vol. 9, no. 1, pp. 30–45, 2012

    2012

  34. [42]

    Push- and pull-based epidemic spreading in networks: Thresholds and deeper insights,

    S. Xu, W. Lu, and L. Xu, “Push- and pull-based epidemic spreading in networks: Thresholds and deeper insights,” ACM TAAS, vol. 7, no. 3, 2012

    2012

  35. [43]

    Preventive and reactive cyber defense dynamics is globally stable,

    R. Zheng, W. Lu, and S. Xu, “Preventive and reactive cyber defense dynamics is globally stable,” IEEE TNSE , vol. 5, no. 2, pp. 156–170, 2018

    2018

  36. [44]

    Unified preventive and reactive cyber defense dynamics is still globally convergent,

    Z. Lin, W. Lu, and S. Xu, “Unified preventive and reactive cyber defense dynamics is still globally convergent,” IEEE/ACM ToN, vol. 27, no. 3, pp. 1098–1111, 2019

    2019

  37. [45]

    Preventive and reactive cyber defense dynamics with ergodic time-dependent parameters is globally attractive,

    Y . Han, W. Lu, and S. Xu, “Preventive and reactive cyber defense dynamics with ergodic time-dependent parameters is globally attractive,” IEEE TNSE, vol. 8, no. 3, pp. 2517–2532, 2021

    2021

  38. [46]

    Adaptive epidemic dynamics in networks: Thresholds and control,

    S. Xu, W. Lu, L. Xu, and Z. Zhan, “Adaptive epidemic dynamics in networks: Thresholds and control,” ACM TAAS, vol. 8, no. 4, 2014. 10

    2014

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.