Protect your web applications from all attack vectors with Barracuda and Microsoft Azure

by Contributed | Sep 29, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Organizations are increasingly moving to Microsoft Azure, and the recent rise in distributed workforces has accelerated the pace. Just a few years ago, most applications were lifted and shifted from on-premises to the cloud before companies started to favor deploying cloud-native applications. However, with the COVID-19 pandemic forcing more employees to work from home, the lift-and-shift approach to the cloud has once again gained momentum.

Tushar Richabadas, Senior Product Manager – Application Security, Barracuda, explains how Barracuda WAF-as-a-Service, available in the Microsoft Azure Marketplace, addresses some of the security issues caused by a rapid shift to the cloud from on-premises:

Companies are moving to the cloud faster than ever to accommodate the surge of employees working from home. Applications that were previously accessible only over a company’s intranet must now be accessible from the internet. However, security can often take a back seat when providing a distributed workforce with fast application access – causing problems later.

One such problem is possible security gaps. This necessitates products that secure deployments in the journey to the cloud. Starting from secure remote access to protecting against application attacks and DDoS, enterprises need solutions that are easy to deploy and fully automated for rapid deployments.

Barracuda CloudGen WAF for Azure and Barracuda WAF-as-a-Service protect web, mobile, and API applications against all application attacks, including zero-day attacks, DDoS attacks, and malicious bot attacks. Their Advanced Bot Protection capability uses Azure Machine Learning to identify and block advanced almost-human bots and account-takeover attempts.

Looking for a solution your organization will manage? Barracuda CloudGen WAF for Azure can offload authentication and help enforce two-factor authentication (2FA), single sign-on (SSO), and multi-domain SSO. It can also communicate with Azure Active Directory, Active Directory Federation Services, or any LDAP, RADIUS, SAML, or OpenID Connect solution to provide access control to applications.

If you have a distributed workforce that needs to access applications from geo-dispersed locations, Barracuda WAF-as-a-Service offers the same proven application security, but as a service hosted on Azure. Barracuda WAF-as-a-Service is deployed in every Azure region worldwide and allows users to add endpoints to the regions closest to their customers and/or workforce to provide fast and secure application access.

Barracuda solutions for Azure are built to work in a near-native manner. CloudGen WAF for Azure delivers complete application security and integrates closely with Azure services, including virtual machine scale sets, Azure Active Directory, log analytics, Event Hubs, and more. Barracuda WAF-as-a-Service is built on Azure and provides the same level of security, as a service.

As e-commerce and distributed workforces continue to grow around the world, ensure your organization provides customers and remote employees with secure, reliable access to the applications they need to keep business moving forward.

Learn more about Barracuda WAF-as-a-Service and see a product demo in this on-demand webinar featuring Keith Vidal, Director Business Program Management, Microsoft; Nitzan Miron VP Product Management, Application Security, Barracuda Networks; and Shab Jahan, Product Marketing Manager, Public Cloud, Barracuda Networks.

Security Controls in Azure Security Center: Manage Access and Permissions

by Contributed | Sep 29, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Continuing our Secure Score series of blog posts, this post will discuss how to manage access and permissions from an Azure Security Center perspective and walk through the respective recommendations.

Access management for cloud resources is a critical function for any organization that is using the cloud. Using Role-based access control (RBAC), an authorization system built on Azure Resource Manager, is the best way to manage access to resources by creating role assignments. Azure role-based access control helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.
In Azure Security Center, we have a dedicated security control named “Manage access and permissions”, which contains our best practices for different scopes.

Why manage access and permissions is so critical?

A core part of a security program is ensuring your users have the necessary access to do their jobs but no more than that: the least privilege access model. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions at a particular scope.
You can control access to your resources by creating role assignments with role-based access control (RBAC). A role assignment consists of three elements:

• Security principal: the object the user is requesting access to (for example, user or group)
• Role definition: their permissions based on built-in or custom roles (for example: owner or contributor)
• Scope: the set of resources to which the permissions apply (for example: subscription or management group)

As you learned in this blog post (blog series), recommendations are grouped in Security Controls.
In Azure Security Center, we have several recommendations based on 4 different scope: Subscriptions, Kubernetes, Storage accounts and Service Fabric resources. All of them are available as part of the “Manage access and permissions” security control which has the max score of 4 points.

What’s included within the Manage access and permissions security control?

Let’s dive into the available recommendations as part of this control. Each one is a built-in policy definition contained within the Azure Portal; all definitions are available in Azure Policy blade.

