| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Firmware-hybrid |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 7/28/2029 |
| Caveat | No assurance of the minimum strength of generated SSPs (e.g., keys). No assurance of minimum security of SSPs (e.g., keys, bit strings) that are externally loaded, or of SSPs established with externally loaded SSPs. |
| Vendor | Cisco Systems, Inc. |
flowchart LR
%% Deterministic review-risk graph for Linux Kernel FIPS Object Module (KFOM) Cryptographic Module
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status<br/>self-test</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
end
subgraph Risk["Reviewer question"]
R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C6 --> I6 --> R6 --> E6
classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
class C2,C3,C6 clue;
class I2,I3,I6 infer;
class R2,R3,R6 risk;
class E2,E3,E6 evidence;flowchart LR
%% Deterministic clue tier for Linux Kernel FIPS Object Module (KFOM) Cryptographic Module
%% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
subgraph CMVP["CMVP-disclosed clues (deterministic)"]
C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status<br/>self-test</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
end
classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
class C2,C3,C6 clueLow;Cisco Systems, Inc. FIPS 140-3 and ISO/IEC 19790 Non-Proprietary Security Policy For Linux Kernel FIPS Object Module Cryptographic Module Last Updated: May 31, 2024, Version 1.1 Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Table of Content List of Tables List of Figures
Module Cryptographic Module (hereinafter referred to as KFOM or Module) firmware version 1.0. The following details how this module meets the security requirements of FIPS 140-3, SP 800-140 and ISO/IEC 19790 for a Security Level 1 Firmware hybrid cryptographic module. The security requirements cover areas related to the design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module interfaces; roles, services, and authentication; software/firmware security; operational environment; physical security; non-invasive security; sensitive security parameter management; self-tests; life-cycle assurance; and mitigation of other attacks. The following table indicates the actual security levels for each area of the cryptographic module. ISO/IEC 24759 FIPS 140-3 Section Title Security Section 6. Level
1 General 1
2 Cryptographic Module Specification 1
3 Cryptographic Module Interfaces 1
4 Roles, Services, and Authentication 1
5 Software/Firmware Security 1
6 Operational Environment 1
7 Physical Security 1
8 Non-Invasive Security N/A
9 Sensitive Security Parameter Management 1
10 Self-Tests 1
11 Life-Cycle Assurance 1
12 Mitigation of Other Attacks N/A
Overall Level 1 Table 1 - Security Levels
The Cisco Linux Kernel FIPS Object Module (KFOM) Cryptographic Module is a firmware hybrid cryptographic library in a multi-chip standalone embodiment that allows for Linux kernel applications to use approved algorithms. It does not implement any security protocols nor create any cryptographic keys. Instead, it only provides Linux kernel applications access to approved algorithms. The module is intended to run on the UCS C220 M5 and MX68W host platforms or any generalpurpose computer, so the physical perimeter of the module is the tested platforms. The cryptographic module comprises the Cisco Linux Kernel FIPS Object Module (KFOM) Cryptographic Module (Firmware Version: 1.0) which is a kernel object file linux_kfom_1_0_0.ko and the processor (Hardware Version: ARMv8 Cortex-A53, Intel Xeon Gold 6138) (only for algorithm acceleration) which only operates in the approved mode of operation which is set at manufacture. The module is validated according to FIPS 140-3 at overall security level 1. Please refer to Table 1 above for the individual areas.
Cisco UCS C220 M5 unifies computing, networking, management, virtualization, and storage access into a single integrated architecture, enabling end-to-end server visibility, management, and control in both bare metal and virtualized environments. The module has been tested on the following Operational Environments. # Operating System Hardware Processor PAA/Acceleration Platform
1 Linux 4.9 MX68CW ARMv8 Cortex-A53 With PAA
2 Ubuntu 18.04 UCS C220 M5 Intel Xeon Gold 6138 With PAA
Table 2 - Tested Operational Environments Figure 1 - UCS C220 M5 Front View Figure 2 - UCS C220 M5 Rear View Figure 3 - MX68CW Front View Figure 4 - MX68CW Rear View
Figure 5 - MX68CW Side View Please note that Figures 1-5 are the tested platforms and not the module itself. Figure 6 - Intel Xeon Gold 6138 Figure 7 - ARMv8 Cortex-A53 The following table lists the Vendor affirmed operational environment: # Operating System Hardware Platform
Table 3 - Vendor Affirmed Operational Environments
The cryptographic module maintains validation compliance when operating on the operating system/mode specified in Table 2 above and on the validation certificate as well as for those specified in Table 3 above (vendor affirmed). For the latter, the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Cryptographic Boundary The KFOM cryptographic module (red box) is a non-modifiable, multi-chip standalone firmware hybrid cryptographic module providing cryptographic support to the Kernel which takes data in and out from the host application via the API (libkcapi) feeding into the kernel. All processing is done on the listed processors in Table 2 above. The KFOM performs no communications other than with the consuming application. The block diagram below shows the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. The cryptographic boundary is the KFOM (red box) and the processors (ARMv8 Cortex-A53, Intel Xeon Gold 6138) with PAA. Tested Platform TOEPP Host Platform libkcapi Application Data/Control Data/Control/Status Input Output Kernel Space KFOM Data/Control Input Kernel Static kernel API (Firmware Components component interfaces) Data/Control/Status Registers (Hardware Output component interfaces Processor (PAA) Figure 8 - Block Diagram Firmware component interfaces include: Data Input, Data Output, Control Input and Status Output interfaces.
Hardware component interfaces include: Input, Output, Control Input and Status registers. Modes of Operation By design, the module is only able to support approved mode of operation. Once the module is configured in the approved mode of operation by following the steps in Section 11 of this document, the module will be ready for approved mode of operation. The module doesn’t claim the implementation of a degraded mode operation. Approved security functions: CAVP Cert Algorithm and Mode/Method Description / Key Use / Function Standard Size(s) / Key Strength(s) A1182 and AES [FIPS 197, CBC, ECB, CTR Key length: 128, Block cipher A1185 SP800-38A] 192 and 256 bits providing encryption/decryption with data confidentiality from the modes of operation A1182 and AES [FIPS 197, CCM Key length: 128, Block cipher A1185 SP800-38C] 192 and 256 bits providing confidentiality an authentication through Counter with Cipher Block Chaining-Message Authentication Code A1182 and AES [FIPS 197, CMAC Key length: 128, A cipher (AES) based A1185 SP800-38B] 192 and 256 bits MAC providing authentication, encryption and decryption A1182 and AES [FIPS 197, GCM, GMAC Key length: 128, Authentication and A1185 SP800-38D] 192 and 256 bits encryption. Providing confidentiality of data through authentication, encryption and decryption A1182 and AES [FIPS 197, CBC-CS3 Key length: 128, Block cipher A1185 SP800- 192 and 256 bits providing 38A(addendum)] encryption/decryption with variant on padding A1182 and AES [FIPS 197, XTS Key length: 128 Authenticated A1185 SP800-38E] and 256 bits symmetric encryption and decryption; XTS in approved mode can only be used for cryptographic
protection of data on storage devices A1182 and SHS [FIPS 180-4] SHA-1, SHA2- N/A Message digest; In A1185 224/256/384/512 approved mode, SHA-1 can only be used for non-digitalsignature and legacy use. All other SHAs acceptable for hash functions applications A1182 and HMAC [FIPS 198- HMAC-SHA-1, Key length: 112 bits Integrity based on A1185 1] HMAC-SHA2-224, or greater secret key. Using HMAC-SHA2-256, standard SHA HASH HMAC-SHA2-384 with secret key for and HMAC-SHA2calculations and verification A1182 and DRBG-CTR AES-128, AES- N/A Deterministic A1185 [SP800-90Arev1] 192, AES-256 Random Bit Derivation Function Generators (DRBG); Enabled; uses an algorithm to Prediction produce random Resistance: Yes output A1182 and DRBG_HASH SHA-1, SHA2- N/A Deterministic A1185 [SP800-90Arev1] 224/256/384/512 Random Bit Generators (DRBG); uses an algorithm to produce random output A1182 and DRBG_HMAC HMAC-SHA-1, N/A Deterministic A1185 [SP800-90Arev1] HMAC-SHA2-224, Random Bit HMAC-SHA2-256, Generators (DRBG); HMAC-SHA2-384 uses an algorithm to and HMAC-SHA2produce random output Table 4 - Approved Algorithms Notes:
The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data input, data output, control input, control output and status output) as follows. Physical Logical Interface Data that passes over port/interface Port Input N/A
Table 5 - Ports and Interfaces Please note that the module does not support control output interface and is not applicable for this module.
The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services to the Crypto Officer. Role Service Input Output Crypto Officer Show Status API call Successful output of module’s name and parameters version denotes that the module is active Crypto Officer Perform Self-Tests Automatically Output on each algorithm running selfexecuted, or host test and pass or fail platform’s shutdown command Crypto Officer Show Version API call Output the version parameters Crypto Officer Configure Symmetric API call LINUX KERNEL FOM followed by the Encryption parameters, encryption in use and ciphertext data encryption key, plaintext data Crypto Officer Configure Symmetric API call LINUX KERNEL FOM followed by the Decryption parameters, decryption in use and plaintext data decryption key, ciphertext data Crypto Officer Configure Keyed Hash API call LINUX KERNEL FOM followed by the parameters, hash in use and keyed hash output authentication key, message Crypto Officer Configure Message API call LINUX KERNEL FOM followed by the Digest parameters, digest in use and hashed output message to be hashed Crypto Officer Configure Random API call LINUX KERNEL FOM followed by the Number Generation parameters random strings in use Crypto Officer Perform Zeroisation API call N/A parameters (for temporary SSPs) and host platform’s shutdown command Table 6 - Roles, Service Commands, Input and Output The table below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP.
R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A = The service does not access any SSP during its operation.
Service Description Approved Keys and/or Roles Access Indicator 1 Security SSPs Rights Functions to Keys and/or SSPs Show Status Provide N/A N/A Crypto N/A Global Module’s status Officer indicator API output as designed by HOST system using the KFOM and output of `echo $?` Perform Execute the None AES Key, Crypto E Global Self-Tests CAST and Authentication Officer indicator API Health tests , DRBG output as entropy input, designed by DRBG Seed, HOST system DRBG V and using the C, DRBG Key KFOM and output of `echo $?` Show Provide N/A N/A Crypto N/A Global Version module’s name Officer indicator API and version output as information designed by HOST system using the KFOM and output of `echo $?` Configure Configure AES AES CBC, AES Key Crypto W,E,Z Global Symmetric algorithm ECB, CTR, Officer indicator API Encryption CCM, GCM, AES GCM IV Crypto W, G, output as CBC-CS3, XTS Officer E, Z designed by 128, 192 HOST system (except XTS), using the
output of `echo $?` Configure Configure AES AES CBC, AES Key Crypto W,E,Z Global Symmetric algorithm ECB, CTR, Officer indicator API Decryption CCM, GCM, AES GCM IV Crypto W, G, output as CBC-CS3, XTS Officer E, Z designed by 128, 192 HOST system (except XTS), using the
If `echo $?` returns 0, the approved service executed successfully. Any other value = not successful.
output of `echo $?` Configure Configure HMAC SHA-1, Authentication Crypto W,E,Z Global Keyed Hash HMAC usage HMAC-SHA2- Officer indicator API 224/256/384/ output as
HOST system using the KFOM and output of `echo $?` Configure Configure SHS SHA-1, SHA2- N/A Crypto N/A Global Message usage 224/256/384/51 Officer indicator API Digest 2 output as designed by HOST system using the KFOM and output of `echo $?` Configure Configure DRBG (Hash, DRBG Crypto W, E, Z Global Random DRBG usage HMAC or AES entropy input Officer indicator API Number CTR) DRBG Seed, Crypto G, E, Z output as Generation DRBG V and Officer designed by C, DRBG Key HOST system using the KFOM and output of `echo $?` Perform Perform N/A All SSPs Crypto Z None Zeroization Zeroization Officer Table 7 - Approved Services
Integrity Technique The Module is provided in the form of binary executable code. To ensure firmware security, the Module is protected by HMAC-SHA2-512 (HMAC Certs. #A1182 or #A1185) algorithm. At Module’s initialization, the integrity of the runtime executable is verified using a HMAC-SHA2-
512 digest which is compared to a value computed at build time. If at the load time the MAC
does not match the stored, known MAC value, the Module would enter an Error state with all crypto functionality inhibited. Integrity Test On-Demand The integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. The operator can initiate the integrity test on demand by power cycling the host platform. The module is a kernel object file linux_kfom_1_0_0.ko
The module is operated in a non-modifiable operational environment per FIPS 140-3 level 1 specifications. The module is installed within the product for use with the kernel, and the linux kernel cannot be modified. The operating systems and tested platforms can be found in Table 2. The application that makes calls to the module is the single user of the module, even when the application is serving multiple clients. The module’s firmware version running on each tested platform is 1.0.
Per ISO/IEC 19790 and FIPS 140-3 classification, this is a multi-chip standalone cryptographic module. KFOM 1.0 is a firmware hybrid module and runs on a production grade chassis.
This section is not applicable as the cryptographic module does not implement any non-invasive attack mitigation techniques.
The following table summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. Key/SSP Strength Security Generation Import/ Establish- Storage Zeroisation Use & Name/ Function Export ment Related Type and Cert. Keys Number DRBG >112 bits N/A Obtained Import N/A: The Zeroized Random Entropy from the to the N/A module when the number Input Entropy module does not tested generation Source via provide platform is within Module’ persistent powered TOEPP s API keys/SSPs down (GPS INT Export: storage Pathways) No DRBG 128 to SP800- Generated Import: N/A N/A: The crypto_free Random Output 512 bits 90Arev1 using No module _rng() bits Counter SP800- does not or power provided DRBG, 90Arev1 Export: provide cycle the for the Hash DRBG No persistent device calling DRBG, keys/SSPs application HMAC storage DRBG Cert A1182/ A1185 DRBG 384 bits SP800- Generated Import: N/A N/A: The crypto_free Internal Seed 90Arev1 using DRBG No module _rng() state of the Counter derivation does not or power DRBG DRBG, function that Export: provide cycle the Hash includes the No persistent device DRBG,
HMAC entropy keys/SSPs DRBG Cert input storage A1182/ A1185 DRBG V 128 SP800- Generated Import: N/A N/A: The crypto_free Internal 90Arev1 first during No module _rng() state of the Counter DRBG does not or power DRBG 440/888 DRBG, instantiation Export: provide cycle the bits Hash and then No persistent device DRBG, subsequently keys/SSPs HMAC updated storage 160/256/3 DRBG Cert using the 84/512 A1182/ DRBG bits) A1185 update function DRBG C 128/192/2 SP800- Generated Import: N/A N/A: The crypto_free Internal
56 90Arev1 first during No module _rng() state of the
Counter DRBG does not or power DRBG 440/888 DRBG, instantiation Export: provide cycle the bits Hash and then No persistent device DRBG Cert subsequently keys/SSPs A1182/ updated storage A1185 using the DRBG update function DRBG 128/192/2 SP800- Established Import: N/A N/A: The crypto_free Internal Key 56 bits 90Arev1 per SP 800- Yes module _rng() state of the Counter 90Arev1 does not or power DRBG DRBG, Counter Export: provide cycle the 160/256/3 HMAC DRBG and No persistent device 84/512 DRBG Cert HMAC keys/SSPs bits A1182/ DRBG storage A1185 AES Key 128,192,2 AES Generated Import: N/A N/A: The crypto_free AES
56 bits (GCM, externally Yes module _cipher() session key
GMAC, and passed does not crypto_free XTS, into the Export: provide _ablkcipher CMAC, module No persistent () CCM, CTR, keys/SSPs crypto_free CBC, ECB) storage _blkcipher() Cert crypto_free A1182/ _skcipher() A1185 crypto_free _aead() or power cycle the device
AES 96-bit AES GCM Generated Import: N/A N/A: The Power cycle AES GCM GCM IV Cert externally Yes module the device session key A1182/ and passed does not and A1185 into the Export: provide decryption module No persistent keys/SSPs Generated storage internally (FIPS 140-3 IG C.H #3) Authentic 160-512 HMAC Generated Import: N/A N/A: The crypto_free Integrity ation bits (SHA-1, externally Yes module _shash() assurance SHA2-224, and passed does not crypto_free SHA2-256, into the Export: provide _ahash() SHA2-384, module No persistent or power SHA2-512) keys/SSPs cycle the Cert storage device A1182/ A1185 Firmware 160 bits HMAC- Pre-loaded at Import: N/A Stored in This key is Used for Integrity SHA2-512 the factory No the module used for firmware Key Cert (in the binary firmware integrity (not a A1182/ module’s Export: computed integrity test. This is SSP) A1185 binary) No during test and not not an SSP build subject to key zeroization requirement s according to FIPS140-
Integrity N/A HMAC- Calculated Import: N/A N/A: The memzero_e Calculated test SHA2-512 during No module xplicit() call during calculatio Cert integrity test does not before integrity n value A1182/ Export: provide exiting the test A1185 No persistent integrity keys/SSPs test storage function Table 8 - SSPs Even though the module does implement an approved random number generator, it is not used by the module for the generation of the cryptographic keys. All Cryptographic keys are externally generated and imported to the working space assigned by the kernel. The module uses approved DRBG for the generation of random strings and passes them to the calling application only upon their request. The cryptographic module is passed a pointer to the cryptographic keys as API parameters, associated by memory location. The application calling the cryptographic module passes keys in plaintext within the physical perimeter. The module does not perform storage of keys. All SSPs can be zeroized by power cycling the host.
Entropy Minimum Details sources number of bits of entropy Entropy At least 112 bits The entropy and seeding material for the entropy source is within the provided to it by the external calling application (and not by the TOEPP was module) which is outside the module’s boundary. The minimum passively load effective strength of the SP 800-90Arev1 DRBG seed is required into the to be at least 112 bits when used in the approved mode of Module to operation, therefore the minimum number of bits of entropy seed the 800- requested when the calling application makes a call to the SP 90Arev1 800-90Arev1 DRBG is 112. Hence the caveat “No assurance of DRBG by the the minimum strength of generated SSPs (e.g., keys)” is operating applicable. system The module does not generate any cryptographic keys but the SP800-90Arev1 DRBGs are used to provide the random strings requested by the calling application. These random strings are not used by the module and is passed to the calling application when requested. The module users (the external calling applications) shall use entropy source which meets the security strength required for the random number generation mechanism as shown in SP 80090Arev1 based on Hash DRBG, HMAC DRBG, and Counter DRBG. Table 9 - Non-Deterministic Random Number Generation Specification
When the Linux kernel is setup properly the self-test solution is that only the kernel module, which has been signed and verified can load in cryptographic algorithms. Once the KFOM is loaded, first the self-test for the algorithm used in the firmware integrity test is run and then the actual firmware integrity test of the module runs for the KFOM, then all the self-tests for the algorithms are run. If a self-test fails, the result from the Linux Crypto Test Manager is a failure. This means the algorithm will not have the self-test flag set. The presence of self-test flag allows the Linux Crypto Framework to utilize the algorithm. A successful log message is provided by the module after the successful completion of the selftests. If an error occurs to a valid approved algorithm during the self-test, the module enters hard error state, and the Linux kernel will print an error message to the console and data output from the data output interface is inhibited. This results in the system shutting down.
Pre-Operational Self-tests
per Section 11.3 of SP 800-90Arev1)
Secure Operations The tested operating systems segregate user processes into separate process spaces. Each process space is an independent virtual memory area that is logically separated from all other processes by the operating system firmware and hardware. The module functions entirely within the process space of the process that invokes it, and thus the module runs on a single user mode of operation. The module is copied into the tested operational environments prior to shipping. The operator needs to load the module per the instructions below, and power cycle the platform. At this point, the pre-operational tests are run, followed by the conditional cryptographic algorithm self-tests. Now KFOM will be in approved mode. KFOM Loading: insmod linux_kfom_1_0_0.ko config_file=kfom_priorities ko_file=linux_kfom_1_0_0.ko The operator can verify that the module is in approved mode by executing the “Show Status” service command. If the module outputs name and version, it can be considered that the module is running in approved mode. The guidance document
The requirements under INCITS+ISO+IEC 19790+2012[2014], section 7.12 “Mitigation of other attacks”, are not applicable to the module since the module currently doesn’t support any mitigation of other attacks services.