PaperlayerView exact revision on arXiv

Source-linked AI summary

Using LLMs to Elicit Security Requirements for Service-Oriented Cyber Ranges

Michail Takaronis, Athanasia Kollarou, Georgios Kavallieratos, Vasileios Gkioulos, Sokratis Katsikas

arXiv:2609.00886v1cs.CR

TL;DR

Security-requirements elicitation for complex service-oriented cyber ranges is difficult and time-consuming. The paper applies a SEBoK-guided process that feeds mission objectives, stakeholder needs, and architectural context to five LLMs, consolidates their outputs, and maps the results to SOR layers. The resulting requirements were broadly accepted by experts, but testability and validation remain important areas for improvement.

  • Problem

    Security-requirements elicitation for complex cyber ranges must translate stakeholder needs and mission objectives into actionable specifications through a difficult, time- and cost-constrained process.

  • Method

    A SEBoK-guided process provided seven security mission objectives, eight stakeholder needs, and nine-layer SOR architectural context to five LLMs, whose outputs were consolidated and mapped to architectural layers.

  • Results

    Five LLMs generated 84 candidate requirements that were consolidated into 27 unique requirements, with expert acceptance of necessity at 98.5%, clarity at 87.4%, completeness at 85.2%, and feasibility at 78.5%.

  • Takeaways & Limitations

    LLMs can support early SOR security-requirements elicitation and produce a baseline for designers and developers, while human review remains needed.

  • Takeaways & Limitations

    The process depends on prompt quality, manual consolidation introduces subjectivity, and the requirements lack validation through implementation or operational testing in a real cyber-range environment.

Abstract

from arXiv · show

Cyber ranges are complex environments comprising many interacting components and stakeholders with different security concerns. The Service-Oriented Cyber Range (SOR) is no exception, particularly when it comes to training scenarios targeting critical infrastructure. Security concerns are translated into security requirements, the elicitation of which is usually difficult and time-consuming. This work examines how large language models can assist in eliciting security requirements for a service-oriented range and help produce a useful baseline for designers and developers. The approach follows a SEBoK-guided process in which security mission objectives and stakeholder needs were first identified and then provided as a prompt context along with architectural guidelines to five LLMs: GPT-5.2, Gemini 3.1 Pro, Grok 4.1, Sonar, and Kimi K2.5. The models generated 84 security requirements in total, which were consolidated into a comprehensive set of 27 requirements and then mapped to the architectural layers of the service-oriented range. The final set was evaluated by five cybersecurity experts against the criteria of necessity, clarity, completeness, feasibility, and testability, with an additional rejection option. The results showed a high acceptance rate, specifically for necessity with 98.5%, clarity with 87.4%, completeness with 85.2%, feasibility with 78.5%, and rejection with 0.7%. Testability was lower at 44.4%, indicating a slight lack of information on how these requirements could be tested. These findings show that LLMs can support early stages of the elicitation of security requirements, although human review is still needed, especially to improve or adjust certain aspects of the requirements.

I. INTRODUCTION

Service-oriented cyber ranges require structured security-requirements elicitation because their layered, interconnected architectures and stakeholder needs create complex security-design challenges. This paper investigates LLM-assisted elicitation as a way to produce traceable, practical requirements for SOR designers and developers.

  • SORs organize cyber-range capabilities as services across functional layers, promoting modularity, scalability, reuse, and interoperability.
  • Traditional security-requirements elicitation translates stakeholder needs and mission objectives into specifications but relies on time- and cost-constrained manual activities.
  • The paper integrates security mission objectives, stakeholder needs, and architectural considerations into LLM-driven requirements generation for an SOR.
  • The proposed methodology maintains traceability to stakeholder needs and architectural layers while providing a practical baseline for cyber-range implementation.

II. RELATED WORK