• External accounts with write permissions should be removed from your subscription
• External accounts with owner permissions should be removed from your subscription
• Deprecated accounts should be removed from your subscription
• Deprecated accounts with owner permissions should be removed from your subscription
• There should be more than one owner assigned to your subscription
• Service principals should be used to protect your subscriptions instead of Management Certificates [Preview]
• Role-Based Access Control (RBAC) should be used on Kubernetes Services
• Azure Policy Add-on for Kubernetes should be installed and enabled on your clusters [Preview]
• Privileged containers should be avoided [Preview]
• Least privileged Linux capabilities should be enforced for containers [Preview]
• Immutable (read-only) root filesystem should be enforced for containers [Preview]
• Usage of pod HostPath volume mounts should be restricted to a known list to restrict node access from compromised containers [Preview]
• Running containers as root user should be avoided [Preview]
• Containers sharing sensitive host namespaces should be avoided [Preview]
• Container with privilege escalation should be avoided [Preview]
• Service Fabric clusters should only use Azure Active Directory for client authentication
• Storage account public access should be disallowed [Preview]

As listed above, a subset of recommendations was recently released as “Preview”. Security Center no longer includes preview recommendations when calculating the Secure Score. Preview recommendations are still available to allow exploration and remediation of the unhealthy resources across your Azure subscriptions.

Category #1: Recommendations for Azure Subscriptions

An Azure subscription refers to the logical entity that provides entitlement to deploy and consume Azure resources. Like any other Azure service, a subscription is a resource which you can assign RBAC on. Azure Security Center provides access and permissions recommendations for subscriptions too. Those are breakdown to sub-categories: external accounts, deprecated accounts, and administrative accounts.

• External accounts with permissions – Extremal accounts in Azure AD are accounts having different domain names than the one which is being used corporate identities (such as Azure AD B2B collaboration, Microsoft Accounts, etc.). Usefully, those accounts are not managed or monitored by the organization and can be targets for attackers looking to find ways to access your data without being noticed. Recommendations will suggest to remove external account with either of the following permissions: owner/write/read (classic-administrators permissions are part of owner role).
  Deprecated accounts – Security Center consider deprecated accounts as the ones which are  stored in Azure AD and have been blocked from signing-in. The same as the external account, these accounts can be targets for attackers looking to find ways to access your data without being noticed.
  Such accounts could have owner permissions on the subscription.
• Administration accounts – One of our best practices is to have more than one owner assigned to a subscription in order to have administrator access redundancy and. Additionally, we recommend to have maximum of 3 owners, in order to reduce the potential for breach by a compromised owner.
  So, the recommendation is to have 2 owners per subscription. Currently, this recommendation check existence of direct assignment at the subscription and not the inherited ones by a management group. Moreover, security groups are currently not supported either. And lastly, to manage your subscriptions more securely, once you decide for the required owners, we recommend using user accounts or service principals rather than management certificates.

The following recommendations belong to this category:

• External accounts with write permissions should be removed from your subscription
• External accounts with owner permissions should be removed from your subscription
• Deprecated accounts should be removed from your subscription
• Deprecated accounts with owner permissions should be removed from your subscription
• There should be more than one owner assigned to your subscription
• Service principals should be used to protect your subscriptions instead of Management Certificates [Preview]

Category #2: Recommendations for Kubernetes

To ensure your Kubernetes workloads are secure by default, Security Center provided Kubernetes-level policies and hardening recommendations, including enforcement options with Kubernetes admission control. We recently announced the deprecation of preview AKS recommendation “Pod Security Policies should be defined on Kubernetes Services”. In favor, we replaced it with 13 new recommendations for AKS workload protection where 7 of them are part of the discussed security control. Those new recommendations allow you to audit or enforce them and are based on the Azure Policy Add-on for Kubernetes. This add-on extends Gatekeeper v3, to apply at-scale enforcements and safeguards on your clusters in a centralized, consistent manner.

The new recommendations allow you to:

• Provide granular filtering on the actions that users can perform by using RBAC to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies.
• Reduce entry points for attacks and to spread malicious code or malware to compromised applications, hosts and networks.
• Reduce attack surface of container by restricting Linux capabilities and granting specific privileges to containers without granting all the privileges of the root user.
• Prevent unrestricted host access (privileged containers have all the root capabilities of a host machine).
• Protect containers from changes at run-time with malicious binaries being added to PATH.
• Prevent from an attacker to use root and exploit misconfigurations.
• Protect against privilege escalation outside the container by avoiding pod access to sensitive host namespaces in a Kubernetes cluster.

During the preview phase, few of the above recommendations will be disabled by default. To enable them or adjust the settings to your needs, modify the “ASC Default” initiative assignment:

The following recommendations belong to this category:

• Role-Based Access Control (RBAC) should be used on Kubernetes Services
• Azure Policy Add-on for Kubernetes should be installed and enabled on your clusters [Preview]
• Privileged containers should be avoided [Preview]
• Least privileged Linux capabilities should be enforced for containers [Preview]
• Immutable (read-only) root filesystem should be enforced for containers [Preview]
• Usage of pod HostPath volume mounts should be restricted to a known list to restrict node access from compromised containers [Preview]
• Running containers as root user should be avoided [Preview]
• Containers sharing sensitive host namespaces should be avoided [Preview]
• Container with privilege escalation should be avoided [Preview]

Category #3: Recommendation for Storage accounts

