Share this:

Received a great FIDO2 Test kit from the vendor PointBlank Security / TrustKey Solutions https://www.trustkeysolutions.com/  https://www.pointblank.de/en/

As FIDO2 is the new hot item in the security world, let see if it is that easy to implement and to use. I’m not going into the depth specs of the keys but more as a user view. easy to use and setup is this key to use by anyone.

for all the Azure AD login this is usable when the Microsoft authentication challenge is the say for Windows virtual desktop (WVD) you can use this.

 

I have a USB key and a USB-C type key.

I use my Computer with the normal USB for this so the Trustkey G310 model

Setting the Key en use it is simple I configured the Azure Active directory did some easy settings add the Key to my profile and ready.

First we Enable FIDO2 security key in the Azure AD this is been configured from the Azure Portal.

Azure Active directory <> Security

 

Next we go to authentication methods.

Here we can change the authentication type for all users of for a select of users.

When this is done you can set the fido option in your profile. If this is your own account then in the top of the azure portal you can go directly to your user account . or go to https://myaccount.microsoft.com/

 

Go to Security info

Here you can do add a method

Adding the Security key or if you want to used the phone the method is similar.

Now that we have chosen the FIDO2 Security Key we can configure this with a PIN.

Choose a proper Pin and use the Key. Now everything is set and ready to use.

Whenever you are challenged to login with the Microsoft Azure AD account you can make the choice on using the USB key. You can also make this dedicated

So for samples we go to  Browse to https://myprofile.microsoft.com use an in private session or different browser to make sure you test this right.

select sign in with a security key

When entering the PIN and touching the USB you will be granted to login when it was successful you will see the page else it will prompt you again.

 

All this is perfect usable to login into your WVD portal

https://rdweb.wvd.microsoft.com/webclient/index.html

 

 

 

Follow Me on Twitter @ClusterMVP

Follow My blog https://robertsmit.wordpress.com

Linkedin Profile Robert Smit MVP Linkedin profile

Google  : Robert Smit MVP profile

Share this:

Sometimes you are building things in Azure and thinking if this is possible than that would be a cool feature. Suddenly you are building this and noticed that it is already there in Azure. How Cool is that.

Today I was building a demo website but I did not want to expose this directly to the web, play with this and still get the use of Azure Cloud over the internet. Reading the Azure Endpoint services there is no WebApp Endpoint services. Using a NSG or enable the Azure Firewall well it is just a test so lets see what we can do with all the basic stuff. But during the test I saw this option Microsoft.Web in the service endpoints.

More security is needed in everything you expose to the internet. And in Azure it all starts with a Vnet.

Virtual Network (VNet) service endpoints extend your virtual network private address space and the identity of your VNet to the Azure services, over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure network.

First we create a new Vnet, while we creating this wen can enable an pick the right service endpoints. this can also be done afterwards.

Azure service traffic from a virtual network uses public IP addresses as source IP addresses. With service endpoints, service traffic switches to use virtual network private addresses as the source IP addresses when accessing the Azure service from a virtual network. This switch allows you to access the services without the need for reserved, public IP addresses used in IP firewalls.

In case you have already a Vnet, just go to the Service points and add the selected service you want to add or select it all.

  

At this point there is no Configuration, it is just adding a services to the network or subnet.

Below is a list of the Azure services that are currently available.

Generally available

• Azure Storage: Generally available in all Azure regions.
• Azure SQL Database: Generally available in all Azure regions.
• Azure SQL Data Warehouse: Generally available in all Azure regions.
• Azure Database for PostgreSQL server: Generally available in Azure regions where database service is available.
• Azure Database for MySQL server: Generally available in Azure regions where database service is available.
• Azure Database for MariaDB: Generally available in Azure regions where database service is available.
• Azure Cosmos DB: Generally available in all Azure regions.
• Azure Key Vault: Generally available in all Azure regions.
• Azure Service Bus: Generally available in all Azure regions.
• Azure Event Hubs: Generally available in all Azure regions.
• Azure Data Lake Store Gen 1: Generally available in all Azure regions where ADLS Gen1 is available.