Prior work covers cyber-range capabilities, threats, requirements-engineering methods, LLM applications, and SOR architectures, but does not address LLM-assisted security-requirements elicitation for an SOR. The paper combines these research strands into a structured SEBoK-guided process.

  • Existing cyber-range research identifies platform features, capabilities, exchanged information, and development guidance.
  • Cyber-range security studies identify threats involving deployment, physical environments, sensitive data, communications, clouds, incident response, virtual machines, and containers.
  • Security-requirements engineering literature compares elicitation methods, tools, and frameworks, including tools addressing functional and nonfunctional requirements.
  • Research surveys LLM use and prompting strategies in requirements engineering, while SOR architecture work organizes cyber-range capabilities into service-oriented functional layers.
  • The paper proposes a structured, SEBoK-guided process that combines prior requirements-engineering, LLM, cyber-range, and architecture research.

III. METHODOLOGY

The methodology derives SOR security requirements by translating mission objectives and stakeholder needs into technical specifications within architectural context. It uses a four-phase process culminating in a structured prompt sent to five LLMs.

  • SEBoK frames system requirements as technical specifications derived from mission objectives and stakeholder needs.
  • Identify security mission objectives: The first phase analyzes guides, taxonomies, and reference architectures to identify SOR security mission objectives.
  • Elicit security stakeholder needs: The second phase identifies key security stakeholders and their needs while respecting the SOR reference architecture.
  • Configure the LLM task: The third phase packages seven mission objectives, eight stakeholder needs, and a condensed nine-layer architecture description into a fixed-structure prompt for five LLMs.
  • Configure the LLM task: The LLM prompt requires outputs in a six-column schema covering ID, name, description, verification measure, class, and sources.

IV. SECURITY MISSION OBJECTIVES FOR THE SERVICE-ORIENTED CYBER RANGE

The SOR’s security mission objectives define high-level goals for protecting exercises, communications, data, identities, execution contexts, monitoring, and federation boundaries.

  • Security mission objectives: Security Mission Objectives (SMOs) describe general security goals used to define the SOR’s security requirements.They translate high-level mission goals into requirements for what the system should do.
  • Security mission objectives: The SOR must contain exercises and experiments to prevent unintended effects on external systems while ensuring legality and safety.
  • Security mission objectives: All user-to-service and service-to-service communications must resist interception and manipulation.
  • Security mission objectives: Platform-managed identities, configurations, telemetry, metadata, and governance policies require confidentiality and integrity protection.
  • Security mission objectives: The architecture must provide trustworthy identity and access management, isolate teams’ scenario contexts, and detect security-relevant conditions with traceability.Federated operation additionally requires boundary protections and monitoring or control of suspicious partner-originating behavior.

V. SECURITY STAKEHOLDER NEEDS FOR THE SERVICE-ORIENTED CYBER RANGE

Security stakeholder needs span administrators, instructors, exercise designers, learners, researchers, federation partners, auditors, and infrastructure providers, with emphasis on isolation, controlled access, traceability, and safe operation.

  • Stakeholder needs: Stakeholder needs are grounded in cyber-range capabilities, participant roles, audiences, and platform selection criteria from prior guidance and literature.
  • Platform and exercise stakeholders: Administrators need protected management services, hardened orchestration interfaces, and carefully authorized administrative functions.
  • Platform and exercise stakeholders: Instructors require secure access to orchestration, learning-management, and monitoring services while protecting learner and assessment data.
  • Platform and exercise stakeholders: Exercise designers need least-privilege policies governing network reachability, credentials, and data flows within scenarios.These policies should prevent access to underlying infrastructure and leakage beyond intended exercise boundaries.
  • Operational and external stakeholders: Learners and researchers need contained environments, privacy-aligned data handling, and controlled asset import or data export for safe experimentation.Federation partners additionally require authenticated, authorized, monitorable, constrainable, and revocable cross-range interactions; auditors need end-to-end event traceability, while providers need workload containment assurances.

VI. LLM-ASSISTED SECURITY REQUIREMENTS

