Roles.

The work

Analysis of communications and electronic-signal reporting the customer is entitled to provide. Collection without authority is not part of the role.

• Read material already held. Record the emitter or the protocol, the time, and the conclusion the material supports.
• Keep the source, the date, and the degree of confidence with that conclusion.
• Separate what is established from what is still open.
• Write the record so a second analyst can follow it without reconstructing the work.

Experience

• Prior reading of communications or electronic-signal reporting that someone was entitled to hold. Open-source notes alone are not this work.
• Name an emitter or a protocol, place it in time, and state what the material supports and what it does not.
• Keep the source, the date, and the degree of confidence attached to the conclusion.
• Do not collect, intercept, or request traffic the customer is not entitled to give.
• Write the file so a second analyst can follow it. Read Arabic when the material is in Arabic.

The work

The networks in the environments CyberListen defends: how they are built, how they are segmented, and how their logs reach the SIEM.

• Describe the path of traffic and of logs for the systems in scope.
• Segmentation, routing, and name resolution, written against the environment rather than a generic diagram.
• An inventory of the devices in scope, and a written change when one is added or removed.
• The work sits with security operations. It is not a general repair desk.

Experience

• Has kept a network that was in use: routing, segmentation, and name resolution, written for that environment.
• Can follow a flow from the host to the collector and into the SIEM, and say where the path fails.
• Keeps an inventory, and writes the change when a device is added or removed.
• The message names the environments. A general repair desk is not this role.

The work

Monitoring and investigation of systems already in operation. The message must say whether the application is for level 1, level 2, or level 3.

• Level 1: watch the queue, triage the alert, write the first record, and escalate on the procedure in force.
• Level 2: investigate what level 1 escalates, correlate it in the SIEM, and adjust a detection only when the change is written down and does not hide a real event.
• Level 3: own the detection content, lead the case when it requires it, map activity that matches a known technique to MITRE ATT&CK, and write the review after recovery.
• EDR and XDR are tuned to the systems in scope. Hours are set in the contract, not on this page.

Experience

• Level 1 requires work on a live queue: triage, a first record, and escalation on a written procedure.
• Level 2 requires investigation of what was escalated, correlation in a SIEM, and a detection change that was written down.
• Level 3 requires detection content the person owned, a case they led, and activity mapped to MITRE ATT&CK.
• The message names the level. EDR or XDR is described against the systems actually tuned, not a vendor list.
• Hours are agreed in the contract. This page does not set a rota.

The work

Authorised testing of the systems named in a written scope. The work does not start without that authority and that list.

• External, internal, and application testing, and a configuration assessment when the scope includes it.
• Findings that describe adversary behaviour are mapped to MITRE ATT&CK, which is a knowledge base, not a certificate. Application testing uses a written method. Where the practice matches, that method uses the OWASP Web Security Testing Guide.
• The report states the method, what was attempted, what succeeded, the evidence, and the condition the systems were left in.
• The scope names the systems, the window, and the contact if a test has to stop.

Experience

• Has tested systems under a written authority and a named list. A demonstration without that authority is not this work.
• External, internal, or application testing, and a configuration assessment when that was in the scope.
• Findings that describe adversary behaviour, mapped to MITRE ATT&CK, with the method and the evidence written down.
• A report that states the method, what was attempted, what succeeded, the evidence, and the state the systems were left in.
• Will stop when the scope says to stop, and will not start without the written authority.

The work

The written record of the rules that apply to CyberListen and to an engagement. The role does not issue a certificate, and the company does not claim one.

• Personal data under Saudi Arabia’s Personal Data Protection Law, Royal Decree No. M/19, as amended by Royal Decree No. M/148, and the SDAIA rules on transfer outside the Kingdom.
• The cybersecurity baseline the company keeps for its own operation, consistent with NCNICC-1:2025, and the controls named in a contract, including ECC-2:2024 where that instrument applies.
• Classification of software and technical detail before it crosses a border. The Wassenaar lists are the company’s own rule. United States ITAR and EAR apply only where United States jurisdiction attaches.
• The Anti-Cyber Crime Law, Royal Decree No. M/17, is a limit. A request to build or to test without authority is refused.

Experience

• Has applied the Personal Data Protection Law, Royal Decree No. M/19, as amended by Royal Decree No. M/148, and the SDAIA transfer rules, to a record that was kept. Reading the text is not enough.
• Can keep a cybersecurity baseline consistent with NCNICC-1:2025, and can name ECC-2:2024 when a contract brings that instrument into scope.
• Can classify software and technical detail before it crosses a border. The Wassenaar lists are the company’s own rule. ITAR and EAR apply only where United States jurisdiction attaches.
• Will refuse a request to build or to test without authority, under the Anti-Cyber Crime Law, Royal Decree No. M/17.
• Does not issue a certificate, and does not claim one the company does not hold.

The work

Builds the interface and the service of software developed from research in Riyadh, for use in Saudi Arabia.