By default, a storage account is configured to allow a user with the appropriate permissions to enable public access to a container.
When public access is allowed, a user with the appropriate permissions can modify a container’s public access setting to enable anonymous public access to the data in that container. Frequently, anonymous public read access to containers and blobs in Azure Storage is a convenient way to share data but might present security risks. Disallowing public access for the storage account prevents anonymous access to all containers and blobs in that account. Moreover, it prevents data breaches caused by undesired anonymous access, Microsoft recommends preventing public access to a storage account unless your scenario requires it.

The following recommendation belong to this category:

• Storage account public access should be disallowed [Preview]

Category #4: Recommendation for Service Fabric

Azure Service Fabric allow few authentication options to secure the access to management endpoints from client  to cluster – to ensure that only authorized users can access the cluster and its management endpoint. Such options are certification authentication or Azure Active Directory authentication.
Azure Security Center recommend performing client authentication only via Azure Active Directory.

The following recommendation belong to this category:

• Service Fabric clusters should only use Azure Active Directory for client authentication

Next Steps

In this blog we all recommendations related to manage access and permissions security control; from protecting subscriptions down to PaaS services like Kubernetes, Service Fabric and Storage accounts. To gain credit and increase your overall Secure Score, you must remediate all recommendations within the control.

Additionally, few recommendations like the Kubernetes one, were automatically configured with default parameters – please make sure to review and customize its values via Security Policy tab.

I hope you enjoyed this blog post and learned how this speisific control can assist you to strengthen your Azure security posture.

• The main blog post to this series (found here)
• The DOCs article about Secure Score (this one) 

Reviewers

How to Change collation for production Azure SQL databases

by Contributed | Sep 29, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

In this article I will explain how to change the collation for your production Azure SQL Databases without loosing data/updates on the database with a minimum downtime.

Steps in brief:

• Take a copy of the production database to a higher service tier ex: P11 on the same server.
• Export the database to bacpac using SQLPackage. (It’s better to use a VM in the same region of the SQL server for less latency)
• Modify the collation by editing the model.xml file.
• Import the database again to a higher service tier ex: P11 by using SQLPackage and overriding the model.xml path.
• Change the database name, or modify app connection string to use the new database.

Things to consider:

• Azure SQL Database only supports changing collation by modifying the model.xml file for .bacpac files.
• Schedule a maintenance window for your application during the process and stop the workload to prevent loosing updates on your database.
• Do the export/import to/from databases with a higher service tier to boost the operation.
• Use a VM in the same region to save latency time.
• If your database is/was used for Data Sync Service, consider removing DSS object before exporting the database. Check: https://techcommunity.microsoft.com/t5/azure-database-support-blog/exporting-a-database-that-is-was-used-as-sql-data-sync-metadata/ba-p/369062
• If your database is a part of Geo-DR replication, consider removing the Geo link and delete secondary database before starting the operation in order to create a new Geo replication and sync the new database with the new collation to the secondary server.

Steps in details:

1. Make sure you have a modern version of SQLPackage.

• Latest SQLPackage version is here .
• Sqlpackage installs to the C:Program FilesMicrosoft SQL Server150DACbin directory.

2. Start the maintenance window for your application.

3. Make a copy of the production database to a higher service tier ex: P11.

    How to copy SQL databases: https://docs.microsoft.com/en-us/azure/azure-sql/database/database-copy?tabs=azure-powershell#copy-using-the-azure-portal

4. Export the copied database using SQLPackage from a VM on the same region of your SQL server.

• Open CMD > Navigate to SQLPackage location > ex: “C:Program FilesMicrosoft SQL Server150DACbin” .

• Run the below command to export the database:

         sqlpackage.exe /Action:Export /ssn:tcp:<ServerName>.database.windows.net,1433 /sdn:<DatabaseName> /su:<UserName> /sp:<Password> /tf:<TargetFile> /p:Storage=File

5. Change the database collation in the bacpac model.xml file:

• Open the .bacpac file using WinRAR without de-compress the file.

• Copy the model.xml to a local folder “C:Tempmodel.xml”.

• Edit the “C:Tempmodel.xml” with the desired collation and save the file.

For example:

From: <Property Name=”Collation” Value=”SQL_Latin1_General_CP1_CI_AS” />

To: <Property Name=”Collation” Value=”Hebrew_CI_AS” />

6. Run the import using sqlpackage.exe, and use the /ModelFilePath:C:Tempmodel.xml parameter to override the model.xml in the .bacpac.

For example:
sqlpackage.exe /Action:Import /tsn:<server>.database.windows.net /tdn:<database> /tu:<user> /tp:<password> /sf:”C:Tempdatabase.bacpac” /ModelFilePath:C:Tempmodel.xml /p:DatabaseEdition=Premium /p:DatabaseServiceObjective=P11

7. When the import operation completed, Change the database name, or modify the application connection string to use the new database.

8. Stop the maintenance window for your application and run workload.

9. Delete the copied and old databases.