The study supplied five LLMs with a common SEBoK- and SOR-based context, then consolidated their overlapping outputs into a unified security-requirement set.

  • LLM-assisted elicitation: The elicitation process translated mission objectives and stakeholder needs into technical SOR security requirements using the SEBoK methodology and reference architecture.
  • LLM-assisted elicitation: Five models received identical input material and generated requirements in a common target table format through one query per model.The reported models were queried through public web interfaces under default decoding settings.
  • Consolidation: Consolidation addressed overlapping requirements by deduplicating entries with the same underlying security-control objective.Isolation and tenant isolation, for example, were treated as duplicates because both target cross-team interference prevention.
  • Consolidation: Duplicate merging retained the most precise or strongest requirement phrasing.
  • Consolidation: Combined requirements were decomposed, while verification methods, classes, and sources were aligned into broader reusable categories where appropriate.For example, protocol, network, and isolation testing were aligned with broader verification categories such as configuration review.

VII. MAPPING SECURITY REQUIREMENTS TO THE SERVICE-ORIENTED CYBER RANGE ARCHITECTURE

The study formalized dependencies among SOR architectural layers and mapped each security requirement to the layer best suited to implement or enforce it.

  • Architectural mapping: The SOR was formalized as a UML dependency model among service-oriented operational layers.
  • Architectural mapping: Security requirements were mapped to implementation or enforcement layers according to each layer’s function and the SOR’s architectural dependencies.Dependency arrows represent architectural dependencies involving capabilities, metadata, or constraints, not runtime message flows.
  • Layer dependencies: Operational Systems, Service Component, and Services layers support core functionality through dependencies among infrastructure, deployable artifacts, and services.The Business Process layer coordinates service deployment and uses consumer and information-layer inputs.
  • Layer dependencies: The Integration layer routes and transforms messages, while Information, QoS, and Governance provide transferred data, authentication or authorization support, and policy metadata.
  • Requirement-to-layer mapping: Isolation, segmentation, and patching map mainly to OSL and SCL; boundary, federation, authentication, and transport traceability map mainly to IL.QoS receives monitoring and access-control requirements, IFL supports data protection and evidence, CL and BPL support interaction and orchestration, and GL controls policies.

VIII. DISCUSSION

The five LLMs produced overlapping security requirements that were consolidated into a smaller unified set, which experts generally judged necessary, clear, complete, and feasible. Testability was the weakest criterion, while prompt quality, manual consolidation, and absent operational validation remain limitations.

  • LLM outputs: 84 candidate requirements were consolidated into 27 unique requirements, showing substantial convergence across the five LLMs.Core controls including containment, isolation, encryption, integrity, confidentiality, authentication, authorization, monitoring, and federation-boundary protection were proposed by all five models.
  • LLM outputs: All five models proposed the core controls of containment, isolation, encryption, integrity, confidentiality, authentication, authorization, monitoring, and federation-boundary protection.Nine of the 27 final requirements traced to a single model, contributing differentiation beyond the shared controls.
  • Expert evaluation: 78.5% of ratings judged the requirements feasible, but only 44.4% indicated that their testability was clear.The authors associate feasibility concerns with possible computational overhead or integration complexity and call for further clarification of verification.
  • Limitations: The process depends on complete, unbiased prompt context, while manual consolidation introduces subjectivity and the requirements were not validated through real cyber-range implementation or operational testing.Manual consolidation was retained to preserve traceability to the original model outputs and avoid an additional generative layer.

IX. CONCLUSION

The study shows that LLMs can support security-requirements elicitation for service-oriented cyber ranges when guided by mission objectives, stakeholder needs, and architectural context. The resulting 27 requirements provide a useful starting baseline, but expert refinement and empirical validation remain necessary.

  • Conclusion: LLMs generated 84 candidate requirements that were consolidated into 27 unique requirements and mapped to the SOR reference architecture.The mapping used a UML class-diagram representation to show dependencies between architectural layers and their security needs.
  • Conclusion: Expert evaluation found high necessity, clarity, completeness, and feasibility, while testability was weakest and rejection was negligible.The conclusion characterizes the resulting requirements as useful and relevant to SOR security needs.
  • Conclusion: The requirements can serve as a starting point for elicitation, with future work targeting established-method comparisons, automated consolidation, and empirical validation for deployment instances.The authors identify prompt quality, manual consolidation subjectivity, and absent real-environment validation as limitations.
Loading 2609.00886v1…