• The interface, the service behind it, and a written statement of what the software does and what it does not do.
• The record of a change stays with the change: what moved, and why.
• The product is for use in Saudi Arabia.
• The interface and the service are described together, so a later change does not split the account of what the software does.

Experience

• Has built an interface and the service behind it, and can state in writing what that software does and what it does not do.
• The record of a change stayed with the change: what moved, and why.
• The software is intended for use in Saudi Arabia. State the function and the limit in the application.
• Name the systems you built, who used them, and the result. Name the tools as well, but do not stop at the tool list.
• Describe a build that was used, including what it did and what it refused to do.

The work

Leads the infrastructure the research and development group runs: the environments, who can change them, and the path from a change to a running service.

• The environments used to build and to run the software, named and written down.
• Who can change an environment, and the record of that change.
• The path from the repository to the running service, including where it stops if a check fails.
• The path is written so a second person can see where a change stopped.

Experience

• Has run the infrastructure for a group that was already building software, not a diagram of a platform.
• Can say what is built, where it runs, and who is allowed to change it.
• Writes the change with the change.
• The message names the environments. A vendor list is not that account.

The work

Models, and the software around them, for work developed from research in Riyadh. The role states what a model does and what it does not do.

• The data a model is trained or evaluated on, and the right under which that data was held.
• What the model is for, how it is evaluated, and the limit of that evaluation.
• The service that presents the result, and the failure cases that are already known.
• No use of data the customer is not entitled to give.

Experience

• Has trained or evaluated a model on a stated set of data, and can say what that evaluation does not show.
• Can put the model behind a service and state the inputs and the outputs.
• State what the evaluation shows and what it does not show. A demonstration is not described as a finished product.
• Name the model work, the data, and the right under which that data was held.

The work

The services behind software built in the research group: what they accept, what they store, and the record of a change.

• The service boundary: what it accepts, what it returns, and what it refuses.
• The data stored, why it is stored, and who can read it.
• The record of a change stays with the change.
• The service boundary is written: what it accepts, what it returns, and what it refuses.

Experience

• Has built a service that was used, and can state what it does and what it does not do.
• Can name the data the service stores and who is allowed to read it.
• The message names the service and who it was for.
• Name the service, who used it, and the data it stores.

The work

Application software for a named research task.

• The function that was asked for, and the limit of that function.
• The change, and why it was made.
• The software is for use in Saudi Arabia.

Experience

• Has written software that someone else ran, and can say what it does.
• Keeps the record of a change with the change.
• The message names what was built.
• Name what was built, who ran it, and what it does.

The work

Operating-system software for the research group: a kernel, a driver, or the boundary between the system and a program, where the task names it.

• The component in scope: kernel, driver, or the system-call boundary.
• What the component is responsible for, and what it is not.
• The condition the system was left in after the change.
• No change to a system the company is not entitled to modify.

Experience

• Has changed operating-system code that was actually run: a kernel, a driver, or the boundary a program uses to ask the system for a service.
• Can say what the change affected and what it left alone.
• Name the system, the component, and what the change affected.
• Will not modify a system without written authority.

The work

The written plan of a research and development task: what is in scope, who does it, and what done means.

• The task, the people on it, and the date the scope was agreed.
• What is in the task and what was left out.
• A change to the scope is written down when it is made.
• The plan does not start collection, testing, or a build without the authority that work requires.

Experience

• Has kept a technical task to a written scope, with a record of what was delivered.
• Can say what was delivered and what was not.
• Writes a change of scope when the scope changes.
• The message names the work that was managed.

The work

Research into weaknesses in web software the company is entitled to examine. A finding is a written record, not a demonstration on a system outside the scope.

• The component in scope: a site, an application, or a protocol used by one.
• The weakness, the condition required for it, and the evidence.
• Where a known technique matches, map the finding to MITRE ATT&CK.
• Nothing is tested on a system that is not named in a written authority.

Experience

• Has written up a weakness in web software the person was entitled to examine.
• The record states the condition, the evidence, and what was not shown.
• Will not test a system that is not named in the authority.
• Name the web software examined, the condition, and the evidence.

The work

Leads the pipelines that prepare data for the research group: where the data came from, what was done to it, and who can read the result.

• The source of the data, and the right under which it was received.
• What the pipeline changes, and what it leaves as it was.
• Who can read the stored result.
• The source of the data, and the right under which it was received, are named before the pipeline runs.

Experience

• Has run a pipeline on data the organisation was entitled to hold, and can name the source.
• Can say what the pipeline did to the data.
• Does not accept a source the company is not entitled to hold.
• Name the pipelines, the sources, and what each pipeline changed.

The work

Analysis of material the customer is entitled to provide. Collection without authority is not part of the role.

• Read material already held. Record the source, the time, and the conclusion the material supports.
• Separate what is established from what is still open.
• Keep the degree of confidence with the conclusion.
• Write the record so a second person can follow it.

