Multiple education institutions for one account
Hello, I work in two places (both are educational institutions), and through MSLE I deliver classes to high‑school and university students. Is it possible to assign two school names to one MSLE account? I would like to be able to select the correct institution here
MSLE Onboarding Session — English
✨ Ready to take your teaching to the next level? Join Carlos, our MSLE Community Manager (English), for an exclusive induction session on the MSLE Program for Educators! ✅ Discover the benefits and scope of the program ✅ Explore the two main portals you’ll have access to ✅ Get your questions answered in a collaborative environment This is your first step toward an enriching experience where knowledge, innovation, and community come together to empower you. 📅 Don’t miss it—your journey starts here! MSLE Onboarding Session | Meeting-Join | Microsoft Teamsجلسة الانضمام إلى MSLE — بالعربية
ل أنت مستعد للارتقاء بتجربتك التعليمية إلى المستوى التالي؟ انضم إلى أنس، مدير مجتمع MSLE (باللغة الإنجليزية)، في جلسة تعريفية حصرية حول برنامج MSLE للمعلمين! ✅ اكتشف مزايا البرنامج ونطاقه ✅ تعرّف على البوابتين الرئيسيتين اللتين ستحصل على إمكانية الوصول إليهما ✅ اطرح أسئلتك في بيئة تفاعلية وتعاونية هذه هي خطوتك الأولى نحو تجربة ثرية، حيث يجتمع العلم والابتكار والمجتمع لتمكينك ودعم مسيرتك التعليمية Microsoft Teams Join the meeting now📣 Getting Started with AI and MS Copilot — Português
Olá, 👋 📢 Quer explorar IA e Microsoft Copilot de forma prática para o aprendizado? Participe da sessão “Introdução à IA com o uso do MS Copilot”, pensada especialmente para docentes que estão começando a usar o Copilot. Vamos aprender os fundamentos da IA generativa, como criar boas instruções e aplicar essas ferramentas na sala de aula. 📌 Sessão com exemplos práticos, materiais para utilizar e um espaço ideal para praticar e tirar dúvidas. No horário indicado, favor realizar acesso ao link: Teams meeting.📣 MSLE Onboarding Session — Português
Olá, 👋 Espero que estejam bem! ✨Participe da sessão de introdução ao programa MSLE para Educadores! Nesta sessão: ✅ Vamos explorar os benefícios e o alcance do programa ✅ Conhecer em detalhe os dois portais principais aos quais você terá acesso ✅ Esclarecer todas as suas dúvidas em um ambiente colaborativo Este é o seu primeiro passo rumo a uma experiência enriquecedora, onde conhecimento, inovação e comunidade se unem para impulsionar você ao próximo nível. No horário indicado, favor realizar acesso ao link: Teams meeting.
Integrating Proofpoint and Mimecast Email Security with Microsoft Sentinel
Microsoft Sentinel can ingest rich email security telemetry from Proofpoint and Mimecast to power advanced phishing detection. The Proofpoint On Demand (POD) Email Security and Proofpoint Targeted Attack Protection (TAP) connectors pull threat logs (quarantines, spam, phishing attempts) and user click data into Sentinel. Similarly, the Mimecast Secure Email Gateway connector ingests detailed mail flow and targeted-threat logs (attachment/URL scans, impersonation events). These integrations use Azure-hosted ingestion (via Logic Apps or Azure Functions) and the new Codeless Connector framework to call vendor APIs on a schedule. The result is a consolidated dataset in Sentinel’s Log Analytics, enabling correlated alerting and hunting across email, identity, and endpoint signals. Figure: Phishing emails are processed by Mimecast’s gateway and Proofpoint POD/TAP services. Security logs (delivery/quarantine events, malicious attachments/links, user clicks) flow into Microsoft Sentinel. In Sentinel, these mail signals are correlated with identity (Azure AD), endpoint (Defender) and network telemetry for end-to-end phishing detection. Proofpoint POD (Email Protection) Connector The Proofpoint POD connector ingests core email protection logs. It creates two tables, ProofpointPODMailLog_CL and ProofpointPODMessage_CL. These logs include per-message metadata (senders, recipients, subject, message size, timestamps), threat scores (spamScore, phishScore, malwareScore, impostorScore), and attachment details (number of attachments, names, hash values and sandbox verdicts). Quarantine actions are recorded (quarantine folder/rule) and malicious indicators (URL or file hash) and campaign IDs are tagged in the threatsInfoMap field. For example, each ProofpointPODMessage_CL record may carry a sender_s (sender email domain hashed), recipient list, subject, and any detected threat type (Phish/Malware/Spam/Impostor) with associated threat hash or URL. Deployment: Proofpoint POD uses Sentinel’s codeless connector (an Azure Function behind the scenes). You must provide Proofpoint API credentials (Cluster ID and API token) in the connector UI. The connector periodically calls the Proofpoint SIEM API to fetch new log events (typically in 1–2 hour batches). The data lands in the above tables. (Older custom logic-app approaches similarly parse JSON output from the /v2/siem/messages endpoints.) Proofpoint TAP (Targeted Attack Protection) Connector Proofpoint TAP provides user-click and message-delivery events. Its connector creates four tables: ProofPointTAPMessagesDeliveredV2_CL, ProofPointTAPMessagesBlockedV2_CL, ProofPointTAPClicksPermittedV2_CL, and ProofPointTAPClicksBlockedV2_CL. The message tables report emails with detected threats (URL or attachment defense) that were delivered or blocked by TAP. They include the same fields as POD (message GUID, sender, recipients, subject, threat campaign ID, scores, attachments info). The click tables log when users click on URLs: each record has the URL, click timestamp (clickTime), the user’s IP (clickIP), user-agent, the message GUID, and the threat ID/category. These fields allow you to see who clicked which malicious link and when. As the connector description notes, these logs give “visibility into Message and Click events in Microsoft Sentinel” for hunting. Deployment: The TAP connector also uses the codeless framework. You supply a TAP API service principal and secret (proofpoint SIEM API credentials) in the Sentinel content connector. The function app calls TAP’s /v2/siem/clicks/blocked, /permitted, /messages/blocked, and /delivered endpoints. The Proofpoint SIEM API limits queries to 1-hour windows and 7-day history, with no paging (all events in the interval are returned). (A Logic App approach could also be used, as shown in the Tech Community blog: one HTTP GET per event type and a JSON Parse before sending to Log Analytics.) Mimecast Secure Email Gateway Connector The Mimecast connector ingests the Secure Email Gateway (SEG) logs and targeted-threat (TTP) logs. Inbound, outbound and internal mail events from the Mimecast MTA (receipt, processing, delivery stages) are pulled via the API. Typical fields include the unique message ID (aCode), sender, recipient, subject, attachment count/names, and the policy actions or holds (e.g. spam quarantine). For example, the Mimecast “Process” log shows AttCnt, AttNames, and if the message was held (Hld) for review. Delivery logs include the success/failure and TLS details. In addition, Mimecast TTP logs are collected: URL Protect logs (when a user clicks a blocked URL) include the clicked URL (url), category (urlCategory), sender/recipient, and block reason. Impersonation Protect logs capture spoofing detections (e.g. if an internal name is impersonated), with fields like Sender, Recipient, Definition and Action (hold/quarantine). Attachment Protect logs record malicious file detections (filename, hash, threat type). Deployment: Like Proofpoint, Mimecast’s connector uses Azure Functions via the Sentinel content hub. You install the Mimecast solution, open the connector page, then enter Azure app credentials and Mimecast API keys (API Application ID/Key and Access/Secret for the service account). As shown in the deployment guide, you must provide the Azure Subscription, Resource Group, Log Analytics Workspace and the Azure Client (App) ID, Tenant ID and Object ID of the admin performing the setup. On the Mimecast side, you supply the API Base URL (regional), App ID/Secret and user Access/Secret. The connector creates a Function App that polls Mimecast’s SIEM APIs on a cron schedule (default every 30 minutes). You can optionally specify a start date for backfilling up to 7 days of logs. The default tables are MimecastSIEM_CL (for email flow logs) and MimecastDLP_CL (for DLP/TTP events), though custom names can be set. Ingestion Considerations Data Latency: All these connectors are pull-based and typically run on a schedule (often 30–60 minutes). For example, the Proofpoint POD docs note hourly log increments, and Mimecast logs are aggregated every 30 minutes. Expect a delay of up to an hour or more from event occurrence to Sentinel ingestion. Schema Nuances: The APIs often return nested arrays and optional fields. For instance, the Proofpoint blog warns that some JSON fields can be null or vary in type, so the parse schema should account for all possibilities. Similarly, Mimecast logs come in pipe-delimited or JSON format, with values sometimes empty (e.g. no attachments). In KQL, use tostring() or parse_json() on the raw _CL columns, and mv-expand on any multivalue fields (like message parts or threat lists). Table Names: Use the connector’s tables as listed. For Proofpoint: ProofpointPODMailLog_CL and ProofpointPODMessage_CL; for TAP: ProofPointTAPMessagesDeliveredV2_CL, ProofPointTAPMessagesBlockedV2_CL, ProofPointTAPClicksPermittedV2_CL, ProofPointTAPClicksBlockedV2_CL. For Mimecast SEG/TTP: MimecastSIEM_CL (seg logs) and MimecastDLP_CL (TTP logs). API Behavior: The Proofpoint TAP API has no paging. Be aware of timezones (Proofpoint uses UTC) and use the Sentinal ingestion TimeGenerated or event timestamp fields for binning. Detection Engineering and Correlation To detect phishing effectively, we correlate these email logs with identity, endpoint and intel data: Identity (Azure AD): Mail logs contain recipient addresses and (hashed) sender user parts. A common tactic is to correlate SMTP recipients or sender domains with Azure AD user records. For example, join TAP clicks by recipient to the user’s UPN. The Proofpoint logs also include the clicker’s IP (clickIP); we can match that to Azure AD sign-in logs or VPN logs to find which device/location clicked a malicious link. Likewise, anomalous Azure AD sign-ins (impossible travel, MFA failure) after a suspicious email can strengthen the case. Endpoints (Defender): Once a user clicks a bad link or opens a malicious attachment (captured in TAP or Mimecast logs), watch for follow-on behaviors. For instance, use Sentinel’s DeviceSecurityEvents or DeviceProcessEvents to see if that user’s machine launched unusual processes. The threatID or URL hash from email events can be looked up in Defender’s file data. Correlate by username (if available) or IP: if the email log shows a link click from IP X, see if any endpoint alerts or logon events occurred from X around the same time. As the Mimecast integration touts, this enables “correlation across Mimecast events, cloud, endpoint, and network data”. Threat Intelligence: Use Sentinel’s ThreatIntelligenceIndicator tables or Microsoft’s TI feeds to tag known bad URLs/domains in the email logs. For example, join ProofPointTAPClicksBlockedV2_CL on the clicked url against ThreatIntelligenceIndicator (type=URL) to automatically flag hits. Proofpoint’s logs already classify threats (malware/phish) and provide a threatID; one can enrich that with external intel (e.g. check if the hash appears in TI feeds). Mimecast’s URL logs include a urlCategory field, which can be mapped to known malicious categories. Automated playbooks can also pull Intel: e.g. use Sentinel’s TI REST API or Azure Sentinel watchlists containing phishing domains to annotate events. In summary, a robust detection strategy might look like: (1) Identify malicious email events (high phish scores, quarantines, URL clicks). (2) Correlate these events by user with Azure AD logs (did the user log in from a new IP after a phish click?). (3) Correlate with endpoint alerts (Defender found malware on that device). (4) Augment with threat intelligence lookups on URLs and attachments from the email logs. By linking the Proofpoint/Mimecast signals to identity and endpoint events, one can detect the full attack chain from email compromise to endpoint breach. KQL Query Here are representative Kusto queries for common phishing scenarios (adapt table/field names as needed): Malicious URL Click Detection: Identify users who clicked known-malicious URLs. For example, join TAP click logs to TI indicators:This flags any permitted click where the URL matches a known threat indicator. Alternatively, aggregate by domain: let TI = ThreatIntelligenceIndicator | where Active == true and _EntityType == "URL"; ProofPointTAPClicksPermittedV2_CL | where url_s != "" | project ClickTime=TimeGenerated, Recipient=recipient_s, URL=url_s, SenderIP=senderIP_s | join kind=inner TI on $left.URL == TI._Value | project ClickTime, Recipient, URL, Description=TI.Description This flags any permitted click where the URL matches a known threat indicator. Alternatively, aggregate by domain: ProofPointTAPClicksPermittedV2_CL | extend clickedDomain = extract(@"https?://([^/]+)", 1, url_s) | summarize ClickCount=count() by clickedDomain | where clickedDomain has "maliciousdomain.com" or clickedDomain has "phish.example.com" Quarantine Spike (Burst) Detection: Detect sudden spikes in quarantined messages. For example, using POD mail log:This finds hours with an unusually high number of held (quarantined) emails, which may indicate a phishing campaign. You could similarly use ProofPointTAPMessagesBlockedV2_CL. ProofpointPODMailLog_CL | where action_s == "Held" | summarize HeldCount=count() by bin(TimeGenerated, 1h) | order by TimeGenerated desc | where HeldCount > 100 Targeted User Phishing: Find if a specific user received multiple malicious emails. E.g., for user email address removed for privacy reasons:This lists recent phish attempts targeting Username. You might also join with TAP click logs to see if she clicked anything. ProofpointPODMessage_CL | where recipient has "email address removed for privacy reasons" | where array_length(threatsInfoMap) > 0 and threatsInfoMap_classification_s == "Phish" | project TimeGenerated, sender_s, subject_s, threat=threatsInfoMap_threat_s Campaign-Level Analysis: Group emails by Proofpoint campaign ID to see scope of each campaign:This shows each campaign ID with how many unique recipients were hit and one example subject. Combining TAP and POD tables on GUID_s or QID_s can further link click events back to the originating message/campaign. ProofpointPODMessage_CL | mv-expand threatsInfoMap | summarize Recipients=make_set(recipient), Count=dcount(recipient) by CampaignID=threatsInfoMap_campaignId_s | project CampaignID, RecipientCount=Count, Recipients, SampleSubject=any(subject_s) Each query can be refined (for instance, filtering only within a recent time window) and embedded in Sentinel Analytics rules or hunting. The key is using the connectors’ fields – URLs, sender/recipient addresses, campaign IDs – to pivot between email data and other security signals.Getting Started with AI and MS Copilot - English
🚀 Ready to explore AI and Microsoft Copilot in a fun, hands-on way? Join our session: “Introduction to AI and Microsoft Copilot”—designed for educators who are just getting started! ✅ Learn the fundamentals of generative AI ✅ Master the art of creating effective prompts ✅ Discover practical ways to use these tools in your classroom ✅ Access ready-to-use teaching resources ✅ Practice with 10 interactive exercises 📅 Don’t miss this opportunity to boost your teaching with AI! #MicrosoftCopilot #AIinEducation #Educators #Innovation #TeachingTools Getting Started with AI and MS Copilot - English | Meeting-Join | Microsoft TeamsMSLE Onboarding Session — English
✨ Ready to take your teaching to the next level? Join Carlos, our MSLE Community Manager (English), for an exclusive induction session on the MSLE Program for Educators! ✅ Discover the benefits and scope of the program ✅ Explore the two main portals you’ll have access to ✅ Get your questions answered in a collaborative environment This is your first step toward an enriching experience where knowledge, innovation, and community come together to empower you. 📅 Don’t miss it—your journey starts here! MSLE Onboarding Session — English | Meeting-Join | Microsoft TeamsCloud Posture + Attack Surface Signals in Microsoft Sentinel (Prisma Cloud + Cortex Xpanse)
Microsoft expanded Microsoft Sentinel’s connector ecosystem with Palo Alto integrations that pull cloud posture, cloud workload runtime, and external attack surface signals into the SIEM, so your SOC can correlate “what’s exposed” and “what’s misconfigured” with “what’s actively being attacked.” Specifically, the Ignite connectors list includes Palo Alto: Cortex Xpanse CCF and Palo Alto: Prisma Cloud CWPP. Why these connectors matter for Sentinel detection engineering Traditional SIEM pipelines ingest “events.” But exposure and posture are just as important as the events—because they tell you which incidents actually matter. Attack surface (Xpanse) tells you what’s reachable from the internet and what attackers can see. Posture (Prisma CSPM) tells you which controls are broken (public storage, permissive IAM, weak network paths). Runtime (Prisma CWPP) tells you what’s actively happening inside workloads (containers/hosts/serverless). In Sentinel, these become powerful when you can join them with your “classic” telemetry (cloud activity logs, NSG flow logs, DNS, endpoint, identity). Result: fewer false positives, faster triage, better prioritization. Connector overview (what each one ingests) 1) Palo Alto Prisma Cloud CSPM Solution What comes in: Prisma Cloud CSPM alerts + audit logs via the Prisma Cloud CSPM API. What it ships with: connector + parser + workbook + analytics rules + hunting queries + playbooks (prebuilt content). Best for: Misconfig alerts: public storage, overly permissive IAM, weak encryption, risky network exposure. Compliance posture drift + audit readiness (prove you’re monitoring and responding). 2) Palo Alto Prisma Cloud CWPP (Preview) What comes in: CWPP alerts via Prisma Cloud API (Compute/runtime side). Implementation detail: Built on Codeless Connector Platform (CCP). Best for: Runtime detections (host/container/serverless security alerts) “Exploit succeeded” signals that you need to correlate with posture and exposure. 3) Palo Alto Cortex Xpanse CCF What comes in: Alerts logs fetched from the Cortex Xpanse API, ingested using Microsoft Sentinel Codeless Connector Framework (CCF). Important: Supports DCR-based ingestion-time transformations that parse to a custom table for better performance. Best for: External exposure findings and “internet-facing risk” detection Turning exposure into incidents only when the asset is critical / actively targeted. Reference architecture (how the data lands in Sentinel) Here’s the mental model you want for all three: flowchart LR A[Palo Alto Prisma Cloud CSPM] -->|CSPM API: alerts + audit logs| S[Sentinel Data Connector] B[Palo Alto Prisma Cloud CWPP] -->|Prisma API: runtime alerts| S C[Cortex Xpanse] -->|Xpanse API: exposure alerts| S S -->|CCF/CCP + DCR Transform| T[(Custom Tables)] T --> K[KQL Analytics + Hunting] K --> I[Incidents] I -->P[SOAR Playbooks] K --> W[Workbooks / Dashboards] Key design point: Xpanse explicitly emphasizes DCR transformations at ingestion time, use that to normalize fields early so your queries stay fast under load. Deployment patterns (practical, SOC-friendly setup) Step 0 — Decide what goes to “analytics” vs “storage” If you’re using Sentinel’s data lake strategy, posture/exposure data is a perfect candidate for longer retention (trend + audit), while only “high severity” may need real-time analytics. Step 1 — Install solutions from Content Hub Install: Palo Alto Prisma Cloud CSPM Solution Palo Alto Prisma Cloud CWPP (Preview) Palo Alto Cortex Xpanse CCF Step 2 — Credentials & least privilege Create dedicated service accounts / API keys in Palo Alto products with read-only scope for: CSPM alerts + audit CWPP alerts Xpanse alerts/exposures Step 3 — Validate ingestion (don’t skip this) In Sentinel Logs: Locate the custom tables created by each solution (Tables blade). Run a basic sanity query: “All events last 1h” “Top 20 alert types” “Distinct severities” Tip: Save “ingestion smoke tests” as Hunting queries so you can re-run them after upgrades. Step 4 — Turn on included analytics content (then tune) The Prisma Cloud CSPM solution comes with multiple analytics rules, hunting queries, and playbooks out of the box—enable them gradually and tune thresholds before going wide. Detection engineering: high-signal correlation recipes Below are patterns that consistently outperform “single-source alerts.” I’m giving them as KQL templates using placeholder table names because your exact custom table names/columns are workspace-dependent (you’ll see them after install). Recipe 1 — “Internet-exposed + actively probed” (Xpanse + network logs) Goal: Only fire when exposure is real and there’s traffic evidence. let xpanse = <XpanseTable> | where TimeGenerated > ago(24h) | where Severity in ("High","Critical") | project AssetIp=<ip_field>, Finding=<finding_field>, Severity, TimeGenerated; let net = <NetworkFlowTable> | where TimeGenerated > ago(24h) | where Direction == "Inbound" | summarize Hits=count(), SrcIps=make_set(SrcIp, 50) by DstIp; xpanse | join kind=inner (net) on $left.AssetIp == $right.DstIp | where Hits > 50 | project TimeGenerated, Severity, Finding, AssetIp, Hits, SrcIps Why it works: Xpanse gives you exposure. Flow/WAF/Firewall gives you intent. Recipe 2 — “Misconfiguration that creates a breach path” (CSPM + identity or cloud activity) Goal: Prioritize posture findings that coincide with suspicious access or admin changes. let posture = <PrismaCSPMTable> | where TimeGenerated > ago(7d) | where PolicySeverity in ("High","Critical") | where FindingType has_any ("Public", "OverPermissive", "NoMFA", "EncryptionDisabled") | project ResourceId=<resource_id>, Finding=<finding>, PolicySeverity, FirstSeen=TimeGenerated; let activity = <CloudActivityTable> | where TimeGenerated > ago(7d) | where OperationName has_any ("RoleAssignmentWrite","SetIamPolicy","AddMember","CreateAccessKey") | project ResourceId=<resource_id>, Actor=<caller>, OperationName, TimeGenerated; posture | join kind=inner (activity) on ResourceId | project PolicySeverity, Finding, OperationName, Actor, FirstSeen, TimeGenerated | order by PolicySeverity desc, TimeGenerated desc Recipe 3 — “Runtime alert on a workload that was already high-risk” (CWPP + CSPM) Goal: Raise severity when runtime alerts occur on assets with known posture debt. let risky_assets = <PrismaCSPMTable> | where TimeGenerated > ago(30d) | where PolicySeverity in ("High","Critical") | summarize RiskyFindings=count() by AssetId=<asset_id>; <CWPPTable> | where TimeGenerated > ago(24h) | project AssetId=<asset_id>, AlertName=<alert>, Severity=<severity>, TimeGenerated, Details=<details> | join kind=leftouter (risky_assets) on AssetId | extend RiskScore = coalesce(RiskyFindings,0) | order by Severity desc, RiskScore desc, TimeGenerated desc SOC outcome: same runtime alert, different priority depending on posture risk. Operational (in real life) 1) Normalize severities early If Xpanse is using DCR transforms (it is), normalize severity to a consistent enum (“Informational/Low/Medium/High/Critical”) to simplify analytics. 2) Deduplicate exposure findings Attack surface tools can generate repeated findings. Use a dedup function (hash of asset + finding type + port/service) and alert only on “new or changed exposure.” 3) Don’t incident-everything Treat CSPM findings as: Incidents only when: critical + reachable + targeted OR tied to privileged activity Tickets when: high risk but not active Backlog when: medium/low with compensating controls 4) Make SOAR “safe by default” Automations should prefer reversible actions: Block IP (temporary) Add to watchlist Notify owners Open ticket with evidence bundle …and only escalate to destructive actions after confidence thresholds.
