This article is contributed. See the original author and article here.
Welcome to the conclusion of our series on OpenAI and Microsoft Sentinel! Back in Part 1, we introduced the Azure Logic Apps connector for OpenAI and explored the parameters that influence text completion from the GPT3 family of OpenAI Large Language Models (LLMs) with a simple use case: describing the MITRE ATT&CK tactics associated with a Microsoft Sentinel incident. Part 2 covered another useful scenario, summarizing a KQL analytics rule extracted from Sentinel using its REST API. In Part 3, we revisited the first use case and compared the Text Completion (DaVinci) and Chat Completion (Turbo) models. What’s left to cover? Well, quite a lot – let’s get started!
There is some incredible work happening every day by Microsoft employees, MVPs, partners, and independent researchers to harness the power of generative AI everywhere. Within the security field, though, one of the most important topics for AI researchers is data privacy. We could easily extract all entities from a Microsoft Sentinel incident and send them through OpenAI’s API for ChatGPT to summarize and draw conclusions – in fact, I’ve seen half a dozen new projects on GitHub just this week doing exactly that. It’s certainly a fun project for development and testing, but no enterprise SOC wants to export potentially sensitive file hashes, IP addresses, domains, workstation hostnames, and security principals to a third party without strictly defined data sharing agreements (or at all, if they can help it). How can we keep sensitive information private to the organization while still getting benefit from innovative AI solutions such as ChatGPT?
Enter Azure OpenAI Service!
Azure OpenAI Service provides REST API access to the same GPT-3.5, Codex, DALL-E 2, and other LLMs that we worked with earlier in this series, but with the security and enterprise benefits of Microsoft Azure. This service is deployed within your Azure subscription with encryption of data at rest and data privacy governed by Microsoft’s Responsible AI principles. Text completion models including DaVinci have been generally available on Azure OpenAI Service since December 14, 2022. While this article was being written, ChatGPT powered by the gpt-3.5-turbo model was just added to Preview. Access is limited right now, so be sure to apply for access to Azure OpenAI!
ChatGPT on Azure solves a major challenge in operationalizing generative AI LLMs for use in an enterprise SOC. We’ve already seen automation for summarizing incident details, related entities, and analytic rules – and if you’ve followed this series, we’ve actually built several examples! What’s next? I’ve compiled a few examples that I think highlight where AI will bring the most value to a security team in the coming weeks and months.
As an AI copilot for SOC analysts and incident responders, ChatGPT could power a natural language assistant interfacing with security operators through Microsoft Teams to provide a common operating picture of an incident in progress. Check out Chris Stelzer’s innovative work with #SOCGPT for an example of this capability.
ChatGPT could give analysts a head start on hunting for advanced threats in Microsoft 365 Defender Advanced Hunting by transforming Sentinel analytic rules into product-specific hunting queries. A Microsoft colleague has done some pioneering work with ChatGPT for purple-teaming scenarios, both generating and detecting exploit code – the possibilities here are endless.
ChatGPT’s ability to summarize large amounts of information could make it invaluable for incident documentation. Imagine an internal SharePoint with summaries on every closed incident from the past two years!
There are still a few areas where ChatGPT, as innovative as it is, won’t replace human expertise and purpose-built systems. Entity research is one such example; it’s absolutely crucial to have fully defined, normalized telemetry for security analytics and entity mapping. ChatGPT’s models are trained on a very large but still finite set of data and cannot be relied on for real-time threat intelligence. Similarly, ChatGPT’s generated code must always be reviewed before being implemented in production.
I can’t wait to see what happens with OpenAI and security research this year! What security use cases have you found for generative AI? Leave a comment below!
This article is contributed. See the original author and article here.
We’re entering the era of next-generation AI that is driving new levels of productivity and efficiency, unleashing new innovations in the customer service space. AI is profoundly changing how customers engage with businesses and how agents provide exceptional service to them.
From a service perspective, customers expect fast, accurate answers to their questions, and personalized help when they contact a business. Meanwhile, businesses are under pressure to provide exceptional customer service with fewer resources. Legacy ways of integrating multiple-point solutions for customer service do not work. The time to embark on a digital transformation journey is now. Choosing the right AI-powered customer service solution for that journey, empowering customer service agents with AI, and reducing costs has never been more important.
We’re excited to launch Copilot in Dynamics 365 Customer Service, which provides agents with real-time AI-powered assistance, developed in alignment with our responsible AI principles and standards. Copilot helps agents resolve issues faster, handle cases more efficiently, and automate time-consuming tasks so they can focus on delivering high-quality service to their customers. In a nutshell, Copilot can help every agent to become your best agent.
With just a click of a button, Copilot empowers any agent to obtain the most relevant answer to any complex question that a customer may have and deliver a tailored response to the customer in real time using chat messages and emails. Copilot is available to agents as part of their natural flow of solving problems using Customer Service workspace. It’s like having an expert at your fingertips, always ready to assist.
Let’s take a closer look at the ways Copilot revolutionizes customer service and enables agents to deliver fast and relevant resolutions to customer problems.
Make every customer service agent a superagent
Today, when agents get a question from a customer that they can’t answer immediately, they typically search multiple internal knowledge sources or try to find an internal expert to consult with. The amount of time it takes to read through search results, find the right solution, compose a response back to the customer, and resolve the case is often lengthy.
Now, agents can chat with the next-generation AI-powered Copilot in Dynamics 365 Customer Service right within Customer Service workspace. Copilot can diagnose customer problems, use the organization’s internal knowledge and vast amounts of data from trusted websites, and supply the agent with an appropriate solution to give to the customer.
Copilot analyzes customer data to identify patterns, anticipate customer needs, and make suggestions to the agent on how to best handle each interaction. With this powerful tool at their disposal, agents can handle more queries in less time, increasing efficiency and improving the overall customer experience. Since agents are always in the loop every step of the way, they are in full control of using AI to drive their productivity. Agents can verify the responses, check the resources, and personalize the message to match the customer’s specific needs to ensure their satisfaction and optimal experience.
Answer customer questions fast across channels
In today’s fragmented contact center solution space, agents are often inundated with multiple messages on different channels of engagement. They are overwhelmed by multitasking and context switching, often wondering how they can keep up with overflowing incoming requests.
With omnichannel capabilities in Dynamics 365 Customer Service, customer service agents get a streamlined view of incoming chats from a variety of channels (such as Apple Messages for Business, Google Business Messaging, text messages, and WhatsApp) integrated with case management. Agents can now use Copilot in Dynamics 365 Customer Service, which intelligently parses information from the conversation and contextualizes it with organizational and customer data. Furthermore, Copilot keeps track of historical interactions, and uses all of that information to recommend a tailored, helpful answer that agents can review before they respond. Customers get the best service, regardless of their choice of channel.
Send expertly crafted customer service emails
For agents who receive questions via email, Copilot in Dynamics 365 Customer Service can help create relevant and personalized email responses in seconds. Copilot provides agents with predefined prompts based on what the agent is trying to do, such as “suggest a call”, “request more information”, “empathize with feedback”, or “resolve the customer’s problem.” Agents can also provide their own custom prompt for more complex issues.
Normally, agents may spend many minutes or hours researching and composing a detailed email with all the necessary information. With Copilot, agents get a composed email response in an instant that they can review and send.This model drives unparalleled productivity for the agent and delivers personalized service for the customer.
This embed requires accepting cookies from the embed’s site to view the embed. Activate the link to accept cookies and view the embedded content.
Enrich self-service with AI-powered conversational assistance
Dynamics 365 Customer Service now offers a powerful conversational experience with Power Virtual Agents, boosted by next-generation AI capabilities. Customers can get relevant answers to their questions immediately from intelligent conversational bots that use trusted websites and internal data. Enterprises also have the choice of using Nuance as an on-ramp for their digital transformation journey. Nuance announced new AI capabilities in Nuance Mix. Dynamics 365 Customer Service, together with Microsoft Teams, Microsoft Power Platform, Nuance, and Microsoft Azure, deliver truly transformative experiences for both agents and customers through the contact center.
Next-generation AI that is ready for enterprises
Azure OpenAI Service offers a range of privacy features, including data encryption and secure storage. It also allows users to control access to their data and provides detailed auditing and monitoring capabilities. Dynamics 365 is built on Azure OpenAI, so enterprises can rest assured that it offers the same level of data privacy and protection.
AI solutions built responsibly
We are committed to creating responsible AI by design. Our work is guided by a core set of principles: fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability. We are putting those principles into practice across the company to develop and deploy AI that will have a positive impact on society.
Try Copilot in Dynamics 365 Customer Service
Sign up for the limited preview of Copilot in Dynamics 365 Customer Service. This preview is available for instances in North America using the English US language.
Microsoft Business Applications Launch Event
On April 4, discover innovations across Microsoft Dynamics 365 and Microsoft Power Platform at a digital event.
This article is contributed. See the original author and article here.
Processing health insurance claims can be quite complex. This complexity is driven by a few factors, such as the messaging standards, the exchange protocol, workflow orchestration, all the way to the ingestion of the claim information in a standardize and scalable data stores. To enable operational, financial, and patient-centric data analytics, the claims data stores are often mapped to patient health records at the cohort, organization, or even population level.
What is X12 EDI?
Electronic Data Interchange (EDI) defines a messaging mechanism for unified communication across different organizations. X12 claims based processing refers to a set of standards for electronic data interchange (EDI) used in the healthcare industry to exchange information related to health claims. The X12 standard defines a specific format for electronic transactions that allows healthcare providers, insurers (payers), and other stakeholders to exchange data in a consistent and efficient manner. This cross-industry standard is accredited by the American National Standards Institution (ANSI). For simplicity, we will refer to ‘X12 EDI’ as ‘X12’ throughout this article.
What is FHIR?
FHIR® (Fast Healthcare Interoperability Resources) is a standard for exchanging information in the healthcare industry through web-based APIs with a broad range of resources to accommodate various healthcare use cases. These resources include patient demographics, clinical observations, medications, claims and procedures to name a few. It aims to improve the quality and efficiency of healthcare by promoting interoperability between different systems.
Azure Health Data Services is a suite of purpose-built technologies for protected health information (PHI) in the cloud. The FHIR service in Azure Health Data Services enables rapid exchange of health data using the Fast Healthcare Interoperability Resources (FHIR®) data standard. As part of a managed Platform-as-a-Service (PaaS), the FHIR service makes it easy for anyone working with health data to securely store and exchange Protected Health Information (PHI) in the cloud.
Why Convert X12 to FHIR?
FHIR is a modern, developer-friendly, born-in-the-cloud data standard compared to the aging X12. Converting from X12 to FHIR has many merits; (1) take advantage of FHIR interoperability and adoption to exchange claim information across various systems using modern and secure protocols, (2) unification of patient health and claim dataset into a single FHIR service in the cloud (3) enjoy a larger community of developers and evolving ecosystem at the global healthcare stage.
The Azure Solution
In essence, this article describes how to orchestrate the conversion of X12 claims to FHIR messages using Azure FHIR Service (with Azure Health Data Services), Azure Integration Account and Azure Logic Apps. Azure Logic Apps is a service within the Azure platform that enables developers to create workflows and automate business processes through the use of low-code/no-code visual and integration-based connectors. The service allows you to create, schedule, and manage workflows, that can be triggered by various events, such as receiving an HTTPS request or the arrival of a new file in an SFTP service. The Azure Integration Account is part of the Logic Apps Enterprise Integration Pack (EIP) and is a secure, manageable and scalable container for the integration artifacts that you create. The X12 XML Schema will be provided through the Azure Integration Account. The complete implementation of the X12 to FHIR conversion in Azure is available on GitHub.
Orchestration of X12 to FHIR Conversion
Azure Logic Apps orchestrates the conversion process from X12 to FHIR resources, allows for additional data quality checks, and then ingests the FHIR resources in the Azure FHIR Service as depicted in the following 4 steps:
X12 to FHIR
First, we ingest the X12 file content into the Azure Logic Apps workflow. In this sample, we submit the X12 file content in the body of an HTTPS Post request to the HTTPS endpoint exposed by Azure Logic Apps.
Initial data quality check and decoding is done using the Azure Logic Apps X12 connector leveraging the X12 XML schemas associated with the transaction sets. This step will verify that the sender is configured and enabled in the system and pick the correct agreement that is configured with the X12 schema. This schema is used to convert the X12 data to XML.
Once the X12 file is validated and decoded into the XML format, the XML content can then be converted to FHIR using the Azure Logic Apps XML to JSON Liquid connector. This uses DotLiquid templates to map the XML content to the corresponding FHIR resources.
The output of the workflow is to store the data in Azure FHIR Service (with Azure Health Data Services) to support a unified view of the patient’s record. The FHIR service supports an HTTP REST endpoint where individual resources can be managed or sent as an atomic transaction using a FHIR bundle.
FHIR Resources
Various FHIR resources can be generated from an X12 transaction set. Depending on business requirements and entities participating in the integration, these resources will vary.
Metadata bout the X12 message including the raw message.
Liquid Template Sample
A sample liquid template is provided showing how to extract data from the decoded X12 file. In the following snippet, the elements under ‘content’ correspond to XML elements in the decoded X12 file. The XML elements are being mapped to the ‘total’ attribute of the ‘Claim’ FHIR resource.
Patient and provider identifiers in the transaction set may not correspond directly to the FHIR identifiers for those matching resources. A lookup approach may be needed to map the data such as an EMPI (enterprise master patient index) and Provider Registry. These mappings can exist in a separate data store or using the FHIR Identifier data type for the corresponding FHIR resource.
Various X12 EDI schemas may need to be managed across your provider base. Each version of the transaction set will have a corresponding Liquid template which will also need to be versioned to convert the correct XML to FHIR. An approach around modularizing templates will be crucial to find the right balance for reusability.
Depending on the scale of the provider base and security requirements the architecture can be revised accordingly:
One instance of Azure Logic Apps can be created per provider providing full compute isolation.
Azure Logic Apps also support parallelization allowing for a batch of X12 files to be submitted and then processed in parallel.
One instance of Azure Logic Apps and Azure FHIR Service can be associated with a certain geographic region which may be needed if data sovereignty is required.
Depending on business scenario, the ingestion process can be trigger from an SFTP event. Health organizations and providers can be associated with an Azure Storage Account enabled with SFTP where they can securely connect and manage their X12 artifacts.
This article is contributed. See the original author and article here.
Automating the deployment and configuration of Warehouse Management can be more efficient for big-scale deployments if you have a lot of devices to manage. One solution for this is using a mobile device management (MDM) solution such as Microsoft Intune, but not limited to it. To learn general information about using Intune to add apps, refer to the guide Add apps to Microsoft Intune.
Mobile Device Management (MDM) Perquisites
This article provides a demonstration of the practical deployment with Intune. It is imperative to ensure the availability of the following resources:
Each MDM solution offers several methods for delivering an application to end devices, including delivering app binaries or from app stores. The preferred delivery method is through app stores, as it is simple and offers the most convenient way to receive updates.
Here is an example of how to configure it on Intune portal.
Android
Add the Warehouse Management app with Add button in the Apps -> Android section.
Select app type as Managed Google Play app. Use your Google account to log into Google Play, it requests only once the first time. In the window that opens, find Warehouse Management then click the Approve button and then the Sync button.
In the list of applications, select Warehouse Management, in the page that opens, select Assignments -> Edit.
On the assignments page, select the user groups for which this application is intended and save.
Windows
The setup process for Windows apps is like Android, except for selecting an app from the Microsoft Store.
Add a new app with Add button in the Apps -> Microsoft Store app (new).
Search for Warehouse Management
Apply user assignments.
Managed Configuration
The Warehouse Management app (available from version 2.0.41.0+) enables connection settings to be import as a managed configuration through an MDM solution, and the same ConnectionsJson configuration key is shared across all platforms.
Remember that it is necessary to have a single connection set as the default (IsDefaultConnection=true) for the first time the application instantly connects to the backend. If this is not done, the user will have to manually choose the initial connection from the available options.
Here is an example of how to configure it on Intune portal.
Android
On the Apps tab, select App Configuration policies -> Managed devices.
Define a name, platform, profile, and app.
To create an app configuration policy, you need to grant the following permissions: Camera, External storage (write), and External storage (read). Then, add a configuration key and choose the ConnectionsJson option from the dialog box that appears. Insert the contents of the Connections.json file as the value of the ConnectionsJson key. Finally, proceed to the subsequent steps and assign the relevant user groups.
Windows
The Warehouse Managed for Windows requires a slightly different approach to deliver managed configuration. Navigate to the Devices section and choose Windows. This is where you will be able to view your Windows devices. Then, move to the Configuration Profiles section and create a custom profile by using templates for the Windows 10 platform.
Define a name.
In the Configuration settings step, add a new OMA-URI Setting and complete all necessary fields. Enter “./User/Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/AppStore/Microsoft.WarehouseManagement_8wekyb3d8bbwe/AppSettingPolicy/ConnectionsJson” in the OMA-URI field and insert the contents of your Connections.json file in the Value field. Finally, proceed to the subsequent steps and assign the relevant user groups.
Certificate-based authentication
Certificate-based authentication is widely used for secure and efficient method of authentication. In mass deployment scenarios, it is advantageous due to its ability to provide a secure access alongside the simplicity of certificate deployment to end devices. This helps in reducing the risk of security breaches, which can be a significant concern in large-scale deployments.
To use the Warehouse Management mobile app, you need to have the certificate stored on each device. If you’re using Intune to manage your devices, you can find additional instructions on how to handle certificates for authentication in the Use certificates for authentication in Microsoft Intune guide.
To utilize a Certificate-based authentication approach, you must obtain a self-signed certificate (.pfx) either through the Windows Server Certificate Authority or by using PowerShell. It’s important to ensure that the certificate is exported along with its private key and protected by a password.
The objective is to transfer the PFX certificate (.pfx) with the thumbprint specified in the ConnectionsJson to the target devices. To achieve this, utilize the PKCS imported certificate configuration profile, as it enables the delivery of the same certificate across devices.
Certificate import
Create App registration in Azure Active Directory for PFXImport Powershell
Create new client secret on Certificates & secrets tab.
Add and configure Mobile and desktop applications on Authentication tab.
Build PFXImport
Download Visual Studio 2022.
Download PFXImport Powershell Project from GitHub.
Open PFXImportPS.sln file, switch it to release mode, and build the project. You can find additional information by following the link.
Dedicated machine for Certificate Connector
Start up the designated machine and carry out all subsequent actions on it.
Copy your self-signed PXF certificate to the Certificate Connector machine.
Copy the project binaries to the machine. (~Intune-Resource-Access-developsrcPFXImportPowershellPFXImportPSbinRelease)
Modify IntunePfxImport.psd1 in Release folder file with data from App registration.
To install the Microsoft Intune Certificate Connector, locate the installation file under the Tenant administration tab in the Endpoint Manager.
To install the Certificate Connector, transfer the installation file to the designated machine where it will be used and then run the file. During the installation process, be sure to select the “PKCS imported certificates” checkbox. Then sign into your Azure AD account using an admin user. As a result of successful installation, you will see a green checkmark on the Endpoint Manager page. You can find additional information by following the link.
Import certificate with PFXImport Powershell
Run Powershell Terminal as administrator on the Certificate Connector machine.
Change folder to PFXImportPowershell release folder.
Additional information is available at the following link.
Troubleshooting: Use Windows Event Viewer to review the Certificate Connector logs.
Endpoint manager portal configurations
To create a new configuration profile, the process is the same across all platforms. Start by going to the Device tab, selecting the desired operating system, and clicking the “Create profile” button. Then, select “PKCS imported certificate” as the profile type (If the operating system is Android, also select the “Android Enterprise platform” option). Give the profile a name and description in the next step.
In the following step, choose “S/MIME Encryption” as the “Intended purpose” and finalize the process by assigning it to a user group (If the operating system is Windows, also select the “Enroll to Software KSP” option).
Use the configuration profile details page to validate the result.
Another way to verify is to inspect the end devices. You can check the certificates using:
the “Manage user certificates” option on Windows, or
an app like “My certificates” to view installed certificates on Android. Please note, this app needs to be installed in the same way and the same work profile as Warehouse Management to access certificates distributed from Intune.
End Device Enrolment
Devices can be enrolled with the Company Portal app, depending on the type of device and platform, and these enrolment programs provide access to work or school resources. Enrolment involves registering with Microsoft Intune and applying organizational policies for security. The Company Portal app is accessible on multiple devices.
This article is contributed. See the original author and article here.
Inaccessible content is everywhere in the digital world. Today, we’re introducing Accessibility Assistant in Microsoft 365 to help creators produce more accessible content with less effort, all in the flow of work.
Recent Comments