SDE Data breach

[Nanomsky]

We have a data breach within the SDE through Azure ML.

Project: Predict
VM - linuxvm2ab2 (regular_workstation_4)

To Reproduce

1. Create a new compute instance from within SDE Azure portal
2. Start the instance and click on JupyterLab (Under the Applications column) to start Jupyter Lab
3. With the file Browser open, click the upload button to manually select and upload data

The uploaded data is visible and can be seen within the JupyterLab file browser

4. Open ml.azure.com from outside the SDE and log in to the same resource group, subscription and workspace.
5. Locate the same compute instance created in the previous step and open JupyterLab
6. The uploaded file is clearly visible

7. Righ-click on the file and select the download button to download the file to your local drive

Expected behavior

This should not happen. I should not be able to download the file from ml.azure.com outside the SDE.

[BIOKU-BH]

[like] BIOKU, Idowu (BARTS HEALTH NHS... reacted to your message:

…

________________________________ From: Nnanyelugo O Nwegbu ***@***.***> Sent: Thursday, August 28, 2025 3:09:29 PM To: Barts-Life-Science/Support ***@***.***> Cc: Subscribed ***@***.***> Subject: [Barts-Life-Science/Support] SDE Data breach (Issue #59) This message originated from outside of NHSmail. Please do not click links or open attachments unless you recognise the sender and know the content is safe. [https://avatars.githubusercontent.com/u/13247547?s=20&v=4]Nanomsky created an issue (Barts-Life-Science/Support#59)<#59> We have a data breach within the SDE through Azure ML. Project: Predict VM - linuxvm2ab2 (regular_workstation_4) To Reproduce 1. Create a new compute instance from within SDE Azure portal 2. Start the instance and click on JupyterLab (Under the Applications column) to start Jupyter Lab 3. With the file Browser open, click the upload button to manually select and upload data image.png (view on web)<https://github.com/user-attachments/assets/c3b89d85-33db-4122-850f-cad250009c0d> The uploaded data is visible and can be seen within the JupyterLab file browser image.png (view on web)<https://github.com/user-attachments/assets/0a93b447-a543-4229-ae24-701cfb5b3760> 1. Open ml.azure.com from outside the SDE and log in to the same resource group, subscription and workspace. 2. Locate the same compute instance created in the previous step and open JupyterLab 3. The uploaded file is clearly visible image.png (view on web)<https://github.com/user-attachments/assets/45e220c3-0844-425b-982d-244b826ed255> 7. Righ-click on the file and select the download button to download the file to your local drive image.png (view on web)<https://github.com/user-attachments/assets/078e0676-5606-4a3e-b897-c9da809f7b5d> Expected behavior This should not happen. I should not be able to download the file from ml.azure.com outside the SDE. — Reply to this email directly, view it on GitHub<#59>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BKK7SVTJQAL3GBNIQ7FYS3L3P4LSTAVCNFSM6AAAAACFBYKPYCVHI2DSMVQWIX3LMV43ASLTON2WKOZTGM3DGNZQG43DKMA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> ************************************************************************************** ****************************** This message may contain confidential information. If you are not the intended recipient please: i) inform the sender that you have received the message in error before deleting it; and ii) do not disclose, copy or distribute information in this e-mail or take any action in relation to its content (to do so is strictly prohibited and may be unlawful). Thank you for your co-operation. NHS.net Connect is the secure email, collaboration and directory service available for all NHS staff in England. NHS.net Connect is approved for exchanging patient data and other sensitive information with NHS.net Connect and other accredited email services. For more information and to find out how you can switch visit Joining NHS.net Connect – NHS.net Connect Support<https://support.nhs.net/article-categories/joining-nhsmail/>

[mkava-barts]

@Nanomsky which RG, subscription is this?

[Nanomsky]

Resource Group -bls-data-science-team
Subscription ID - c8ee312f-ad24-4e17-86e0-70eb77f66674

[mkava-barts]

seems I don't have access to the workspace so its not reproducible for me

[Nanomsky]

Why don't you try in whatever RG subscription and workspace you have access to?

[TonyWildish-BH]

A couple of clarifications:

• the linuxvm2ab2 VM is in the rg-sdebeta-ws-3e8d resource group, which is for the DAR-016 Williams workspace, in the BH-LS-PMP TRE subscription.
• the BLS-Data-Science-Team resource group is in the BH-LS-Microsoft Azure Enterprise subscription.
• @mkava-barts, you should have access to both these resources, please check.

@Nanomsky, some questions for you:

• can you explain point 4 in more detail please. What does it mean to connect to the same VM from outside the SDE, how are you doing that? Are you connecting to linuxvm2ab2 without going via Guacamole? if so, that's a serious breach in itself.
• can you also confirm that this is with a standalone Jupyter instance, not as part of the Azure ML deployment in your workspace?

I ask the second question because we'd already considered the possibility of a breach through Azure ML via the storage, but that seems to be adequately protected by network security groups. You can see the storage, but not access it, from outside the SDE. This sounds like it may be different to that.

[TonyWildish-BH]

I spoke to Osita. The issue is this:

• He has an AzureML workspace, ‘Predict’, created outside the SDE, in the BLS-Data-Science-Team resource group.
• When he logs into ml.azure.com from within the SDE, he can browse to this AzureML workspace
• He can then upload data to a Jupyter notebook in that ML workspace from within the SDE
• From outside the SDE, he logs in to ml.azure.com, goes to the same notebook, and can download that file

So the breach is not from the SDE itself, the AzureML workspaces it deploys are secure (I had tested before, and Mahesh & Bioku verified this today). The ML workspace storage is correctly secured there.

The breach comes from

1. being able to create AzureML workspaces independently of the SDE
2. being able to browse to those workspaces from within the SDE

and this happens because the browsing goes via ml.azure.com, not from the SDE workspace subnet.

This may be limited to the Data Science team, since no other user of the SDE has access to our tenancy to be able to create a resource group or an Azure ML instance. I'll open a sub-issue to confirm that.

Now investigating possible workarounds/fixes.