Experience

• Prior work reading material someone was entitled to hold, and writing the conclusion it supports.
• Name the source and the date with the conclusion.
• Do not collect, intercept, or request material the customer is not entitled to give.
• Open-source notes alone are not this work.

The work

Tools the research group uses on material it is already entitled to hold. A tool does not collect. It works on what has already been received.

• What the tool accepts, what it produces, and what it does not do.
• The record of a change stays with the change.
• A tool is not pointed at a system outside the written authority.
• The tool states what it accepts, what it produces, and what it refuses.

Experience

• Has built a tool that a second person used on a stated input.
• Can write what the tool does and what it refuses.
• Will not build a tool whose purpose is collection without authority.
• The message names the tool and who used it.

The work

Research into weaknesses in software and systems the company is entitled to examine. The output is a written finding.

• The system or the component in scope.
• The weakness, the condition required for it, and the evidence.
• Where a known technique matches, map it to MITRE ATT&CK.
• The record states what was not shown.

Experience

• Has written a finding against software or a system the person was entitled to examine.
• The record includes the condition and the evidence.
• Will not examine a system that is not in the written scope.
• Name the research, the condition, and the evidence in the written record.

The work

The commercial contact with a customer. The role does not start the technical work. It records what was asked, so that a scope can be written.

• The organisation, the question, and what the customer says it already holds.
• What was asked, and what was not offered.
• A request to build or to test without authority is not taken forward.
• The technical work starts only after the scope and the authority are written.

Experience

• Has kept a commercial conversation as a written record of what the customer asked.
• Does not describe a capability the company has not stated.
• Passes on a request that would require collection or testing without authority, so that it can be refused.
• The message names the work and the kind of customer. Do not attach classified material or passwords.

The work

The structure of a system built for the research group: the parts, the boundary of each part, and what the system does not do.

• The parts of the system and the boundary of each one.
• What data crosses a boundary, and who can read it.
• A change to the structure is written down when it is made.
• What crosses each boundary, and who may read it, is written with the structure.

Experience

• Has written the structure of a system that was then built, not a diagram with no system behind it.
• Can say what each part is responsible for and what it refuses.
• The message names the system.
• Name the system that was built from the structure, and what each part refuses.

The work

The hiring record for an open role: who was asked to write, which role was named, and what was not asked for.

• The role as it is written on this page, including the city, Riyadh or Beirut.
• The message asks for the work already done. It does not ask for classified material, passwords, or sensitive personal data.
• A record of who was written to, and the role that was named.
• The role does not set a certificate, a clearance, or a start date. Those are not decided on this page.

Experience

• Has kept a hiring record: the role, the person asked, and the date.
• Uses the requirements written for the role, and does not add a bar that is not written here.
• Does not ask an applicant to send classified material or passwords.
• The message names the hiring work already done.

The work

Software close to the machine: memory, time, and the interface the hardware or the operating system actually offers.

• The component in scope, and the interface it uses.
• What the code is responsible for in memory and in time, as far as that was measured.
• The condition the system was left in.
• No change to a system the company is not entitled to modify.

Experience

• Has written low-level code that was run, and can name the interface it used.
• Can say what the code controls and what it does not.
• The message names the system. A language name alone is not enough.
• Will not modify a system without written authority.

The work

A full-time internship in the research and development group. The intern writes software on a named task, and the result is read by someone who already does that work.

• The task is named before the work starts: what to build, and what it does not need to do.
• The change is small enough that a second person can read it.
• The task stays inside the authority given for that task. Do not send credentials or sensitive case files.
• The internship does not itself create a later role. A later role, if any, is a separate decision.

Experience

• Has written a program another person could run.
• Can say what the program does.
• Does not send classified material, passwords, or sensitive personal data.
• The message names the program. The internship uses the same limits as the other software roles.

The work

Checks software built by the research group against the written statement of what it does. The result is a record of what passed and what failed.

• The statement of what the software does, and the checks written against that statement.
• What passed, what failed, and the evidence.
• A failed check is not closed by rewriting the statement after the fact, unless that change is written down.
• A check is not a test of a system outside the written scope.

Experience

• Has checked software against a written statement of what it should do, and recorded what failed.
• Can separate a failure of the software from a failure of the check.
• The message names the software and the checks.
• Name the software, the checks, and what failed.

The work

Research into the condition and evidence of a vulnerability in software the company is entitled to examine.

• The software in scope, named.
• The vulnerability, the condition required to reach it, and the evidence.
• Where a known technique matches, map it to MITRE ATT&CK.
• Nothing is tried on a system outside the written authority. The record states the condition the software was left in.

Experience

• Has documented a vulnerability in software the person was entitled to examine.
• The record includes the condition, the evidence, and what was not demonstrated.
• Stops at the written scope.
• Name the vulnerability, the condition required to reach it, and the evidence.