Public Preview

• Azure Container Registry: Preview available in all Azure regions where Azure Container Registry is available.

The Web app is not listed but the option is there, and working. The Azure service Endpoint is not a Firewall, as the Azure Firewall this is a totally different service.

For Samples you have a Web application, and it needs to have connection to storage or SQL server and connection to an other Web services, without setting this open to Any – Any you can restrict this with the Azure Service Endpoints

Creating the Rules is a quick process, these are similar as in the NSG.

• Network security groups (NSGs) with service endpoints:

• By default, NSGs allow outbound Internet traffic and so, also allow traffic from your VNet to Azure services. This continues to work as is, with service endpoints.
• If you want to deny all outbound Internet traffic and allow only traffic to specific Azure services, you can do so using service tags in your NSGs. You can specify supported Azure services as destination in your NSG rules and the maintenance of IP addresses underlying each tag is provided by Azure.

First we go the the Web App Service. in Networking and the non readers will click the VNet integration. #Wrong 

In this case I don’t want a premium network, So we go to Configure Access Restrictions

Here we create a access rule, on who gets access to this web application.

I created a deny rule for a specific IP.

And the pages shows an error webapp is stopped. here you can also see the difference between a complete port block and no access to the application.

Changing this to Allow the App is visible

Also for the KUDU SCM you can have different rules or apply the same rules. with the little check box

With these options you can create a more secure environment again this is a great add on.

Follow Me on Twitter @ClusterMVP

Follow My blog https://robertsmit.wordpress.com

Linkedin Profile Robert Smit MVP Linkedin profile

Google  : Robert Smit MVP profile

The Secure DevOps Kit for Azure is a collection of scripts, tools, extensions, automations.

The kit is based on Powershell and can be extended to Azure log analytics with some nice dashboarding. But if you have a large subscription the Powershell query can take some time. With this toolkit Devops teams using extensive automation and smoothly integrating security into native Devops workflows helping accomplish secure Devops with these 6 focus areas:

• Secure the subscription: A secure cloud subscription provides a core foundation upon which subsequent development and deployment activities can be conducted. An engineering team should have the capabilities to deploy and configure security in the subscription including elements such as alerts, ARM policies, RBAC, Security Center policies, JEA, Resource Locks, etc. Likewise, it should be possible to check that all settings are in conformance to a secure baseline
• Enable secure development: During the coding and early development stages, developers should have the ability to write secure code and to test the secure configuration of their cloud applications. Just like build verification tests (BVTs), we introduce the concept of security verification tests (SVTs) which can check for security of various resource types in Azure
• Integrate security into CICD: Test automation is a core tenet of devops. We emphasize this by providing the ability to run SVTs as part of the VSTS CICD pipeline. These SVTs can be used to ensure that the target subscription used to deploy a cloud application and the Azure resources the application is built upon are all setup in a secure manner
• Continuous Assurance: In the constantly changing dev ops environment, it is important to move away from the mindset of security being a milestone. We have to treat security as a continuously varying state of a system. This is made possible through capabilities that enable continuous assurance using a combination of automation runbooks, schedules, etc.
• Alerting & Monitoring: Visibility of security status is important for individual application teams and also for central enterprise teams. We provide solutions that cater to the needs of both. Moreover, the solution spans across all stages of dev ops in effect bridging the gap between the dev team and the ops team from a security standpoint through the single, integrated views it generates
• Cloud Risk Governance: Lastly, underlying all activities in the kit is a telemetry framework that generates events capturing usage, adoption, evaluation results, etc. This allows us to make measured improvements to security targeting areas of high risk and maximum usage before others.

Keep in mind that The OMS portal will is retired on January 15, 2019. You can continue to use your existing services and licensing in the Azure portal.

Even in the Azure portal you can still connect to OMS

Complete feature set of Secure DevOps Kit for Azure

