Ch1
This commit is contained in:
25
.env.example
25
.env.example
@@ -87,6 +87,8 @@ SEARXNG_URL=
|
||||
# Knowledge synthesis after a verified relation has formed a useful source cluster.
|
||||
# Relation thinking always remains separate and only creates graph edges.
|
||||
BRAIN_ARTICLE_SYNTHESIS_ENABLED=true
|
||||
# Language tag for generated KB drafts (for example de-DE or en-US).
|
||||
BRAIN_ARTICLE_LANGUAGE=de-DE
|
||||
BRAIN_ARTICLE_MIN_SOURCES=3
|
||||
BRAIN_ARTICLE_MAX_SOURCES=8
|
||||
BRAIN_ARTICLE_MIN_PRODUCTION_RATIO=0.70
|
||||
@@ -97,19 +99,34 @@ BRAIN_ARTICLE_MIN_ANSWER_CHARS=420
|
||||
# Maximal number of precise queries per research round.
|
||||
BRAIN_ARTICLE_MAX_RESEARCH_QUERIES=6
|
||||
# Raw SearXNG candidates per query.
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=8
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=12
|
||||
# Iterative search/reformulation rounds.
|
||||
BRAIN_ARTICLE_RESEARCH_ROUNDS=3
|
||||
# Highest-ranked pages whose full content is downloaded.
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=4
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.65
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.45
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=6
|
||||
# Reserve up to this many fetch slots for promising candidates below the final
|
||||
# relevance threshold. They are re-evaluated against the extracted full text.
|
||||
BRAIN_ARTICLE_RESEARCH_EXPLORATION_RESULTS=3
|
||||
# Lower title/snippet threshold used only before the full-text fetch.
|
||||
BRAIN_ARTICLE_RESEARCH_PREFETCH_MIN_RELEVANCE=0.25
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.55
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.35
|
||||
BRAIN_ARTICLE_RESEARCH_PAGE_MAX_BYTES=2097152
|
||||
BRAIN_ARTICLE_RESEARCH_PAGE_MAX_CHARS=14000
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_TIMEOUT=20s
|
||||
# Keep false unless private/intranet research URLs are intentionally trusted.
|
||||
BRAIN_ARTICLE_RESEARCH_ALLOW_PRIVATE=false
|
||||
|
||||
# Research orchestration. All SearXNG requests, web fetches and Ollama calls
|
||||
# share this bounded queue. With one Ollama node, 2 is a conservative default:
|
||||
# one model request may run while one web request progresses.
|
||||
BRAIN_RESEARCH_OLLAMA_MAX_INFLIGHT=2
|
||||
BRAIN_RESEARCH_OLLAMA_QUEUE_SIZE=64
|
||||
# Semantically equivalent research intents reuse a running/recent result bundle.
|
||||
BRAIN_RESEARCH_DEDUPE_THRESHOLD=0.92
|
||||
BRAIN_RESEARCH_DEDUPE_TTL=45m
|
||||
# site: filters are always stripped at runtime. Research remains domain-open.
|
||||
|
||||
# Autonomous, persistent background research. Tasks are stored in graph.db and
|
||||
# handed to Ollama asynchronously with low priority. Disabled by default.
|
||||
BRAIN_AUTONOMOUS_RESEARCH_ENABLED=false
|
||||
|
||||
64
CHANGELOG-ARTICLE-CREATION-GATES.md
Normal file
64
CHANGELOG-ARTICLE-CREATION-GATES.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# Changelog: Article Creation Gates
|
||||
|
||||
## Problem
|
||||
|
||||
The article pipeline could collect and persist strong research evidence but still create no staging article. Four independent behaviors amplified each other:
|
||||
|
||||
1. model-generated topic labels such as `site:digital-forensics` were used as if they were real domains;
|
||||
2. legacy `missing_information` and editorial refinements were promoted to critical blockers;
|
||||
3. every article type used the same answer-length gate;
|
||||
4. several skip paths, especially deterministic draft validation and duplicate detection, emitted no terminal diagnostic event.
|
||||
|
||||
## Changes
|
||||
|
||||
### Valid search-domain restrictions
|
||||
|
||||
- `preferred_domains` now accepts only real fully-qualified hostnames.
|
||||
- Schemes, paths and `www.` are normalized.
|
||||
- IP addresses, one-label topic names and malformed hostnames are rejected.
|
||||
- Invalid `site:` tokens already present in model-generated queries are removed before SearXNG is called.
|
||||
- At least one unrestricted language variant remains available as before.
|
||||
|
||||
Examples:
|
||||
|
||||
- accepted: `nist.gov`, `docs.aws.amazon.com`, `https://www.nist.gov/path`
|
||||
- rejected: `digital-forensics`, `assetmanagement`, `cleanroomrecovery`
|
||||
|
||||
### Narrower critical-gap classification
|
||||
|
||||
- The knowledge-brief prompt now requires a concrete consequence for every critical gap: a false conclusion, safety risk or non-executable core procedure.
|
||||
- Definitions, comparisons, examples, screenshots, variants and editorial depth are optional by default when a grounded usable core already exists.
|
||||
- Deterministic normalization downgrades over-classified editorial gaps only when at least three grounded statements remain.
|
||||
- Missing rollback information, safety prerequisites, permissions, parameters, commands, validation steps and comparable operational blockers remain critical.
|
||||
- Legacy `missing_information` is no longer automatically critical; it is classified by the same blocker rules.
|
||||
- Research queries are rebuilt only from remaining critical gaps and unresolved critical contradictions.
|
||||
|
||||
### Article-type-aware draft validation
|
||||
|
||||
- `how_to` and `troubleshooting` retain the configured full answer minimum.
|
||||
- `concept` and `reference` use a lower answer-length minimum but require at least two grounded key points.
|
||||
- `decision_guide` uses a proportional minimum and requires at least two decision criteria.
|
||||
- Confidence, productive-source ratio, generation depth and problem-description checks remain enforced for every type.
|
||||
|
||||
### Complete diagnostics
|
||||
|
||||
All article skip/rejection paths now publish an explicit event. After `article.draft.started`, the pipeline terminates with exactly one of:
|
||||
|
||||
- `article.created`
|
||||
- `article.draft.rejected`
|
||||
- `article.duplicate`
|
||||
- `article.failed`
|
||||
|
||||
Deterministic validation failures expose structured metadata:
|
||||
|
||||
- `reason`
|
||||
- `field`
|
||||
- `actual`
|
||||
- `required`
|
||||
- `article_type`
|
||||
|
||||
The activity UI displays these values directly.
|
||||
|
||||
## Compatibility
|
||||
|
||||
No new environment variables are required. Existing thresholds remain valid; their interpretation is now article-type aware.
|
||||
38
CHANGELOG-RESEARCH-ORCHESTRATION.md
Normal file
38
CHANGELOG-RESEARCH-ORCHESTRATION.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Research-Orchestrierung: offene Suche, Deduplizierung und gemeinsame Queue
|
||||
|
||||
## Ziel
|
||||
|
||||
Die Recherche darf nicht mehr durch automatisch erzeugte `site:`-Filter auf eine fachlich falsche Domain eingeschränkt werden. Gleichzeitig sollen semantisch gleiche Research-Aufträge nicht mehrfach dieselben Web- und Modellaufrufe erzeugen. SearXNG, Volltextabrufe und Ollama teilen deshalb ein gemeinsames begrenztes Arbeitsbudget.
|
||||
|
||||
## Änderungen
|
||||
|
||||
- Alle `site:`-Tokens werden unmittelbar vor der SearXNG-Anfrage entfernt. Das gilt auch für bereits vom Modell erzeugte Queries, Autonomous Research und Relation Research.
|
||||
- `preferred_domains` bleibt aus Schema-Kompatibilitätsgründen vorhanden, wird zur Laufzeit aber ignoriert und geleert.
|
||||
- Standardwerte sind recall-orientierter: 12 Treffer, 6 Volltextabrufe, 3 Explorationsslots, Prefetch 0.25, finale Relevanz 0.55 und Mindestqualität 0.35.
|
||||
- Eine fachlich relevante, starke Quelle darf bereits oberhalb der Prefetch-Schwelle als Evidenz angenommen werden, wenn ihre Quellenqualität mindestens 0.70 erreicht. Ob daraus ein Artikel entstehen darf, entscheidet weiterhin die Knowledge-Brief-/Readiness-Prüfung.
|
||||
- Fehlendes `actionable=true` verwirft eine ansonsten relevante Quelle nicht mehr vollständig. Bei How-to-/Troubleshooting-Artikeln kann die nachgelagerte Konsolidierung weiterhin eine kritische Handlungslücke offen lassen.
|
||||
- Ein gemeinsamer `workqueue.Limiter` begrenzt SearXNG-Search, Webseiten-Fetches und Ollama Chat/Embedding gemeinsam.
|
||||
- Research-Intents werden per Embedding semantisch verglichen. Gleichbedeutende parallele Tasks warten auf den laufenden Owner; abgeschlossene Ergebnisse können innerhalb der TTL wiederverwendet werden. Artikel-/Autonomous-Evidenz und Relationsrecherche verwenden getrennte Dedupe-Namespaces.
|
||||
- DE- und EN-Queries derselben Forschungsfrage werden nicht gegeneinander dedupliziert; sie bilden gemeinsam ein Ergebnis-Bundle. Relationsrecherche berücksichtigt statt der früheren vier nun bis zu 8–12 offene SearXNG-Treffer.
|
||||
- Die gewünschte Artikelsprache ist über `BRAIN_ARTICLE_LANGUAGE` konfigurierbar und wird in Prompt, Staging-Dokument und Metadaten übernommen.
|
||||
|
||||
## Neue ENV
|
||||
|
||||
```env
|
||||
BRAIN_ARTICLE_LANGUAGE=de-DE
|
||||
BRAIN_RESEARCH_OLLAMA_MAX_INFLIGHT=2
|
||||
BRAIN_RESEARCH_OLLAMA_QUEUE_SIZE=64
|
||||
BRAIN_RESEARCH_DEDUPE_THRESHOLD=0.92
|
||||
BRAIN_RESEARCH_DEDUPE_TTL=45m
|
||||
```
|
||||
|
||||
## Angepasste Defaults
|
||||
|
||||
```env
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=12
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=6
|
||||
BRAIN_ARTICLE_RESEARCH_EXPLORATION_RESULTS=3
|
||||
BRAIN_ARTICLE_RESEARCH_PREFETCH_MIN_RELEVANCE=0.25
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.55
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.35
|
||||
```
|
||||
@@ -28,7 +28,7 @@ Wissensbasis neu konsolidieren
|
||||
weitere Recherche-Runde oder KB-Artikel
|
||||
```
|
||||
|
||||
Standardmäßig sind bis zu drei Runden vorgesehen. Eine spätere Runde erhält die verbliebenen kritischen Lücken und die bereits versuchten Queries. Dadurch kann Qwen die Anfrage fachlich enger formulieren, englische Herstellerbegriffe verwenden oder eine begründete `site:`-Einschränkung ergänzen.
|
||||
Standardmäßig sind bis zu drei Runden vorgesehen. Eine spätere Runde erhält die verbliebenen kritischen Lücken und die bereits versuchten Queries. Dadurch kann Qwen die Anfrage fachlich enger formulieren und englische Herstellerbegriffe verwenden. `site:`-Einschränkungen werden grundsätzlich entfernt; die Suche bleibt domain-offen.
|
||||
|
||||
## Kritische und optionale Wissenslücken
|
||||
|
||||
@@ -146,24 +146,24 @@ SEARXNG_URL=http://searxng:8080
|
||||
BRAIN_ARTICLE_MAX_RESEARCH_QUERIES=6
|
||||
|
||||
# SearXNG-Treffer je Query
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=8
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=12
|
||||
|
||||
# Maximale iterative Runden
|
||||
BRAIN_ARTICLE_RESEARCH_ROUNDS=3
|
||||
|
||||
# Volltextabrufe je Query nach dem Snippet-Gate
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=4
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=6
|
||||
|
||||
# Bis zu zwei Fetch-Plätze dürfen hochwertige Explorationskandidaten nutzen,
|
||||
# die im Snippet noch unter der finalen Relevanzschwelle liegen.
|
||||
BRAIN_ARTICLE_RESEARCH_EXPLORATION_RESULTS=2
|
||||
BRAIN_ARTICLE_RESEARCH_EXPLORATION_RESULTS=3
|
||||
|
||||
# Niedrigere Vorabruf-Schwelle für Titel und Snippet
|
||||
BRAIN_ARTICLE_RESEARCH_PREFETCH_MIN_RELEVANCE=0.35
|
||||
BRAIN_ARTICLE_RESEARCH_PREFETCH_MIN_RELEVANCE=0.25
|
||||
|
||||
# Finale Mindestwerte für akzeptierte Volltextbelege
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.65
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.45
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.55
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.35
|
||||
|
||||
# Abrufgrenzen je Webquelle
|
||||
BRAIN_ARTICLE_RESEARCH_PAGE_MAX_BYTES=2097152
|
||||
@@ -217,3 +217,15 @@ Die bestehende Rechercheanimation bleibt während Graph-Neuaufbau und Node-Erzeu
|
||||
Ein einzelner Fehler beendet nicht die gesamte Artikelrecherche. Das Brain versucht weitere Kandidaten, Queries und gegebenenfalls eine weitere Runde. Nach jeder fokussierten Forschungsfrage wird die Wissensbasis neu konsolidiert; sobald alle kritischen Lücken geschlossen sind, endet die Runde frühzeitig. Der Artikel wird erst nach Ausschöpfen der konfigurierten Runden übersprungen, wenn weiterhin eine kritische Lücke oder ein kritischer Widerspruch besteht.
|
||||
|
||||
Die Skip-Meldung enthält jetzt die verbleibenden kritischen Lücken, optionale Lücken sowie die Anzahl der Queries, Treffer, Volltextabrufe, akzeptierten und verworfenen Belege.
|
||||
|
||||
|
||||
## Gemeinsame Research/Ollama-Queue und Deduplizierung
|
||||
|
||||
SearXNG-Suchen, Volltextabrufe sowie Ollama Chat/Embedding teilen einen gemeinsamen begrenzten Limiter. Gleichbedeutende Research-Intents werden über Embeddings erkannt und können laufende oder kürzlich abgeschlossene Ergebnisse wiederverwenden. Deutsche und englische Query-Varianten innerhalb derselben Frage bleiben erhalten.
|
||||
|
||||
```env
|
||||
BRAIN_RESEARCH_OLLAMA_MAX_INFLIGHT=2
|
||||
BRAIN_RESEARCH_OLLAMA_QUEUE_SIZE=64
|
||||
BRAIN_RESEARCH_DEDUPE_THRESHOLD=0.92
|
||||
BRAIN_RESEARCH_DEDUPE_TTL=45m
|
||||
```
|
||||
|
||||
@@ -63,11 +63,11 @@ Ein einzelner Such- oder Fetchfehler beendet den Vorgang nicht. Optional fehlend
|
||||
BRAIN_RESEARCH_ENABLED=true
|
||||
SEARXNG_URL=http://searxng:8080
|
||||
BRAIN_ARTICLE_MAX_RESEARCH_QUERIES=6
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=8
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=12
|
||||
BRAIN_ARTICLE_RESEARCH_ROUNDS=3
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=4
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.65
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.45
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=6
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.55
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.35
|
||||
BRAIN_ARTICLE_RESEARCH_PAGE_MAX_BYTES=2097152
|
||||
BRAIN_ARTICLE_RESEARCH_PAGE_MAX_CHARS=14000
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_TIMEOUT=20s
|
||||
@@ -134,6 +134,7 @@ Ist Learning im Webinterface deaktiviert, bleibt der Artikel sichtbar und verkn
|
||||
|
||||
```env
|
||||
BRAIN_ARTICLE_SYNTHESIS_ENABLED=true
|
||||
BRAIN_ARTICLE_LANGUAGE=de-DE
|
||||
BRAIN_ARTICLE_MIN_SOURCES=3
|
||||
BRAIN_ARTICLE_MAX_SOURCES=8
|
||||
BRAIN_ARTICLE_MIN_PRODUCTION_RATIO=0.70
|
||||
@@ -142,11 +143,11 @@ BRAIN_ARTICLE_MIN_CONFIDENCE=0.74
|
||||
BRAIN_ARTICLE_MIN_TEXT_CHARS=180
|
||||
BRAIN_ARTICLE_MIN_ANSWER_CHARS=420
|
||||
BRAIN_ARTICLE_MAX_RESEARCH_QUERIES=6
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=8
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=12
|
||||
BRAIN_ARTICLE_RESEARCH_ROUNDS=3
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=4
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.65
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.45
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=6
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.55
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.35
|
||||
```
|
||||
|
||||
Ein Entwurf, der diese Regeln nicht erfüllt, wird nicht geschrieben. Bereits erkannte belastbare Relationen bleiben dennoch im Graphen bestehen.
|
||||
@@ -156,3 +157,15 @@ Ein Entwurf, der diese Regeln nicht erfüllt, wird nicht geschrieben. Bereits er
|
||||
Der Artikelplan unterscheidet `troubleshooting`, `how_to`, `reference`, `concept` und `decision_guide`. How-to- und Troubleshooting-Artikel erhalten nummerierte Arbeitsschritte. Konzept- und Referenzartikel verwenden belegte Kernaussagen sowie Einordnung und Abgrenzung; Entscheidungsartikel verwenden Entscheidungskriterien. Dadurch werden bei rein fachlichen Vergleichs- oder Referenzthemen keine künstlichen Lösungsschritte erzeugt.
|
||||
|
||||
Die interne Konsolidierung verwirft außerdem jede Aussage, deren `source_refs` nicht auf eine tatsächlich im aktuellen Kontext vorhandene interne Quelle oder Recherche-Referenz verweisen.
|
||||
|
||||
|
||||
### Research-Orchestrierung
|
||||
|
||||
Die Recherche verwendet keine `site:`-Filter mehr. Alle Web- und Modelloperationen teilen eine begrenzte Queue; semantisch gleiche Research-Intents werden wiederverwendet.
|
||||
|
||||
```env
|
||||
BRAIN_RESEARCH_OLLAMA_MAX_INFLIGHT=2
|
||||
BRAIN_RESEARCH_OLLAMA_QUEUE_SIZE=64
|
||||
BRAIN_RESEARCH_DEDUPE_THRESHOLD=0.92
|
||||
BRAIN_RESEARCH_DEDUPE_TTL=45m
|
||||
```
|
||||
|
||||
21
README.md
21
README.md
@@ -33,7 +33,7 @@ AI-THINK bleibt `auto_reply: false`, trägt die Kategorien `AI-THINK` und `AI-St
|
||||
|
||||
## Grounded Knowledge Synthesis
|
||||
|
||||
Verwandtes Wissen wird nicht direkt als Bewertungsbericht gespeichert. Das Brain konsolidiert zunächst belegte Fakten, Lösungsschritte, Widersprüche sowie kritische und optionale Wissenslücken. Kritische Unklarheiten werden iterativ über präzise deutsche und englische SearXNG-Queries recherchiert. Die besten Treffer durchlaufen ein Relevanz- und Quellenqualitäts-Gate, werden als vollständige Webseite geladen und nach einer zweiten Volltextprüfung erneut konsolidiert. Nur akzeptierte Volltextbelege werden sofort eingebettet, mit den Fachkategorien ihrer internen Quellen eingeordnet, unter `BRAIN_DATA_DIR/research-evidence/` für spätere Zyklen aufbewahrt und über `grounded_by` mit dem erzeugten Artikel verbunden. Bereits gelernte Belege werden bei verbundenen Themen erneut konsolidiert, ohne die Webseite unnötig noch einmal abzurufen. Optionale Vertiefungen blockieren keinen ansonsten belastbaren Artikel. Interne Aussagen ohne reale Referenz auf eine tatsächlich vorhandene Quelle werden verworfen. Konzept-, Referenz- und Entscheidungsartikel erhalten eine passende fachliche Struktur statt künstlich erzeugter Schrittfolgen.
|
||||
Verwandtes Wissen wird nicht direkt als Bewertungsbericht gespeichert. Das Brain konsolidiert zunächst belegte Fakten, Lösungsschritte, Widersprüche sowie kritische und optionale Wissenslücken. Kritische Unklarheiten werden iterativ über präzise deutsche und englische SearXNG-Queries recherchiert. `site:`-Filter werden grundsätzlich entfernt, damit eine vom Modell falsch zugeordnete Herstellerdomain die Treffer nicht künstlich auf null reduziert. Die besten Treffer durchlaufen ein recall-orientiertes Relevanz- und Quellenqualitäts-Gate, werden als vollständige Webseite geladen und nach einer zweiten Volltextprüfung erneut konsolidiert. Nur akzeptierte Volltextbelege werden sofort eingebettet, mit den Fachkategorien ihrer internen Quellen eingeordnet, unter `BRAIN_DATA_DIR/research-evidence/` für spätere Zyklen aufbewahrt und über `grounded_by` mit dem erzeugten Artikel verbunden. Bereits gelernte Belege werden bei verbundenen Themen erneut konsolidiert, ohne die Webseite unnötig noch einmal abzurufen. Optionale Vertiefungen blockieren keinen ansonsten belastbaren Artikel. Interne Aussagen ohne reale Referenz auf eine tatsächlich vorhandene Quelle werden verworfen. Konzept-, Referenz- und Entscheidungsartikel erhalten eine passende fachliche Struktur statt künstlich erzeugter Schrittfolgen.
|
||||
|
||||
Details: [`KNOWLEDGE-SYNTHESIS.md`](KNOWLEDGE-SYNTHESIS.md) und [`ITERATIVE-GROUNDED-RESEARCH.md`](ITERATIVE-GROUNDED-RESEARCH.md).
|
||||
|
||||
@@ -200,7 +200,7 @@ Mehr Details: [`SOURCE-ONLY-FILTERS.md`](SOURCE-ONLY-FILTERS.md), [`VISUALIZATIO
|
||||
|
||||
Die Webrecherche ist nicht mehr an einen einzelnen AI-THINK-Artikelversuch gebunden. Ein eigener Opportunity-Scanner bewertet den Graphen regelmäßig auf Widersprüche, fehlende externe Evidenz, Alter, Zentralität und schwache Verknüpfung. Qwen zerlegt geeignete Kandidaten in konkrete Forschungsfragen sowie deutsche und englische SearXNG-Queries.
|
||||
|
||||
Aufgaben landen zuerst persistent in `graph.db`. Ein Low-Priority-Worker least genau eine Aufgabe, prüft Leerlauf, Tagesbudget und freie Kapazität im Ollama-Pool und verwendet danach die bestehende iterative SearXNG-/Volltext-/Evidenzpipeline. Das ist bewusst keine unkontrollierte zweite Ollama-Queue: Benutzeranfragen und normales AI-THINK behalten Vorrang, Aufgaben überleben Neustarts, werden dedupliziert und nach temporären Fehlern mit Backoff wiederholt. Der Ollama-Pool kennt zusätzlich normale und Low-Priority-Waiter; autonome Modellaufrufe dürfen bei der nächsten Node-Zuteilung keine wartende interaktive Anfrage überholen.
|
||||
Aufgaben landen zuerst persistent in `graph.db`. Ein Low-Priority-Worker least genau eine Aufgabe, prüft Leerlauf und Tagesbudget und verwendet danach die bestehende iterative SearXNG-/Volltext-/Evidenzpipeline. SearXNG-Suchen, Volltextabrufe und Ollama-Aufrufe teilen jetzt zusätzlich eine gemeinsame begrenzte Work-Queue. Semantisch äquivalente Research-Intents werden über Embeddings erkannt: läuft bereits eine gleichbedeutende Recherche, wartet der zweite Auftrag auf ihr Ergebnis; kürzlich abgeschlossene Evidenz kann ohne erneuten Webabruf wiederverwendet werden. Deutsche und englische Query-Varianten innerhalb derselben Forschungsfrage bleiben ausdrücklich erhalten.
|
||||
|
||||
```env
|
||||
BRAIN_AUTONOMOUS_RESEARCH_ENABLED=false
|
||||
@@ -247,11 +247,26 @@ BRAIN_ENRICH_BATCH_SIZE=3
|
||||
BRAIN_ENRICH_STEP_DELAY=3s
|
||||
|
||||
BRAIN_ARTICLE_SYNTHESIS_ENABLED=true
|
||||
BRAIN_ARTICLE_LANGUAGE=de-DE
|
||||
BRAIN_ARTICLE_MIN_SOURCES=3
|
||||
BRAIN_ARTICLE_MAX_SOURCES=8
|
||||
BRAIN_ARTICLE_MIN_PRODUCTION_RATIO=0.70
|
||||
BRAIN_ARTICLE_MAX_GENERATION_DEPTH=2
|
||||
BRAIN_ARTICLE_MIN_CONFIDENCE=0.74
|
||||
|
||||
# offene, recall-orientierte Recherche
|
||||
BRAIN_ARTICLE_RESEARCH_RESULTS=12
|
||||
BRAIN_ARTICLE_RESEARCH_FETCH_RESULTS=6
|
||||
BRAIN_ARTICLE_RESEARCH_EXPLORATION_RESULTS=3
|
||||
BRAIN_ARTICLE_RESEARCH_PREFETCH_MIN_RELEVANCE=0.25
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_RELEVANCE=0.55
|
||||
BRAIN_ARTICLE_RESEARCH_MIN_QUALITY=0.35
|
||||
|
||||
# gemeinsame Research/Ollama-Queue und semantische Deduplizierung
|
||||
BRAIN_RESEARCH_OLLAMA_MAX_INFLIGHT=2
|
||||
BRAIN_RESEARCH_OLLAMA_QUEUE_SIZE=64
|
||||
BRAIN_RESEARCH_DEDUPE_THRESHOLD=0.92
|
||||
BRAIN_RESEARCH_DEDUPE_TTL=45m
|
||||
```
|
||||
|
||||
Details: [`KNOWLEDGE-SYNTHESIS.md`](KNOWLEDGE-SYNTHESIS.md).
|
||||
@@ -327,4 +342,4 @@ Unter **FILTER → SearXNG-Diagnose** kann eine direkte Testsuche ausgeführt we
|
||||
- DNS-, Netzwerk-, TLS-, HTTP- und JSON-Fehler,
|
||||
- bei Fehlern den Antwortausschnitt von SearXNG oder Reverse Proxy.
|
||||
|
||||
Die automatische Artikelrecherche zeigt zusätzlich Recherche-Runden, deutsch/englische Teilqueries, Kandidatenauswahl, Volltextabruf, Relevanz, Quellenqualität sowie akzeptierte und verworfene Belege. SearXNG-Snippets werden nicht als ausreichender Artikelbeleg verwendet. Die API-Endpunkte sind `GET /api/research/status` und `POST /api/research/test`. Details stehen in `SEARXNG-VISUALIZATION.md` und `ITERATIVE-GROUNDED-RESEARCH.md`.
|
||||
Die automatische Artikelrecherche zeigt zusätzlich Recherche-Runden, deutsch/englische Teilqueries, Deduplizierungsereignisse, Kandidatenauswahl, Volltextabruf, Relevanz, Quellenqualität sowie akzeptierte und verworfene Belege. Im Analyse-Center zeigt der Ollama-Status außerdem aktive und wartende Einträge der gemeinsamen Research/Ollama-Queue. SearXNG-Snippets werden nicht als ausreichender Artikelbeleg verwendet. Die API-Endpunkte sind `GET /api/research/status` und `POST /api/research/test`. Details stehen in `SEARXNG-VISUALIZATION.md` und `ITERATIVE-GROUNDED-RESEARCH.md`.
|
||||
|
||||
@@ -1,16 +1,22 @@
|
||||
e47d6942446b96553c04efdd424ee72ff9ca76345110b34c12dedbbe1aad3299 .env.example
|
||||
ce4ee061d3cc480eeccd68d32a9b19db3ec65169b5a77b84976cdf30c918cff7 .env.example
|
||||
236713daf159ff0a8067e80a442ae3404fa28a5251ae6f24782f263bcfc17005 .gitea/workflows/registry.yml
|
||||
caf5847b0ca972e7701ec23222302ac72de05d20f620d1b0f508efa126f24bfd .gitignore
|
||||
048f53e6ca01ac583b48784cd2f6f7d248e0534849955b144e75f017f73188a3 .vscode/settings.json
|
||||
8ddf797373e5cb397a6a8ed35b868393846752339ec7010d0148509794500d3c ANALYSIS-DASHBOARD.md
|
||||
8955cfbeff229e73f0cad664863ff21711c270a4233c3225680c89aa6268a901 ARCHITECTURE.md
|
||||
cf3e5275f1eb623da3b6f734d233197e8b47879b8e7cdfd4d373a7ecdd921651 AUTONOMOUS-RESEARCH.md
|
||||
7aed2194baab0fb66c561446e5f1cd7724c1166bfa3a08c9e59157d1878bf994 CHANGELOG-ANALYSIS-DASHBOARD.md
|
||||
518daa4c734c46e3c063b66d57e8d3a422f5d7ae7f52bef74db58d881bb979b8 CHANGELOG-ARTICLE-CREATION-GATES.md
|
||||
0ed6ff0d82b3b6776970200a021937611d4f3273f6727d296aec16cfac6153b8 CHANGELOG-AUTONOMOUS-RESEARCH.md
|
||||
2bc149241c2d25f755e4a0470dc517f646527ee3e98d3a6c2e7798639bd70866 CHANGELOG-CONSTELLATION-ECO-TRANSITIONS.md
|
||||
933cdaeae7895e31d2281d591a75f23f07e7c41d356638654bac4f5e7a20a069 CHANGELOG-FILTER-PANEL-SCROLL.md
|
||||
176f089da30ddea637d7a4c81ef45dfa889e0b36a9180a17145ef0931b523a69 CHANGELOG-FILTER-SCOPES-SOURCES.md
|
||||
213ac897cd415bbeb9764a847843b9eff366983cf25bb3cbce4efa4c04b9e5f5 CHANGELOG-GLPI-POOL-PERSISTENCE.md
|
||||
e2f1f0400999cb59b8be09bc2743e06e0a0b2ecdc44a583af7c9a08b70d8509e CHANGELOG-GPU-NODE-LIMIT.md
|
||||
a317376127be1e47b9ec9f0781fcfebdcbf7fccfaeb7840d9241f9586048fadb CHANGELOG-GROUNDED-KNOWLEDGE-SYNTHESIS.md
|
||||
02a8d3e541967e2d2ef9dd5451f470679e262ad851aca9f03563b322914c3181 CHANGELOG-ITERATIVE-GROUNDED-RESEARCH.md
|
||||
e167a9d64f63c3933ad40c5078684bc019db303043c34ea3965f3b089f3d32c7 CHANGELOG-KNOWLEDGE-SYNTHESIS.md
|
||||
fbf686a1acc2de6c4fbb56730a5f87dfdf28d93125fa56ae0c588c29ce492efe CHANGELOG-RESEARCH-ORCHESTRATION.md
|
||||
37e1803aa4bc2f8da851c748447e0e3cb59beb1c426248fba5df6ba9fa171cc5 CHANGELOG-RESEARCH-PREFETCH-GATE.md
|
||||
87f89a81e1124b18e092a4ea946cb037295cb9e884a46b392286272dc8134dd4 CHANGELOG-RUNTIME-HONEYCOMB.md
|
||||
2d04e6d385f4b902080a0bcaab510a846a8ae6a76cb757423c50425c8433e7f9 CHANGELOG-SEARXNG-DIAGNOSTICS.md
|
||||
@@ -19,30 +25,37 @@ be9f133ae933bdc0e0a8aa5d176dd3e39488a191337043533379e23d179f3ad2 CHANGELOG-SOUR
|
||||
5433a7c2e67ab35fb320bc872e9024fa5f3e765736184e9f878340b8b45407aa CHANGELOG-SQLITE-STARTUP-FIX.md
|
||||
5b9deeab0cd59b3c649fd73f129361a1e773ed3955cded0048b8cb280bb32e88 CHANGELOG-SQLITE-STORAGE.md
|
||||
b5e24ea594df82a221a8789d2c42ea373c79d475370fc3fbf64401fa296df86f Dockerfile
|
||||
a1aed7c198bc1ffc7af4a8f69ccf137541e4887ce5d59a0d67f2be7216a37dcd FILTER-SCOPES-SOURCES.md
|
||||
5534536965bf0479455f97324c242160202650ca1256f1ba0420b4ad67125e49 GLPI-KB.md
|
||||
4ecb5d9d8d059088117f93268e3c8fe5999e5fb4c4cffb7ce6ab806ff90b2a5c ITERATIVE-GROUNDED-RESEARCH.md
|
||||
e3ae87108607ca494668a9974c467a5c529b9599bf88d3d2a79ddc15b64e4a38 KNOWLEDGE-SYNTHESIS.md
|
||||
4e724efeb14c9e9a3938c7d05d023b469aa301764edca35e007132509f53e32a ITERATIVE-GROUNDED-RESEARCH.md
|
||||
81bd55135910bd0b831162370e3394591ac9f42c6821f849a8ca5de6ee9f5e30 KNOWLEDGE-SYNTHESIS.md
|
||||
696d2da2338cd8190b9614707e4059d78ce291e7334f273633aad815c3b6a6df Makefile
|
||||
381d7d6ac9e3c2e63c9ecdaa42ed4c73058f5d78e57c7532bb75a9663c919530 OLLAMA-POOL.md
|
||||
2c0062941ef3edbd40d46b823934a7d0a3a9da7581b83d0b9360e8aaa7694b1b PERSISTENCE.md
|
||||
5e1965cd2d5f428651ff2fac9874afa38ab6281585d4db330acac1f69c321608 README.md
|
||||
0a12f71cd148e3ed016b12ade1e8d170ea67ec2b22820cc6309c8ae867981c9e README.md
|
||||
2838cd19ac2bfa35bebbef2541f631b99221b5997bbb6dbc27146a66a3a1ad34 RUNTIME-CONTROLS-HONEYCOMB.md
|
||||
c3da43b33e550901d55789f2ee526c2e50f61ee028a3f59e0a40e77e1057fde7 SEARXNG-VISUALIZATION.md
|
||||
c69419c0327425186cfb84f25746feff226ce813cf467b3f252e729517455047 SOURCE-ONLY-FILTERS.md
|
||||
ae7bc1f1959071f79b76ca8a4ba103064ec0d5c5752af346175731ef4f636d9d SQLITE-STORAGE.md
|
||||
b0123b8425993dea7dd3864f930527b6a1a0e965ff29c0e4899620a64cd9451d VALIDATION-ANALYSIS-DASHBOARD.md
|
||||
2bcfeb932094dff1203aed517978c224888edaaa9e0095253a5f0906efd92b39 VALIDATION-ARTICLE-CREATION-GATES.md
|
||||
116a87c5e7c4fcfc333bbdf84979d5bab619b8a0936cd9f8838df04c9981bff7 VALIDATION-AUTONOMOUS-RESEARCH.md
|
||||
e05449bab6250e585a6c0ac0735008cd533baf07dbf7149ddae609ae252d4425 VALIDATION-CONSTELLATION-ECO-TRANSITIONS.md
|
||||
3830269b6584e63b4d5cd3627ac5c713c0aedc80e189b35e920d1228de25ff5e VALIDATION-FILTER-SCOPES-SOURCES.md
|
||||
e7ab2cddec372db906c7883a6e0861b71999043cfb9b94e527c3b2aee4532035 VALIDATION-ITERATIVE-GROUNDED-RESEARCH.md
|
||||
e5d2e3da41bfb6e720f2a9a4b95d0002fb01835db5120674c137f57110312b33 VALIDATION-RESEARCH-ORCHESTRATION.md
|
||||
044cf894b43d8ce1746adce9e58d75a6c7b0c1f3f3d2f0abcdeaab1db435014d VALIDATION-RESEARCH-PREFETCH-GATE.md
|
||||
e08b0eaab827fe03d5a72327e8fdfe9ce4025097e28208714246969e7d059561 VALIDATION-SEARXNG-DIAGNOSTICS.md
|
||||
f46938b5de7e139e1b21868b1bedce6e312d69cd61602b4f8f43512a327dd422 VALIDATION-SOURCE-ONLY-FILTERS.md
|
||||
4cd120496664388717fe422a8c54380708df723fea26b35f81799665dfaf2c1c VALIDATION-SQLITE.md
|
||||
f6699e4cdbaadc720e4b8a22c557d02319325283775a2b8a87ff78ca202e3386 VISUALIZATION-PERFORMANCE.md
|
||||
8970f2abf17bddcd0d84387e8a4975588df2776f03a7a54c5a283470769ca0c8 cmd/brain/main.go
|
||||
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 data/.gitkeep
|
||||
7ad10f51cf26747b4f186c540ecb7c77662f001800f0f7803422d45e8d72a4db data/graph.db
|
||||
587064aa2b583235d2235f4dcff2854b47347d47aef12ce266d56e9da6986843 data/runtime-settings.json
|
||||
21b51d0e1b7ed07c20f7f3a5da76dedab8df44a94a51724b67b0c3411599fe15 deployment/README.md
|
||||
ec106bc91cb70f7f41d3ff0369373ef2a9cf3c4da9cf5af5a13af028c828cf37 deployment/docker-compose.full.yml
|
||||
9ed0a04ca0a47f3732862165bac7b2aecc12ff1e4a1532c1a83880cb7028f630 docker-compose.yml
|
||||
bd3c31babac31e94a845c02c634c90f7c090019f4c1f46cc7c52aef20b33d1d9 docker-compose.yml
|
||||
1edabd3a7fc60aebaca37fae228a5f34ddbf9ed18478aa1b114204cb956a4027 go.mod
|
||||
864c3376212497b070feca13d26cfc28e96876078ce7a0b5b0c0470e2dd4fbf8 go.sum
|
||||
ed7fa0e09e94aa9e89c93b00303d4ce6f0f20dac626ecb91181c3aabc76bc8ff integrations/agent/README.md
|
||||
@@ -50,21 +63,23 @@ ed7fa0e09e94aa9e89c93b00303d4ce6f0f20dac626ecb91181c3aabc76bc8ff integrations/a
|
||||
3c0fc6913501976100521526e1ee8e7988d33fbce3f7b4bab26387d42b0966f5 integrations/knowledgebase/README.md
|
||||
12f8424f863b13f19aab9c2e6c2828c0ad824a55a62fe336e062db534102bc3a integrations/knowledgebase/glpi-ai-knowledgebase-neural-brain.patch
|
||||
93d8993e09473559a191c4e01252d6d1fdb214646d65e1271cde018b47d939ed internal/activity/broker.go
|
||||
68ecc931c3fdf8d77150b1a096f8a819a5518bd422ee2ad7962c98e6d8905137 internal/config/config.go
|
||||
1dd9f964fee9fa30c2dbbd6edf986aa5cb941eec936b85cfea9b01a4ea719864 internal/config/config_test.go
|
||||
2d948168b80e8d0d59f2890396bb9f3000555d9d0ded89ec424b86fe495856d1 internal/engine/article.go
|
||||
d5d18a26010fe5f308c05b79e3a3d7501c8490bb33098357cde4373affd7e60d internal/engine/article_format_test.go
|
||||
1b6573d7ea997cb89eec086ac8d56818de7790a342f70d9f44c2cf01acd42589 internal/engine/article_research.go
|
||||
dbcd1c06a744fe960e858d151b5f25814f59f6ee387b94b3a86e3fde195ed33a internal/config/config.go
|
||||
cc2159d4f036730aa90d64d804d3d66f8970b1d8e0dedb3db06bdb3480a0c6bf internal/config/config_test.go
|
||||
33061488eba055aa7e4f471d87684738c7dcebb1f98c68beb3e9e1a9b46f7baf internal/engine/article.go
|
||||
07e5ede41cbab177e8a2c79c53064e394b22f28ccbacde2c6b11c885a605f432 internal/engine/article_format_test.go
|
||||
c4d3dff9b11f7212e96e15e2d3065cb00b4ea6eb30db19c403f73c0e1f4a7a01 internal/engine/article_research.go
|
||||
501597b1b9340726e13c200099fdc10dc2a661410c76dce16f250b4dc6233871 internal/engine/article_research_cache.go
|
||||
3ca7037231935329d49b6b80553fbfef206c079a6aed4c2379dadd46d39ebc0d internal/engine/article_research_cache_test.go
|
||||
eba0d3478058119a27154511c7c37d653dacd1606f82677c1dcd79874589b51f internal/engine/article_research_test.go
|
||||
ee0197234e4b6b01c06dfe33c1f22cd73212a8b08aeb81fec98665ff21b5349c internal/engine/autonomous_research.go
|
||||
f04b09aee55437a5d35fa6c4adf3d7857a8336d195060bcf6f8e19f6880849e3 internal/engine/article_research_test.go
|
||||
b9496f8923251d07804ea2c96d62aeefdb18933531e54602c894931a78688a93 internal/engine/autonomous_research.go
|
||||
62a69f1af6fc3842e34f3847a5f868f81202feaaa6429e4e84db8115f5d14ad8 internal/engine/autonomous_research_test.go
|
||||
6a0a9d88dfb0a8b695989a84496e1ac542d48aa648b4b2c0b2e88fb0ffebcb47 internal/engine/engine.go
|
||||
520994a6cd24ad52a1824383ed81df0c93c403706178edcc31dd69272b593b1c internal/engine/engine.go
|
||||
24e022c1e572b42752fed780ff57f2c857d0600460b7806f7664f3c8c7dbb811 internal/engine/engine_test.go
|
||||
6209e4e52d8e822d0f72ca5ec04612b0a9ba8a9fe55d2a855d703f2e26e534a5 internal/engine/research_diagnostics.go
|
||||
2038a3909b147a630e361faae3f5c1cc22218d0f1336c91d4c1b795c52665e9b internal/engine/research_diagnostics.go
|
||||
0eb3f00e2ab73d2dc6a4cbc1a4038533a4bb20fbbbb6190abd39feff6b34b8e1 internal/engine/research_diagnostics_test.go
|
||||
716d42138db9eb64480c1bbaf4cb3b70bce1edf72c17c3d85a8d84f866fd8700 internal/engine/research_events.go
|
||||
ba0a67e541e2893f788662ac0aa00c55b9cbde6ce898b5a206300698bb07384a internal/engine/research_work.go
|
||||
cf4540c8f4f03e1a9047c8a12d18bacff674f57ab55c2ae673ff6280f34f594b internal/engine/research_work_test.go
|
||||
5654eadda4cfbc6f160cac9d680ad6b2f4d8c12b65b89bf99df037c3348221b2 internal/engine/runtime.go
|
||||
87416a32118e86c42e14a959f3f807463a694d4cb9218640e0664a39bab43991 internal/engine/runtime_filter_test.go
|
||||
b82980a646a92751bdd27a866ba1ffc6d34a3ba81d537f7b6e5a78e1432ee6fa internal/glpi/client.go
|
||||
@@ -85,20 +100,24 @@ ff44d56d56b9e301fbcf0f028d1bae6f0b851665f4fee65222097f1a2450f24a internal/inges
|
||||
257a4beba480dab7d9b79c1f32496f6b4f648c4c05170f51a77220dbfd21fe96 internal/ingest/knowledge.go
|
||||
a13910fb417484d56e78ae856b71fb66c63987d9abf3b513190bc52697321a18 internal/ingest/knowledge_test.go
|
||||
6185da62c3f526bacf2b4d6bd5617a10d72af2318852679030251ccb0f1a3882 internal/model/model.go
|
||||
5f6969313f1ca42a498d48787bbb56c173f7c272b54014e03af9bd3ac385c3fe internal/ollama/client.go
|
||||
ad1dd47b90792505defb20d8cbd328ed60ef6c61844e869f3e6857a72659381f internal/ollama/client.go
|
||||
28854e001cfecdd06d94ee5166cfd1af3b2a0281fb5a1a7fb52280f3edf71edc internal/ollama/client_test.go
|
||||
0bc8bb4c698c2c5dbef5c980d3e3fb88f10d35a8d7a230cbc81d218798bc1fe6 internal/persist/coordinator.go
|
||||
46144aa719ff5c3ab787c214d8e32e4b3c6883bed068410e5403a26f6352cd6a internal/persist/coordinator_test.go
|
||||
e7138877303bcc07c429323c4792fed112d8c16d35fd44222fe144ab0b69344f internal/research/fetch.go
|
||||
6a9f269783a7c41d5b63f9bd5022f415ed1b5572041ca5ccae1512d6dc2a0b80 internal/research/fetch_test.go
|
||||
a46b953c22fb2aef112b11ba65c61bda1e1582903e39489c2d081d17519ebd9d internal/research/searxng.go
|
||||
05f1be6d9169f74fed33cd5c392cd06acf8907756d69ea30a141f2b9f007ba1a internal/research/searxng.go
|
||||
2f82e80ad91590f419b1bbb19647b5191596e97c4d765e8736c1867ad899d457 internal/research/searxng_test.go
|
||||
984966a437944530008f4888944a91130604aad8891da3f67a89656bc991d9e4 internal/web/server.go
|
||||
b5abd1c3591242a7e8835eb38866410558d0e7901c75f5b11b94039ee3747716 internal/web/server_test.go
|
||||
3e27efdbeaf8aba34864f6d1dd47d101d04c87993d02e35ee08df34affaefe29 internal/web/static/analysis.css
|
||||
db27a3c62848dbb0f383886c1075d2c0c779363cea3e847793104ca708c1d6f0 internal/web/static/analysis.html
|
||||
5b6e8d6952c2ffd66b79d86bf32db139f73e37b0d7d02d154804ef111cce19b6 internal/web/static/analysis.js
|
||||
c63d7b2b2e5352515cbcb082860c37492276279dcf06b4eb7fad99e61d3a02dd internal/web/static/analysis.js
|
||||
6a92c00a768cbef68b2565f6e021351833373bacea7c537c8fba61746e917edc internal/web/static/app.css
|
||||
c23b771c37f4ebf8d6fd4292fc9d4939adc1989f1125aa48c3fabfa0e15a8a87 internal/web/static/app.js
|
||||
38ab054e9a40b68502fac89737b2e66e5935438972cffb7aa7deca9a4bcd80b2 internal/web/static/app.js
|
||||
a9327a08da143c45cfb8708a8bff5c4bf780644dddc891d0d2aceffb0bb183b1 internal/web/static/index.html
|
||||
a00976a14275d1adb69cba78683f7bff0205ed9c13ca6ec1424f7bbd5aba8808 internal/workqueue/limiter.go
|
||||
d57c818031a8a30846d9dcf570c95e623ecb237f2e4d94f4bbfc6a5045fc9de3 internal/workqueue/limiter_test.go
|
||||
83aded814b6225395935e61fe957963c3c470f368fc9089f505b6de23e959115 preview.png
|
||||
8d2a2794dfc3048a25aefa7cc47545cb8d70842b9092db42dbce3176fdab0f46 run.ps1
|
||||
a5f073faef5358937f6fb46cfa489e6c42c06febe3da8c432474deff0ad77440 runs.jsonl
|
||||
|
||||
47
VALIDATION-ARTICLE-CREATION-GATES.md
Normal file
47
VALIDATION-ARTICLE-CREATION-GATES.md
Normal file
@@ -0,0 +1,47 @@
|
||||
# Validation: Article Creation Gates
|
||||
|
||||
## Source case
|
||||
|
||||
The implementation targets the behavior observed in `brain-analysis (4).json`:
|
||||
|
||||
- research evidence was learned successfully;
|
||||
- article cycles repeatedly ended with `articles_created: 0` and `articles_skipped: 1`;
|
||||
- generated queries included invalid restrictions such as `site:digital-forensics`, `site:assetmanagement` and `site:cleanroomrecovery`;
|
||||
- editorial definition and differentiation requests remained critical;
|
||||
- at least one run reached `article.draft.started` without a visible rejection reason.
|
||||
|
||||
## Automated checks
|
||||
|
||||
The following focused engine tests pass:
|
||||
|
||||
- valid FQDN restrictions are retained;
|
||||
- topic labels are rejected as domains;
|
||||
- invalid query-level `site:` filters are removed;
|
||||
- editorial critical gaps are downgraded only with a grounded core;
|
||||
- rollback/data-loss gaps remain critical;
|
||||
- legacy editorial missing information becomes optional;
|
||||
- concept drafts pass the type-aware minimum with grounded key points;
|
||||
- the same short content fails the operational how-to minimum;
|
||||
- deterministic rejection metadata includes reason, field, actual and required values;
|
||||
- existing research-gate and knowledge-brief tests continue to pass.
|
||||
|
||||
Commands used in the isolated validation copy:
|
||||
|
||||
```bash
|
||||
go test ./internal/engine -run 'Test(NormalizeKnowledgeBrief|HeuristicResearchAssessment|FilterUsableResearchEvidence|AppendResearchEvidence|GapExpectsActionable|NormalizeResearchPlan|SelectResearchCandidates|CanonicalResearchURL|FilterKnowledgeBriefReferences|ArticleContentToDraft|NormalizeArticleContent|ArticleQualityContext|ArticleDraftContext|ValidateArticleDraft|ArticleDraftValidationMetadata|CleanDomains|SanitizeSearchQuery)' -count=1
|
||||
go test ./... -run '^$' -count=1
|
||||
node --check internal/web/static/app.js
|
||||
```
|
||||
|
||||
## Environment limitation
|
||||
|
||||
The project declares Go 1.26 and depends on `modernc.org/sqlite`. The available validation environment provides Go 1.23.2 and no internet access. Compilation validation therefore used a temporary Go 1.23 copy and a compile-only local SQLite package stub. The original `go.mod` and production source remain unchanged.
|
||||
|
||||
Focused pure-logic tests were executed normally. Full runtime tests that open a real SQLite database must be rerun in the regular project build environment:
|
||||
|
||||
```bash
|
||||
go test ./...
|
||||
make build
|
||||
```
|
||||
|
||||
The existing precompiled `neural-brain` file was not rebuilt in this environment.
|
||||
36
VALIDATION-RESEARCH-ORCHESTRATION.md
Normal file
36
VALIDATION-RESEARCH-ORCHESTRATION.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Validierung: Research-Orchestrierung
|
||||
|
||||
Geprüfte Punkte:
|
||||
|
||||
- Query-Normalisierung entfernt sowohl ungültige als auch gültige `site:`-Filter.
|
||||
- `preferred_domains` beeinflusst keine SearXNG-Query mehr.
|
||||
- Semantische Deduplizierung verwendet die Cosinus-Ähnlichkeit der Research-Intent-Embeddings; der Fallback arbeitet deterministisch über normalisierte Terme.
|
||||
- Ein zweiter paralleler Intent kann auf das Ergebnis eines laufenden Owners warten, statt erneut Webrecherche zu starten.
|
||||
- Die gemeinsame Work-Queue begrenzt aktive Operationen und die maximale Zahl wartender Aufträge.
|
||||
- Ollama Chat und Embedding verwenden denselben Limiter wie SearXNG-Suche und Volltext-Fetch.
|
||||
- `BRAIN_ARTICLE_LANGUAGE=en-US` erzeugt englische Abschnittsüberschriften im formatierten Antwortteil; `de-DE` behält die deutschen Überschriften.
|
||||
- JavaScript des Analysis Centers ist syntaktisch valide und zeigt Shared-Queue-/Dedupe-Zähler.
|
||||
|
||||
Lokale Prüfung in der Entwicklungsumgebung:
|
||||
|
||||
```text
|
||||
go test ./internal/config ./internal/research ./internal/ollama ./internal/workqueue
|
||||
PASS
|
||||
|
||||
go test ./internal/engine -run '<Research-/Language-Regressiontests>'
|
||||
PASS
|
||||
|
||||
go test ./... -run '^$'
|
||||
PASS (Compile-Check mit lokalem SQLite-Stub)
|
||||
|
||||
node --check internal/web/static/analysis.js
|
||||
PASS
|
||||
```
|
||||
|
||||
Die Projektdatei deklariert Go 1.26. In der Build-Umgebung steht nur Go 1.23.2 ohne Internetzugriff zur Verfügung. Für den Compile-Check wurde deshalb ausschließlich die Go-Direktive temporär auf 1.23 gesetzt und `modernc.org/sqlite` durch einen leeren lokalen Compile-Stub ersetzt. Diese temporären Teständerungen sind nicht Bestandteil des Releases.
|
||||
|
||||
## Zusätzliche Regressionen
|
||||
|
||||
- Dedupe-Namespaces verhindern, dass Relations-Snippets mit vollständiger Artikel-Evidenz verwechselt werden.
|
||||
- Wartende Duplikate werden nach einem Fehler des ersten Owners erneut als Owner eingeplant, statt einen leeren Erfolg zu übernehmen.
|
||||
- Relationsrecherche verwendet offene Queries und bis zu 8–12 Treffer statt der früheren vier.
|
||||
@@ -0,0 +1,339 @@
|
||||
{
|
||||
"action": "merge",
|
||||
"ai_source_count": 0,
|
||||
"article_id": "KB-AI-THINK-ARTICLE-20260807-8CA4EB67EE65",
|
||||
"article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-8ca4eb67ee65.json",
|
||||
"confidence": 1,
|
||||
"generated_at": "2026-08-07T05:12:13.562568Z",
|
||||
"generation_depth": 1,
|
||||
"knowledge_brief": {
|
||||
"topic": "Workload Trust, Zero Trust Architecture, Trust Boundaries, Device Trust",
|
||||
"purpose": "Zusammenfassung der fachlichen Inhalte zu Workload Trust, Zero Trust Architecture, Trust Boundaries und Device Trust aus mehreren Quellen.",
|
||||
"scope": [
|
||||
{
|
||||
"text": "Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
}
|
||||
],
|
||||
"facts": [
|
||||
{
|
||||
"text": "Workload Trust sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: sicher entwerfen und umsetzen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Identitäts-, Asset-, Daten- und Kommunikationspfade gegen definierte Trust Boundaries und Policies prüfen; implizite Vertrauensbeziehungen sichtbar machen. Für Workload Trust Baseline und erwartetes Normalverhalten dokumentieren; Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren. Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
|
||||
"source_refs": [
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Keine implizite Vertrauensannahme aus Netzstandort ableiten; Identität, Gerätezustand, Workload-Kontext und Ressourcensensitivität mit Least Privilege und kontinuierlicher Verifikation verbinden. Änderungen für Workload Trust kontrolliert testen, Rollback vorsehen, Ausnahmewege befristen und Konfigurationsdrift überwachen. Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
|
||||
"source_refs": [
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Prioritär sichern: Architekturdiagramme, Datenflüsse, Policy-/Konfigurationsstände, Identitäts- und Zugriffsaudits, Netzwerkpfade, Change-Historie und dokumentierte Ausnahmen. Flüchtige Daten vor Neustarts erfassen, sofern betrieblich vertretbar. Beweismittel mit Zeitbezug, Herkunft und Hash/Integritätsnachweis dokumentieren; Datenminimierung und Zugriffsschutz beachten.",
|
||||
"source_refs": [
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen. Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
|
||||
"source_refs": [
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Workload Trust sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: Wirksamkeit und Angriffspfade überprüfen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Zero Trust Architecture sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: Wirksamkeit und Angriffspfade überprüfen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"2c5d40d62109f0e5c9ffa8a0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Identitäts-, Asset-, Daten- und Kommunikationspfade gegen definierte Trust Boundaries und Policies prüfen; implizite Vertrauensbeziehungen sichtbar machen. Für Zero Trust Architecture Baseline und erwartetes Normalverhalten dokumentieren; Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren. Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
|
||||
"source_refs": [
|
||||
"2c5d40d62109f0e5c9ffa8a0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Keine implizite Vertrauensannahme aus Netzstandort ableiten; Identität, Gerätezustand, Workload-Kontext und Ressourcensensitivität mit Least Privilege und kontinuierlicher Verifikation verbinden. Änderungen für Zero Trust Architecture kontrolliert testen, Rollback vorsehen, Ausnahmewege befristen und Konfigurationsdrift überwachen. Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
|
||||
"source_refs": [
|
||||
"2c5d40d62109f0e5c9ffa8a0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Nach Änderungen Funktion, Security-Kontrolle und Telem, Telemetrie separat testen. Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
|
||||
"source_refs": [
|
||||
"2c5d40d62109f0e5c9ffa8a0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Zero Trust Architecture sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: sicher entwerfen und umsetzen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"a790904a2cefa56ad32cdef9"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Trust Boundaries sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: Wirksamkeit und Angriffspfade überprüfen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"854899964b8980e34aaf6d57"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Identitäts-, Asset-, Daten- und Kommunikationspfade gegen definierte Trust Boundaries und Policies prüfen; implizite Vertrauensbeziehungen sichtbar machen. Für Trust Boundaries Baseline und erwartetes Normalverhalten dokumentieren; Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren. Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
|
||||
"source_refs": [
|
||||
"854899964b8980e34aaf6d57"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Keine implizite Vertrauensannahme aus Netzstandort ableiten; Identität, Gerätezustand, Workload-Kontext und Ressourcensensitivität mit Least Privilege und kontinuierlicher Verifikation verbinden. Änderungen für Trust Boundaries kontrolliert testen, Rollback vorsehen, Ausnahmewege befristen und Konfigurationsdrift überwachen. Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
|
||||
"source_refs": [
|
||||
"854899964b8980e34aaf6d57"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Device Trust sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: Wirksamkeit und Angriffspfade überprüfen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"78b7adbdcbf17bb7afe6a9d0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Identitäts-, Asset-, Daten- und Kommunikationspfade gegen definierte Trust Boundaries und Policies prüfen; implizite Vertrauensbeziehungen sichtbar machen. Für Device Trust Baseline und erwartetes Normalverhalten dokumentieren; Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren. Einzelne Indikatoren sind kein ausreichender Beweis für einen Vorfall.",
|
||||
"source_refs": [
|
||||
"78b7adbdcbf17bb7afe6a9d0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Keine implizite Vertrauensannahme aus Netzstandort ableiten; Identität, Gerätezustand, Workload-Kontext und Ressourcensensitivität mit Least Privilege und kontinuierlicher Verifikation verbinden. Änderungen für Device Trust kontrolliert testen, Rollback vorsehen, Ausnahmewege befristen und Konfigurationsdrift überwachen. Sicherheitsmaßnahmen dürfen Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
|
||||
"source_refs": [
|
||||
"78b7adbdcbf17bb7afe6a9d0"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Device Trust sollte risikobasiert betrachtet werden. Der Schwerpunkt dieses Artikels ist: sicher entwerfen und umsetzen. Zuerst Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten dokumentieren.",
|
||||
"source_refs": [
|
||||
"773c4491ae9eadb8e132e295"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Prioritär sichern: Architekturdiagramme, Datenflüsse, Policy-/Konfigurationsstände, Identitäts- und Zugriffsaudits, Netzwerkpfade, Change-Historie und dokumentierte Ausnahmen. Flüchtige Daten vor Neustarts erfassen, sofern betrieblich vertretbar. Beweismittel mit Zeitbezug, Herkunft und Hash/Integritätsnachweis dokumentieren; Datenminimheit und Zugriffsschutz beachten.",
|
||||
"source_refs": [
|
||||
"773c4491ae9eadb8e132e295"
|
||||
]
|
||||
}
|
||||
],
|
||||
"symptoms": [],
|
||||
"prerequisites": [],
|
||||
"solution_steps": [
|
||||
{
|
||||
"text": "Identitäts-, Asset-, Daten- und Kommunikationspfade gegen definierte Trust Boundaries und Policies prüfen; implizite Vertrauensbeziehungen sichtbar machen.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Für Workload Trust, Zero Trust Architecture, Trust Boundaries und Device Trust Baseline und erwartetes Normalverhalten dokumentieren; Abweichungen immer mit Asset-, Identitäts- und Change-Kontext korrelieren.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Keine implizite Vertrauensannahme aus Netzstandort ableiten; Identität, Gerätezustand, Workload-Kontext und Ressourcensensitivität mit Least Privilege und kontinuierlicher Verifikation verbinden.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Änderungen für Workload Trust, Zero Trust Architecture, Trust Boundaries und Device Trust kontrolliert testen, Rollback vorsehen, Ausnahmewege befristen und Konfigurationsdrift überwachen.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Prioritär sichern: Architekturdiagramme, Datenflüsse, Policy-/Konfigurationsstände, Identitäts- und Zugriffsaudits, Netzwerkpfade, Change-Historie und dokumentierte Ausnahmen.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Flüchtige Daten vor Neustarts erfassen, sofern betrieblich vertretbar. Beweismittel mit Zeitbezug, Herkunft und Hash/Integritätsnachweis dokumentieren; Datenminimierung und Zugriffsschutz beachten.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen. Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
}
|
||||
],
|
||||
"validation_steps": [
|
||||
{
|
||||
"text": "Nach Änderungen Funktion, Security-Kontrolle und Telemetrie separat testen.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Bei bestätigter Kompromittierung Scope auf angrenzende Systeme/Identitäten erweitern, Ursache beseitigen, Credentials/Keys nur gezielt rotieren und anschließend erhöhtes Monitoring einplanen.",
|
||||
"source_refs": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
]
|
||||
}
|
||||
],
|
||||
"troubleshooting": [],
|
||||
"contradictions": [],
|
||||
"critical_gaps": [],
|
||||
"optional_gaps": [
|
||||
{
|
||||
"id": "GAP-001",
|
||||
"description": "Fehlende klare Abgrenzung zwischen 'Workload Trust' und 'Zero Trust Architecture' könnte zu falscher Anwendung führen. Ohne klare Unterscheidung könnten Sicherheitsmaßnahmen für 'Workload Trust' fälschlicherweise auf 'Zero Trust Architecture' angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"reason": "Ohne klare Abgrenzung könnten Sicherheitsmaßnahmen für 'Workload Trust' fälschlicherweise auf 'Zero Trust Architecture' angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"research_queries": [
|
||||
"Abgrenzung zwischen Workload Trust und Zero Trust Architecture",
|
||||
"Unterschiede in der Anwendung von Sicherheitsmaßnahmen für Workload Trust und Zero Trust Architecture"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "GAP-002",
|
||||
"description": "Fehlende klare Definition von 'Trust Boundaries' könnte zu ungenauer Implementierung führen. Ohne klare Definition könnten Trust Boundaries nicht korrekt definiert und überwacht werden, was zu Sicherheitsrisiken führen kann.",
|
||||
"reason": "Ohne klare Definition könnten Trust Boundaries nicht korrekt definiert und überwacht werden, was zu Sicherheitsrisiken führen kann.",
|
||||
"research_queries": [
|
||||
"Definition von Trust Boundaries",
|
||||
"Korrekter Einsatz von Trust Boundaries in der Sicherheitsarchitektur"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "GAP-003",
|
||||
"description": "Fehlende klare Definition von 'Device Trust' könnte zu ungenauer Implementierung führen. Ohne klare Definition könnten Sicherheitsmaßnahmen für 'Device Trust' fälschlicherweise auf andere Systeme angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"reason": "Ohne klare Definition könnten Sicherheitsmaßnahmen für 'Device Trust' fälschlicherweise auf andere Systeme angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"research_queries": [
|
||||
"Definition von Device Trust",
|
||||
"Korrekter Einsatz von Sicherheitsmaßnahmen für Device Trust"
|
||||
]
|
||||
}
|
||||
],
|
||||
"resolved_gaps": [],
|
||||
"missing_information": [
|
||||
"Fehlende klare Abgrenzung zwischen 'Workload Trust' und 'Zero Trust Architecture' könnte zu falscher Anwendung führen. Ohne klare Unterscheidung könnten Sicherheitsmaßnahmen für 'Workload Trust' fälschlicherweise auf 'Zero Trust Architecture' angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"Fehlende klare Definition von 'Device Trust' könnte zu ungenauer Implementierung führen. Ohne klare Definition könnten Sicherheitsmaßnahmen für 'Device Trust' fälschlicherweise auf andere Systeme angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"Fehlende klare Definition von 'Trust Boundaries' könnte zu ungenauer Implementierung führen. Ohne klare Definition könnten Trust Boundaries nicht korrekt definiert und überwacht werden, was zu Sicherheitsrisiken führen kann."
|
||||
],
|
||||
"research_queries": null,
|
||||
"ready_for_article": true
|
||||
},
|
||||
"language": "de-DE",
|
||||
"open_questions": [
|
||||
"Fehlende klare Abgrenzung zwischen 'Workload Trust' und 'Zero Trust Architecture' könnte zu falscher Anwendung führen.",
|
||||
"Fehlende klare Abgrenzung zwischen 'Workload Trust' und 'Zero Trust Architecture' könnte zu falscher Anwendung führen. Ohne klare Unterscheidung könnten Sicherheitsmaßnahmen für 'Workload Trust' fälschlicherweise auf 'Zero Trust Architecture' angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"Fehlende klare Definition von 'Device Trust' könnte zu ungenauer Implementierung führen.",
|
||||
"Fehlende klare Definition von 'Device Trust' könnte zu ungenauer Implementierung führen. Ohne klare Definition könnten Sicherheitsmaßnahmen für 'Device Trust' fälschlicherweise auf andere Systeme angewendet werden, was zu Sicherheitslücken führen kann.",
|
||||
"Fehlende klare Definition von 'Trust Boundaries' könnte zu ungenauer Implementierung führen.",
|
||||
"Fehlende klare Definition von 'Trust Boundaries' könnte zu ungenauer Implementierung führen. Ohne klare Definition könnten Trust Boundaries nicht korrekt definiert und überwacht werden, was zu Sicherheitsrisiken führen kann."
|
||||
],
|
||||
"planning": {
|
||||
"article_type": "how_to",
|
||||
"contradictions": [],
|
||||
"expected_value": "Konsolidierung der vier Artikel zu Workload Trust, Trust Boundaries, Zero Trust Architecture und Device Trust unter dem gemeinsamen Thema 'Workload Trust in IT-Security'.",
|
||||
"missing_information": [],
|
||||
"reason": "Die Quellen behandeln ähnliche Themen und sind stark überlappend. Sie können als Staging-Entwurf in einen Zielartikel konsolidiert werden, um eine umfassende, strukturierte und praxisnahe Anleitung zu Workload Trust in der IT-Security zu erstellen."
|
||||
},
|
||||
"production_ratio": 1,
|
||||
"productive_source_count": 7,
|
||||
"research_evidence": null,
|
||||
"research_query": "",
|
||||
"source_node_ids": [
|
||||
"0689d670262bda1704a8d735",
|
||||
"2c5d40d62109f0e5c9ffa8a0",
|
||||
"773c4491ae9eadb8e132e295",
|
||||
"78b7adbdcbf17bb7afe6a9d0",
|
||||
"854899964b8980e34aaf6d57",
|
||||
"a790904a2cefa56ad32cdef9",
|
||||
"a9dc317b7a6e9ba767fb52a6"
|
||||
],
|
||||
"source_nodes": [
|
||||
"KB-SEC-HB-03222",
|
||||
"KB-SEC-HB-03223",
|
||||
"KB-SEC-HB-03236",
|
||||
"KB-SEC-HB-03237",
|
||||
"KB-SEC-HB-03238",
|
||||
"KB-SEC-HB-03239",
|
||||
"KB-SEC-HB-03249"
|
||||
],
|
||||
"status": "staging",
|
||||
"subtype": "knowledge_synthesis",
|
||||
"target_article_id": "KB-SEC-HB-03238",
|
||||
"target_node_id": "a9dc317b7a6e9ba767fb52a6"
|
||||
}
|
||||
@@ -0,0 +1,483 @@
|
||||
{
|
||||
"action": "merge",
|
||||
"ai_source_count": 0,
|
||||
"article_id": "KB-AI-THINK-ARTICLE-20260807-8F77165ADAC2",
|
||||
"article_path": "E:\\GoProjects\\glpi-neural-brain\\staging\\kb-ai-think-article-20260807-8f77165adac2.json",
|
||||
"confidence": 1,
|
||||
"generated_at": "2026-08-07T04:26:28.0387044Z",
|
||||
"generation_depth": 1,
|
||||
"knowledge_brief": {
|
||||
"topic": "BGP Prefix Filtering und BGP Security – Sicherheitsplanung, Härtung, Überwachung, Anomalienerkennung und forensische Analyse bei Sicherheitsvorfällen",
|
||||
"purpose": "Die Sicherheitsplanung, Härtung, Überwachung, Anomalienerkennung und forensische Analyse von BGP Prefix Filtering und BGP Security sind zentral für die Sicherheit von Netzwerken. Die Artikel legen die Grundlagen für die risikobasierte Sicherheitsplanung und die Sicherstellung der Netzwerkintegrität fest.",
|
||||
"scope": [
|
||||
{
|
||||
"text": "Die Sicherheitsplanung und Härtung von BGP Prefix Filtering und BGP Security umfasst die Dokumentation von Scope, betroffenen Assets/Identitäten, Datenkritikalität, Exposition und betrieblichen Abhängigkeiten.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Die Überwachung und Anomalienerkennung von BGP Prefix Filtering und BGP Security umfasst die Zusammenführung von Flows, Firewall-/Router-/Switch-/VPN-/DNS-Telemetrie und Asset-/Identitätskontext.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Die forensische Analyse und Incident Response bei Sicherheitsvorfällen umfasst die Priorisierung der Sicherung von PCAP, NetFlow/IPFIX, Firewall-/VPN-/DNS-/AAA-Logs, Konfigurationsständen, Routing-/Neighbor-Tabellen und Zeitquellen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"facts": [
|
||||
{
|
||||
"text": "BGP Prefix Filtering und BGP Security sollten risikobasiert betrachtet werden. Der Schwerpunkt der Artikel liegt auf der Sicherheitsplanung, der Überwachung, der Anomalienerkennung und der forensischen Analyse bei Sicherheitsvorfällen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Für die Sicherheitsplanung und Härtung von BGP Prefix Filtering und BGP Security sind Default-Deny, Segmentierung, Management-Plane-Trennung, starke Admin-Authentisierung, verschlüsselte Protokolle und Egress-Kontrolle empfohlen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Bei der Überwachung und Anomalienerkennung von BGP Prefix Filtering und BGP Security sollten Flows, Firewall-/Router-/Switch-/VPN-/DNS-Telemetrie und Asset-/Identitätskontext zusammengeführt werden. Baseline und erwartetes Normalverhalten müssen dokumentiert werden, Abweichungen mit Asset-, Identitäts- und Change-Kontext korreliert werden.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Bei der forensischen Analyse und Incident Response von BGP Security-Vorfällen sollten PCAP, NetFlow/IPFIX, Firewall-/VPN-/DNS-/AAA-Logs, Konfigurationsstände, Routing-/Neighbor-Tabellen und Zeitquellen priorisiert gesichert werden. Flüchtige Daten vor Neustarts erfassen, Beweismittel mit Zeitbezug, Herkunft und Hash/Integritätsnachweis dokumentieren.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Nach Änderungen von BGP Prefix Filtering und BGP Security sollten Funktion, Security-Kontrolle und Telemetrie separat getestet werden. Bei bestätigter Kompromittierung sollte der Scope auf angrenzende Systeme/Identitäten erweitert werden, Ursache beseitigt, Credentials/Keys nur gezielt rotiert und erhöhtes Monitoring eingeplant werden.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"symptoms": [
|
||||
{
|
||||
"text": "Abweichungen im Normalverhalten von BGP Prefix Filtering und BGP Security, die mit Asset-, Identitäts- und Change-Kontext korreliert werden müssen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Unzulässige Änderungen an BGP Prefix Filtering und BGP Security, die Konfigurationsdrift und Sicherheitslücken verursachen können.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Fehlende Beweismittel oder unklare Herkunft von Daten bei Sicherheitsvorfällen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"prerequisites": [
|
||||
{
|
||||
"text": "Die Sicherheitsplanung und Härtung von BGP Prefix Filtering und BGP Security erfordert die Dokumentation von Scope, betroffenen Assets/Identitäten, Datenkritikalität, Exposition und betrieblichen Abhängigkeiten.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Die Überwachung und Anomalienerkennung von BGP Prefix Filtering und BGP Security erfordert die Zusammenführung von Flows, Firewall-/Router-/Switch-/VPN-/DNS-Telemetrie und Asset-/Identitätskontext.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Die forensische Analyse und Incident Response bei Sicherheitsvorfällen erfordert die Priorisierung der Sicherung von PCAP, NetFlow/IPFIX, Firewall-/VPN-/DNS-/AAA-Logs, Konfigurationsständen, Routing-/Neighbor-Tabellen und Zeitquellen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"solution_steps": [
|
||||
{
|
||||
"text": "Dokumentieren Sie Scope, betroffene Assets/Identitäten, Datenkritikalität, Exposition und betriebliche Abhängigkeiten.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Zusammenführen von Flows, Firewall-/Router-/Switch-/VPN-/DNS-Telemetrie und Asset-/Identitätskontext.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Dokumentieren Sie Baseline und erwartetes Normalverhalten, korrelieren Sie Abweichungen mit Asset-, Identitäts- und Change-Kontext.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Implementieren Sie Default-Deny, Segmentierung, Management-Plane-Trennung, starke Admin-Authentisierung, verschlüsselte Protokolle und Egress-Kontrolle.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Testen Sie Änderungen kontrolliert, vorsehen Sie Rollback, befristen Sie Ausnahmewege und überwachen Sie Konfigurationsdrift.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Sichern Sie PCAP, NetFlow/IPFIX, Firewall-/VPN-/DNS-/AAA-Logs, Konfigurationsstände, Routing-/Neighbor-Tabellen und Zeitquellen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Erfassen Sie flüchtige Daten vor Neustarts, dokumentieren Sie Beweismittel mit Zeitbezug, Herkunft und Hash/Integritätsnachweis.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Testen Sie Funktion, Security-Kontrolle und Telemetrie separat nach Änderungen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Erweitern Sie den Scope bei bestätigter Kompromittierung, beseitigen Sie Ursache, rotieren Sie Credentials/Keys gezielt und planen Sie erhöhtes Monitoring ein.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"validation_steps": [
|
||||
{
|
||||
"text": "Testen Sie Funktion, Security-Kontrolle und Telemetrie separat nach Änderungen.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Überprüfen Sie, ob Sicherheitsmaßnahmen die Verfügbarkeit und Wiederherstellbarkeit nicht unbeabsichtigt verschlechtern.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Überprüfen Sie, ob Beweismittel mit Zeitbezug, Herkunft und Hash/Integritätsnachweis dokumentiert sind.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"troubleshooting": [
|
||||
{
|
||||
"text": "Bei Abweichungen im Normalverhalten von BGP Prefix Filtering und BGP Security sollten die Asset-, Identitäts- und Change-Kontexte korreliert werden, um die Ursache zu identifizieren.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Bei unzulässigen Änderungen an BGP Prefix Filtering und BGP Security sollten die Konfigurationsdrift überwacht und Rollback-Pläne aktiviert werden.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
},
|
||||
{
|
||||
"text": "Bei fehlenden Beweismitteln oder unklarer Herkunft von Daten bei Sicherheitsvorfällen sollten die Sicherung von PCAP, NetFlow/IPFIX, Firewall-/VPN-/DNS-/AAA-Logs, Konfigurationsständen, Routing-/Neighbor-Tabellen und Zeitquellen priorisiert werden.",
|
||||
"source_refs": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
]
|
||||
}
|
||||
],
|
||||
"contradictions": [],
|
||||
"critical_gaps": [],
|
||||
"optional_gaps": [
|
||||
{
|
||||
"id": "OG-001",
|
||||
"description": "Zusätzliche Beispiele für die Anwendung von BGP Prefix Filtering in verschiedenen Netzwerkumgebungen.",
|
||||
"reason": "Zusätzliche Beispiele können die Anwendbarkeit der beschriebenen Sicherheitsmaßnahmen verdeutlichen, sind aber nicht zwingend für die Umsetzung der Sicherheitsrichtlinien.",
|
||||
"research_queries": [
|
||||
"Beispiele für BGP Prefix Filtering in verschiedenen Netzwerkumgebungen"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "OG-002",
|
||||
"description": "Zusätzliche Informationen zu den Sicherheitsrisiken, die durch fehlerhafte BGP Prefix Filtering-Konfigurationen entstehen können.",
|
||||
"reason": "Diese Informationen könnten die Sicherheitsbewertung vertiefen, sind aber nicht zwingend für die Umsetzung der Sicherheitsmaßnahmen.",
|
||||
"research_queries": [
|
||||
"Sicherheitsrisiken durch fehlerhafte BGP Prefix Filtering-Konfigurationen"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "OG-003",
|
||||
"description": "Zusätzliche Informationen zu den Tools und Automatisierungsmöglichkeiten für die Überwachung von BGP Prefix Filtering.",
|
||||
"reason": "Diese Informationen könnten die Effizienz der Überwachung erhöhen, sind aber nicht zwingend für die Umsetzung der Sicherheitsmaßnahmen.",
|
||||
"research_queries": [
|
||||
"Tools und Automatisierungsmöglichkeiten für BGP Prefix Filtering-Überwachung"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "KG-001",
|
||||
"description": "Fehlende konkrete Vorschläge für die Implementierung von BGP Prefix Filtering, wie z.B. spezifische Konfigurationsbeispiele oder Tools zur Automatisierung der Filterung.",
|
||||
"reason": "Ohne konkrete Implementierungsvorschläge ist es für die Praxis nicht möglich, die beschriebenen Sicherheitsmaßnahmen effektiv umzusetzen. Ein falsches oder unvollständiges Konfigurationsdesign könnte zu Sicherheitslücken führen.",
|
||||
"research_queries": [
|
||||
"Konkrete Konfigurationsbeispiele für BGP Prefix Filtering",
|
||||
"Tools zur Automatisierung von BGP Prefix Filtering"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "KG-002",
|
||||
"description": "Fehlende Informationen zu den spezifischen Anomalien, die bei BGP Prefix Filtering erkannt werden können, und wie diese differenziert erfasst werden können.",
|
||||
"reason": "Ohne klare Definition der Anomalien und ihrer Erkennungsmethoden ist die Überwachung und Anomalienerkennung nicht belastbar. Dies könnte zu Fehlalarmen oder verpassten Sicherheitsvorfällen führen.",
|
||||
"research_queries": [
|
||||
"Anomalien bei BGP Prefix Filtering",
|
||||
"Erkennungsmethoden für BGP Prefix Filtering-Anomalien"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "KG-003",
|
||||
"description": "Fehlende detaillierte Informationen zur forensischen Analyse von BGP Security-Vorfällen, wie z.B. spezifische Indikatoren oder Verfahren zur Beweissicherung.",
|
||||
"reason": "Ohne detaillierte forensische Anleitungen ist die Analyse von Sicherheitsvorfällen unvollständig und könnte zu falschen Schlussfolgerungen führen. Dies beeinträchtigt die Ermittlungen und die Prävention zukünftiger Vorfälle.",
|
||||
"research_queries": [
|
||||
"Forensische Indikatoren für BGP Security-Vorfälle",
|
||||
"Verfahren zur Beweissicherung bei BGP Security-Vorfällen"
|
||||
]
|
||||
}
|
||||
],
|
||||
"resolved_gaps": [],
|
||||
"missing_information": [
|
||||
"Fehlende Informationen zu den spezifischen Anomalien, die bei BGP Prefix Filtering erkannt werden können, und wie diese differenziert erfasst werden können.",
|
||||
"Fehlende detaillierte Informationen zur forensischen Analyse von BGP Security-Vorfällen, wie z.B. spezifische Indikatoren oder Verfahren zur Beweissicherung.",
|
||||
"Fehlende konkrete Vorschläge für die Implementierung von BGP Prefix Filtering, wie z.B. spezifische Konfigurationsbeispiele oder Tools zur Automatisierung der Filterung.",
|
||||
"Zusätzliche Beispiele für die Anwendung von BGP Prefix Filtering in verschiedenen Netzwerkumgebungen.",
|
||||
"Zusätzliche Informationen zu den Sicherheitsrisiken, die durch fehlerhafte BGP Prefix Filtering-Konfigurationen entstehen können.",
|
||||
"Zusätzliche Informationen zu den Tools und Automatisierungsmöglichkeiten für die Überwachung von BGP Prefix Filtering."
|
||||
],
|
||||
"research_queries": null,
|
||||
"ready_for_article": true
|
||||
},
|
||||
"language": "de-DE",
|
||||
"open_questions": [
|
||||
"Fehlende Informationen zu den spezifischen Anomalien, die bei BGP Prefix Filtering erkannt werden können, und wie diese differenziert erfasst werden können.",
|
||||
"Fehlende detaillierte Informationen zur forensischen Analyse von BGP Security-Vorfällen, wie z.B. spezifische Indikatoren oder Verfahren zur Beweissicherung.",
|
||||
"Fehlende konkrete Vorschläge für die Implementierung von BGP Prefix Filtering, wie z.B. spezifische Konfigurationsbeispiele oder Tools zur Automatisierung der Filterung.",
|
||||
"Zusätzliche Beispiele für die Anwendung von BGP Prefix Filtering in verschiedenen Netzwerkumgebungen.",
|
||||
"Zusätzliche Informationen zu den Sicherheitsrisiken, die durch fehlerhafte BGP Prefix Filtering-Konfigurationen entstehen können.",
|
||||
"Zusätzliche Informationen zu den Tools und Automatisierungsmöglichkeiten für die Überwachung von BGP Prefix Filtering."
|
||||
],
|
||||
"planning": {
|
||||
"article_type": "how_to",
|
||||
"contradictions": [],
|
||||
"expected_value": "BGP Prefix Filtering – Sicher entwerfen, härten, überwachen, bei Vorfällen untersuchen",
|
||||
"missing_information": [],
|
||||
"reason": "Die Quellen behandeln das Thema 'BGP Prefix Filtering' und teilen ähnliche Struktur und Inhalt in den Abschnitten 'Defensive Prüfung / Detection', 'Härtung' und 'Forensik / Incident Response'. Sie sind eng miteinander verwandt und beschäftigen sich mit ähnlichen Aspekten der Sicherheit und der praktischen Umsetzung. Ein Zielartikel, der alle drei Aspekte (sicher entwerfen und härten, überwachen und Anomalien erkennen, bei Sicherheitsvorfällen untersuchen) abdeckt, wäre ein echter Mehrwert für den Helpdesk."
|
||||
},
|
||||
"production_ratio": 1,
|
||||
"productive_source_count": 7,
|
||||
"research_evidence": null,
|
||||
"research_query": "",
|
||||
"source_node_ids": [
|
||||
"125b32eef1d4b0e1f2b472fe",
|
||||
"37defcd6155965e8f1878dee",
|
||||
"48245e1bea164920e52fd4b3",
|
||||
"ab7ddbbf9925bad5983e52f4",
|
||||
"c4442db240a56438dab261a6",
|
||||
"cd8b2578c0f1e657e6080205",
|
||||
"deb0fe9a48ac770686a3f06c"
|
||||
],
|
||||
"source_nodes": [
|
||||
"KB-SEC-HB-00576",
|
||||
"KB-SEC-HB-00579",
|
||||
"KB-SEC-HB-00709",
|
||||
"KB-SEC-HB-00710",
|
||||
"KB-SEC-HB-00711",
|
||||
"KB-SEC-HB-00715",
|
||||
"KB-SEC-HB-00716"
|
||||
],
|
||||
"status": "staging",
|
||||
"subtype": "knowledge_synthesis",
|
||||
"target_article_id": "KB-SEC-HB-00715",
|
||||
"target_node_id": "ab7ddbbf9925bad5983e52f4"
|
||||
}
|
||||
BIN
data/graph.db
BIN
data/graph.db
Binary file not shown.
25
data/research-evidence/01501de800a4f2e587d30727.json
Normal file
25
data/research-evidence/01501de800a4f2e587d30727.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-06T22:05:33.1888208Z",
|
||||
"content_sha256": "3af68f810310ca34d5e719a95b17ade547cd796ce354a0b9747f939317958655",
|
||||
"result": {
|
||||
"title": "OPUS 4 | Analyse des forensischen Nutzen biometrischer Merkmale für die Nutzer Authentifizierung an mobilen Endgeräten",
|
||||
"url": "https://monami.hs-mittweida.de/frontdoor/index/index/year/2022/docId/13442",
|
||||
"snippet": "Mit einem Brute-Force-Angriff kann es jedoch mehrere Jahre dauern, Passwörter zu knacken. Daher kann die Biometrie eine schnellere Lösung sein, um mobile Geräte zu entsperren. Hier liegt der Fokus auf der Erstellung von Fingerabdruck-Artefakten, um sich Zugang zu verschaffen.",
|
||||
"content": "OPUS 4 | Analyse des forensischen Nutzen biometrischer Merkmale für die Nutzer Authentifizierung an mobilen Endgeräten\n\nEnglish\n\nAnmelden\n\nStartseite\n\nSuchen\n\nBrowsen\n\nVeröffentlichen\n\nFAQ\n\nVolltext-Downloads (blau) und Frontdoor-Views (grau)\n\nSchließen\n\nAnalyse des forensischen Nutzen biometrischer Merkmale für die Nutzer Authentifizierung an mobilen Endgeräten\n\nAnalysis of biometric features for user authentication on mobile devices for forensic purposes\n\nNavina Halbe\n\nDie Biometrie ist eine Methode für die Zugriffssicherung auf sensible Daten, welche sich seit dem letzten Jahrzehnt immer mehr durchgesetzt hat. Sie wird vor allem in dem Bereich mobiler Endgeräte verbreitet eingesetzt, da die Implementierung kostengünstig ist. Außerdem muss sich der Benutzer keine Zugangsdaten merken, um Zugriff zu erlangen. Mit dem zunehmenden Nutzen werden jedoch auch Ansätze evaluiert, um diese Sicherheitsbeschränkungen von biometrischen Systemen zu umgehen.\n\nIn dieser Arbeit werden Ansätze evaluiert, um Zugang zu gesicherten Daten für forensische Zwecke zu erhalten. Bei Straftaten ist es entscheidend, in kurzer Zeit an die benötigten Daten zu kommen. Mit einem Brute-Force-Angriff kann es jedoch mehrere Jahre dauern, Passwörter zu knacken. Daher kann die Biometrie eine schnellere Lösung sein, um mobile Geräte zu entsperren. Hier liegt der Fokus auf der Erstellung von Fingerabdruck-Artefakten, um sich Zugang zu verschaffen.\n\nUm diese These zu überprüfen, werden Experimente mit verschiedenen Ansätzen durchgeführt, um gängige Typen von Fingerabdrucksensoren zu umgehen. Zu Beginn wurden 2D-Ansätze evaluiert. Hierbei werden Fingerabdrücke mit einem Laserdrucker auf verschiedenste Materialien gedruckt. Als nächstes werden 3D-Ansätze getestet, wozu ein SLA Drucker verwendet wird. Darüber hinaus sind Hilfsmittel evaluiert worden, um die Eigenschaften der Fingerabdruckartefakte zu verbessern, damit sie sich mehr wie ein menschlicher Finger verhalten.\n\nDie Experimente zeigen, dass es möglich ist, Fingerabdrucksensoren mit Artefakten zu umgehen, um an gesicherte Daten zu gelangen. Optische Sensoren akzeptieren 2D gedruckte Fingerabdrücke. Im Gegensatz dazu benötigen kapazitive und ultraschallbasierte Sensoren andere Artefakte. Wir konnten die Sicherheitssperre mit 3D Fingerabdrücken überwinden. Darüber hinaus sind Hilfsmittel nützlich, wenn eine Lebenderkennung integriert ist.\n\nVolltext Dateien herunterladen\n\nBachelorarbeit_Navina_Halbe.pdf\n\nMetadaten exportieren\n\nBibTeX\n\nRIS\n\nWeitere Dienste\n\nStatistik\n\nMetadaten\n\nVerfasserangaben:\n\nNavina Halbe\n\nBetreuer*in:\n\nRonny Bodach, Christian Kison\n\nDokumentart:\n\nBachelorarbeit\n\nSprache:\n\nDeutsch\n\nErscheinungsjahr:\n\n2021\n\nTitel verleihende Institution:\n\nHochschule Mittweida\n\nDatum der Freischaltung:\n\n07.10.2022\n\nGND-Schlagwort:\n\nBiometrie; Mobiles Endgerät; Authentifikation\n\nFakultäten:\n\nAngewandte Computer‐ und Biowissenschaften\n\nDDC-Sachgruppen:\n\n005.8 Internetkriminalität, Computersicherheit, Datensicherung, Computerforensik, Identitätsverwaltung\n\nZugriffsrecht:\n\nInnerhalb der Hochschule\n\nLizenz (Deutsch):\n\nUrheberrechtlich geschützt\n\nKontakt\n\nImpressum\n\nSitelinks",
|
||||
"content_type": "text/html",
|
||||
"query": "Welche forensischen Artefakte sind typisch für Mobile Authentication?",
|
||||
"language": "de-DE",
|
||||
"round": 2,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.9200000000000002,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.7440000000000001,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"OG-001"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschäftigt sich direkt mit forensischen Artefakten im Kontext von Mobile Authentication, insbesondere mit Fingerabdruck-Artefakten und deren Umgehung. Sie liefert konkrete Experimente und Techniken zur Erstellung von Artefakten, die für die forensische Zugangserlangung relevant sind. Allerdings fehlen konkrete umsetzbare Schritte oder Prüfkriterien, die in der Suchanfrage explizit erwartet werden."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/01e3e34e2ad5e1b374ed3598.json
Normal file
25
data/research-evidence/01e3e34e2ad5e1b374ed3598.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/02547b986f201664ebc4a5ed.json
Normal file
25
data/research-evidence/02547b986f201664ebc4a5ed.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:14:37.3843202Z",
|
||||
"content_sha256": "2f01e1e50660b39754fb31f7e1e95ae8dcb03f8c14f936ee7e19d2e12d71715d",
|
||||
"result": {
|
||||
"title": "SSL mit Perfect Forward Secrecy unter nginx - Michis Blog",
|
||||
"url": "https://blog.doenselmann.com/ssl-mit-perfect-forward-secrecy-unter-nginx/",
|
||||
"snippet": "Um PFS jetzt zu aktivieren, sind ein paar zusätzliche Parameter in der Konfigurationsdatei erforderlich. Im weiter unten folgenden Ausschnitt einer Konfigurationsdatei wird dies ersichtlich.",
|
||||
"content": "SSL ist in den letzten Tagen mal wieder in aller Munde. Dank des Heartbleed Bugs in OpenSSL ist es Angreifern möglich, entschlüsselte Informationen oder sogar den privaten Schlüssel des Zertifikats aus dem Speicher des Webservers zu ziehen, ohne dabei Spuren zu hinterlassen. Sollte der private Schlüssel in fremde Hände gelangen, lässt sich damit einiges an Schindluder treiben. Eine Möglichkeit wäre, bereits aufgezeichnete, jedoch verschlüsselte Kommunikation, nachträglich zu entschlüsseln. Um das zu verhindern, gibt es eine Funktion die sich „Perfect Forward Secrecy“ nennt. PFS nutzt nicht das Public Key Verfahren um einen Sitzungsschlüssel zu erzeugen. Für PFS wird das Diffie-Hellman Verfahren eingesetzt. Hier wird von beiden Seiten (Client/Server) ein gemeinsamer Sitzungsschlüssel erzeugt. Wer’s gern etwas genauer wissen will, kann sich folgenden Wiki Artikel durchlesen Klick\n\nFolgende Komponente werden für SSL mit PFS benötigt.\n\nSSL Zertifikat\n\nDiffie-Hellman Key für den Schlüsselaustausch\n\nWebserver. Ich verwende hier nginx ( nginx Website )\n\nOpenSSL zur Zertifikatserstellung. Wichtig ist mind. Version 1.0.1g einzusetzen, um nicht mehr von Heartbleed betroffen zu sein. Wer mag, kann sich auch gerne seine eigene Version ohne Heartbeat Funktion kompilieren.\n\nUm an ein eigenes SSL Zertifikat zu kommen, gibt es mehrere verschiedene Möglichkeiten. Ich beschränke mich jetzt auf die Erstellung mittels OpenSSL. Da ein selbstsigniertes Zertifikat zu Fehlern in Browsern bzw. Apps führt, ist es wichtig den öffentlichen Schlüssel auf dem Client zu importieren. Wer sowas umgehen möchte/muss, wird um einen kommerziellen Anbieter nicht rum kommen (StartSSL.com). Folgender Befehl erzeugt ein Zertifikat, welches den heutigen Anforderungen an „vernünftige“ Krypto gerecht wird:\n\nopenssl req -newkey rsa:4096 -sha512 -x509 -days 365 -nodes -out /etc/nginx/certs/cert.pem -keyout /etc/nginx/certs/cert\n\nDas Zertifikat ist ein Jahr gültig und setzt auf RSA 4096 Bit mit SHA512 Hashalgorithmus. Um den Schlüsselaustausch zu gewährleisten, muss noch ein Diffie-Hellman Key erzeugt werden.\n\nopenssl dhparam -out /etc/nginx/certs/dhparam.pem 2048\n\nJetzt, wo alle Voraussetzungen erfüllt sind, ist der Webserver an der Reihe. Die nginx Konfigurationsdatei für einen Host liegt per Default unter\n\n/etc/nginx/sites-available/default\n\nMit dem Editor seiner Wahl lässt sich die Datei bearbeiten. Z.B.\n\nnano /etc/nginx/sites-available/default\n\nUm PFS jetzt zu aktivieren, sind ein paar zusätzliche Parameter in der Konfigurationsdatei erforderlich. Im weiter unten folgenden Ausschnitt einer Konfigurationsdatei wird dies ersichtlich.\n\nssl_protocols : Unterstützte TLS/SSL Versionen\n\nssl_prefer_server_ciphers : Vom Server vorgegebene Cipher verwenden\n\nssl_dhparam : Pfad zum Diffie-Hellman Key\n\nssl_ciphers : Verwendete Cipher. Ohne diese Sektion bzw. mit den falschen Werten ist PFS nicht möglich!\n\nAusschnitt einer nginx Konfigurationdatei:\n\nserver {\nlisten 443 ssl;\nserver_name server.example.com;\n#SSL/PFS settings\nssl on;\nssl_certificate /etc/nginx/certs/cert.pem;\nssl_certificate_key /etc/nginx/certs/cert.key;\nssl_protocols TLSv1 TLSv1.1 TLSv1.2;\nssl_prefer_server_ciphers on;\nssl_dhparam /etc/nginx/certs/dhparam.pem;\nssl_ciphers HIGH:!aNULL:!MD5:!RC4;\n\nUm die Anpassungen scharf zu schalten, muss der Webserver neu gestartet werden:\n\nsystemctl restart nginx.service\n\nWer das Ergebnis jetzt testen möchte, kann dies bei SSL Labs tun. Dort gibt es einen sehr detaillierten Bericht mit den verwendeten Verfahren sowie über die Kompatibilität mit verschiedensten Browsern und Betriebssystemen.\n\nTeilen auf:\n\nPocket LinkedIn Bluesky Threema WhatsApp Telegram",
|
||||
"content_type": "text/html",
|
||||
"query": "Welche TLS-Konfigurationsparameter sind erforderlich, um Perfect Forward Secrecy zu aktivieren?",
|
||||
"language": "de-DE",
|
||||
"round": 2,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.99,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.8240000000000001,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"G1"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschreibt konkrete TLS-Konfigurationsparameter für Nginx, insbesondere die `ssl_ciphers`, `ssl_dhparam` und `ssl_protocols`-Einstellungen, die zur Aktivierung von Perfect Forward Secrecy erforderlich sind. Sie liefert umsetzbare Schritte und ist fachlich verlässlich."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/0281f08987a72b328a2783ca.json
Normal file
25
data/research-evidence/0281f08987a72b328a2783ca.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0282fb302484cdd1ec6fc1e4.json
Normal file
25
data/research-evidence/0282fb302484cdd1ec6fc1e4.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/02fca6c57060644c85090d31.json
Normal file
25
data/research-evidence/02fca6c57060644c85090d31.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:41:41.7289042Z",
|
||||
"content_sha256": "20dd2edad4ce3033e9809aa6e15bf366147fd9f7d9c680c03c879e542722a729",
|
||||
"result": {
|
||||
"title": "Guide to Bluetooth Security | NIST",
|
||||
"url": "https://www.nist.gov/publications/guide-bluetooth-security-2",
|
||||
"snippet": "Abstract Bluetooth wireless technology is an open standard for short-range radio frequency communication used primarily to establish wireless personal area networks (WPANs), and has been integrated into many types of business and consumer devices. This publication provides information on the security capabilities of Bluetooth and gives recommendations to organizations employing Bluetooth ...",
|
||||
"content": "Padgette, J.\n, Bahr, J.\n, Batra, M.\n, Smithbey, R.\n, Chen, L.\nand Scarfone, K.\n\n(2022),\nGuide to Bluetooth Security, Special Publication (NIST SP), National Institute of Standards and Technology, Gaithersburg, MD, [online], https://doi.org/10.6028/NIST.SP.800-121r2-upd1, https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=934038 (Accessed August 6, 2026)\n\nAdditional citation formats\n\nDOI\n\nGoogle Scholar\n\nBibTeX\n\nRIS",
|
||||
"content_type": "text/html",
|
||||
"query": "How can security measures such as Default-Deny and segmentation be implemented in the context of Bluetooth Security?",
|
||||
"language": "en-US",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.8444444444444444,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.99,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"G1"
|
||||
],
|
||||
"assessment_reason": "Die Quelle ist eine offizielle NIST-Publikation, die direkt auf Sicherheitsmaßnahmen wie Default-Deny und Segmentierung im Kontext von Bluetooth-Security eingehen. Sie bietet konkrete Empfehlungen und technische Schritte zur Implementierung dieser Maßnahmen, was den konkreten Schritten-Expectations-Kontext erfüllt."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/04cc85331b6fa0bd5f82fb94.json
Normal file
25
data/research-evidence/04cc85331b6fa0bd5f82fb94.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:10:05.4413224Z",
|
||||
"content_sha256": "ef408d889fc18816a55ddb3802236b1f55b9864874dd7e1426411d41f1b24269",
|
||||
"result": {
|
||||
"title": "Digitale Beweissicherung im Verbraucherschutz: Eine DLT-basierte Lösung mit Crowd-Verifikation | HMD Praxis der Wirtschaftsinformatik | Springer Nature Link",
|
||||
"url": "https://link.springer.com/article/10.1365/s40702-026-01249-0?code=edf0053e-0b43-4c87-aa11-0a52c312f7d9\u0026error=cookies_not_supported",
|
||||
"snippet": "Im Zentrum steht die Nutzung einer Konsortial-Blockchain, in die Beweisdaten mitsamt Hashwerten und Zeitstempeln eingetragen werden, um Authentizität und Integrität sicherzustellen.",
|
||||
"content": "Digitale Beweissicherung im Verbraucherschutz: Eine DLT-basierte Lösung mit Crowd-Verifikation\n\nDigital Evidence Preservation in Consumer Protection: A DLT-Based Solution with Crowd Verification\n\nSchwerpunkt\n\nOpen access\n\nPublished: 23 February 2026\n\nVolume 63 , pages 488–508 ( 2026 )\n\nCite this article\n\nYou have full access to this open access article\n\nDownload PDF\n\nSave article\n\nView saved research\n\nHMD Praxis der Wirtschaftsinformatik\n\nAims and scope\n\nSubmit manuscript\n\nDigitale Beweissicherung im Verbraucherschutz: Eine DLT-basierte Lösung mit Crowd-Verifikation\n\nDownload PDF\n\nZusammenfassung\n\nVerbraucherschutzorganisationen stehen im digitalen Raum zunehmend vor der Herausforderung, Rechtsverstöße gerichtsfest zu dokumentieren. Manipulative Online-Inhalte, unvollständige oder falsche Angaben sowie irreführende Werbung sind flüchtig, leicht veränderbar und daher nur schwer beweiskräftig zu sichern. Herkömmliche Verfahren wie Screenshots sind unzureichend, da sie durch Bildbearbeitung oder minimale Änderungen im Quelltext leicht manipuliert werden können. In diesem Beitrag wird ein hybrides technisches System vorgestellt, das eine zuverlässige und manipulationssichere Beweissicherung solcher Verstöße ermöglicht. Der Ansatz kombiniert Distributed-Ledger-Technologie (DLT) zur Integritätssicherung der erfassten Daten mit einer verifizierenden Crowd-Absicherung durch Fachpersonal der Verbraucherzentralen. Die Lösung erlaubt es, erkannte Rechtsverstöße automatisiert zu erfassen, indem ein Hashwert des Webseiteninhalts erzeugt und zusammen mit Metadaten und Zeitstempel in einem DLT-System unveränderbar gespeichert wird. Ergänzend bestätigen Arbeitsplatzrechner von Verbraucherschutzmitarbeitenden durch ein automatisiertes paralleles Vorgehen die Existenz der Verstöße, ohne dass aktives Eingreifen erforderlich ist. Dieses Verfahren stärkt den Beweiswert, erhöht die Widerstandsfähigkeit gegen Manipulation und ermöglicht es, nachgelagerte Veränderungen oder Löschungen gerichtsfest nachzuweisen.\n\nAbstract\n\nConsumer protection organizations increasingly face the challenge of providing legally valid evidence of violations in the digital sphere. Manipulative online content, incomplete or false information, and misleading advertising are often ephemeral, easily altered, and therefore difficult to preserve in a legally robust way. Conventional approaches such as screenshots are insufficient, as they can be manipulated through image editing or minimal changes to the source code. This paper presents a hybrid technical system that enables reliable and tamper-proof evidence preservation of such violations. The approach combines distributed ledger technology (DLT) to ensure data integrity with a verifying crowd-based safeguard operated by consumer protection staff. The solution allows recognized violations to be documented automatically by generating a hash of the web content, which is then stored together with metadata and a timestamp in a DLT system in an immutable manner. In addition, workstations of consumer protection employees confirm automatically the existence of the violation through parallel background captures, without requiring active user interaction. This procedure strengthens the evidential value, increases resilience against manipulation, and enables providers’ subsequent modifications or deletions to be legally demonstrated.\n\nSimilar content being viewed by others\n\nGerichtsfeste Beweissicherung im Daten- und Verbraucherschutz\n\nArticle\n\n30 March 2026",
|
||||
"content_type": "text/html",
|
||||
"query": "Wie wird die Dokumentation von Hashwerten, Zeitstempeln und forensischen Integritätserklärungen für digitale Beweismittel in der Praxis umgesetzt?",
|
||||
"language": "de-DE",
|
||||
"round": 2,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.9127272727272728,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.8240000000000001,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"GAP-002"
|
||||
],
|
||||
"assessment_reason": "Wiederverwendete semantisch äquivalente Recherche: Die Quelle beschreibt eine konkrete Praxis der Dokumentation von Hashwerten, Zeitstempeln und forensischen Integritätserklärungen im Kontext der digitalen Beweissicherung. Sie erläutert, wie DLT-Technologie und Crowd-Verifikation genutzt werden, um Beweise zu sichern, und gibt detaillierte Schritte zur Erstellung von Hashwerten, Zeitstempeln und der Speicherung in DLT-Systemen. Die Quelle ist fachlich relevant und bietet umsetzbare Schritte."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/06157a2d43dec3230e19c0d5.json
Normal file
25
data/research-evidence/06157a2d43dec3230e19c0d5.json
Normal file
File diff suppressed because one or more lines are too long
24
data/research-evidence/067c0ce7582ba311d065b694.json
Normal file
24
data/research-evidence/067c0ce7582ba311d065b694.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/076b371a9f5490e73a4faf29.json
Normal file
25
data/research-evidence/076b371a9f5490e73a4faf29.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/084e37e8154d35ad3a535054.json
Normal file
25
data/research-evidence/084e37e8154d35ad3a535054.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0a7547bf897fc216b6f069e9.json
Normal file
25
data/research-evidence/0a7547bf897fc216b6f069e9.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0b6377da0c266529721672c4.json
Normal file
25
data/research-evidence/0b6377da0c266529721672c4.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0b872963d5914b685ad8cee1.json
Normal file
25
data/research-evidence/0b872963d5914b685ad8cee1.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0c3c7269eade4903c061ad4d.json
Normal file
25
data/research-evidence/0c3c7269eade4903c061ad4d.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0e76c27c13f46d30cd40ad5e.json
Normal file
25
data/research-evidence/0e76c27c13f46d30cd40ad5e.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0e874041e0ce541bc34a1304.json
Normal file
25
data/research-evidence/0e874041e0ce541bc34a1304.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0ee9c6cbd804ab8b8dae060f.json
Normal file
25
data/research-evidence/0ee9c6cbd804ab8b8dae060f.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0f8b32064fe84bd968e7661a.json
Normal file
25
data/research-evidence/0f8b32064fe84bd968e7661a.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0fc51b45a057024ee08b11c7.json
Normal file
25
data/research-evidence/0fc51b45a057024ee08b11c7.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/0ff90d734b993429fa8f5776.json
Normal file
25
data/research-evidence/0ff90d734b993429fa8f5776.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1096bfc46a2444762b466a43.json
Normal file
25
data/research-evidence/1096bfc46a2444762b466a43.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/10e37f8cd6eef3841094fa4e.json
Normal file
25
data/research-evidence/10e37f8cd6eef3841094fa4e.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1199ff8f9d4b8817040e65c1.json
Normal file
25
data/research-evidence/1199ff8f9d4b8817040e65c1.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:36:29.3491457Z",
|
||||
"content_sha256": "5ea89e06f9036c3014f2fb0e321ae59ab4f989f3face03f9a8472f06789d5e59",
|
||||
"result": {
|
||||
"title": "What is Digital Evidence Preservation in Cybersecurity? - Hexnode Blogs",
|
||||
"url": "https://www.hexnode.com/blogs/explained/what-is-digital-evidence-preservation-in-cybersecurity/",
|
||||
"snippet": "Evidence preservation in cybersecurity is the process of collecting, protecting, and maintaining digital data in its original state so investigators can analyze security incidents without compromising its integrity. It ensures that logs, system records, files, network data, and other artifacts remain admissible and trustworthy throughout an investigation. Organizations rely on preserved ...",
|
||||
"content": "What is Digital Evidence Preservation in Cybersecurity? - Hexnode Blogs\n\nSubscribe to Hexnode Blog\n\nGet fresh insights, pro tips, and thought starters–only the best of posts for you.\n\nCybersecurity 101 What is Digital Evidence Preservation in Cybersecurity?\n\nBack\n\nWhat is Digital Evidence Preservation in Cybersecurity?\n\nEvidence preservation in cybersecurity is the process of collecting, protecting, and maintaining digital data in its original state so investigators can analyze security incidents without compromising its integrity . It ensures that logs, system records, files, network data, and other artifacts remain admissible and trustworthy throughout an investigation.\n\nOrganizations rely on preserved evidence to determine the root cause of cyberattacks, support legal proceedings, meet regulatory requirements, and improve future security controls. Consequently, improper handling can lead to data contamination, lost insights, and weakened incident response outcomes.\n\nWhy is Evidence Preservation Important?\n\nWhen a security incident occurs, investigators need accurate and untampered information to reconstruct events. However, digital data can change quickly due to user activity, automated processes, or system reboots. Therefore, preserving evidence as early as possible is critical.\n\nEffective digital evidence preservation helps organizations:\n\nEstablish a reliable timeline of events.\n\nSupport internal investigations and forensic analysis.\n\nMeet compliance and regulatory obligations.\n\nStrengthen legal defensibility if litigation arises.\n\nImprove incident response and post-incident reporting.\n\nMoreover, maintaining evidence integrity builds confidence in investigation findings and reduces the risk of disputed conclusions.\n\nKey Principles of Digital Evidence Preservation\n\nSecurity teams should follow established forensic best practices when handling evidence.\n\nPrinciple\n\nPurpose\n\nIntegrity\n\nEnsure evidence remains unchanged from its original state.\n\nChain of custody\n\nDocument who collected, accessed, transferred, or analyzed evidence.\n\nDocumentation\n\nRecord collection methods, timestamps, and actions taken.\n\nSecure storage\n\nProtect evidence from unauthorized access or modification.\n\nRepeatability\n\nAllow investigators to reproduce findings using the same evidence.\n\nCommon Types of Digital Evidence\n\nOrganizations may preserve several forms of evidence during an incident, including:\n\nSystem and security logs\n\nEndpoint data and device artifacts\n\nMemory captures (RAM dumps)\n\nNetwork traffic records\n\nEmail communications\n\nAuthentication and access records\n\nCloud service activity logs\n\nBecause each data source provides different context, investigators often combine multiple evidence types to gain a complete picture of an attack.\n\nHow UEM Supports Evidence Preservation\n\nModern Unified Endpoint Management (UEM) platforms help security teams maintain visibility across distributed endpoints. For example, Hexnode enables organizations to centrally manage devices, enforce security policies, and maintain endpoint visibility across diverse environments.\n\nAs a result, security teams can quickly identify affected devices, support incident investigations, and access critical endpoint information needed during response and forensic workflows.\n\nFAQs\n\nCan encrypted data be used as digital evidence?\n\nYes. Investigators can preserve encrypted files, disks, or communications as evidence. Even if the content is inaccessible initially, the encrypted data itself may provide valuable forensic context.\n\nHow long should organizations retain cybersecurity evidence?\n\nRetention periods vary based on legal, regulatory, contractual, and business requirements. Organizations should align evidence retention policies with applicable compliance frameworks and internal governance standards.\n\nDoes cloud infrastructure create new evidence preservation challenges?\n\nYes. Cloud environments often generate evidence across multiple services, regions, and providers. Therefore, organizations need clear logging, retention, and access policies to ensure relevant data remains available during investigations.\n\nRelated Queries\n\nWhat is Indicators matching?\n\nWhat is Human Risk Management (HRM)?\n\nWhat is Federated learning?\n\nWhat is a Forensics service?\n\nWhat is Fake Update attack?\n\nWhat is an Exposure management service?\n\nJoin readers from 120 countries\n\nClick to Copy\n\nThis website uses cookies. By continuing to browse this website, you are agreeing to our use of cookies. See our Cookie policy for more information.\n\nI Accept",
|
||||
"content_type": "text/html",
|
||||
"query": "What role do digital evidence play in IT security regarding the preservation and traceability of incidents?",
|
||||
"language": "en-US",
|
||||
"round": 3,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.9511111111111111,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.904,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"G2"
|
||||
],
|
||||
"assessment_reason": "The article directly addresses the role of digital evidence in IT security, specifically regarding preservation and traceability of incidents. It explains how digital evidence is collected, protected, and maintained to ensure its integrity and admissibility in investigations. It also outlines the importance of evidence preservation for legal, regulatory, and incident response purposes. The content is relevant to the question and provides actionable steps for preserving digital evidence."
|
||||
}
|
||||
}
|
||||
24
data/research-evidence/13315685606f9a2de354a493.json
Normal file
24
data/research-evidence/13315685606f9a2de354a493.json
Normal file
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:21:09.1556305Z",
|
||||
"content_sha256": "b5b5109532c1b365edd43ec1db37b772a4ea29c9c08d82426014448fdca04a5c",
|
||||
"result": {
|
||||
"title": "BSI - Elektronische Signaturen, Siegel und Zeitstempel",
|
||||
"url": "https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/eIDAS-Verordnung/Elektronische-Signaturen-Siegel-und-Zeitstempel/elektronische-signaturen-siegel-und-zeitstempel_node.html",
|
||||
"snippet": "Die Verwendung elektronischer Signaturen und Zeitstempel war bisher durch die Signaturrichtlinie geregelt, die in Deutschland seit 2001 mit Signaturgesetz und Signaturverordnung umgesetzt wurde.",
|
||||
"content": "Elektronische Signaturen, Siegel und Zeitstempel\n\nDie Verwendung elektronischer Signaturen und Zeitstempel war bisher durch die Signaturrichtlinie geregelt, die in Deutschland seit 2001 mit Signaturgesetz und Signaturverordnung umgesetzt wurde. Das BSI ist als anerkannte Bestätigungsstelle verantwortlich für die Bestätigung von Produkten (Signaturerstellungseinheiten, Signaturanwendungskomponenten, Terminals und Chipkartenleser) nach dem Signaturgesetz. Um die Sicherheit und Zuverlässigkeit qualifizierter elektronischer Signaturen sicherzustellen, erarbeitet das BSI zudem seit 2004 jährlich eine Übersicht über die Eignung von Algorithmen nach dem Signaturgesetz, den sogenannten \" Algorithmenkatalog \". Mit Einführung der eIDAS-Verordnung wurde die Signaturrichtlinie aufgehoben; das Signaturgesetz wurde durch das Vertrauensdienstegesetz abgelöst, das am 29.07.2017 in Kraft getreten ist. Auch die Signaturverordnung trat zum 29.07.2017 außer Kraft.\n\nAls neuen Dienst führt die eIDAS-Verordnung die elektronischen Siegel ein. Technisch sind diese vergleichbar mit den elektronischen Signaturen. Der wesentliche Unterschied ist die Zuordnung zu einer juristischen anstatt einer natürlichen Person. Während mit elektronischen Signaturen eine Willenserklärung abgegeben werden kann, dient das elektronische Siegel einer Institution als Herkunftsnachweis: Es kann überall dort eingesetzt werden, wo eine persönliche Unterschrift nicht notwendig, aber der Nachweis der Authentizität gewünscht ist (z. B. bei amtlichen Bescheiden, Urkunden, Kontoauszügen etc.).\n\nEine Zertifizierung nach der Technischen Richtlinie BSI TR-03145 erfüllt die technischen und organisatorischen Sicherheitsanforderungen der eIDAS-Verordnung für qualifizierte Signatur- und Siegelzertifikate.\n\nWebsite Authentication, Electronic Signatures and Electronic Seals fulfilling the eIDAS requirements for providers of qualified certificates with BSI Technical Guidelines\n\nSignatur- und Siegelerstellungseinheiten\n\nZur sicheren Speicherung der für die Signatur-/Siegelerstellung notwendigen kryptographischen Schlüssel werden qualifizierte Signatur/Siegelerstellungseinheiten eingesetzt, kurz QSEEs. Dies entspricht der sicheren Signaturerstellungseinheit nach der bisherigen Signaturgesetzgebung.\n\nGemäß der eIDAS-Verordnung müssen QSEEs nach Common Criteria zertifiziert werden. Eine Liste der zugehörigen Protection Profiles wurde in einem Durchführungsrechtsakt festgelegt. Eine Liste der zertifizierten Produkte findet sich hier.\n\nÄhnliche Themen\n\nElektronische Identifizierung\n\nInteroperabilität\n\nVertrauensdienste\n\nZustellung elektronischer Einschreiben\n\nWebseiten-Zertifikate\n\nBewahrungsdienste\n\nAufsichtsstelle\n\nQualifizierung als Vertrauensdiensteanbieter\n\nZurück zu eIDAS Verordnung\n\nKurz-URL:\n\nhttps://www.bsi.bund.de/dok/7831046",
|
||||
"content_type": "text/html",
|
||||
"query": "Welche offiziellen Richtlinien oder Standards existieren für die Erstellung und Dokumentation von Hash-Werten, Zeitstempeln und forensischen Integritätsaussagen in digitalen Ermittlungen?",
|
||||
"language": "de-DE",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.576,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.9100000000000001,
|
||||
"covered_gap_ids": [
|
||||
"GAP-002"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschäftigt sich mit elektronischen Signaturen, Siegeln und Zeitstempeln, die relevant sind für die Erstellung und Dokumentation von Hash-Werten und Zeitstempeln. Sie erwähnt auch die eIDAS-Verordnung und die Technische Richtlinie BSI TR-03145, die für qualifizierte Signatur- und Siegelzertifikate gelten. Dies ist eine relevante Teilabdeckung der Wissenslücke, da es um offizielle Richtlinien und Standards geht, die für die forensische Integritätsaussage relevant sind. Allerdings fehlen konkrete Schritte zur Dokumentation von Hash-Werten und forensischen Integritätsaussagen."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/13865418476ec40346703924.json
Normal file
25
data/research-evidence/13865418476ec40346703924.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/161d9f55b1cecd9c437dbd22.json
Normal file
25
data/research-evidence/161d9f55b1cecd9c437dbd22.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/16b4463988f6661d53a1fb3d.json
Normal file
25
data/research-evidence/16b4463988f6661d53a1fb3d.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/18843e5f5f68df76f13d2726.json
Normal file
25
data/research-evidence/18843e5f5f68df76f13d2726.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/190b36001cc68bcd8324296d.json
Normal file
25
data/research-evidence/190b36001cc68bcd8324296d.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:41:06.7879206Z",
|
||||
"content_sha256": "b40b80c761784ea46b1a0b567c73ed3b000399e51ca00449725a492c2c169059",
|
||||
"result": {
|
||||
"title": "Security und Privacy von Bluetooth Low Energy",
|
||||
"url": "https://www.cybersicherheit.fraunhofer.de/de/unsere-kurswelt/sichere-infrastruktur/security-und-privacy-von-bluetooth-low-energy.html",
|
||||
"snippet": "Dieses Seminar vermittelt, wie Sie Gefahren im BLE-Protokoll erkennen und Sicherheits- sowie Datenschutzaspekte frühzeitig einbinden. Sie lernen verschiedene Methoden kennen, bewerten ihre Sicherheit und wenden Ihr Wissen in praktischen Übungen an.",
|
||||
"content": "Bluetooth Low Energy (BLE) ist ein zentraler Bestandteil des Internet of Things (IoT) und ermöglicht die energieeffiziente Vernetzung zahlreicher Geräte. Diese weite Verbreitung macht BLE jedoch zu einem attraktiven Ziel für Angreifer, insbesondere da in der Grundkonfiguration oft Schutzmechanismen fehlen. Daher ist es essenziell, potenzielle Schwachstellen im BLE-Protokoll zu kennen und Sicherheits- sowie Datenschutzaspekte bereits bei der Konzeption von BLE-Anwendungen zu berücksichtigen.\n\nDas Seminar beginnt mit einer kurzen Wiederholung der BLE-Grundlagen, gefolgt von einer Betrachtung der Trackingmöglichkeiten von BLE-Geräten und deren Verhinderung durch privatsphärenfreundliche Konfigurationen. Da die Pairing-Methoden einer der größten Angriffsflächen im BLE-Protokoll darstellen, werden diese im Detail betrachtet und hinsichtlich ihrer Sicherheit bewertet. Ein praktisches Training auf bereitgestellten virtuellen Maschinen ermöglicht es den Teilnehmern, das theoretische Wissen direkt anzuwenden.\n\nAm zweiten Live-Tag werden weitere relevante und veröffentlichte Schwachstellen im BLE-Protokoll vorgestellt . Es wird demonstriert, wie Angriffe wie Sniffing, Man-in-the-Middle (MITM) und Hijacking im BLE-Kontext durchgeführt werden können. Abschließend erhalten die Teilnehmer Best-Practice-Empfehlungen für die Konzeption sicherer BLE-Applikationen.\n\nIm Vorfeld der beiden Live-Tage werden vorbereitend zwei e-Learning Module angeboten, die Grundlagen zur sicheren Kommunikation bieten und den Einstieg in die Live-Tage anhand einer kleinen Hacker-Story anschaulicher gestaltet.\n\nNach dem Seminar können Sie:\n\nPairing-Methoden von BLE hinsichtlich ihrer Sicherheit bewerten.\n\nAktuelle Schwachstellen im BLE-Protokoll erkennen und deren Risiken einschätzen.\n\nDie Auswirkungen von Privacy-Einstellungen auf die Sicherheit von BLE-Anwendungen verstehen.",
|
||||
"content_type": "text/html",
|
||||
"query": "Wie können Sicherheitsmaßnahmen wie Default-Deny und Segmentierung im Kontext von Bluetooth-Security konkret implementiert werden?",
|
||||
"language": "de-DE",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.6599999999999999,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.7440000000000001,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"G1"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschäftigt sich direkt mit Bluetooth Low Energy (BLE) und Sicherheitsaspekten, aber nicht mit konkreten Implementierungsschritten für Default-Deny oder Segmentierung. Es fehlen explizite Anleitungen zur Umsetzung."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/19339e1d16516841caea7094.json
Normal file
25
data/research-evidence/19339e1d16516841caea7094.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/195f21b4354f96bbac36859f.json
Normal file
25
data/research-evidence/195f21b4354f96bbac36859f.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/196df6c31a7b090c4195be32.json
Normal file
25
data/research-evidence/196df6c31a7b090c4195be32.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1a2d647bde91e51b0fc42bbf.json
Normal file
25
data/research-evidence/1a2d647bde91e51b0fc42bbf.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1ae10cc7e528b99f719b317d.json
Normal file
25
data/research-evidence/1ae10cc7e528b99f719b317d.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:03:55.7637044Z",
|
||||
"content_sha256": "cc6404c1b96b62d6f1fb2679abc6c89bc4297e2cab659b0dcefb4fb70a0c260d",
|
||||
"result": {
|
||||
"title": "Sicherstellung von Beweismitteln",
|
||||
"url": "https://fastextract.de/sicherstellung-von-beweismitteln/",
|
||||
"snippet": "Bei Ermittlungen in Cybercrime-, Betrugs- oder Missbrauchsfällen sichern wir digitale Beweise gerichtsfest und unter Berücksichtigung der Chain of Custody. Unsere Expert:innen unterstützen zuverlässig bei Durchsuchungen, Sicherstellungen und IT-forensischen Auswertungen.",
|
||||
"content": "Sichere IT‑Forensische Beweissicherung\n\nIT-Forensische Beweissicherung nach Dekra Standard\n\nSchnell. Diskret. Zuverlässig.\n\nSichere IT‑Forensische Beweissicherung vor Ort\n\nFast Extract bietet professionelle Unterstützung bei der Sicherstellung digitaler Beweismittel – ob vor Ort in Unternehmen oder für Strafverfolgungsbehörden. Mit modernsten Tools und klar dokumentierten Prozessen stellen wir sicher, dass jede Datenträgerübernahme gerichtsfest und revisionssicher erfolgt\n\nUmfangreiches Beweis‑Assessment \u0026 Geräte‑Inventarisierung\n\nWir führen eine Bestandsaufnahme aller relevanten IT-Komponenten durch:\n\nIdentifikation von Endgeräten, Servern, Smartphones, NAS, E-Mail-Systemen etc.\n\nAuswahl relevanter Datenquellen und Eingrenzung auf fallrelevante Zeiträume\n\nErstellung einer Strategie für Live-/Post-Mortem-Images\n\nTermin vereinbaren\n\nForensisches Imaging \u0026 Hash-verifizierte Duplikate\n\nErstellung bit-genauer, forensischer Kopien (Images) mit Writeblockern\n\nVerwendung kryptografischer Prüfsummen (Hashwerte) zur Beweismittelintegrität.\n\nAuswahl passender Methoden: Live- oder Post-Mortem-Imaging je nach Situation .\n\nTermin vereinbaren\n\nWiederherstellung gelöschter oder versteckter Daten\n\nRekonstruktion gelöschter Dateien, versteckte Partitionen, Metadaten\n\nSuche nach Cloud‑Inhalten, Browser-Chroniken, Logs, Systemspuren\n\nTermin vereinbaren\n\nLückenlose Dokumentation \u0026 Chain of Custody\n\nJeder Schritt wird revisionssicher dokumentiert:\n\nProtokolle zu Aufnahme, Transport, Lagerung\n\nDokumentierte Beweismittelkette für juristische Nachvollziehbarkeit\n\nDatenschutzkonforme Handhabung durchgängig gesichert\n\nTermin vereinbaren\n\nGerichtsfeste Übergabe \u0026 IT‑Forensik‑Gutachten\n\nÜbergabe der Datenträger in prüfungssicherer Form\n\nAuf Wunsch: Erstellung gerichtsfester Gutachten mit methodischer Klarheit, Bewertung und Handlungsempfehlungen\n\nMehr erfahren\n\nFür wen ist unser Service geeignet?\n\nStrafverfolgungsbehörden \u0026 Staatsanwaltschaften\n\nBei Ermittlungen in Cybercrime-, Betrugs- oder Missbrauchsfällen sichern wir digitale Beweise gerichtsfest und unter Berücksichtigung der Chain of Custody. Unsere Expert:innen unterstützen zuverlässig bei Durchsuchungen, Sicherstellungen und IT-forensischen Auswertungen.\n\nUnternehmen \u0026 Konzerne\n\nOb bei Verdacht auf Datenklau, internen Betrug oder Compliance-Verstöße – wir sichern digitale Spuren rechtssicher, diskret und ohne Betriebsunterbrechung. Auf Wunsch auch mit Soforteinsatz vor Ort.\n\nRechtsanwaltskanzleien\n\nWir unterstützen Kanzleien bei zivil- und strafrechtlichen Verfahren mit gerichtlich verwertbaren IT-Gutachten und der forensisch korrekten Sicherung relevanter Beweismittel – vom Smartphone bis zum Unternehmensserver.\n\nIT-Sicherheitsbeauftragte \u0026 Datenschutzbeauftragte\n\nBei DSGVO-Vorfällen, Datenpannen oder internen Verdachtsfällen dokumentieren und sichern wir digitale Beweise lückenlos und datenschutzkonform – als Grundlage für weitere Maßnahmen oder Meldungen an Behörden.\n\nIhre Vorteile bei Fast Extract\n\nVollumfängliche Dienstleistungen von Erstbewertung bis Gutachten\n\nTechnisch ausgereifte Methoden: Imaging, Datenrettung, Analyse\n\nRückverfolgbare Chain of Custody und Datenschutzkonformität\n\nFlexible, sofort verfügbare Expert:innen für kritische Fälle.\n\nJetzt Kontakt aufnehmen!\n\nKontakt\n\nSicherstellung von Beweismitteln?Wir helfen.\n\nKontakt\n\ninfo@fastextract.de\n\nFast Extract\nDürener Str. 44\n52393 Hürtgenwald",
|
||||
"content_type": "text/html",
|
||||
"query": "Wie wird die Authentifizierung von Beweismitteln mit Zeitstempel und Hash-Prüfsumme in forensischen Ermittlungen implementiert?",
|
||||
"language": "de-DE",
|
||||
"round": 3,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.9066666666666667,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.864,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"KG-003"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschreibt explizit die Sicherstellung von Beweismitteln mit Hash-Prüfsummen und forensischem Imaging. Sie erläutert die Schritte zur Erstellung von forensischen Images, die Verwendung von Hashwerten zur Integritätssicherung und die Dokumentation der Chain of Custody. Dies ist direkt relevant für die konkrete Frage und enthält umsetzbare Schritte."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/1aeba0d1bfb7bbc9b3ee139f.json
Normal file
25
data/research-evidence/1aeba0d1bfb7bbc9b3ee139f.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1baf5e65b7ab7970b378af45.json
Normal file
25
data/research-evidence/1baf5e65b7ab7970b378af45.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1c9a06a88c5f16594a719b44.json
Normal file
25
data/research-evidence/1c9a06a88c5f16594a719b44.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1da19dbc971f9ad02f30d8c8.json
Normal file
25
data/research-evidence/1da19dbc971f9ad02f30d8c8.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1e1608d7d13cb1960a9a4733.json
Normal file
25
data/research-evidence/1e1608d7d13cb1960a9a4733.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1ec605304776793f26808a8e.json
Normal file
25
data/research-evidence/1ec605304776793f26808a8e.json
Normal file
File diff suppressed because one or more lines are too long
26
data/research-evidence/1eccb9ff9cacb60f3c7d2e87.json
Normal file
26
data/research-evidence/1eccb9ff9cacb60f3c7d2e87.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/1ef9d75e3d7211edc610a7bf.json
Normal file
25
data/research-evidence/1ef9d75e3d7211edc610a7bf.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:08:56.8990994Z",
|
||||
"content_sha256": "ef192baaf4f259e723994f4698476150728508fc29eff17a5108a33a99232d08",
|
||||
"result": {
|
||||
"title": "BSI - Elektronische Signatur Signaturanwendung - Signaturanwendung",
|
||||
"url": "https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/ElektronischeSignatur/Signaturanwendungen/siganwerzeugung.html",
|
||||
"snippet": "In der Praxis werden dafür meist Chipkarten mit integriertem Mikroprozessor (Smart Cards) oder USB - Token eingesetzt. Bei Anwendungen, die eine hohe Performance erfordern, kommen auch spezialisierte Hardware Security Module zum Einsatz.",
|
||||
"content": "Signaturanwendung\n\nKapitel 4.1 \"Signaturerzeugung\" der Broschüre Grundlagen der elektronischen Signatur\n\n4.1 Signaturerzeugung\n\nDie Erzeugung einer digitalen Signatur umfasst drei Berechnungs-Schritte:\n\nHashing\n\nDas zu signierende Dokument wird durch eine kryptographische Hash funktion auf einen Hash wert fester Länge gebracht.\n\nPadding\n\nDer Bitstring mit dem Hash wert wird in geeigneter Weise auf die für das Signaturverfahren und den Signaturschlüssel notwendige Länge aufgefüllt.\n\nSignatur\n\nDer aufgefüllte Bitstring wird je nach Signaturalgorithmus ( vgl. Abschnitt 3.1.3 ) mit dem privaten Signaturschlüssel zu einer Signatur verknüpft.\n\nNur im dritten Schritt werden geheime Informationen verarbeitet: Der private Schlüssel und ggf. auch geheime Zufallszahlen, die in die Signatur mit eingehen. Diese Berechnungen sollten daher in einer Umgebung erfolgen, die gegen Abhören durch Dritte gesichert ist. Idealerweise wird der private Signaturschlüssel ausschließlich in einer speziellen Hardware , der Signaturerstellungseinheit , gespeichert und angewendet, die ein Auslesen wirksam verhindert. In der Praxis werden dafür meist Chipkarten mit integriertem Mikroprozessor ( Smart Cards ) oder USB - Token eingesetzt. Bei Anwendungen, die eine hohe Performance erfordern, kommen auch spezialisierte Hardware Security Module zum Einsatz. Moderne Chipkarten und USB- Token können auch zufällige Signaturschlüssel-Paare generieren, so dass der private Schlüssel niemals das Gerät verlässt.\n\nIn den ersten beiden Schritten müssen dagegen keine geheimen Informationen geschützt werden. In der Praxis erfolgt die Berechnung des Hash wertes daher auch meist außerhalb der Signaturerstellungseinheit , so dass dieser nur der kurze Hash wert und nicht eine große Nachricht übergeben werden muss. Damit auch wirklich die korrekten Daten signiert werden, muss der gesamte Prozess der Signaturerstellung vor Manipulationen ( z. B. durch Viren oder Trojaner) sicher sein. Dies betrifft nicht nur die Berechnungen zur Erzeugung der digitalen Signatur, sondern auch die Übergabe der zu signierenden Daten und Zwischenergebnisse (z. B. dem Hash wert) zwischen den beteiligten Komponenten. In Fällen, in denen eine elektronische Signatur als Willenserklärung einer Person aufgefasst werden soll, sollte diese die zu signierenden Daten zuvor angezeigt bekommen. Insbesondere bei qualifizierten elektronischen Signaturen , die vom Gesetzgeber der eigenhändigen Unterschrift in den meisten Fällen gleichgestellt worden sind, muss der Ersteller der Signatur sicher sein können, dass er nur das signiert, was er sieht. Dateiformate, die versteckte Informationen (z. B. Kommentare, Meta-Daten, Text mit weißer Schriftfarbe, etc. ) enthalten können, eröffnen Betrügern Tür und Tor und sind daher eher ungeeignet. Wichtig ist aber auch, dass die Signaturanwendungskomponente – die zur Signierung verwendete Software oder Hardware – zuverlässig ( d. h. ohne schwerwiegende Fehler) und vertauenswürdig (d. h. ohne böswillige, versteckte Funktionen) ist. Die gesetzlichen Anforderungen an Signaturanwendungskomponenten sind in Abschnitt 2.1.4 skizziert.\n\nDamit dem Signaturschlüssel-Inhaber keine Nachteile entstehen sollte er dafür Sorge tragen, dass er\n\nseine Signaturerstellungseinheit und die dazugehörige PIN sicher verwahrt,\n\nDokumente nur nach Kenntnisnahme und Prüfung signiert,\n\nseine Signaturen nur mit vertrauenswürdigen Signaturanwendungskomponenten erstellt und\n\nbei Kompromittierung seiner Signaturerstellungseinheit sein Zertifikat umgehend sperren lässt.\n\nIn Anwendungen, in denen qualifizierte elektronische Signaturen in automatisierter Art und Weise erstellt werden (vgl. Abschnitt 4.4 ), existieren besonders hohe Sicherheitsanforderungen. Insbesondere muss sichergestellt sein, dass dem Signaturserver nicht unberechtigt Dokumente zur Signierung untergeschoben werden können.\n\nÄhnliche Themen\n\nRechtl. Rahmenbedingungen\n\nTechnische Realisierung\n\nProdukte\n\nStandards\n\nGlossar\n\nDownload\n\nZurück zu Elektronische Signatur\n\nKurz-URL:\n\nhttps://www.bsi.bund.de/dok/6604468",
|
||||
"content_type": "text/html",
|
||||
"query": "Welche Tools und Verfahren werden in der Praxis verwendet, um Hashwerte, Zeitstempel und forensische Integritätserklärungen für digitale Beweismittel zu erstellen und zu dokumentieren?",
|
||||
"language": "de-DE",
|
||||
"round": 2,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.8445714285714286,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.99,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"GAP-002"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschreibt detailliert die Erzeugung von digitalen Signaturen, die Hashwerte, Zeitstempel und forensische Integritätserklärungen beinhalten. Sie nennt konkrete Tools wie Smart Cards, USB-Token und Hardware Security Modules, sowie Verfahren wie Hashing, Padding und Signaturerzeugung. Die Quelle ist offiziell und bietet umsetzbare Schritte."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/1f5129c514a4d0ba0f46ad05.json
Normal file
25
data/research-evidence/1f5129c514a4d0ba0f46ad05.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/203ccc22925404bf3bd251a9.json
Normal file
25
data/research-evidence/203ccc22925404bf3bd251a9.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/20d0f30ca3f9d1e3536ed232.json
Normal file
25
data/research-evidence/20d0f30ca3f9d1e3536ed232.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/21abb46d82d4983d5f9dfcdf.json
Normal file
25
data/research-evidence/21abb46d82d4983d5f9dfcdf.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/21da67f33635915b59da7996.json
Normal file
25
data/research-evidence/21da67f33635915b59da7996.json
Normal file
File diff suppressed because one or more lines are too long
24
data/research-evidence/22da5a8c9e2b85a2c343c0d7.json
Normal file
24
data/research-evidence/22da5a8c9e2b85a2c343c0d7.json
Normal file
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:13:45.2254738Z",
|
||||
"content_sha256": "04b8ea0d2ab93e0c701aae548052b68f69e7f002220d49d5e5cc83e68975c42c",
|
||||
"result": {
|
||||
"title": "Patellofemorales Schmerzsyndrom | Die Orthopädie | Springer Nature Link",
|
||||
"url": "https://link.springer.com/article/10.1007/s00132-005-0818-5?code=2491161c-65e9-434f-a64c-2a3d35a18f4b\u0026error=cookies_not_supported",
|
||||
"snippet": "Statische Ursachen der Beschwerden (Knick-Senkfuß, Instabilitäten, Beinlängendifferenz) oder Überlastungen des Kniestreckapparats sollten erkannt und behoben werden. Nach Ausschluss einer intraartikulären Pathologie erfolgt die Erstbehandlung konservativ.",
|
||||
"content": "Patellofemorales Schmerzsyndrom\n\nPatellofemoral pain syndrome\n\nLeitthema\n\nPublished: July 2005\n\nVolume 34 , pages 668–676 ( 2005 )\n\nCite this article\n\nSave article\n\nView saved research\n\nDer Orthopäde\n\nAims and scope\n\nSubmit manuscript\n\nZusammenfassung\n\nDas patellofemorale Schmerzsyndrom (PFS) hat eine hohe sozioökonomische Relevanz, da es in der Regel bei jungen arbeitsfähigen Patienten auftritt und es aufgrund der häufig unklaren Ätiologie keine Kausalbehandlung gibt. Zahlreiche Arbeiten haben die verschiedenen möglichen Auslöser patellofemoraler Beschwerden und deren Therapiemöglichkeiten analysiert. Statische Ursachen der Beschwerden (Knick-Senkfuß, Instabilitäten, Beinlängendifferenz) oder Überlastungen des Kniestreckapparats sollten erkannt und behoben werden.\n\nNach Ausschluss einer intraartikulären Pathologie erfolgt die Erstbehandlung konservativ. Eine Dehnung der Streck- und Beugemuskulatur und ein Aufbau des Quadrizepsmuskels stehen hierbei im Vordergrund. Bei persistierenden patellofemoralen Schmerzen gibt es Operationsverfahren zur Rezentrierung der Patella im Gleitlager und Verringerung des patellofemoralen Drucks.\n\nBei Übergewichtigen scheint es zu einer mechanischen Überlastung des Patellofemoralgelenks zu kommen. Als Ursache der daraus resultierenden patellofemoralen Beschwerden muss neben dem erhöhten Knorpelverschleiß eine chronische Überanspruchung der Sehnen und patellastabilisierenden Weichteile angesehen werden.\n\nAbstract\n\nThe patellofemoral pain syndrome is of high socioeconomic relevance as it most frequently occurs in young working patients. As its etiology is often unknown there is no standard treatment protocol. Several studies analyzed the different causes of patellofemoral pain and their different therapies. Static problems (pes planovalgus, instabilities, leg length differences) or chronic overuse of the knee extensor mechanism have to be identified and treated.\n\nAfter exclusion of intra-articular pathologies, the treatment of patellofemoral pain syndrome begins with conservative management. Stretching of the flexor and extensor muscles and training of the quadriceps muscle are the main approaches. If conservative treatment fails and patellofemoral pain persists, there are several surgical procedures for realignment of the patella in the trochlear groove and reduction of the patellofemoral pressure.\n\nOverweight patients exhibit chronic mechanical overuse of the patellofemoral joint. This leads to a higher rate of cartilage degeneration and problems at the inserting tendons and stabilizing tissues.\n\nThis is a preview of subscription content, log in via an institution\n\nto check access.\n\nAccess this article\n\nLog in via an institution\n\nSubscribe and save\n\nSpringer+\n\nfrom €39.99 /Month\n\nStarting from 10 chapters or articles per month\n\nAccess and download chapters and articles from more than 300k books and 2,500 journals\n\nCancel anytime\n\nView plans\n\nBuy Now\n\nPrice includes VAT (Germany)\n\nInstant access to the full article PDF.\n\nInstitutional subscriptions\n\nAbb. 1\n\nAbb. 2\n\nAbb. 3\n\nAbb. 4\n\nAbb. 5\n\nAbb. 6\n\nSimilar content being viewed by others\n\nBiomechanik und Untersuchung des patellofemoralen Gelenks\n\nArticle\n\n04 June 2020",
|
||||
"content_type": "text/html",
|
||||
"query": "Welche Anomalien sind typisch für PFS-Verletzungen?",
|
||||
"language": "de-DE",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.6560000000000001,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.6639999999999999,
|
||||
"covered_gap_ids": [
|
||||
"G2"
|
||||
],
|
||||
"assessment_reason": "Der Text beschreibt typische Anomalien wie Fehlstellungen (Knick-Senkfuß, Beinlängendifferenz), Überlastungen und muskuläre Ungleichgewichte, die zu PFS-Verletzungen führen können. Es wird jedoch keine konkrete, umsetzbare Schritt-für-Schritt-Anleitung gegeben."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/249b7ae9d4b3201e4cdf0cce.json
Normal file
25
data/research-evidence/249b7ae9d4b3201e4cdf0cce.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:09:02.9237833Z",
|
||||
"content_sha256": "25b6b2c1dbff623a08e4d13b5709326c52d7c21c83ad2de5438b4d106f040004",
|
||||
"result": {
|
||||
"title": "How can you implement rate limiting in a GraphQL API - Surfside Media",
|
||||
"url": "https://www.surfsidemedia.in/post/how-can-you-implement-rate-limiting-in-a-graphql-api",
|
||||
"snippet": "How to Implement Rate Limiting The implementation of rate limiting can be done using various strategies. One effective method is to assign a cost to each query based on its complexity and limit the total cost that a client can incur within a specified time frame. Step 1: Define Query Costs Assign costs to different fields in your GraphQL schema.",
|
||||
"content": "GraphQL\n\nHow can you implement rate limiting in a GraphQL API\n\nRate limiting is a crucial aspect of API design that helps prevent abuse and ensures fair usage among clients. In a GraphQL API, where clients can send complex queries, implementing rate limiting can be more challenging than in traditional REST APIs. This guide will walk you through the process of implementing rate limiting in a GraphQL API using a cost-based approach.\n\nWhy Implement Rate Limiting?\n\nThe main reasons for implementing rate limiting in a GraphQL API include:\n\nPreventing Abuse: Rate limiting helps protect your API from excessive requests that could lead to service degradation.\n\nEnsuring Fair Usage: It ensures that all clients have equitable access to the API resources.\n\nImproving Performance: By limiting the number of requests, you can maintain better performance and response times.\n\nHow to Implement Rate Limiting\n\nThe implementation of rate limiting can be done using various strategies. One effective method is to assign a cost to each query based on its complexity and limit the total cost that a client can incur within a specified time frame.\n\nStep 1: Define Query Costs\n\nAssign costs to different fields in your GraphQL schema. For example, you might assign higher costs to fields that return large datasets or perform complex calculations.\n\nStep 2: Create a Middleware for Rate Limiting\n\nYou can create a middleware function that checks the cost of incoming queries and compares it against the allowed limit. Below is a sample implementation using Node.js and Apollo Server.\n\nSample Code for Rate Limiting\n\nconst { ApolloServer, gql } = require('apollo-server');\nconst { createComplexityLimitRule } = require('graphql-validation-complexity');\n// Define your schema\nconst typeDefs = gql`\ntype User {\nid: ID!\nname: String!\nposts: [Post]\ntype Post {\nid: ID!\ntitle: String!\ncontent: String!\ntype Query {\nusers: [User ]\n`;\n// Define your resolvers\nconst resolvers = {\nQuery: {\nusers: () =\u003e {\nreturn [\n{ id: '1', name: 'Alice', posts: [] },\n{ id: '2', name: 'Bob', posts: [] },\n];\n},\n},\n};\n// Rate limiting configuration\nconst RATE_LIMIT = 100; // Maximum cost allowed per hour\nlet requestCount = 0; // Track the number of requests\n// Middleware for rate limiting\nconst rateLimitMiddleware = (resolve, parent, args, context, info) =\u003e {\nconst complexity = calculateQueryComplexity(info); // Function to calculate query complexity\nif (requestCount + complexity \u003e RATE_LIMIT) {\nthrow new Error('Rate limit exceeded. Please try again later.');\nrequestCount += complexity; // Increment the request count\nreturn resolve(parent, args, context, info);\n};\n// Function to calculate query complexity (simplified)\nconst calculateQueryComplexity = (info) =\u003e {\n// Here you would implement logic to calculate the complexity based on the query structure\nreturn 1; // Placeholder for actual complexity calculation\n};\n// Create an instance of ApolloServer\nconst server = new ApolloServer({\ntypeDefs,\nresolvers,\nschemaTransforms: [rateLimitMiddleware], // Apply the rate limit middleware\n});\n// Start the server\nserver.listen().then(({ url }) =\u003e {\nconsole.log(`🚀 Server ready at ${url}`);\n});\n\nStep 3: Testing Rate Limiting\n\nAfter implementing the rate limiting middleware, you can test it by sending queries that exceed the defined cost limit. The server should respond with an error message indicating that the rate limit has been exceeded.\n\nConclusion\n\nImplementing rate limiting in a GraphQL API is essential for maintaining performance and security. By assigning costs to queries and using middleware to enforce limits, you can effectively manage resource usage and prevent abuse. This approach not only protects your API but also ensures a better experience for all users.\n\nWritten by Surfside Media\n\nSenior Full Stack Developer specializing in Web Technologies.\n\nPrevious\n« What is query complexity...\n\nNext Part\nWhat are some strategies... »",
|
||||
"content_type": "text/html",
|
||||
"query": "How can rate limits be implemented in GraphQL servers?",
|
||||
"language": "en-US",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.9733333333333334,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.904,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"KG-001"
|
||||
],
|
||||
"assessment_reason": "The article provides a direct, actionable implementation of rate limiting in a GraphQL API using a cost-based approach. It includes a sample code snippet with a middleware function and a complexity calculation method, which are concrete steps for implementing rate limits."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/2611010e1e2705209bdb07ce.json
Normal file
25
data/research-evidence/2611010e1e2705209bdb07ce.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/26504ebe64be3792810cbcb0.json
Normal file
25
data/research-evidence/26504ebe64be3792810cbcb0.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/276b1186e95f2c6eae85b83a.json
Normal file
25
data/research-evidence/276b1186e95f2c6eae85b83a.json
Normal file
File diff suppressed because one or more lines are too long
24
data/research-evidence/28303fbed5f14330120fedb7.json
Normal file
24
data/research-evidence/28303fbed5f14330120fedb7.json
Normal file
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:46:05.5398577Z",
|
||||
"content_sha256": "76ce00b6caca8bf7b73f96f880b10decc1b74c5a1d2cac74472c4e8d27031a20",
|
||||
"result": {
|
||||
"title": "Updated NIST Guidance for Bluetooth Security | NIST",
|
||||
"url": "https://www.nist.gov/publications/updated-nist-guidance-bluetooth-security",
|
||||
"snippet": "Abstract This bulletin summarizes the information in NIST SP 800-121, Revision 2: Guide to Bluetooth Security which provides information on the security capabilities of Bluetooth and provides recommendations to organizations employing Bluetooth wireless technologies on securing them effectively.",
|
||||
"content": "Chen, L.\n, Feldman, L.\nand Witte, G.\n\n(2017),\nUpdated NIST Guidance for Bluetooth Security, ITL Bulletin, National Institute of Standards and Technology, Gaithersburg, MD, [online], https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=923791 (Accessed August 6, 2026)\n\nAdditional citation formats\n\nGoogle Scholar\n\nBibTeX\n\nRIS",
|
||||
"content_type": "text/html",
|
||||
"query": "How can security policies for Bluetooth connections be configured in an enterprise network to achieve default-deny?",
|
||||
"language": "en-US",
|
||||
"round": 2,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.6,
|
||||
"source_quality": "authoritative",
|
||||
"source_quality_score": 0.8300000000000001,
|
||||
"covered_gap_ids": [
|
||||
"G1"
|
||||
],
|
||||
"assessment_reason": "Die Quelle ist ein NIST-Dokument, das allgemeine Leitlinien für Bluetooth-Sicherheit bietet, aber keine konkreten, umsetzbaren Schritte zur Konfiguration von Sicherheitsrichtlinien in einem Enterprise-Netzwerk. Sie ist relevant, aber nicht direkt umsetzbar."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/285a7c98530f81aede614f6c.json
Normal file
25
data/research-evidence/285a7c98530f81aede614f6c.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/29b843bede394f8d20dcd3b0.json
Normal file
25
data/research-evidence/29b843bede394f8d20dcd3b0.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T04:15:19.708366Z",
|
||||
"content_sha256": "94e25775335ec2366eea7db67a32547c1788bd4f9d24c4b428b2842be1ed51a8",
|
||||
"result": {
|
||||
"title": "Forward Secrecy | Cybersecurity | CodePath Guides",
|
||||
"url": "https://guides.codepath.org/websecurity/Forward-Secrecy",
|
||||
"snippet": "Forward Secrecy Forward secrecy, also known as \"perfect forward secrecy\" (PFS), protects data or communications encrypted in the past against compromises of secret keys or passwords in the future. Without forward secrecy, a patient attacker could capture an encrypted communication, and then obtain the private key for that communication at a later date. With forward secrecy, a stolen ...",
|
||||
"content": "Updated 10 days ago\n\nView on\nGitHub\n\nForward Secrecy\n\nForward secrecy, also known as “perfect forward secrecy” (PFS), protects data or communications encrypted in the past against compromises of secret keys or passwords in the future. Without forward secrecy, a patient attacker could capture an encrypted communication, and then obtain the private key for that communication at a later date. With forward secrecy, a stolen private key or password does not allow decrypting the communication in the future. It remains private. This does not mean that the encryption cannot be broken in other ways, it just prevents the private key from being a weak point.\n\nPublic-key and TLS Forward Secrecy\n\nPublic-key communications can have forward secrecy if they use the Diffie-Hellman technique for key exchange. The client and server use their public and private keys to establish a temporary key (a “shared secret”). Then the temporary key is used to encrypt and decrypt the communication. Once the communication is complete, the temporary key disappears and is forgotten. It is said to be “ephemeral”. Neither the client nor the server’s public or private keys can be used to decrypt the communication—not now, not in the future. An attacker who later obtains the long-term keys would not be able to use them to decrypt a previously captured encrypted message.\n\nTLS uses public keys to establish a connection. Every TLS 1.3 handshake based on certificates provides forward secrecy as a property of the protocol — RFC 8446 removed the static-RSA and static-Diffie-Hellman cipher suites, so “all public-key based key exchange mechanisms now provide forward secrecy”. The documented exceptions are PSK-only handshakes ( §2.2 ) and 0-RTT early data ( §2.3 ), which reuse a pre-shared key and are not forward-secret in the same sense — RFC 8446 §2.3 states of 0-RTT that “this data is not forward secret”. For TLS 1.2 servers, forward secrecy is configuration-dependent: require an ephemeral Diffie-Hellman key exchange (DHE, or preferably the faster ECDHE) and disable any static-RSA cipher suites. TLS 1.2 is the minimum acceptable floor; TLS 1.3 is the current preferred standard.",
|
||||
"content_type": "text/html",
|
||||
"query": "Which protocols and key types are required for Perfect Forward Secrecy?",
|
||||
"language": "en-US",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.9733333333333334,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.896,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"G1"
|
||||
],
|
||||
"assessment_reason": "Wiederverwendete semantisch äquivalente Recherche: Die Quelle erklärt detailliert, welche Protokolle (z.B. TLS 1.3, Diffie-Hellman) und Schlüsseltypen (ephemeral keys) für Perfect Forward Secrecy erforderlich sind. Sie liefert konkrete, umsetzbare Informationen zu den Anforderungen und Implementierungen."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/2a68f592abb3a5b9e6506b20.json
Normal file
25
data/research-evidence/2a68f592abb3a5b9e6506b20.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2aa3d874fec29b607b33cdb4.json
Normal file
25
data/research-evidence/2aa3d874fec29b607b33cdb4.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2ad630a239e98e40dfd6e720.json
Normal file
25
data/research-evidence/2ad630a239e98e40dfd6e720.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2afd5681e7870686627e9439.json
Normal file
25
data/research-evidence/2afd5681e7870686627e9439.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2b1909294469c8f1a75d2977.json
Normal file
25
data/research-evidence/2b1909294469c8f1a75d2977.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2b9a8fe14b82e1a5fd7bdf7e.json
Normal file
25
data/research-evidence/2b9a8fe14b82e1a5fd7bdf7e.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2bb8a6dd683b817b636d08b9.json
Normal file
25
data/research-evidence/2bb8a6dd683b817b636d08b9.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2cb0a8a5c11b131bca63a605.json
Normal file
25
data/research-evidence/2cb0a8a5c11b131bca63a605.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2d4e249effb2914e888e91b3.json
Normal file
25
data/research-evidence/2d4e249effb2914e888e91b3.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2d7365e9d72d03c57d04ccdc.json
Normal file
25
data/research-evidence/2d7365e9d72d03c57d04ccdc.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2ddfd05b94a0574fb622c65b.json
Normal file
25
data/research-evidence/2ddfd05b94a0574fb622c65b.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2e1e8230bca851934ea3ef5e.json
Normal file
25
data/research-evidence/2e1e8230bca851934ea3ef5e.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2eebe4b39f967837128bae3a.json
Normal file
25
data/research-evidence/2eebe4b39f967837128bae3a.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2fce70d93a96623657b10edf.json
Normal file
25
data/research-evidence/2fce70d93a96623657b10edf.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/2fd0324569a83d7009c0d3a9.json
Normal file
25
data/research-evidence/2fd0324569a83d7009c0d3a9.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/30496b2f80a3d3badc1f7ab9.json
Normal file
25
data/research-evidence/30496b2f80a3d3badc1f7ab9.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/311752f5f02fd87149d6b6eb.json
Normal file
25
data/research-evidence/311752f5f02fd87149d6b6eb.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/31836d0f07ceb914e40df653.json
Normal file
25
data/research-evidence/31836d0f07ceb914e40df653.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/32b757b5b3383aa00f15cbf1.json
Normal file
25
data/research-evidence/32b757b5b3383aa00f15cbf1.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/32dbcbdf3e9f24b7d29c5248.json
Normal file
25
data/research-evidence/32dbcbdf3e9f24b7d29c5248.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/3371a0fe01d0f44185518063.json
Normal file
25
data/research-evidence/3371a0fe01d0f44185518063.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/33bea35536cd97e7823eace4.json
Normal file
25
data/research-evidence/33bea35536cd97e7823eace4.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T06:08:09.6676825Z",
|
||||
"content_sha256": "01ea00df6b02236d09832bc93e6f72700103921fc99fd5906cedf03c67cb3db2",
|
||||
"result": {
|
||||
"title": "DNS sinkhole - Wikipedia",
|
||||
"url": "https://en.wikipedia.org/wiki/DNS_sinkhole",
|
||||
"snippet": "DNS Sinkholes are effective at detecting and blocking bots and other malicious traffic. By default, the local hosts file on a computer is checked before DNS servers, and can be used to block sites in the same way.",
|
||||
"content": "From Wikipedia, the free encyclopedia\n\nDNS server that points a domain to bogus internet addresses\n\nThis article needs more citations . Please help improve this article by adding citations to reliable sources . Unsourced material may be challenged and removed .\nFind sources: \"DNS sinkhole\" – news · newspapers · books · scholar · JSTOR ( November 2021 ) ( Learn how and when to remove this message )\n\nA DNS sinkhole , also known as a sinkhole server , Internet sinkhole , or Blackhole DNS [ 1 ] is a Domain Name System (DNS) server that is configured to hand out non-routable addresses for a certain set of domain names . Computers that use the sinkhole fail to access the real site. [ 2 ] The higher up the DNS resolution chain the sinkhole is, the more requests will fail, because of the greater number of lower nameservers that in turn serve a greater number of clients. Some of the larger botnets have been made unusable by top-level domain sinkholes that span the entire Internet. [ 3 ] DNS Sinkholes are effective at detecting and blocking bots and other malicious traffic.\n\nBy default, the local hosts file on a computer is checked before DNS servers, and can be used to block sites in the same way.\n\nApplications\n[ edit ]\n\nSinkholes can be used both constructively, to contain threats such as WannaCry [ 4 ] and Avalanche , [ 5 ] [ 6 ] and destructively, for example disrupting DNS services in a DoS attack. [ clarification needed ]\n\nDNS sinkholing can be used to protect users by intercepting DNS request attempting to connect to known malicious domains and instead returning an IP address of a sinkhole server defined by the DNS sinkhole administrator. [ 7 ] One example of blocking malicious domains is to stop botnets , by interrupting the DNS names the botnet is programmed to use for coordination. [ 8 ] Another use is to block ad serving sites, either using a host's file-based sinkhole [ 9 ] or by locally running a DNS server (e.g., using a Pi-hole ). Local DNS servers effectively block ads for all devices on the network. [ 10 ]\n\nReferences\n[ edit ]\n\n↑ kevross33, pfsense.org (November 22, 2011). \"BlackholeDNS: Anyone tried it with pfsense?\" . Retrieved October 12, 2012 . {{ cite news }} : CS1 maint: deprecated archival service ( link ) CS1 maint: numeric names: authors list ( link )\n\n↑ Kelly Jackson Higgins, sans.org (October 2, 2012). \"DNS Sinkhole - SANS Institute\" . Retrieved October 12, 2012 .\n\n↑ Kelly Jackson Higgins, darkreading.com (October 2, 2012). \"Microsoft Hands Off Nitol Botnet Sinkhole Operation To Chinese CERT\" . Retrieved September 2, 2015 .\n\n↑ Hay Newman, Lily (2017-05-13). \"The WannaCry Ransomware 'Kill Switch' That Saved Untold PCs From Harm\" . Wired . Archived from the original on 2022-06-27 . Retrieved 2022-08-19 .\n\n↑ Symantec Security Response (December 1, 2016). \"Avalanche malware network hit with law enforcement takedown\" . Symantec Connect . Symantec . Retrieved December 3, 2016 .\n\n↑ Europol (December 1, 2016). \" 'Avalanche' network dismantled in international cyber operation\" . europol.europa.eu . Europol . Retrieved December 3, 2016 .\n\n↑ \"DNS Sinkhole\" . ENISA . Retrieved 2022-08-19 .\n\n↑ Hay Newman, Lily (2018-01-02). \"Hacker Lexicon: What Is Sinkholing?\" . Wired . Retrieved 2022-08-19 .\n\n↑ Dan Pollock, someonewhocares.org (October 11, 2012). \"How to make the Internet not suck (as much)\" . Retrieved October 12, 2012 .\n\n↑ \"Turn A Raspberry Pi Into An Ad Blocker With A Single Command\" . Lifehacker Australia . 2015-02-17 . Retrieved 2018-05-06 .\n\nRetrieved from \" https://en.wikipedia.org/w/index.php?title=DNS_sinkhole\u0026oldid=1282773663 \"\n\nCategory :\n\nDomain Name System\n\nHidden categories:\n\nArticles with short description\n\nShort description matches Wikidata\n\nArticles needing additional references from November 2021\n\nAll articles needing additional references\n\nCS1 maint: deprecated archival service\n\nCS1 maint: numeric names: authors list\n\nWikipedia articles needing clarification from August 2021",
|
||||
"content_type": "text/html",
|
||||
"query": "Was ist der präzise Unterschied zwischen DNS Sinkhole und DNS Security im Sicherheitskontext?",
|
||||
"language": "de-DE",
|
||||
"round": 1,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.7466666666666668,
|
||||
"source_quality": "reputable_secondary",
|
||||
"source_quality_score": 0.8560000000000001,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"G1"
|
||||
],
|
||||
"assessment_reason": "Die Wikipedia-Quelle definiert DNS-Sinkhole präzise und beschreibt seine Funktion im Sicherheitskontext. Sie erwähnt auch Anwendungen wie die Blockierung von Botnets und die Sicherung von Nutzern. Zwar wird DNS-Security nicht direkt behandelt, aber die Quelle liefert eine belastbare Definition und Anwendungsbeispiele für DNS-Sinkholes, was für die konkrete Frage relevant ist. Die Quelle ist fachlich verlässlich und bietet konkrete Informationen."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/342f4e92cedb8641d97f47cb.json
Normal file
25
data/research-evidence/342f4e92cedb8641d97f47cb.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/349e9696076a56aae6e9a2ef.json
Normal file
25
data/research-evidence/349e9696076a56aae6e9a2ef.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:03:55.7637044Z",
|
||||
"content_sha256": "cd5dc8d57b1d16ac53e559d6bd40f15767131b31d5294142407e317295607d22",
|
||||
"result": {
|
||||
"title": "BSI - Elektronische Signatur Signaturanwendung",
|
||||
"url": "https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/ElektronischeSignatur/Signaturanwendungen/signaturanwendungen_node.html",
|
||||
"snippet": "In diesem Kapitel werden verschiedene Aspekte der Anwendung der elektronischen Signatur dargestellt. Nach der Erläuterung der Abläufe bei der Erzeugung und Prüfung von elektronischen Signaturen werden die gängigen Signaturformate erklärt.",
|
||||
"content": "4 Signaturanwendung\n\nKapitel 4 \"Signaturanwendung\" der Broschüre Grundlagen der elektronischen Signatur\n\nIn diesem Kapitel werden verschiedene Aspekte der Anwendung der elektronischen Signatur dargestellt. Nach der Erläuterung der Abläufe bei der Erzeugung und Prüfung von elektronischen Signaturen werden die gängigen Signaturformate erklärt. Danach wird auf die Themenbereiche Massensignatur, Zeitstempel, Archivierung von signierten Daten und Code-Signing eingegangen.\n\nWeitere Kapitel:\n\n4.1 Signaturerzeugung\n\n4.2 Signaturprüfung\n\n4.3 Signaturformate\n\n4.4 Massensignatur\n\n4.5 Zeitstempel\n\n4.6 Archivierung von signierten Daten\n\n4.7 Code-Signing\n\nDie vorgenannten \"weiteren Kapitel\" finden Sie als Kapitel 4 in der Broschüre \"Grundlagen der elektronischen Signatur\", die mit Verweis auf aktuelle Standards, wie z.B. EN 319 102-1 , überarbeitet werden.\n\nÄhnliche Themen\n\nRechtl. Rahmenbedingungen\n\nTechnische Realisierung\n\nProdukte\n\nStandards\n\nGlossar\n\nDownload\n\nZurück zu Elektronische Signatur\n\nKurz-URL:\n\nhttps://www.bsi.bund.de/dok/6604468",
|
||||
"content_type": "text/html",
|
||||
"query": "Wie wird die Authentifizierung von Beweismitteln mit Zeitstempel und Hash-Prüfsumme in forensischen Ermittlungen implementiert?",
|
||||
"language": "de-DE",
|
||||
"round": 3,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.8106666666666668,
|
||||
"source_quality": "primary",
|
||||
"source_quality_score": 0.95,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"KG-003"
|
||||
],
|
||||
"assessment_reason": "Die Quelle ist eine Broschüre des BSI und beschreibt die technische Realisierung von Zeitstempeln und elektronischen Signaturen. Sie erwähnt explizit die Anwendung von Zeitstempeln in der Signaturanwendung und verweist auf relevante Standards. Dies ist relevant für die Frage, da sie die technische Umsetzung von Zeitstempeln und Hash-Prüfsummen in der Authentifizierung von Beweismitteln behandelt."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/34e51f2b85ce2ce9931594c4.json
Normal file
25
data/research-evidence/34e51f2b85ce2ce9931594c4.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/35ddd1eb2eb89a6aa69db52e.json
Normal file
25
data/research-evidence/35ddd1eb2eb89a6aa69db52e.json
Normal file
File diff suppressed because one or more lines are too long
26
data/research-evidence/364157dfeebe60a6e77c8a69.json
Normal file
26
data/research-evidence/364157dfeebe60a6e77c8a69.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/38c8dd4d213ad407018a1e1f.json
Normal file
25
data/research-evidence/38c8dd4d213ad407018a1e1f.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/3b3a257b771cdf3509feb668.json
Normal file
25
data/research-evidence/3b3a257b771cdf3509feb668.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/3b969196e107fae5728987cf.json
Normal file
25
data/research-evidence/3b969196e107fae5728987cf.json
Normal file
File diff suppressed because one or more lines are too long
25
data/research-evidence/3c90e928b6df18e5b52b954f.json
Normal file
25
data/research-evidence/3c90e928b6df18e5b52b954f.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"schema_version": 1,
|
||||
"saved_at": "2026-08-07T05:24:35.7383809Z",
|
||||
"content_sha256": "eefa0b5c2c69a8f67049e1cd2808b53d86c306066b6b018f67e68768b3358707",
|
||||
"result": {
|
||||
"title": "Cloud Storage Folder access in buckets - Database - Google Developer forums",
|
||||
"url": "https://discuss.google.dev/t/cloud-storage-folder-access-in-buckets/182855",
|
||||
"snippet": "Hi All, I have a Cloud Storage bucket that contains two folders, each with its own set of files. I need to grant user access to only Folder A while restricting their access to Folder B. What is the best approach to achieving this folder-level access control in Google Cloud Storage? Please help. Thank you.",
|
||||
"content": "Cloud Storage Folder access in buckets - Database - Google Developer forums\n\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-ai_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-gamification_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"discourse-reactions_desktop\" /\u003e\n= 40rem)\" rel=\"stylesheet\" data-target=\"poll_desktop\" /\u003e\n\nCloud Storage Folder access in buckets\n\nGoogle Cloud\n\nDatabase\n\ncloud-bigtable\n\nGargeya\n\nFebruary 28, 2025, 3:34pm\n\nHi All,\n\nI have a Cloud Storage bucket that contains two folders, each with its own set of files. I need to grant user access to only Folder A while restricting their access to Folder B. What is the best approach to achieving this folder-level access control in Google Cloud Storage? Please help.\n\nThank you.\n\nJoy_S\n\nMarch 3, 2025, 3:31pm\n\nHi @Gargeya ,\n\nWelcome to Google Cloud Community!\n\nCurrently, access control is available only at the bucket level or object level, but not at the folder level. But you can follow these steps as a workaround:\n\nGo to the Google Cloud Console then navigate to the Cloud Storage section. Select the bucket containing Folder A and Folder B. Enable uniform bucket-level access for the bucket.\n\nCreate an IAM policy that grants Storage Object Viewer role IAM permission\n\n(resource.name.startsWith('projects/_/buckets/Samplebucket/objects/def')\n\nto the user for Folder A. Create another IAM policy that denies access to Folder B.\n\nApply the IAM policy for Folder A by specifying the folder path in the policy. Paste the bucket url in the browser with the user logged in. Ensure that the IAM policy for Folder B restricts access to that folder.\n\nWas this helpful? If so, please accept this answer as “Solution”. If you need additional assistance, reply here within 2 business days and I’ll be happy to help.\n\nAI Suggested topics\n\nTopic\n\nReplies\n\nViews\n\nActivity\n\nIssues with Setting Up Access Control for Google Cloud Storage Buckets\n\nCompute Infrastructure\n\ncloud-storage\n\n82\n\nMarch 3, 2025\n\nGive permission to list the files in folder of bucket\n\nCompute Infrastructure\n\ncloud-storage\n\n324\n\nOctober 18, 2023\n\nIssues with Setting Up Access Control for Google Cloud Storage Buckets\n\nCompute Infrastructure\n\ncloud-storage\n\n25\n\nFebruary 20, 2025",
|
||||
"content_type": "text/html",
|
||||
"query": "How are private paths configured in GCP Cloud Storage to restrict access to storage objects?",
|
||||
"language": "en-US",
|
||||
"round": 3,
|
||||
"fetched": true,
|
||||
"relevant": true,
|
||||
"relevance": 0.92,
|
||||
"source_quality": "community",
|
||||
"source_quality_score": 0.7440000000000001,
|
||||
"actionable": true,
|
||||
"covered_gap_ids": [
|
||||
"GAP-004"
|
||||
],
|
||||
"assessment_reason": "Die Quelle beschreibt, wie Zugriff auf Ordner in Cloud Storage eingeschränkt werden kann, indem einheitlicher Zugriff auf Bucket-Ebene aktiviert wird und IAM-Pfade für spezifische Ordner konfiguriert werden. Sie liefert konkrete Schritte zur Einrichtung von Zugriffsrechten auf Ordner, was direkt relevant für die Frage ist."
|
||||
}
|
||||
}
|
||||
25
data/research-evidence/3cbc56b1059f4cfcc643ece2.json
Normal file
25
data/research-evidence/3cbc56b1059f4cfcc643ece2.json
Normal file
File diff suppressed because one or more lines are too long
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user