Theme Technical Testing

This page contains tests of technical aspects of the theme I am using and Jekyll in general.

Michael McDonnell

Michael McDonnell/ The Cybersecurity Librarian

404.html_pages/curated-threat-report-list.md_pages/detection-engineering-notes.md_pages/guardduty-to-splunk-cim-alert.mdindex.html_pages/learning-podcasts.md_pages/learning-writing.md_pages/learning.md_pages/moro-and-mike.md_pages/moro-mike-podcast.xml_pages/test.mdassets/css/style.scssfeed.xmlblog/page2/index.htmlblog/page3/index.htmlblog/page4/index.htmlblog/page5/index.htmlblog/page6/index.htmlblog/page7/index.htmlsitemap.xmlrobots.txt _pages/detection-engineering-notes.md_pages/learning.md_pages/moro-and-mike.md

404

Page not found :(

The requested page could not be found.

Last Update: 2025-04-05

(DRAFT) This is a list of threat and risk reports curated by The Cybersecurity Librarian. This is the list of annual and periodic reports I read to keep informed on changes in the threat landscape and to forecast threats for the coming months. It is updated annually.

Overview

If you work in cybersecurity, you face a difficult reality: constantly changing threats. What worked to defend your organization last year (or month) may not work today. Your adversaries partially dictate your operational tempo. When they innovate you must match their pace or you will be left unaware of your vulnerability and exposure.

A constantly changing threat landscape frequently means that no cybersecurity program is complete and there is always too much to do. To succeed, you will necassarily need to set priorities based on “threat-risk”: estimates of the liklihood that a threat could have a material impact on you in the near future.

But how do you stay informed as to what threats are relevant to you? Which should be viewed a risk that requires mitigation in the near-term? That is where having a well curated list of threat reports helps.

I use this list to keep myself informed and adjust my understanding of shifts in the threat landscape annually.

Categories of Report

I categorize these reports using several demensions:

  1. Frequency of Publication
  2. Type of Publisher
  3. Scope of Report
  4. Focus of Report

Frequency of Publication

This list is intended for strategic insights. I only include in this list reports that are infrequently published: annually or quarterly. This is to give you a look back at the trends to look for patterns that might indicate a trend.

Should you track sources more frequently? Yes, but daily, weekly, and monthly reports forecast threats that require immediate operational or tactical adjustments. You need a collection process for that: your sources will change frequently.

Where possible, I include the rough time-of-year when annual reports are expected. Some are predictably published in specific months or quarters. It helps to know when to go looking!

Type of Publisher

It helps to understand the bias and context of each report. Commercial vendors often publish reports. Despite being marketing tools, certain vendors have unprecendented or unique insight into threats. Government organizations also supply report but the context or scope may bias their view: do they only analyze Nation-based cyber-espionage and ignore cybercrime? Do they only focus on fraud that targets indviduals?

Scope of the Report

The scope of the report is important. Some have a global focus, others limited to a specific customer base or Nation. I have no fixed vocabluary for these but I attempt to identify the scope.

Focus of the Report

You should have some diversity in your curated list. You need to consider cybercrime, geopolitics, IT/OT, cyberware, fraud etc. So I identify the focus as best as I can so I can later consider if I have enough sources for each of my priority requirements.

Curated List of Reports

PIRs/Identified Topics Cloud Threats Software Supply Chain Ransomware-as-a-Service Nation-aligned cyber-attacks Post-quantum Threats Mobile Threats

Threats that target various assets:

  • Cloud
  • Mobile
  • Endpoint
  • Web Applications
  • Network Services
  • Encrypted Data (Network and Storage)
  • People
  • Software Applications

Annoted Bibliography

Verizon Data Breach Investigations Report (DBIR).
This is one of the longest running cybersecurity reports available. It uses the VERIS Vocabulary to classify incidents. It provides a common basis with which can compare your own incidents and other reports.
World Economic Forum Global Risk Report
Based on the Global Risks Perception Survey whose participants include a wide variety organizations across the globe, this provides unique insight into the evolving risk landscape. It is not cybersecurity specific and therefore gives us insight into where cybersecurity should be prioritized relative to other business risks.
World Economic Forum Global Cybersecurity Outlook
The World Economic Forum’s Global Cybersecurity Outlook 2025, written in collaboration with Accenture, examines the cybersecurity trends that will affect economies and societies in the year to come. The report explores major findings and puts a spotlight on the complexity of the cybersecurity landscape, which is intensified by geopolitical tensions, emerging technologies, supply chain interdependencies and cybercrime sophistication.
Crowdstrike Global Threat Report
Crowdstrike has remarkable access to real-world attack data both from their Falcon product but also from their threat hunting and incident response practices. They are a leading Incident Response provider, and each year the investigate some of the biggest, and smallest, threats.
Cisco Talos Year in Review
Cisco Talos’ Year in Review reveals insights into how cyber criminals carried out their campaigns, and what made an attack successful. Read about threat actor activities across topics including top targeted vulnerabilities, network-based attacks, email threats, adversary toolsets, identity attacks, multi-factor authentication abuse, ransomware, and AI-based threats.
Department of Homeland Security Threat Assessment
This report covers cyber and non-cyber threats. This respresent the USA nexus of threat, filtered through the lens of government policy. It should be checked for bias and omissions given the current US government climate.
ENISA Threat Landscape Reports
ENISA publishes several reports that include cyberthreat coverage. These are seen through the European nexus of threat. Their Foresight Cybersecurity Threats provide a unique longer time frame of forecasting. They also have a report specific to the Finance Secrore.
FBI Internet Crime Complaint Center (IC3) Reports
The FBI operates the Internet Crime Complaint Center which receives reports from US Citizens of cybercrime. Their annual reports given insight into the crimes that affect individuals, not just businesses. Most other reports are biased toward espionage, cyberwar, and cybercrime targeting organizations. These reports provide a balancing perspective on the individual’s nexus-of-threat.
RedCanary Threat Detection Report
RedCanary is a leading Managed Security Provider and has visibility into a large number of cyberattacks. Further, they have an outstanding threat intelligence team.
Mandiant M-Trends Report
Like Crowdstrike, Mandiant has unprecendented visibility into cyberattacks of all sizes. They have a long track record of tracking Nation-sponsored cyber attacks against Western countries.
Flashpoint Global Threat Intelligence Report
Not on my list for high priority.
Google Cybersecurity Forecast
Google now owns Mandiant, but also has it’s own cybersecurity teams. This report provides insights from their Cloud security marketing. It includes insights into AI and Cloud threats. Note: this is published by Google Content Marketing team: it is not from one of their intelligence units. A sales bias shoudl be assumed.
Google Cloud Threat Horizons Report
Published twice a year, this report is specific to Cloud security threats and names specific actors known to launch real world cloud attacks.

RecordedFuture Cyber Threat Analysis Report

Microsoft Digital Defense Report

Sophos Threat Report
Sophos Active Adversary Report
Now it it’s fifth year of publication (as of 2025), Sophos provides excellent analysis of cyber attacks. While they are not the biggest security software provider, they have excellent threat intelligence.
Reliaquest Annual Threat Report
Reliaquest has purchased and developed a number of threat intelligence platforms and services. While they lack the scope of other intelligence services, they have timely coverage of major trends in cyber attacks.

FIRST Vulnerability Forecast

Uptycs Threat Bulletin
Arguably and authority on cloud cyber attacks.

ISACA State of Privacy https://www.isaca.org/resources/reports/state-of-cybersecurity-2024 https://www.fairinstitute.org/blog/takeaway-from-isaca-report-cybersecurity-needs-new-quantitative-focus

FS-ISAC https://www.fsisac.com/navigatingcyber2024 https://www.fsisac.com/hubfs/Knowledge/NavigatingCyber/2024/FSISAC-NavCyber24-Report.pdf

Canadian Centre for Cyber Security Cyber Threat Assessment

https://www.cyber.gc.ca/en/guidance/baseline-cyber-threat-assessment-cybercrime https://www.cyber.gc.ca/en/guidance/threat-large-language-model-text-generators

Intel 471 Cyber Threat Report
Intel 471 leads on threat intelligence processes and frameworks. They also have outstanding visibility into cyber criminal networks and forums.

Akamai Palo Alto SiloBreaker Huntress Threat Report IBM X-Force Threat Intelligence Index IBM X-Force Cloud Threat Landscape Report Crowdstrike Threat Hunting Report Veracode State of Software Security Accenture State of Cybersecurity Resilience ISC2 Cyberthreat Defense Report Deloitte Future of Cyber Survey Proofpoint Voice of the CISO Report KnowBe4 Cybersecurity Culture Report PwC Global Digital Trust Report Splunk State of Security Verizon Mobile Security Index Snyk State of Open Source Security Checkmarx State of Software Supply Chain Security Crowdstrike SaaS Security Posture Management ISC2 Cloud Security Report Palo Alto State of Cloud Native Security Report Google Cybersecurity Forecast 2025 Cobalt State of Pentesting HackerOne Hacker Powered Security Report Proofpoint Data Loss Landscape

Research Sources

This section is a list of sites and search strategies I use to discover new sources for potential inclusion in this list. Every year there are new sources.

https://github.com/jacobdjwilson/awesome-annual-security-reports https://github.com/hslatman/awesome-threat-intelligence

Obtaining Access to Private Sources

Some of the sources listed here require subscriptions or membership in private groups. When that is true, I will clearly identify the source and provide a footnote on how to obtain access or membership.

Gartner

FS-ISAC

Canadian Centre for Cybersecurity (CCCS)

ISACA

Last Update: 2023-05-13

I want to better understand the industry landscape and emerging practices in Detection Engineering and Threat Hunting. These are my notes on DE perspectives, frameworks, processes, tools, and people to learn from.

What is Detection Engineering?

Detection Engineering is the populized term to describe the practice of designing, developing, and maintaining systems for the detection of cyber threats. It is closely related to Threat Hunting and shares frameworks and processes. It is a not a discipline of Engineering as defined by many regulatory bodies, but a term populized through wide-accepted usage in cybersecurity. It is used to distinguish between the roles of Threat Intelligence and Incident Response in Security Operations. The specific definition varies, but the term itself is now widely used.

My working definition (subject to change):

Modern Detection Engineering and Threat Hunting are agile threat-informed defense practices that develop and operationalize threat detection analytics. These practices require threat analysis, data engineering, design and management of detection systems, development of detection analytics, and operation/execution of threat detection. They are DevOps practices driven by threat intelligence, enabled by data modeling on large datasets, and increasingly requiring the application of statistical techniques. The product of these practices are analytics: rules, signatures, dashboards, reports, searches, data models, visualizations, and/or “enrichments”. They are both functions of Security Operations and distinct from Incident Response, Vulnerability Management, and Threat Intelligence.

Some perspectives on how to define Detection Engineering/Threat Hunting:

Threat hunting and detection engineering are different specializations, but are closely related. They have common goal of finding attackers using available data, whether its the attackers that got past your detections (threat hunting) or the next ones through (detections). – Mark Simos

Detection engineering is the process of identifying threats before they can do significant damage. Detection engineering is about creating a culture, as well as a process of developing, evolving, and tuning detections to defend against current threats. – CrowdStrike

Detection engineering transforms information about threats into detections…. Detection engineering transforms an idea of how to detect a specific condition or activity into a concrete description of how to detect it. – Florian Roth

Enter Threat hunting - the proactive practice of ferreting out those sneaky cyber-rodents. Or, if you insist on a more formal definition, “any manual or machine-assisted process intended to find security incidents missed by an organization’s automated detection systems.” Either way, hunting is a great way to drive improvement in automated detection and help you stay ahead of the attackers. – David Bianco

When I teach threat hunting, I say “The purpose of threat hunting is not to find new incidents. It’s to drive improvement in automated detection.” Put simply, threat hunting is detection R&D (at least at the higher levels of hunting maturity)…. our hunting outputs are not only detections. We update playbooks and other documentation for our detection engineers and (especially) our response teams. Our primary goal is to improve automated detection, but we see IR improvements as important secondary goals. – David Bianco

Detection engineering is by no means limited to the detection of events (activity). It also includes detecting conditions (states), often used in digital forensics or incident response. – Florian Roth

A Threat Detection Engineer is someone who applies domain knowledge on designing, building or maintaining detection content in the form of detections generating alerts; or interfaces in the form of dashboards or reports supporting the security monitoring practice within an organization. – Alex Teixeira

Detection engineering is a process—applying systems thinking and engineering to more accurately detect threats. The goal is to create an automated system of threat detection which is customizable, flexible, repeatable, and produces high quality alerts for security teams to act upon. – Laura Kenner, uptycs

Detection engineering functions within security operations and deals with the design, development, testing, and maintenance of threat detection logic. – Mark Stone, panther

Detection engineers design and build security systems that constantly evolve to defend against current threats. – Josh Day, gigamon

Threat hunting is an active means of cyber defense in contrast to traditional protection measures, such as firewalls, intrusion detection and prevention systems, quarantining malicious code in sandboxes, and Security Information and Event Management technologies and systems. Cyber threat hunting involves proactively searching organizational systems, networks, and infrastructure for advanced threats. The objective is to track and disrupt cyber adversaries as early as possible in the attack sequence and to measurably improve the speed and accuracy of organizational responses. Indications of compromise include unusual network traffic, unusual file changes, and the presence of malicious code. Threat hunting teams leverage existing threat intelligence and may create new threat intelligence, which is shared with peer organizations, Information Sharing and Analysis Organizations (ISAO), Information Sharing and Analysis Centers (ISAC), and relevant government departments and agencies. – NIST SP 800-53 v5: RA-10

Detection Engineering sits at the intersection of InfoSec, Cloud Infrastructure, DevOps, and Software Development. – Jack Naglieri

If you want to scale your detection program, you need to hire a Detection Engineering team that can complement each other in the following areas: 1. Subject matter expertise in security, 2. Software engineering, 3. Statistics – Zack Allen

Detection engineering is a new approach to threat detection. More than just writing detection rules, detection engineering is a process — applying systems thinking and engineering to more accurately detect threats. Detection Engineering involves the research, design, development, testing, documentation, deployment and maintenance of detections/analytics and metrics. - Sohan G

Detection Engineering is a capability that researches and models threats in order to deliver modern and effective threat detections. What is Detection Engineering? Goal is to provide automated analytical capabilities {hunts} that can capture and detect the behaviours and TTPs of adversaries. – Atanas Viyachki, Senior Threat Hunter@Weatlthsimple

Detection engineering is the continuous process of deploying, tuning, and operating automated infrastructure for finding active threats in systems and orchestrating responses. Indeed, both the terms “detection” and “engineering” carry important connotations when it comes to the new approaches to security we’re discussing. – Jamie Lewis

Are Threat Hunting and Detection Engineering the Same Thing?

A number of emerging frameworks and defitions for Threat Hunting overlap with Detection Engineering. For this reason, I will include Threat Hunting models, methods, and frameworks. The newest thinking provides fewer differences, mostly around goals and who-does-what.

There appear to be more similarities that differences in processes, with differences proposed depending on the size of the organization. For example, large MSPs see a greater distinction than a mid-size financial institution would: the MSP has entire departments who much detect threats, and labour must be divided. A single organiztaion with an Information Security department of 20 people might want a one or two people to take on all detection development tasks.

Perspectives

Can I get certified as a Detection Engineer?

How can I learn more about Detection Engineering?

Maturity Models

Reading

Articles

Blogs

Books

Listening (Podcasts)

Watching (Videos)

Courses

Events (Conferences)

What are the core Detection Engineering Processes?

TODO. See articles above for now.

What tasks should a Detection Engineering Program document?

Appendix C.3 of the MITRE book 11 Strategies of a World-Class Cybersecurity Operations Center outlines a framework for Detection Engineering/SOC Systems Administrator documentation. In a past job, I worked together with a SOC Syadmin, collaborated on documentation that was similar. I was delighted when I read this appendix and found it was a strong match for what we did. It drove new effeciencies, supported better understanding by incident handlers, and ensured our systems were well maintained and worked.

This key document types for SOC Engineering are:

  • Monitoring Architecture
  • Internal Change Management Processes
  • Systems and Sensors Maintenance and Build Instructions
  • Operational, Functional, and Systems Requirements
  • Budget and current spending (capital and operational expenditures)
  • Unfunded Requirements
  • Sensor and SIEM Detections/Analytics/Content Lists(s)
  • SOC System Inventory
  • Network Diagrams

I like to focus more on the documentation of use-case development. In the MITRE book that would be “Sensor and SIEM Detections/Analytics/Content List(s)” as well as “Internal Change Management Processes” primarily. Below is my own framework for the medium-grained tasks a Detectin Engineer would carry out. You can think of each item below as being an artifact or task documented in Jira or Confluence etc.

  • Document use-case – Taking as input some need, define the use-case so that it maybe reviewed and prioritized and added to the backlog
  • Develop use-case – Input is a documented need for the use-case. Perform in-depth requirements analysis, data wrangling, iterative development of detection and data sources, and full documentation. Output is a test detection in non-production ready to be reviewed for acceptance by stakeholders, and for final implementation.
  • Implement use-case – Input is an developed use-case that has passed acceptance. Implement it in production and remove it from the backlog.
  • Monitor use-cases – Input is all production use-cases. Monitor use-cases and periodically review them for relevancy and effectivness. Output is requests to retire, enhance, or maintain the use-cases
  • Retire use-case – Input is a request from monitoring of all use-cases. Ensure the use-case is disabled tracking anything that has dependencies on the use-case. If necassary create a new use-case to replace this one if others depend on it but it needs to be retired. Output is confirmation that retirement has not caused adverse impact.
  • Plan threat-hunt – Input is demand for a new use-case. Generate a hypothesis and test plan. Describe data sources needed, effort and resources required and a schedule. Output is a plan and schedule ready for approval.
  • Execute threat-hunt – Input is a threat hunt plan that has been approved. Gather the required team, and on schedule execute the hunt. Output is documented findings, and possibly escalation to incident response.
  • Develop metric – Input is a deman from a stakeholder or a documented use-case ready for development. Develop a way to measure the effectiveness of a use-case, or some aspect of the DE program. Output is the logic/process for a scheduled report dashboard or some data.
  • Implement metric – Input is a developed metric. Implement it and remove it from the backlog.
  • Report metrics – Input is all developed, implemented metrics. Operationize reporting. Output is feedback into the use-case development process or advise to stakeholders outside DE.
  • Document datasource
  • Implement datasource
  • Monitor datasource

Frameworks

Frameworks for Detection Engineering/Threat Hunting

  • MITRE TTP-Based Hunting (TCHAMP)
  • Splunk SURGE PEAK
  • Open Detection Engineering Framework
  • MaGMa: a framework and tool for use case management – The MaGMa Use Case Framework (UCF) is a framework and tool for use case management and administration on security monitoring. MaGMa’s tool is decprecated and not maintained but the methodology remains sound well aligned with current practices. It is documented where other practices are often shared word-of-mouth. The primary author works at Splunk which now offers the Entprise Security Content library, with MaGMa like features.
  • TaHiTI: Threat Hunting Methodology – Aligned with MaGMa, the TaHiTI methodology for threat hunting is created with real hunting practice in mind and provides organization with a standardized and repeatable approach to their hunting investigations. The methodology uses 3 phases and 6 steps and integrates threat intelligence throughout its execution.

Standards for Implementing Detection Engineering Processes

Naming Conventions

  • From LASCON talk by – Primary Key:SCOPE:TTP:Short name – Scope is servers, workstations, or something more granular

Detection Specification Languages/Formats

  • Sigma
  • YARA
  • Splunk SPL
  • Microsoft KQL
  • Snort Rules
  • GraphQL
  • YAML

Managing a Backlog of Work

  • JIRA

Processes

  • Agile Use Case Detection Methodologies
  • DevOps CI/CD

EDR

  • Wazuh
  • CrowdStrike
  • Microsoft Defender for Endpoint

SIEM

  • Microsoft Sentinel
  • Splunk Enterprise Security

SOAR

  • Splunk SOAR
  • LogicHub
  • Palo Alta Cortex
  • CrowdStrike Fusion

Analytics

Data Sources (Event Logs)

  • MITRE ATT&CK datasource mapping
  • Sysmon
  • Linux auditd
  • Filebeat
  • Windows Events
  • syslog
  • Firewall Logs
  • Zeek (network events)
  • DNS logs
  • Anti-virus Alerts
  • Active Directory changes
  • AWS CloudTrail

Malware Analysis

  • VirusTotal
  • Any.run
  • Hybrid Analysis
  • Cisco Malware Analytics
  • IDA Pro

Who are the leaders in Detection Engineering?

These are leaders in the sense, that they are people I follow! I have quite a few more to add to this list, many quoted earlier this these notes.

Where does Detection Engineering fit into the NIST Cybersecurity Framework

That’s complicated. The NIST CSF has an entire category called Detect but various activities that are part of Detection Engineering and Threat Hunting are found in other CSF categories as well.

It can be modeled as a control to address the Identity category. For example, through NIST 800-53v5 RA-10: Threat Hunting. Have they confused the role that Threat Intelligence has in informing Threat Hunting? No. The control definition clearly outlines a requirement to establish a capability to monitor for and detect threats. Multiple controls, including threat hunting must be applied toward this requirement.

What is the relationship between Detection Engineering and Incident Response?

Incident Response is the key stakeholder in the development of detection analytics. In the past, or in small organizations, they may also be the developer of detection analytics.

The creation of detection rules and their “tuning” to eliminate false-positives has often been described as an activity carried about by incident responders. For example, a corporate security team, the incident response manage and use the SIEM for detection. The rules exist for them, and they create those rule in response to past incidents or from a library of pre-defined rules that they customize for their environment.

This approach may be considered “historic” and is not emphasized in modern frameworks. It is not that incident responder cannot or should not be involved, it is that their role is operational and should be the consumer of good analytics, the driver of the development of new analytics, and not the developers of analytics. They are a stakeholder, perhaps the most important stakeholder!

What is the relationship between Detection Engineering and Threat Hunting?

Threat Hunting and Detection Engineering go hand-in-hand. Threat Hunting methods are used by Detection Engineers to validate their detection logic, data sources, and measure effectiveness. That said, Threat Hunting has additional outcomes unrelated to Detection Engineering goals, and may trigger incident response.

Most Detection Engineering use-cases begin with a Threat Hunt to validate and priorize the use-case. If the threat hunt proves difficult, it helps estimate the effort of developing the use-case for detecting that threat. If the threat hunt yeilds few false positives, it indicates that the use-case could be highly effective and should get higher priority. If the threat hunt fails due to lack of data, it may indicate that developmen to the use-case should be deferred until the datasource can be developed.

What is the relationship between Detection Engineering and Threat Intelligence?

The need for new detections is often driven by threat intelligence. We want to detect threats before they become incidents and the earliest needs may come from threat intelligence analysis. For example, if Qakbot has changed their methods but your organization has not yet encountered them, threat intelligence may be able to provide information on how to detect the new methods days before you are attacked.

A good detection engineer reads threat reports differently than a malware or TI analyst. He/she discovers detection opportunities, pivots and writes rules for any trace the reported threat may have left. – Florian Roth

What is the relationship between Detection Engineering and Offensive Security?

What is the relationship between Detection Engineering and IT Asset Inventory?

Detection Engineering both consumes and produces asset inventories. Detection Engineering crucially requires quality inventory of assets, identifies, and configurations.

If you want to measure the converage of your detections for an specific threat, you will need to have an inventory of assets targeted by, exposed to, or vulnerable to the threat. If you don’t have a good inventory, you will not know how effective your detection will be. For example, if you have a detection for exploitation of a vulnerability in MS SQL Server, but you don’t know how many SQL Servers you have, or their addresses, you cannot determine if your detection will actually work.

Detection Engineers often have specific inventory requirements that others do not. For example, knowing which security agents are present, knowing how assets are configured, knowing what permissions an identity has. These all can be used to enrich detections to priotize alerts by priority of the asset or severity of the detected threat. Without this additional information, you can detect a threat, but not detemine how urgent a response to that threat is.

What is the relationship between Detection Engineering and Malware Analysis?

In some larger organizations, especially security product vendors and MSP, a core activitity is analyzing new malware samples to extract useful indicators and to turn those into detection rules. The continuous deployment of new detection signatures is driven by malware analysis, and malware analysis might be considered a core skill required of those in a Detection Engineering role. Given that malware hashes are trivially changed, this activity involves more in-depth understanding of malware behaviour and the identification of invariant observables as well as behavior-based detections.

Last Update: 2023-07-16 16:43 UTC (Draft)

A method for mapping AWS GuardDuty Findings to Splunk’s CIM Alert Datamodel. While the common GuardDuty Finding fields are easy to map to the CIM Alert datamodel, it is hard to map the actor and target of a finding. This method provides a dynamic, easy to maintain, way of performing that mapping.

Background

TODO: write an introduction

Why not provide this as a Splunk Add-on? I have provided this to support understanding the two different alert formats. Understanding our data is important because it changes but the patterns for performing this type of mapping are less variant. While much of what I have documented is better implemented in Splunk as specific knowledge objects and settings, the purpose of the document is to understand how to normalize a complex detection event to CIM’s generic format.

By practicing this kind of analysis and design we can apply this method to other formats from other detection engines in the future.

AWS GuardDuty Findings

Splunk CIM Alert Datamodel

Undertanding the CIM Alert Fields

Our goal is to map AWS GuarDuty Finding fields to Splunk CIM Alert datamodel fields. Here is a summary of the

Parsing the GuardDuty Finding Format

The general JSON structure of a GuardDuty finding from CloudWatch looks like this. But we only care about what is in the detail field.

{
         "version": "0",
         "id": "cd2d702e-ab31-411b-9344-793ce56b1bc7",
         "detail-type": "GuardDuty Finding",
         "source": "aws.guardduty",
         "account": "111122223333",
         "time": "1970-01-01T00:00:00Z",
         "region": "us-east-1",
         "resources": [],
         "detail": {GUARDDUTY_FINDING_JSON_OBJECT}
}

You can see a sample of the details object on the AWS GuardDuty Response Syntax page. Here is a sample:

{
  "account: ...,
  "detail": {
    "id": ...,
    "type": ...,
    "resource": {},
    "service": {},
    "severity": 3.3,
    "createdAt": ...,
    "updatedAt": ...,
    "title": ...,
    "description": ...
  }
  "detail-type": "GuardDuty Finding",
  "id": ...,
  "region": "us-east-1",
  resources: [],
  source: "aws.guardduty",
  time: ...,
  version: 0
}

You can see an example from the aws-samples/amazon-guardduty-waf-acl GitHub repository. It shows all the fields you might expect for one specific type of finding. The fields vary from finding type to finding type.

Parsing the Finding Overview

The GuardDuty Finding overview contains descriptive metadata to help us understand the type of finding, how it was detected, who the actor was, and was resource was affected. The finding overview data fills in most of the CIM Alert fields.

CIM Alert Field GuardDuty Finding Field Description
app source When you have many alert sources in the CIM datamodel, you need this to find the GuardDuty ones.
description detail.description A human readable description of the details of the alert.
dest TBD The thing affected by detected activity
dest_type TBD The type of thing affected by the activity detected
id detail.id A unique ID for this specific occurence of the detection type. Updates or related details will share this ID
mitre_technique_id TBD We could create a lookup table to perform this mapping
severity TBD The Splunk prescribed severity values: critical, high, medium, low, informational, unknown
severity_id detail.severity The original detection’s severity rating
signature detail.title A human readable label of the detection
signature_id detail.type A machine readable label for the detection
src TBD The thing that caused the detected activity
src_type TBD The type of thing that caused the detected activity
tag “alert” These will determine which datamodels this event is mapped to
type “alert” The alert type prescribed by the Splunk Alert datamodel: alarm, alert, event, task, warning, unknown
user TBD A user involved in the detected activity in the format used by the Splunk ES Identity inventory. This can the actor or target: we have to choose what makes sense for our use-case.
user_name n/a A username invovled in the detected activity. Human readable.
vendor_account account The AWS where the activity took place
vendor_region region The AWS region where the finding was generated

Parsing the Finding Details

This is the tricky part. GuardDuty has many different types of findings and each one provides different details with different field names. There are thousands of them! How do we know which fields to parse?

For our purpose, we do not need every detail provided in a GuardDuty finding, we only need a few to map to the CIM Alert datamodel. Specifically:

  • The source of the finding. Who was the actor? Was it an IP? An account?
  • The target of the finding. What was affected by the actor? Was it an EC2 instance? An S3 bucket?

We may need a few other details to help provide us context and generate a human readable description.

The field names follow a well structured format defined by an API and easily parsible when exported in JSON. If we parse out relevent details about the type of finding and the resources affected, we can determine which detial fields we want to parse out as well.

Parsing the Finding Type/Signature ID

GuardDuty provides a Finding Type field in a machine parseable format that we will use as the CIM Alert signature_id. It contains a lot of detail that we may want to use during our mapping process. I use the following Splunk Regular Expression in rex to parse out it’s parts.

| rex field=detail.findingType "(?<ThreatPurpose>[^:]+):(?<ResourceTypeAffected>[^/]+)/(?<ThreatFamilyName>[^\.]+)\.(?<DetectionMechanism>[^!]+)!(?<Artifact>)"`

This will produce the fields ThreatPurpose, ResourceTypeAffected, ThreatFamilyName, DetectionMechanism, Artifact and we may or may not want to use these later when determining what other fields to map to the CIM Alert datamodel.

Mapping GuardDuty Severity to CIM Alert Severities

GuardDuty severities to map completely to Splunk CIM’s Alert datamodel. You will need to make a design decision and below you can see my choices.

GuardDuty currenlty uses a 0-10 numeric value and maps these to low, medium, high. However, they do not use the numeric values 0-1 or 9-10. Further, GuardDuty’s documentation recommends “that you treat any High severity finding security issue as a priority and take immediate remediation steps to prevent further unauthorized use of your resources.” CIM Alert uses critical, high, medium, low, informational, and unknown.

How should we map GuardDuty severity to CIM Alert severity? I use the following table and only deviate from GuardDuty’s mapping of numeric ratings to word labels to put the highest GuardDuty findings as Splunk CIM “critical”. I make an assumption that GuardDuty will only use 1 decimal place.

GuardDuty CIM Alert Comment
0-0.9 informational Unused by GuardDuty
1-3.9 low Failed attempts
4 - 6.9 medium Suspicious and anomylous activity
7-7.9 High We will stick with the GuarDuty definition here
8-10 Critical Based on my experience

A simple Splunk eval to acheive this:

| eval severity=case(
    detail.severity > 7.9, "critical",
    detail.severity > 6.9, "high",
    detail.severity > 3.9, "medium",
    detail.severity > 0.9, "low",
    detail.severity > -1, "informational"
)

Dynamically Mapping GuardDuty Targets to CIM Destinations

The CIM uses dest to represent the thing that is affected by an event. GuardDuty findings call these targets. In the CIM Alert datamodel there is only one dest field, but we can describe it with the dest_type field.

There are several CIM Alert fields that are still To Be Determined (TBD). We must use additional details from the GuardDuty finding to determine the values we need.

CIM Alert Field GuardDuty Finding Field Description
dest TBD The thing affected by detected activity
dest_type TBD The type of thing affected by the activity detected
mitre_technique_id TBD We could create a lookup table to perform this mapping
severity TBD The Splunk prescribed severity values: critical, high, medium, low, informational, unknown
src TBD The thing that caused the detected activity
src_type TBD The type of thing that caused the detected activity
user TBD A user involved in the detected activity in the format used by the Splunk ES Identity inventory. This can the actor or target: we have to choose what makes sense for our use-case.
user_name n/a A username invovled in the detected activity. Human readable.

The values we want are usually found in the GuardDuty resource details. Some of them might be in the service details. However, these are complex data objects with many fields. We may need to combine them or compare other field values to determine the specific one we need.

Understanding GuardDuty Resource Details

Each GuardDuty finding detail will contain a resource but is this the thing that was the target or the source of the detected activity? Is the threat actor or the victim?

We can determine this by look at the service details. This is contains details of what the GuardDuty service observed and how to interpret them.

Relevant parts can be

detail.service.resourceRole == TARGET
detail.service.action.actionType = <actionTypeParseable> (eg. NETWORK_CONNECTION)
map actioneTypeParseable to actionType
detail.service.action.<actionType>Action
detail.resource.resourceType == <resourceType>
detail.resource.<resourceType>Details

detail.resource.accessKeyDetails.accessKeyId
detail.resource.accessKeyDetails.principalId
detail.resource.accessKeyDetails.userName
detail.resource.accessKeyDetails.userType

detail.resource.containerDetails

detail.resource.ebsVolumeDetails
detail.resource.ebsVolumeDetails.scannedVolumeDetails.deviceName
detail.resource.ebsVolumeDetails.scannedVolumeDetails.volumeArn

detail.resource.ecsClusterDetails
detail.resource.eksClusterDetails

detail.resource.instanceDetails
detail.resource.instanceDetails.imageDescription
detail.resource.instanceDetails.instanceId
detail.resource.instanceDetails.networkInterfaces{}.privateIpAddress
detail.resource.instanceDetails.networkInterfaces{}.publicIp

detail.resource.lambdaDetails
detail.resource.rdsDbInstanceDetails
detail.resource.rdsDbuserDetails

detail.resource.s3BucketDetails
detail.resource.s3BucketDetails.arn
detail.resource.s3BucketDetails.name
detail.resource.s3BucketDetails.owner.id
detail.resource.s3BucketDetails.type

We can easily map the dest_type and src_type from detail.service.resourceRole and detail.resource.resourceType.

| eval dest_type=case(detail.service.resourceRole=="TARGET", detail.resource.resourceType, True, "unknown")
| eval src_type=case(detail.service.resourceRole=="ACTOR", detail.resource.resourceType, True, "unknown")

It is more challenging to determine the specific value we should put in src or dest however. The following table can be used to describe how we choose values to put into src, dest, user, and user_name. It should have one value for each combination of resourceType and resourceRole. We may need to include a column for the finding type, threat family name, detection mechanism as well. If so, this will be quite long and may need to be updated overtime as we encounter findings we have not handled.

Resource Type Resource Role dest field src field user field
accessKey TARGET detail.resource.accessKeyDetails.accessKeyId TBD detail.resource.accessKeyDetails.principalId
instance TARGET detail.resource.instanceDetails.instanceId   TBD
ebsVolume TARGET detail.resource.ebsVolumeDetails.scannedVolumeDetails.deviceName TBD TBD

Enriching the Alert Description

We have an opportunity to enrich the CIM Alert description field by combining the GuardDuty description with other information. The description field provided by GuardDuty is fine, but relatively generic. Most of the details GuardDuty provides are in other fields. For any important information we want our Splunk users to see but for which CIM Alert has not field, we should consider adding it to the description field.

Another approach is to noralize GuardDuty events to multiple CIM datamodels, some of which can represent the details of GuardDuty alerts better than others. This is discussed in the Conclusion of this article.

What could we add to the description?

  • Attack Details
  • Malware family details
  • Quarantine status
  • Threat intel used to determine the finding
  • Additional ‘src’ and ‘dest’ values we chose not to use in our mapping
  • AWS identifiers that would help an analyst quickly lookup more details
  • Links to GuardDuty

Conclusion

Mapping a complex detection alert to a the CIM Alert fields requires us to make design decisions that interpret the intention of both systems. For example, what is the intended meaning of critical in labeling an alert? Our design choices will affect how the normalized data is used later.

Further, it takes analysis to determine which data represents the threat actor, action, and impacted asset. In this excercise, both models have presentations for these, but mapping this is not straight forward. We have learn about how each format intends to represent them and transform one into the other, often comparing and combining multiple fields.

Should we map GuardDuty Findings to other Splunk CIM Datamodels?

Yes. While all GuardDuty findings can be usefully modeled as Splunk Alerts, some GuardDuty findings can be mapped to other CIM Datamodels.

For examples:

  • GuardDuty can data malware which maps to the CIM Malware datamodel.
  • GuardDuty can detect network attacks which maps to the CIM Intrusion Detection datamodel
  • GuardDuty can detect exfiltration which could map to the CIM DLP datamodel

If you use Splunk Enterprise Security (Splunk ES) then you will have immediate benefits. Splunk ES used many datamodels automatically in dashboard, correlation searches, and investigative tools. By mapping specific GuardDuty findings to relevant CIM datamodels used automatmatically improve your ability to gain insights.

However, if you are using Splunk Enterprise without Splunk ES, I think you have to carefully consider if you have a use case. You may get value from the datamodels, but only if you are already mapping other datasources to them, or if you are building your own add-ons, dashboards, alerting, or reporting.

References

This is a list of high-quality audio-only podcasts

Top 3

The Cybersecurity Librarian recommends these 3 podcasts. They have these attributes:

  • Original Content
  • Quality Analysis
  • Minimal or Stated Bias
The Cyberwire
I believe this is the gold standard for general daily cybersecurity news. The content is timely. The producers actively minimize, disclose, or state bias. The information is accurate and authoritative. The sources they choose are well selected and authoritative. I have seen them state when a source was not primary. The analysis is insightful. The style of the primary host (Dave Bittner) is charming, wry, and still effecient and professional. The guests are well choosen and diverse. While the revenue model they have (advertising/sponsorship) does bias their selection of guests, the interviews themselves appear to be far less bias than other similar shows.
The Cyberwire has a number of spin-off podcasts on the topics of Social Engineer, Cybersecurity Law, Security and Vulnerability Research, and Security Management. Each strikes its own balance of entertainment, education, and original content. Each relies on unique and authoritative guests.
Malicious Life
An extraordinary documentary-style podcast. The host Ran Levi is an engaging presenter and selects worthy topics from the history of cybercrime. What makes this podcast worth listening too is how the producers take complicate timelines of events, balance the detail required, and tell the story of major historical cybersecurity events. There is occaisional bias, but the hosts are good at stating it (mostly). The accuracy and historical detail of the content are impressive. They manage to balance the level of historical and technical detail and tell an entertaining and educational story.
Darknet Diaries
Darknet Diaries presents stories of recent cybercrimes and interviews with cybercriminals, hackers, and penetration testers. Despite the title, the stories are not about the Darknet per se, but about criminal hacking and world of those that compromise security. The topics are diverse, the storytelling is compelling, and interviewed guests are unique. This will give you more than just an entertaining look at cybercrime, it allows us a window into the minds of the people behind many well known security incidents. This is not fact-checked journalism: these are excellent stories. You will hear first hand accounts from criminals and here them state their motivations, tell their life stories, and explain their actions.

News / Threat Intelligence

Discarded
Proofpoint has an amazing Cyber Threat Intelligence team. They are especially well known for tracking email-based threats. This podcasts gives you a behind-the-scenes look into the work of Proofpoint’s intelligence analysts. Typical episodes introduce you to a few analysts, their backgrounds, and the focus of their intelligence work. Then there is a discussion that follows about notable threat actors or analysis methods. If your work involves reporting on any of the “TA” actors (TA505, TA577, TA570), then this podcast is for you. While this is sponsored by a security vendor it is not marketing oriented, and seems to be driven by the analysts themselves giving it an authentic feel: quality content instead of shiny production values.
Click Here
Recorded Future’s newest podcast takes a journalistic style that is different than many other security podcasts. The topics are typically similar to what you might see in the news, but coving the “cyber” side: cyber-espionage, cyber-crime, or cyber-intelligence. The host, Dina Temple-Raston, was formerly part of NPR’s Investigation team and the podcast takes on a serious and more intriguing tone: The format is documentary journalism not round-table discussion.
Recorded Future Podcast
Recorded Future is a company that offers Threat Intelligence services. Their podcast is hosted by Cyberwire host Dave Bittner, and presents interviews with professionals involved in Cyber Threat Intelligence work. Unlike many other vendor podcasts, this one does not focus exclusively on interviewing their own staff and includes many people throughout the industry. It is not a sales-focused marketing initiative and the treatment of topics and selection of guests does not appear to be overly biased.

Privacy, Law, and Policy

Caveat
Caveat is hosted by Cyberwire’s Dave Bittner and Lawyer Ben Yelin. You do not have to be a lawyer to enjoy or learn from this podcast. It discusses recent cybersecurity news and events that are impacted by law.
Privacy Insider
Hosted by Justin Antonipllai, the former Under Secretary for Economic Affairs at the US Department of Commerce, this podcast takes a serious look at law, policy, and social issues related to privacy. The Cybersecurity Librarian has yet to render a verdict on bias. It is sponsored, but the content seemed more “privacy geek” than marketing.

Management and Leadership

Dev.Sec.Lead
While this podcast is no longer produced, it is still available on most platforms. Hosted by Threat Intelligence author Wilson Bautisa Jr., this podcast focuses on leadership development. It is of interest not just to CISOs and managers, but also for the every-day professional. The interview and topics vary greatly and the depth the topics are treated is refreshing. These guests are positive role models focused on improving our profession. This

Writing is a vital skill in cybersecurity. Even those in highly technical roles will be required to write clear concise technical documentation, procedures, and playbooks. Those involved in the assessment of risk, threats, and vulnerabilities will benefit from strong report writing skills. Managers and Consultants have the greatest need to develop effective communication and persuasive writing abilities.

The resources listed on this page will help you develop your writing skills, no matter what your role and need. Please share with us anything that you found helpful. The most useful, clear, and authoritative resources will be added to this list.

Top 3

Ten Steps to Help you Write Better Essays & Term Papers
This book by Neil Sawer is concise and practical. It doesn’t make you learn theory, it tells you what actions to take, right now, to start writing. Then it tells you want you can do to edit your writing and improve it. While this book is focused on students, the advice applies generally to anyone suffering from writers block, or who finds themselves challenged to write more clearly or briefly.
How to write Proposals, Sales Letters & Reports
Also from Neil Sawer, this book uses some of the same writing advice from “Write Better Essays” and applies it to the business world. There is more emphasis on persuasive writing and on communicating with visuals, charts, etc.

Writing for Penetration Testers and Vulnerability Assessment

If you have additional or better examples, templates, or writing guides for pentration testers, please let us know!

Penetration Testers rarely start as excellent writers. Your observations and discoveries need to be communicated and understood if they are to be valued. If you have felt frustrated trying to find good resources on writing pentest reports, you are not alone. Standards for writing pentest reports are emerging and so is advince on good writing. If writing is new to you, remember it just takes practice, just like pentesting does.

Start with learning how to write a narrative report: the most common and easiest type of pentest report.

Penetration Test Report
Offensive Security has provided this template for use by their OSCP penetration testing students for years. It is intended to capture what activities you carried our in your pentest and the order you did them. While it does include recommendations the main focus is on capturing evidence.

Your clients will probably want more than a narrative report. Most want documented observations, risk assessment, and actionable recommendations. When you get good at writing your narrative reports, and consistently include verifiable proof of testing as well as verifiable findings, it will be time to practice writing more complete reports.

Writing Penetration Testing Reports
This is a paper from the SANS Institute’s Reading Room, submitted by a GIAC candidates paper for “GOLD” certification. It presents a fuller view of what a penetration testing report should look like. You will notice that it does not bear much resemblance to the Offensive Security “narrative” template. A narrative report would be an appendix to this type of report. This is what a client is looking for from a vulnerability report: background, risk assessment, and actionable recommendations.

Project Propoals and Statements of Work

If you work as a consultant you will need to write Statements of Work (SOWs) frequently. These are brief summaries that contain a Work Breakdown Structure (WBS) and estimated effort. They do not fully describe a Scope of Work, but are enough to authorize work when a client has trust and clear understanding.

Consultants and employees with initiative will have to write Project Proposals or Plans. These are larger detailed documents that explain the background and need for a project, the detailed scope, a Work Breakdown Structure, estimated effort, requirements for the project, roles of the parties involved, estimates of cost, and more.

How to write Proposals, Sales Letters & Reports
This book uses some of the same writing advice from “Write Better Essays” and applies it to the business world. There is more emphasis on persuasive writing and on communicating with visuals, charts, etc.

The Cybersecurity Librarian maintains a list of use references for helping you to learn more about cybersecurity, to keep up to date, and to develop your skills and knowledge. There are seperate pages for major categories of reference material.

Resource Categories

Do you have a great book, video, blog, article, magazine, journal, podcast, or course that helped you? Let us know. The most compelling, useful, concise, and clear resources will be added to the lists!

“Moro and Mike” was a weekly livestream discussing the cybersecurity profession practice. Our topics included leadership, management, job hunting, career development, emotional intelligence, threat intelligence, situational awareness and more. We go beyond the technology to discuss the professional practice of cybersecurity and IT.

Podcasts

The RSS feed for the Moro and Mike Podcast is https://cyberlibrarian.ca//moro-and-mike/podcast.rss

The Podcast is the audio-only portion of the Moro and Mike YouTube Livestream

Moro and Mike is recorded live on YouTube, but past episodes are available in podcast (audio-only) format on:

Just search for “Moro and Mike”.

Past Livestreams

<?xml version=”1.0” encoding=”UTF-8”?>

https://cyberlibrarian.ca/moro-and-mike/about</link> Moro and Mike Professional Development in Cybersecurity and IT en-us michael@cyberlibrarian.ca (michael@cyberlibrarian.ca) michael@cyberlibrarian.ca (michael@cyberlibrarian.ca) 2025 The Cybersecurity Librarian Sat, 05 Apr 2025 21:18:41 +0000 Sat, 05 Apr 2025 21:18:41 +0000 https://cyberlibrarian.ca/moro-and-mike/about</link> https://cyberlibrarian.ca/assets/images/moro-and-mike-thumb-podcast.png Moro and Mike Professional Development in Cybersecurity and IT The Cybersecurity Librarian Moro and Mike cybersecurity,professional development Michael McDonnell michael@cyberlibrarian.ca no Next Level Mentorship Part 2 https://cyberlibrarian.ca/moro%20and%20mike/2020/10/15/Next-Level-Mentorship-Part-2.html</link> Thu, 15 Oct 2020 19:00:00 +0000 Moro and Mike are joined by guest Kristin McVeigh to discuss how to take mentorship to the next level in your career. https://cyberlibrarian.ca/moro%20and%20mike/2020/10/15/Next-Level-Mentorship-Part-2.html Michael McDonnell Next Level Mentorship Part 2 Moro and Mike are joined by guest Kristin McVeigh to discuss how to take mentorship to the next level in your career. 01:05:49 featured,leadership,mentoring,mentorship,career development,careers no no Threat Intelligence Oct 2020 https://cyberlibrarian.ca/moro%20and%20mike/2020/10/01/threat-intelligence-oct-2020.html</link> Thu, 01 Oct 2020 19:00:00 +0000 Alec and Chris join Moro and Mike for a briefing on the latest threats and cybersecurity news for October 2020 https://cyberlibrarian.ca/moro%20and%20mike/2020/10/01/threat-intelligence-oct-2020.html Michael McDonnell Threat Intelligence Oct 2020 Alec and Chris join Moro and Mike for a briefing on the latest threats and cybersecurity news for October 2020 01:03:54 youtube,livestream,cybersecurity,threat intelligence no no Next Level Mentorship https://cyberlibrarian.ca/moro%20and%20mike/2020/08/20/Next-Level-Mentorship.html</link> Thu, 20 Aug 2020 19:00:00 +0000 Moro and Mike are joined by guest Patti Blackstaffe to discuss how to take mentorship to the next level in your career. https://cyberlibrarian.ca/moro%20and%20mike/2020/08/20/Next-Level-Mentorship.html Michael McDonnell Next Level Mentorship Moro and Mike are joined by guest Patti Blackstaffe to discuss how to take mentorship to the next level in your career. 01:27:2 featured,leadership,mentoring,mentorship,career development,careers no no Futurism https://cyberlibrarian.ca/moro%20and%20mike/2020/08/13/Futurism.html</link> Thu, 13 Aug 2020 19:00:00 +0000 Moro and Mike are joined by co-host Warren Lafountain to discuss Futurism and topics like Artificial Intelligence, CRISPR, Self-driving Cars, and more. https://cyberlibrarian.ca/moro%20and%20mike/2020/08/13/Futurism.html Michael McDonnell Futurism Moro and Mike are joined by co-host Warren Lafountain to discuss Futurism and topics like Artificial Intelligence, CRISPR, Self-driving Cars, and more. 01:48:13 featured,futurism,artificial intelligence,crispr,decision intelligence,self-driving cars,machine learning,blockchain no no Handling Rejection https://cyberlibrarian.ca/moro%20and%20mike/2020/08/06/handling-rejection.html</link> Thu, 06 Aug 2020 19:00:00 +0000 Moro and Mike interview HR Professional Emilie Vincent about how job seekers and hiring managers can handle rejection better, provide meaningful feedback, and improve the hiring process. https://cyberlibrarian.ca/moro%20and%20mike/2020/08/06/handling-rejection.html Michael McDonnell Handling Rejection Moro and Mike interview HR Professional Emilie Vincent about how job seekers and hiring managers can handle rejection better, provide meaningful feedback, and improve the hiring process. 01:27:16 featured,youtube,livestream,cybersecurity,leadership,careers,job hunting,management,emotional intelligence,rejection,hiring,management,recruiting no no Threat Intelligence July 2020 https://cyberlibrarian.ca/moro%20and%20mike/2020/07/30/threat-intelligence-july-2020.html</link> Thu, 30 Jul 2020 19:00:00 +0000 Alec and Chris join Moro and Mike for a briefing on the latest threats and cybersecurity news for July 2020 https://cyberlibrarian.ca/moro%20and%20mike/2020/07/30/threat-intelligence-july-2020.html Michael McDonnell Threat Intelligence July 2020 Alec and Chris join Moro and Mike for a briefing on the latest threats and cybersecurity news for July 2020 01:33:26 youtube,livestream,cybersecurity,threat intelligence no no Students and New Professionals https://cyberlibrarian.ca/moro%20and%20mike/2020/07/23/students-and-new-professionals.html</link> Thu, 23 Jul 2020 19:00:00 +0000 Student Leaders Emily and Alex host the show and interview Moro, Mike, and a panel of experts about careers in Cybersecurity https://cyberlibrarian.ca/moro%20and%20mike/2020/07/23/students-and-new-professionals.html Michael McDonnell Students and New Professionals Student Leaders Emily and Alex host the show and interview Moro, Mike, and a panel of experts about careers in Cybersecurity 02:03:14 featured,youtube,livestream,cybersecurity,career-development,students no no Cybersecurity Certifications https://cyberlibrarian.ca/moro%20and%20mike/2020/07/16/cybersecurity-certification.html</link> Thu, 16 Jul 2020 19:00:00 +0000 Moro and Mike are joined by Mark Shykula to discuss the types, value, and controveries of cybersecurity certifications. https://cyberlibrarian.ca/moro%20and%20mike/2020/07/16/cybersecurity-certification.html Michael McDonnell Cybersecurity Certifications Moro and Mike are joined by Mark Shykula to discuss the types, value, and controveries of cybersecurity certifications. 01:39:36 youtube,livestream,cybersecurity,certifications,training,career-development no no Threat Intelligence June 18 2020 https://cyberlibrarian.ca/moro%20and%20mike/2020/06/18/threat-intelligence-june-2020.html</link> Thu, 18 Jun 2020 19:00:00 +0000 Moro and Mike are joined by Chris McNeil and Alec Mather-Shapiro to discuss the value of Threat Intel reports and to discuss recent breaches and cybersecurity news. https://cyberlibrarian.ca/moro%20and%20mike/2020/06/18/threat-intelligence-june-2020.html Michael McDonnell Threat Intelligence June 18 2020 Moro and Mike are joined by Chris McNeil and Alec Mather-Shapiro to discuss the value of Threat Intel reports and to discuss recent breaches and cybersecurity news. 01:29:43 threat-intel no no Leadership and Emotional Awareness https://cyberlibrarian.ca/moro%20and%20mike/2020/06/11/emotional-awareness.html</link> Thu, 11 Jun 2020 19:00:00 +0000 Moro and Mike interview Nahid Asani about his experience as a manager in using emotional intelligence and emotional awareness. https://cyberlibrarian.ca/moro%20and%20mike/2020/06/11/emotional-awareness.html Michael McDonnell Leadership and Emotional Awareness Moro and Mike interview Nahid Asani about his experience as a manager in using emotional intelligence and emotional awareness. 01:17:36 featured,leadership,emotional-awareness,eq,emotional-intelligence no no Networking for Professional Development https://cyberlibrarian.ca/moro%20and%20mike/2020/06/05/networking-irl.html</link> Fri, 05 Jun 2020 19:00:00 +0000 Moro and Mike interview TJ Zhang and Burhan Syed, two people who have excellent In-Real-Life networking skills. Learn how to improve your professional development by meeting people. https://cyberlibrarian.ca/moro%20and%20mike/2020/06/05/networking-irl.html Michael McDonnell Networking for Professional Development Moro and Mike interview TJ Zhang and Burhan Syed, two people who have excellent In-Real-Life networking skills. Learn how to improve your professional development by meeting people. 01:28:04 networking,professional-development,career-development,job-hunting no no Preparing for a Job Interview https://cyberlibrarian.ca/moro%20and%20mike/2020/05/29/preparing-a-job-interview.html</link> Fri, 29 May 2020 19:00:00 +0000 Moro and Mike talk to Jessica Riad-Wallace about how people can prepare for job interviews. https://cyberlibrarian.ca/moro%20and%20mike/2020/05/29/preparing-a-job-interview.html Michael McDonnell Preparing for a Job Interview Moro and Mike talk to Jessica Riad-Wallace about how people can prepare for job interviews. 01:40:00 featured,careers,job-interview,professional-development no no Cybersecurity in Popular Culture https://cyberlibrarian.ca/moro%20and%20mike/2020/05/22/cybsecurity-in-popular-culture.html</link> Fri, 22 May 2020 19:00:00 +0000 Moro and Mike are joined friends to discuss representations of cybersecurity in popular culture including music, books, news, and movies. https://cyberlibrarian.ca/moro%20and%20mike/2020/05/22/cybsecurity-in-popular-culture.html Michael McDonnell Cybersecurity in Popular Culture Moro and Mike are joined friends to discuss representations of cybersecurity in popular culture including music, books, news, and movies. 02:11:03 featured,cybersecurity,music,movies,books,popular-culture no no Job Hunting and Online Presence https://cyberlibrarian.ca/moro%20and%20mike/2020/05/15/networking-and-job-hunting.html</link> Fri, 15 May 2020 19:00:00 +0000 Moro and Mike interview TJ Zhang and Jessica Riad-Wallace, two exception role models for authentic and effective online networking and social media presence. https://cyberlibrarian.ca/moro%20and%20mike/2020/05/15/networking-and-job-hunting.html Michael McDonnell Job Hunting and Online Presence Moro and Mike interview TJ Zhang and Jessica Riad-Wallace, two exception role models for authentic and effective online networking and social media presence. 01:32:02 job-hunting,networking,careers,linkedin no no Advice on Resumes and Cover Letters https://cyberlibrarian.ca/moro%20and%20mike/2020/05/08/advice-on-resumes-and-cover-letters.html</link> Fri, 08 May 2020 19:00:00 +0000 Moro and Mike and guest Jim Clark provide advice on Resumes and Cover Letters https://cyberlibrarian.ca/moro%20and%20mike/2020/05/08/advice-on-resumes-and-cover-letters.html Michael McDonnell Advice on Resumes and Cover Letters Moro and Mike and guest Jim Clark provide advice on Resumes and Cover Letters 01:59:38 careers,podcast,livestream,professional development,job hunting,networking no no Career Stories and Advice https://cyberlibrarian.ca/moro%20and%20mike/2020/05/01/career-stories.html</link> Fri, 01 May 2020 19:00:00 +0000 Moro and Mike interview a series of Cybersecurity and IT professionals about their career stories and advice for career development. https://cyberlibrarian.ca/moro%20and%20mike/2020/05/01/career-stories.html Michael McDonnell Career Stories and Advice Moro and Mike interview a series of Cybersecurity and IT professionals about their career stories and advice for career development. 01:53:18 careers,podcast,livestream,career stories,professional development no no

Theme Technical Testing

This page contains tests of technical aspects of the theme I am using and Jekyll in general.

{{ site.author.name }}

{{ site.author.name escape }}
{%- assign default_paths = site.pages map: “path” -%}    
{%- assign page_paths = site.header_pages default: default_paths -%}    
{%- assign titles_size = site.pages map: ‘title’ join: ‘’ size -%}
{{ “/” relative_url }}
{{ site.title escape }}

{{ default_paths }} {{ page_paths }} {{ site.pages }} {{ site.pages | map: ‘title’ | join: ‘’ }} {{ titles_size }} @import “minima/skins/{{ site.minima.skin | default: ‘classic’ }}”, “minima/initialize”; <?xml version=”1.0” encoding=”utf-8”?>{% if page.xsl %}<?xml-stylesheet type=”text/xml” href=”{{ ‘/feed.xslt.xml’ | absolute_url }}”?>{% endif %}<feed xmlns=”http://www.w3.org/2005/Atom” {% if site.lang %}xml:lang=”{{ site.lang }}”{% endif %}>Jekyll<link href=”{{ ‘/’ | absolute_url }}” rel=”alternate” type=”text/html” {% if site.lang %}hreflang=”{{ site.lang }}” {% endif %}/>{{ site.time | date_to_xmlschema }}{{ page.url | absolute_url | xml_escape }}{% assign title = site.title | default: site.name %}{% if page.collection != “posts” %}{% assign collection = page.collection | capitalize %}{% assign title = title | append: “ | “ | append: collection %}{% endif %}{% if page.category %}{% assign category = page.category | capitalize %}{% assign title = title | append: “ | “ | append: category %}{% endif %}{% if title %}{{ title | smartify | xml_escape }}{% endif %}{% if site.description %}{{ site.description | xml_escape }}{% endif %}{% if site.author %}{{ site.author.name | default: site.author | xml_escape }}{% if site.author.email %}{{ site.author.email | xml_escape }}{% endif %}{% if site.author.uri %}{{ site.author.uri | xml_escape }}{% endif %}{% endif %}{% if page.tags %}{% assign posts = site.tags[page.tags] %}{% else %}{% assign posts = site[page.collection] %}{% endif %}{% if page.category %}{% assign posts = posts | where: “categories”, page.category %}{% endif %}{% unless site.show_drafts %}{% assign posts = posts | where_exp: “post”, “post.draft != true” %}{% endunless %}{% assign posts = posts | sort: “date” | reverse %}{% assign posts_limit = site.feed.posts_limit | default: 10 %}{% for post in posts limit: posts_limit %}<entry{% if post.lang %}{{“ “}}xml:lang=”{{ post.lang }}”{% endif %}>{% assign post_title = post.title | smartify | strip_html | normalize_whitespace | xml_escape %}{{ post_title }}{{ post.date | date_to_xmlschema }}{{ post.last_modified_at | default: post.date | date_to_xmlschema }}{{ post.id | absolute_url | xml_escape }}{% assign excerpt_only = post.feed.excerpt_only | default: site.feed.excerpt_only %}{% unless excerpt_only %}<![CDATA[{{ post.content | strip }}]]>{% endunless %}{% assign post_author = post.author | default: post.authors[0] | default: site.author %}{% assign post_author = site.data.authors[post_author] | default: post_author %}{% assign post_author_email = post_author.email | default: nil %}{% assign post_author_uri = post_author.uri | default: nil %}{% assign post_author_name = post_author.name | default: post_author %}{{ post_author_name | default: "" | xml_escape }}{% if post_author_email %}{{ post_author_email | xml_escape }}{% endif %}{% if post_author_uri %}{{ post_author_uri | xml_escape }}{% endif %}{% if post.category %}{% elsif post.categories %}{% for category in post.categories %}{% endfor %}{% endif %}{% for tag in post.tags %}{% endfor %}{% assign post_summary = post.description | default: post.excerpt %}{% if post_summary and post_summary != empty %}<summary type="html"><![CDATA[{{ post_summary | strip_html | normalize_whitespace }}]]></summary>{% endif %}{% assign post_image = post.image.path | default: post.image %}{% if post_image %}{% unless post_image contains “://” %}{% assign post_image = post_image | absolute_url %}{% endunless %}{% endif %}</entry>{% endfor %}</feed><?xml version=”1.0” encoding=”UTF-8”?> {% if page.xsl %}<?xml-stylesheet type=”text/xsl” href=”{{ “/sitemap.xsl” | absolute_url }}”?> {% endif %} {% assign collections = site.collections | where_exp:'collection','collection.output != false' %}{% for collection in collections %}{% assign docs = collection.docs | where_exp:'doc','doc.sitemap != false' %}{% for doc in docs %}

{{ doc.url | replace:'/index.html','/' | absolute_url | xml_escape }}

{% if doc.last_modified_at or doc.date %}{{ doc.last_modified_at | default: doc.date | date_to_xmlschema }} {% endif %}</url> {% endfor %}{% endfor %}{% assign pages = site.html_pages | where_exp:’doc’,’doc.sitemap != false’ | where_exp:’doc’,’doc.url != “/404.html”’ %}{% for page in pages %}

{{ page.url | replace:'/index.html','/' | absolute_url | xml_escape }}

{% if page.last_modified_at %}{{ page.last_modified_at | date_to_xmlschema }} {% endif %}</url> {% endfor %}{% assign static_files = page.static_files | where_exp:’page’,’page.sitemap != false’ | where_exp:’page’,’page.name != “404.html”’ %}{% for file in static_files %}

{{ file.path | replace:'/index.html','/' | absolute_url | xml_escape }} {{ file.modified_time | date_to_xmlschema }}

</url> {% endfor %}</urlset> Sitemap: {{ “sitemap.xml” | absolute_url }}

A Curate List of Threat ReportsDetection Engineering NotesMapping AWS GuardDuty Finding to Splunk CIM Alert DatamodelRecommended PodcastsWriting SkillsLearning ResourcesMoro and MikeMoro and Mike PodcastTechnical Tests 218