Feature Area	Secure DevOps Kit Feature
Secure the subscription	Subscription Health Check Subscription Provisioning Alerts Configuration ARM Policy Configuration Azure Security Center Configuration Access control (IAM) Hygiene
Enable secure development	Security Verification Tests (SVT) Security IntelliSense- VS Extension
Integrate security into CICD	AzSK VS Extension-executes SVTs in a CICD pipeline
Continuous Assurance	Security scanning via Azure Automation Runbooks
Alerting & Monitoring	OMS Solution for AzSK containing: Security dashboard views covering security state/actions Alerts with pertinent search queries
Cloud Risk Governance	Control/usage telemetry through Insights

Setting up Secure DevOps Kit for Azure (AzSK)

First make sure you have the right Azure modules installed, I noticed the automation module failed So I added this manualy.

Import-Module AzureRM.Automation

Get-AzSKAzureServicesSecurityStatus -SubscriptionId

Installing the Secure DevOps Kit for Azure (AzSK)

Install-Module AzSK -Scope CurrentUser

Now that the Powershell modules are installed we can start the (AzSK) Scan

Get-AzSKAzureServicesSecurityStatus –SubscriptionId  ID

In this subscription there are 44 items that are been checked

Items are been checked on the security issues

Nice detailed overview is shown. Also a log folder is been created with all the issues. per resource Item.

As you can see I have some failed items and with a High, so I need to take a good look at this and fix this.

This maybe one of the best Items here an excel sheet with al the issues listed with the solution mentioned and if this can be automated.

If needed there is an URL that points you to the right solution.

As Azure log analytics is great and it can be integrated with some OMS (Azure monitoring Dashboards)

The OMS portal will be retired on January 15, 2019. You can continue to use your existing services and licensing in the Azure portal. So the current documentation need some updating.

Pressing the OMS button in the Azure portal brings you to the OMS portal but then nothing. As it is now all Azure portal.

Setting up the dashboards failed on me during the first installation but when I did run this a second time the dashboard was there.  (Timing) 

Creating the OMS default dashboard we need to run some powershell scripts.

$omsSubId =”id”   #subscription hosting the OMS workspace

$omsWSId =’OMS ID’

$omsRGName =’omsrsg’     #RG where the OMS workspace is hosted

