Every stage of runtime security builds on itself, from how you observe or enforce on events, to actually collecting interesting data, exporting it back to a logging platform, and ultimately using that data to create better policy decisions and harden gaps. This release marks a major leap forward for runtime security across the Isovalent Enterprise Platform and across all stages of why teams use Isovalent Runtime Security.
Whether your workloads run in Kubernetes, on VMs, at the edge, or across mixed environments, Isovalent Runtime Security 1.18 gives you faster visibility and stronger response capabilities across every deployment. With an improved lightweight telemetry architecture and risk driven threat detection framework, security and platform teams benefit from high-impact alerts, reduced noise, and a hardened security deployment.
If you are interested in learning about a specific topic, navigate directly to that feature using the section below. If you are curious about more under the hood details or broader use cases behind a feature, then please feel free to reach out directly.
What’s new in Isovalent Runtime Security v1.18?
- Smarter Telemetry & Data Exporting
- Previous exporting based on constantly streaming events now steps aside for the new Connection Log pull-based telemetry model, reducing both data transfer and processing overhead.
- Real-time alerts act as the immediate tripwire for critical events, so that urgent security or operational issues are surfaced instantly.
- Connection logs are now natively formatted for Hubble Timescape, streamlining Timescape’s visualization and analytics.
- New performance testing demonstrated extremely lightweight overhead to capture network telemetry data.
- Threat Detection & Response
- Configurable risk scores in policies give flexibility for real-time alerting or enforcement workflows.
- Toxic combinations of suspicious events builds an alerting threshold based on quantitative risk scores, allowing for more precise and context-rich security alerts from multiple low-medium risk events.
- More than 20+ new CVE security policies are published to detect vulnerabilities and critical access attempts immediately.
- Splunk + Isovalent Better Together
- Isovalent arrives on Splunkbase! Streamline security operations, view runtime events, correlate signals, and speed up incident response via new pre-packaged Splunk dashboards.
Connection Log Pull Model
Isovalent Runtime Security uses eBPF to collect data at extremely low overhead and package it with rich metadata about each event. But we know not every event is worth saving. Or often even necessary to export in real time. For most mature security teams, the old firehose model of constantly real-time streaming every event into a backend SIEM simply isn’t optimal any more. Too much data, too much overhead.
In 1.18 this issue is addressed with a new telemetry model that shifts Isovalent’s runtime event architecture from a push model (firehose) that constantly streams events up, and moves towards a pull model where only new or unique events are generated.
Previously, every notable event was pushed in real-time to userspace, written to JSON, and exported to your preferred backend SIEM or metrics DB. The new model (referred to as Connection Log) focuses on the delta between pulls, aggregating the repeat events to reduce data transfer size. A few clear benefits emerge: lower overhead, aggregated metrics, flexible data collection, and less noise to name the primary winners.
Customers already notice the positive relationship between longer pull windows and the value of aggregating. Let's look at a case study around tracking a high-volume of exec calls in a production workload. Isovalent records when a process inside a container is started through an exec action, and a five minute pull might gather roughly a thousand of these actions, which the new connection log data model returns as one compact record rather than a thousand individual events. Stretching that window to ten or fifteen minutes cuts resource use even more, as repeat actions collapse into the same aggregated entry.
Isovalent Runtime Security is constantly keeping track of all data collected in the kernel, so if a platform or security team deploys the Isovalent sensor and pulls every ten minutes starting at 9:00, what teams see at 9:20 is the delta between snapshots 9:10 and 9:20. This significantly reduces the noise generated as teams only see the difference between the last snapshot (9:10 -> 9:20), rather than the entire blob of data observed from deployment to pull (9:00 -> 9:20). You still receive full context for each process, including its lineage back to the parent that created it, without the extra volume or distraction.
The Connection Log model has also been tuned for larger volumes during pulls, to lower overhead when surfacing up data. This gives teams more flexibility in when they collect data and from what types of production workloads. Because of early design decisions using eBPF, Tetragon has always been ultralightweight in how it collects and exports data. We dive into the performance metrics below again using this new model, with a key takeaway that the cost of observing and exporting high-volume network events is now less than 1% overhead in most use cases.
Let’s look at a sample JSON output using the new Connection Log model:
{
"id": "48e63407-2c51-...",
"cluster_name": "test-cluster",
"node_name": "worker-node-1",
"event_type": "TELEMETRY_TYPE_PROCESS",
"time": "2025-11-04T15:00:08.003550552Z",
"kubernetes_namespace": "default",
"kubernetes_workload_name": "nginx",
"kubernetes_workload_kind": "WORKLOAD_KIND_DEPLOYMENT",
"process_hash": "def456...",
"process_name": "/usr/bin/curl",
"process_arguments": "-s https://api.example.com/data",
"execution_count": 1,
"parent_names": ["/bin/bash"],
"first_start_time": "2025-11-04T15:00:08.003550552Z",
"latest_start_time": "2025-11-04T15:00:08.003550552Z",
"application_model_id": "019a4f61-e810-...",
"node_labels": {
"node.kubernetes.io/instance-type": "m5.large",
"topology.kubernetes.io/zone": "us-east-1a"
}
}Notable for this JSON event, you’ll see the Connection Log model is now aggregating events tied to a specific process execution: here we are tracking the process "/usr/bin/curl" on line 11. Since different parent processes can launch the same child process with identical arguments, the new Connection Log output allows for multiple "parent_names" (line 14). This flexibility in stacking metadata extends across other fields in the JSON as well as teams scale up the number of events being aggregated.
The outcome is one single data transfer to userspace, aggregating multiple repeat curl events.
While this new model drastically improves performance, you might be wondering: what happens during pull windows? What if there's an urgent high-risk event that needs investigating? For this, we have Time Sensitive Alerts.
Time Sensitive Alerts
Hand-in-hand with the Connection Log model, Security and Platform teams need immediate real-time alerts for high-risk events. Where the Connection Log model helps with day-to-day observability, alerts are the distributed tripwires to catch and surface up threats in real-time.
Isovalent Runtime Security v1.18’s enhanced alerting logic and new out-of-the-box policies make it easier to detect suspicious runtime behaviors, without being overwhelmed by the need to constantly tune policies. Isovalent has built an expanded library of pre-made policies for known suspicious behaviors. Customers easily apply these to specific workloads or sets of workloads, bringing a user friendly approach to building out detections.
For example, when a privilege escalation attempt is detected on a container, Isovalent generates a concise, context-rich alert, automatically pushed to the SIEM, with workload identity metadata (process, user, cloud metadata, etc), and incident priority embedded into the JSON. Security teams also leverage the tags and severity fields to surface up extra context about the alert, using these to then route the alert to the appropriate team or dashboard.
Each rule lets you set the alert severity, add helpful messages and tags, and filter for exactly what matters. Once in place, the policy watches for specific behaviors and triggers an alert in real time, making it easy for teams to catch and respond to threats fast without drowning in noisy data or waiting for runtime data to transfer between endpoint and SIEM for analysis.
The AlertRule below is a lightweight way to spot threats in real time right where events happen, using Isovalent. Instead of shipping all your data to a SIEM and building heavy detection logic there, you can define simple rules (like this example, which flags when someone searches for AWS credentials with typical shell commands) directly in your cluster.
As we see below, the alert has a severity of high with the tags aws, security, and credential used to route the alert to an internal cloud security team. Or, for teams that leverage the MITRE ATT&CK framework, each alert could be embedded with the MITRE ATT&CK technique that corresponds to that CVE or known suspicious behaviour.
apiVersion: cilium.io/v1alpha1
kind: AlertRule
metadata:
name: aws-credential-hunting
spec:
message: "AWS credential hunting detected"
tags: ["security", "aws", "credential"]
severity: "high"
expression: |
process_exec.process != null && (
(
process_exec.process.binary.endsWith("grep") ||
process_exec.process.binary.endsWith("egrep") ||
process_exec.process.binary.endsWith("fgrep")
) &&
(
process_exec.process.arguments.contains("AWS_ACCESS_KEY_ID") ||
process_exec.process.arguments.contains("AWS_SECRET_ACCESS_KEY") ||
process_exec.process.arguments.contains("AWS_SESSION_TOKEN")
)
) || (
process_exec.process != null && (
(
process_exec.process.binary.endsWith("find") ||
process_exec.process.binary.endsWith("fd")
) &&
(
process_exec.process.arguments.contains("AWS_ACCESS_KEY_ID") ||
process_exec.process.arguments.contains("AWS_SECRET_ACCESS_KEY") ||
process_exec.process.arguments.contains("config")
)
)
)Often there’s not one single event that makes an attack suspicious, but instead a series of risky events that together paint the story of an alert worth investigating. Jump to the section below on Toxic Combinations for a look into how signals are correlated to build an alert from a series of lower risk events.
Correlate process-to-network data, with host-based Kubernetes visibility.
Decode DNS, TLS, HTTP, UDP, TCP, and more while matching to process ancestry information, all with Kubernetes identity-aware metadata (labels, pod names, etc).
Exporting Network Events to Hubble Timescape
Hubble Timescape is your portal to turn raw network data into clear insight about how workloads and policies behave over time.
For customers using Timescape, the Connection Log export also has a few unique optimizations under-the-hood for formatting telemetry from Tetragon into Timescape. The same basic architecture is used for collecting and pulling data, but customers will benefit from pre-tailored formatting and export options for Timescape.
Now, teams can visualize Tetragon’s network events within Timescape, using the aggregated connection data between workloads. The Timescape UI features a live relationship map that groups and displays these connections, letting teams drill into specific paths, see traffic statistics, and filter the view for troubleshooting. This system works alongside traditional Hubble flow data, giving platform teams flexible options for both granular and high-level network visibility.
To learn more about Timescape and Hubble improvements in 1.18 (including this dashboard), hop over to the Isovalent Networking for Kubernetes 1.18 release deep dive.
Additionally, Timescape can visualize the service map Connection Logs from both Kubernetes and VM deployments. Over the coming releases, customers will be able to easily map workload-to-workload topologies and trace connections end-to-end, whether on Kubernetes or VMs.
Performance Benchmarks
Collecting and exporting high-fidelity network data at runtime has historically required trade-offs in performance or scope. The new Connection Log export architecture addresses these trade offs by making it easy to collect, export, and analyze large volumes of events.
Connection Log exports events with improved data formatting for large volumes of telemetry. The new architecture better supports chunked, manageable payloads, addressing bottlenecks with large data exports and compatibility with downstream tools. There’s no trade offs in terms of data richness, each event still includes the same identity context that makes Isovalent Runtime Security so useful, such as process identity, connection details, container metadata, and more.
The goal is always to improve performance, so we ran benchmarks to test just how low impact the new model is. It’s expensive to transfer events from kernel space to userspace, and we think of overhead primarily in two ways: CPU and Memory. Both help frame the ‘cost’ of storing and exporting events.
The below results measure the performance overhead of the Isovalent Runtime Security sensor by comparing CPU and Memory utilization during consistent HTTP workloads (using the hey program) in two scenarios: with the 1) new Connection Log model and 2) legacy push model.
hey was configured to run for 30 minutes with a target throughput of 1000 HTTP requests per second without keep-alive, with 10 goroutines each attempting to sustain 100 HTTP requests per second. The Connection Log model was configured to aggregate and send events over 15 second periods.
First, let’s look at CPU. These two dashboards show Kernel (System) CPU and Userspace CPU % consumed by Isovalent under the previous push model (blue) and new Connection Log model (green).
First off, both of these results are impressive, at under 1% total overhead to observe and export the 1000 HTTP requests per second test under each model.
Diving into each: On the left, the graph for Kernel CPU shows Connection Log at 0.355% and the push model lower at 0.275%. This means the Connection Log is consuming slightly more CPU in the Kernel.
However, the right graph covering Userspace is where the optimizations shine. While the push model creates consistent overhead waking up Userspace (0.472%) to transfer each individual JSON event, the new model shifts a higher CPU cost to the Kernel with the added benefit of significantly lowering the Userspace CPU (0.0031%) down to almost no overhead. This improvement becomes clear and significant when looking at total CPU usage below.
Ultimately, the net win in total CPU (Kernel + Userspace) overhead is significant when stacked together in the above graph. This is a 47.9% reduction in total CPU usage from one model to the other, under the same conditions. Isovalent’s push model stays under 1% (0.747%), while the Connection Log (0.358%) manages to maintain under 0.5% utilization, almost indistinguishable from just the isolated out Kernel CPU results.
While CPU was split into Kernel and Userspace, Memory is tracked in one form as part of the application. Here we see how the Connection Log model, coupled with memory optimizations in v1.18, reduces and stabilizes the amount of memory consumed.
In the graph, we see the new Connection Log (green) staying below 512 MiB for the duration of the test, stabilizing around 384 MiB. The push model (blue) is also relatively stable around 768 MiB.
While some improvement is expected due to the aggregation logic, we expected the largest gains to be seen under CPU. Therefore, we want to contextualize this leap in memory usage as also attributable to a series of improvements across v1.18’s memory optimization’s.
As demonstrated from the benchmarks, Connection Log has been optimized beyond the already impressive push model to deliver more manageable payloads, keeping CPU utilization under 0.5% and memory under 500MiB. All together, the extremely low overhead and export architecture makes it easier to collect, analyze, and act on highly scaled runtime security events.
Tetragon observability performance benchmarks
Dive into Tetragon's low performance overhead for core use cases: tracking process executions, high-volume file monitoring, and network TCP_CRR.
Risk Scoring
Policies now attach a risk score to each event, correlating public CVE severity data, exploit techniques, workload context, and relevant compliance information. This score is derived from a blend of external threat intelligence (such as CVSS), Isovalent security engineers' understanding of the kernel exploit path, and workload context (process privilege, workload sensitivity, etc). The result is a quantitative value embedded in each policy.
Risk scores are then leveraged into a variety of outcomes for security and platform teams: drive automated policy actions, inform triage decisions in SIEM and SOAR systems, or even trigger an immediate enforcement action to block a process and quarantine the host.
Risk scores give a foundation for building out more complex downstream logic. Imagine a use case where a production workload reaches a risk threshold where events become worth investigating, this then triggers a workflow that increases the scope of logging (turn on the firehose) in anticipation of an investigation.
Take the top section of this policy:
{
"name": "protection-cve-2022-0847",
"severity": "CRITICAL",
"message": "CVE-2022-0847 DirtyPipe splice syscall exploit attempt detected",
"tags": [
"cve-2022-0847",
"dirtypipe",
"privilege-escalation",
"attack.t1068",
"attack.privilege-escalation",
"attack.t1611",
"NIST_800-53_SI-3",
"NIST_800-53_AC-6"
],
"risk_score": 78
}In this snippet, we see a risk score of 78 (line 15) is assigned to the detection of CVE-2022-0847 ("DirtyPipe") exploit activity. The risk score quantifies the potential impact by combining the vulnerability’s severity to the kernel, attack method, and workload, providing a consistent metric that is directly consumed by automated security workflows or alerting systems for prioritization and response.
This is important as we explore in the next sections for building out complex detections or enforcement responses to known CVE’s.
Toxic Combination Detections
The foundation of risk scores allows us to build more complex detection logic. Oftentimes one single event is not suspicious on its own or worthy of bringing everything to a standstill, it’s rare for a single isolated event to 100% indicate an early sign of compromise. Instead, a combination of signals gives the best analysis for understanding threats. In practice, what security teams see is a series of smaller suspicious events and techniques that lead to compromise.
With v1.18, Isovalent introduces Toxic Combinations, which correlate multiple security signals to more accurately identify real threats. Using risk scores, the Isovalent sensor tracks the combined risk of all observed events; when the cumulative risk exceeds a set threshold, it can trigger alerts or enforcement actions.
Take an example workload that has an alerting threshold of 175 points and quarantine threshold of 225 points. All of the below events in isolation are not worth bringing the workload down or forcing an investigation, but combined they indicate a potential larger security gap.
- The workload uses an out-of-date openssll.so.3.5.3. Risk-score = 50
- And weak ciphers are used. Risk-score = 75
- And there is a namespace creation event (more common behaviour so lower risk). Risk-score = 15
- And three new external network connections are made, with tx-bytes > 50MB. Risk-score = 30(*3) = 90
- Total workload risk-score = 230
- Risk threshold is greater than >175, an alert is triggered and sent to Splunk.
- Risk threshold is greater than >225, the workload is sandboxed for investigation.
Attackers rarely rely on one silver bullet to cut through systems. They probe at a variety of weak points and hop around workloads with lateral movement. Toxic combinations are the answer to these smaller indications of compromise, giving flexibility to security and platform teams that want more control over their environment without disrupting production operations or being disrupted by one-off alerts.
Risk scoring based on toxic combinations of suspicious behaviors brings together signals across everything happening in the kernel. Using eBPF, Isovalent’s runtime security has visibility into all activity: outdated libraries, process and network events, weak ciphers, namespace creation, high-volume external transfers, and anything else you want to hook into.
Isovalent Enterprise for Cilium: Security Visibility Lab
Simulate the exploitation of a nodejs application, with the attacker spawning a reverse shell inside of a container and moving laterally within the Kubernetes environment.
CVE Mitigation
Extending the idea of risk scores and toxic combinations even further, 1.18 adds 20+ new CVE policies (referred to as “security shields”) targeting recent, high-profile vulnerabilities (e.g., DirtyPipe, NVIDIA Container Toolkit). These are configured to trigger an immediate response (alert or enforcement) when a violating event is observed.
CVE policies can be prescriptive, looking for specific processes or actions that are indicative of a compromise, or can work similar to Toxic Combinations while including a high enough implied risk score that an immediate response is triggered.
Zero-day vulnerabilities and unpatched exploits represent critical risks for modern enterprises. Traditional detection often stops at static signatures, failing to account for exploitability or environmental context.
At no point should a Kubernetes pod decide its root, let’s look at a CVE covered in 1.18 that protects against a vulnerability in sudo. CVE-2025-32463 allows users to obtain root access using sudo and – chroot.
The following policy mitigates CVE-2025-32463 by restricting sudo from executing mmap'd files with executable permissions from untrusted directories, while keeping normal operations up and running.
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "cve-policy-sudo-cve-2025-32463"
annotations:
author: "Isovalent now part of Cisco"
spec:
enforcers:
- calls:
- "security_mmap_file"
kprobes:
- call: "security_mmap_file"
# https://attack.mitre.org/tactics/TA0003/
# https://attack.mitre.org/techniques/T1574/006/
# tags namespaces:
# - "attack": MITRE ATT&CK https://attack.mitre.org/
# "attack.persistence": The adversary is trying to maintain their foothold.
# - "cve": MITRE CVE https://cve.mitre.org/
# "cve.2025-32463" "cve.CVE-2025-32463"
tags: [ "process-injection", "attack.persistence", "attack.T1574", "cve.2025-32463" ]
syscall: false
message: "Prevented sudo library injection"
return: true
args:
- index: 0
type: "file"
returnArg:
index: 0
type: "int"
- index: 1
type: "uint32"
selectors:
- matchBinaries:
- operator: "Prefix"
values:
- "/usr/bin/sudo"
matchArgs:
- index: 0
operator: "NotPrefix"
values:
# Add trusted paths here for libraries
- "/etc/"
- "/usr/lib/"
- "/usr/lib64"
- "/usr/bin/"
- "/lib/"
- "/lib64/"
- "/bin/"
- index: 1
operator: "Mask"
values:
- 4 # PROT_EXEC
matchActions:
- action: "NotifyEnforcer"
argError: -1We’ve modified the policy to obfuscate the full list of matchBinaries and matchArgs, let’s dive into the high-level important bits.
The initial enforcers section (line 8) tells the policy to actively enforce (not just observe) rules on the target kernel function security_mmap_file (line 10).
matchBinaries (line 33) limits scope to sudo processes, while matchArg (line 37) filters attempts by sudo to only those outside trusted directories.
The operator (line 39) uses Mask with the value 4 to check for the PROT_EXEC flag, directly checking if the process has execute permission and is about to be run as code.
At the end, matchActions (line 53) provides the enforcement mechanism to notify the enforcer and return an error, blocking the disallowed sudo process from executing.
Putting it all together, we have a policy that allows normal operations to run without interference, but enforces against known unexpected root access behavior. These events are then easily piped to a preferred SIEM, as we will see in the next section with Splunk. Each detection event is enriched with the calculated risk score, correlating CVE severity, exploit method, process arguments, and workload context.
A major benefit of Isovalent’s Runtime Security is the dynamic application of new policies, so no downtime needed to protect hundreds of thousands of production workloads when a new zero-day emerges. Read the blog below to learn more about how these vulnerability mitigation policies work under the hood, looking closely at the XZ Utils CVE 2024-3094.
eBPF & Tetragon: Tools for Detecting XZ Utils CVE 2024-3094 Exploit
See how Isovalent helped customers build and deploy policies for the XZ Utils zero-day, keeping production workloads up with the right compensating controls.
Splunk Workflows & Integrations
We’ve spent the earlier parts of this release discussing new improvements around how Isovalent is capturing and exporting telemetry, then what types of alerts teams might build and deploy, and now we get to see it all come together with our workflows in Splunk!
Here, we see the benefits of Isovalent’s rich kernel-level telemetry, getting piped into the leading SIEM. The following pre-packaged Splunk dashboards include new risk scores, alerts, CVE data, argument and identity information, MITRE attack techniques, and more Day Two operation workflows that help teams control and understand their environment.
Start using these dashboards today via Splunkbase, simply download & install the pre-built Splunk App and pull in data from Isovalent to populate. Let’s look at a few example Splunk widgets below where Isovalent Runtime Security v1.18 brings deeper context and modularity to Splunk workflows.
The Top Risky Assets dashboard continuously ranks Kubernetes workloads and virtual machines by aggregated risk, surfacing the most at-risk assets in real time. Assets are separated out by type (K8s vs VMs), so above we see just the top risky Kubernetes workloads, with all of them AWS nodes from the kube-system namespace. Here, teams are using the Isovalent risk scores to track and aggregate real time risk across production workloads.
As a risky workload’s score suddenly spikes, Security teams trace recent changes and focus investigation on that exact cluster or asset. The dashboard’s live risk tracing helps administrators compare trending risk over 24 hours or any defined intervals, showing which workloads are seeing unusual threat activity or trending towards policy violations.
Using tags in the alert policies, specific CVE’s and threats are tied back to the MITRE ATT&CK framework. In the previous CVE section’s example policy, we saw the tag "attack.persistence" is included, so when that event surfaces in Splunk it’s linked with that specific MITRE ATT&CK technique.
The Threat Detection dashboard then filters each Alert by MITRE ATT&CK tactic, making it clear which techniques like Privilege Escalation or Execution are active in the environment. This is an entry point for more context into specific alerts to filter by severity, drill into time windows, or quickly identify clusters of related activity.
When the time sensitive alert ‘tripwires’ catch attackers, security teams need the right context at their fingertips. This dashboard surfaces up new alerts that need investigation, with the context needed for immediate understanding and investigation stretching back to container init.
The Alerts dashboard provides granular, drill-down visibility into every individual alert, linking each event to its process, workload, arguments and execution context.
Drilling into an alert, customers see precise process IDs, executable paths, argument values, parent-child relationships, and the exact Kubernetes workload and namespace. This level of detail enables direct mapping of the alert to system activity, clarifies the source and intent of suspicious commands, and provides the context needed for forensic traceability.
If you are curious about the Isovalent + Splunk integration, see it first hand with the free lab below.
Discover the Splunk + Isovalent lab!
This ready-to-spin-up lab shows you how Isovalent and Splunk work together to provide compensating runtime controls and advanced threat detection for cloud-native environments.
Ready to learn more?
Isovalent Runtime Security 1.18 delivers a leap forward in cloud-native security with smarter telemetry, context-rich risk scoring, and flexible integrations for modern Splunk observability workflows.
By combining the optimized, low-overhead connection log model, real-time alerting, and new “toxic combination” detections, security and platform teams gain faster, more accurate visibility into workload behavior with minimal noise. Seamless integrations with Splunk and Hubble Timescape, plus a robust library of new CVE policies, helps customers detect and respond while continuously improving their security posture across Kubernetes, VMs, and hybrid environments.
Learn more about our full Isovalent Enterprise Platform 25.11 release in our webinar, register below!
Register for the Isovalent Enterprise Platform 25.11 Release Webinar!
If you’d like to learn more about Isovalent Runtime Security and related topics, check out the following links:
- Try Tetragon in a hands-on lab, earn a badge and progress down the Security Engineer Track.
- Request a Demo – Schedule a demo session with an Isovalent Solution Architect.
- Learn more about Isovalent & Cilium at our resource library – It lists guides, tutorials, and interactive labs.
- Get the Security & Compliance White Paper – the 25+ page blueprint for Kubernetes compliance.
- Extract security data no one else can with the host-based Kubernetes visibility solution brief.
Do you have any questions?
Jeremy Colvin, Senior Technical Marketing Engineer