$azSkViewName = ‘MVP_AzSK_view’ #This will identify the tile for AzSK view in OMS.

    #This command will deploy the AzSK view in the OMS workspace.  
    Install-AzSKOMSSolution -OMSSubscriptionId $omsSubId `

                    -OMSResourceGroup $omsRGName `

                    -OMSWorkspaceId $omsWSId `

                    -ViewName $azSkViewName

Note:

1) The blades of the OMS view created by this command will start populating only after AzSK scan events become available in the corresponding OMS workspace.

To understand how to send AzSK events to an OMS workspace see https://aka.ms/devopskit/oms.

2) The OMS view installed contains a basic set of queries over DevOps Kit scan events. Please feel free to customize them once you get familiar with the que

ries.

We also periodically publish updated/richer queries at: https://aka.ms/devopskit/omsqueries.

Checking the OMS – log analytics workspace it has not much issues as this is a test subscription and if it was all perfect then there is no fun.

and with longer logging and more Items in azure you will get a different overview.

There are lots of options you can set and there is a detailed description on how to use this on Github

Setting up ARM policys is also one of the options

Set-AzSKARMPolicies –SubscriptionId

So get started with the DevOpsKit https://github.com/azsk/DevOpsKit-docs 

https://github.com/azsk/DevOpsKit-docs/tree/master/05-Alerting-and-Monitoring

AzSK Security Controls Portal @https://aka.ms/azskosstcp

With this it’s a nice tool and yes a bit time consuming but learned a lot and make me see things different in the Azure Subscription 

And If you combine this directly and not afterwards then this could be your time saver to fix all the security items

 

Follow Me on Twitter @ClusterMVP

Follow My blog https://robertsmit.wordpress.com

Linkedin Profile Robert Smit MVP Linkedin profile

Google  : Robert Smit MVP profile

Share this:

Now Days I see that people not fully understand  the security needs in Azure. There are a lot of options in Azure to improve the security.

A great option is the Security Center. This is a great dashboard to get a quick over view an the security status of your subscription.

 

 

But the other Option is setting up a network security group (NSG)

A network security group (NSG) contains a list of security rules that allow or deny network traffic to resources connected to Azure Virtual Networks (VNet). NSGs can be associated to subnets, individual VMs (classic), or individual network interfaces (NIC) attached to VMs (Resource Manager).

When an NSG is associated to a subnet, the rules apply to all resources connected to the subnet. Traffic can further be restricted by also associating an NSG to a VM or NIC.

Associating NSGs

You can associate an NSG to VMs, NICs, and subnets, depending on the deployment model you are using, as follows:

• VM (classic only): Security rules are applied to all traffic to/from the VM.
• NIC (Resource Manager only): Security rules are applied to all traffic to/from the NIC the NSG is associated to. In a multi-NIC VM, you can apply different (or the same) NSG to each NIC individually.
• Subnet (Resource Manager and classic): Security rules are applied to any traffic to/from any resources connected to the VNet.

You can associate different NSGs to a VM (or NIC, depending on the deployment model) and the subnet that a NIC or VM is connected to. Security rules are applied to the traffic, by priority, in each NSG, in the following order:

• Inbound traffic

  1. NSG applied to subnet: If a subnet NSG has a matching rule to deny traffic, the packet is dropped.

  2. NSG applied to NIC (Resource Manager) or VM (classic): If VM\NIC NSG has a matching rule that denies traffic, packets are dropped at the VM\NIC, even if a subnet NSG has a matching rule that allows traffic.

• Outbound traffic

  1. NSG applied to NIC (Resource Manager) or VM (classic): If a VM\NIC NSG has a matching rule that denies traffic, packets are dropped.

  2. NSG applied to subnet: If a subnet NSG has a matching rule that denies traffic, packets are dropped, even if a VM\NIC NSG has a matching rule that allows traffic.

As most items in Azure there are Limits to the number of NSGs you can have in a subscription and number of rules per NSG. To learn more about the limits, read the Azure limits article.

Creating a network security group (NSG) is easy you can do this in the portal or with Powershell

As I mentioned above you can set the network security group (NSG) on a subnet or VM. Add multiple items in a network security group (NSG)

By default all is set to basic just pick a service and open or close the port.

But when checking the Advanced option the Rule pane will change into a rich and flexible option menu.

 

   Instead of selecting just a service You can also add a IP range to exclude others for accessing this machine.

Setting this in the GUI is nice but when you need to change or add a lot of these you will need Powershell or ARM templates.

Below are just some examples on how to use them

Login-AzureRmAccount
 
# Select a subscription
$subscriptionId = (Get-AzureRmSubscription | Out-GridView -Title ‘Select your Azure Subscription:’ -PassThru)
Select-AzureRmSubscription -SubscriptionId $subscriptionId.Id
 
# Select a Resource Group
$rgName = (Get-AzureRmResourceGroup | Out-GridView -Title ‘Select your Azure Resource Group:’ -PassThru).ResourceGroupName
 
# Set the NSG name and Azure region
$nsgName = "Trusted-Nsg01"
$location = "West Europe"
$source1 = "8.8.8.8/32"
$source2 = "8.8.4.4/32"
$source3 = "*"
$dest1="3389"
$dest2="443"
$dest3="80"
$tag="blog"

#Below are Sample Rules
$rule1 = New-AzureRmNetworkSecurityRuleConfig -Name rdp-rule -Description "Allow RDP" `
-Access Allow -Protocol Tcp -Direction Inbound -Priority 100 `
-SourceAddressPrefix $source1 -SourcePortRange * `
-DestinationAddressPrefix * -DestinationPortRange $dest1

$rule2 = New-AzureRmNetworkSecurityRuleConfig -Name web-rule2 -Description "Allow Port" `
-Access Allow -Protocol Tcp -Direction Inbound -Priority 101 `
-SourceAddressPrefix $source2 -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange $dest2

$rule3 = New-AzureRmNetworkSecurityRuleConfig -Name web-rule3 -Description "Allow Port" `
-Access Allow -Protocol Tcp -Direction Inbound -Priority 103 `
-SourceAddressPrefix $source3 -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange $dest3

$rule4 = New-AzureRmNetworkSecurityRuleConfig -Name web-rule4 -Description "Allow Port" `
-Access Allow -Protocol Tcp -Direction Inbound -Priority 104 `
-SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange 88

 

Now that the port Rules are created we need to put them in a security group

#applying the Rules
$nsg = New-AzureRmNetworkSecurityGroup -ResourceGroupName $rgName -Location $location -Name $nsgName -SecurityRules $rule1,$rule2,$rule3,$rule4

# Display default and security rules for NSG
 
(Get-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName).SecurityRules | Select-Object * | Out-GridView
(Get-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName).DefaultSecurityRules | Select-Object * | Out-GridView

#Remove NSG

Remove-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName

 

Now that we created a network security group (NSG) we can add it to a VM this can also be done with PowerShell but there is a BUT.

let me show you, Go to the VM and select the network card.

The Nic can be named nic245768323 something, I always use named NIC’s so that is easy but if not the NSG could be applied on an other VM and maybe it will fail.

When selecting this manual you can see the nic and if you are sure on the other machines you can do this with PowerShell also.

 

Follow Me on Twitter @ClusterMVP

Follow My blog https://robertsmit.wordpress.com

Linkedin Profile Http://nl.linkedin.com/in/robertsmit

Google Me : https://www.google.nl

Bing Me : http://tinyurl.com/j6ny39w

LMGTFY : http://lmgtfy.com/?q=robert+smit+mvp+blog

Share this:

The Enhanced Mitigation Experience Toolkit (EMET) helps raise the bar against attackers gaining access to computer systems. EMET anticipates the most common actions and techniques adversaries might use in compromising a computer, and helps protect by diverting, terminating, blocking, and invalidating those actions and techniques. EMET helps protect your computer systems even before new and undiscovered threats are formally addressed by security updates and antimalware software. EMET benefits enterprises and all computer users by helping to protect against security threats and breaches that can disrupt businesses and daily lives.

 

Download The Enhanced Mitigation Experience Toolkit (EMET) : http://www.microsoft.com/en-us/download/details.aspx?id=41963

 

EMET 5.0 Technical preview introduces a mitigation that can be used to reduce the exposure of components at risk to remote attackers. ASR is a new feature that can be used to block the usage of specific modules or plugins within an application. For example, EMET can be configured to prevent Microsoft Word/Excel from loading the Flash plugin, or, with the support of security zones, can be used to prevent Internet Explorer from loading the Java plugin on an Internet Zone website while continuing to allow Java on Intranet Zone websites. The mechanism simply prevents DLL loading in a selective way per-process and it essentially adds the benefit of the “killbit” mechanism to any application without need of complicated CLSID.
NOTE: The list of blocked modules for ASR and the zones with exceptions (where the modules are allowed to be loaded) should be manually defined by the user in the following registry key per-application:

HKLM\SOFTWARE\Microsoft\EMET\_settings_\{CLSID}\asr_modules = “…”
HKLM\SOFTWARE\Microsoft\EMET\_settings_\{CLSID}\asr_zones = “…”
In EMET 5.0TP the feature is enabled only for the following combinations of processes and modules:

The list of security zones is the standard one used by Internet Explorer: Local (0), Intranet (1), Trusted (2), Internet (3), Untrusted (4).

EMET offers the “Early Warning Program” reporting feature. When an exploitation attempt is detected and blocked by EMET, a set of information related to the attack will be sent back to Microsoft through the standard Windows Error Reporting channel.

This information will help Microsoft to obtain information related to 0day exploits and will facilitate the remediation of the issue before it becomes a large scale threat. If the vulnerability is related to a software from a third party vendor, Microsoft will work with the affected vendor through the Microsoft Vulnerability Research program to remediate the issue.

The Early Warning Program reporting feature will also send back to Microsoft information related to suspicious SSL certificates related to Microsoft online services. Please refer to the “Privacy Statement.rtf” file, available also through the “Help” ribbon in EMET GUI, and at http://aka.ms/emet41ps, for more information on the type of data that will be sent to Microsoft.