by Scott Muniz | Jan 20, 2022 | Security, Technology
This article is contributed. See the original author and article here.
Google has released Chrome version 97.0.4692.99 for Windows, Mac, and Linux. This version addresses vulnerabilities that an attacker could exploit to take control of an affected system.
CISA encourages users and administrators to review the Chrome Release Note and apply the necessary update as soon as possible.
by Contributed | Jan 19, 2022 | Technology
This article is contributed. See the original author and article here.
Azure Firewall is a managed stateful network security service that recently became generally available for premium features across most Azure regions, providing capabilities such as TLS inspection, URL filtering and more
Across the different virtual networks and subscriptions, rules are created for network segmentation and access control. Managing the network traffic may require you to audit rules for utilization, flow hit count or require a previous working configuration.
This runbook will help create instantaneous back-up copies of Azure Firewall with the Firewall Policy and when scheduled with an automation account, you can take daily/weekly snapshots and store them in a specified path.
For this runbook, Azure blob storage will be used to store Azure Firewall configuration for both network infrastructure and firewall policy at the time of the dump. You can edit the template to specify another storage method. We also discuss how to redeploy a firewall to a known configuration using one of the backed-up templates. For more information on other network resources that you may like to adapt to this runbook, please see the Export-AzResourceGroup module.
Requirements
- Automation account
- Storage Account
- Runbook
Set up Automation account
Go to the Search bar and type Automation account. Create a New Automation account. When done, go to the Automation account and in the Settings blade, under Account settings, create a “Run As” account. This provide the service principal access that will be used to auto-login into our script later.

This runbook is a PowerShell module and we need to confirm that we have access to network and resources modules. On the Automation account blade which you have just created, go to Modules and then search the Gallery to import the following three requisites:
– Az.Account
– Az.Network
– Az.Resources

Create Storage account
Next, we create a storage account to store each back-up created in Azure Blob storage. Go to the search bar for resources and search for Storage Account. Create a Storage account. Select Cool storage mode

Next, we create the Runbook.
On the Automation account blade, click on Runbooks and create one. Here below, I have created AzFwBackUp.

After creating the runbook, copy the code from our Azure Network Security Github repository and paste it in line one. This code has three functions: 1. Create storage, 2. Export the firewall configuration, and save in the storage, and 3. Purge the older backups. It uses the Get-AzFirewall and Get-AzFirewallPolicy cmdlet to create snapshot instances.
Click Save and then click on Test Plane.

On the next page, you will be prompted for a few parameters which you have set up earlier:
- Provide the resource group name, Azure Firewall name and Firewall Policy name, obtainable in your Resource group
- Provide storage account name that was created in the step earlier above and the storage key. The storage key can be obtained under “Access Keys” in the Storage Account blade (see image below).
- Give it a Blob container name and specify a retention date. Back-ups older than this date will be deleted at next run.

Test the script
Click Start to begin the dry run to confirm you can store a copy of the current configuration. Once done, you can then proceed to create a schedule to make this run periodically.

The back-up should be available in your Storage -> Container in .json format.
Create a schedule
To create a schedule, go to the Runbook that was created, at the Runbook blade, select Schedules -> Add a Schedule. Give it a name and select “Recurring” Configure for every week or month.

Click to “Link the schedule to the runbook.” Select the runbook you have created and then click “Configure parameters and run settings,” Fill this form as done earlier.
The Runbook should now be all set to create back-ups in. json template that may be used to restore the firewall to an earlier configuration. The storage account should now store your back-ups as specified.

Restore Azure Firewall
To restore an Azure firewall (firewall infrastructure and firewall policy) to an earlier configuration, run the following syntax in your Cloud shell:
New-AzResourceGroupDeployment -name $azurefirewallname -ResourceGroupName $resourcegroupname -TemplateFile $filepath
Note that Rule Collection Groups or RCGs are treated as dependency objects and these objects cannot be deployed in parallel. Collection groups all reference the policy as dependant (dependsOn in the arm template).
This means it will first update policy and then try to update all rule collection groups in parallel. This may fail due to the policy dependency issue. (This is currently by ARM (Azure Resource Manager) design and a roadmap item).
Hence, rule collection groups must be deployed one after the other using the “depends on” tag in your firewall backup file.
As an example, the Rule Collection Group would have to be edited using the rule processing order.
The format is to first specify the Firewall Policy name, then Policy RCG object.
"type": "Microsoft.Network/firewallPolicies/ruleCollectionGroups",
"apiVersion": "2020-11-01",
"name": "SOC-NS-FWPolicy_premium/DefaultNetworkRuleCollectionGroup",
"location": "westus2",
"dependsOn": [
"[resourceId('Microsoft.Network/firewallPolicies', 'SOC-NS-FWPolicy_premium')]",
"[resourceId('Microsoft.Network/firewallPolicies/ruleCollectionGroups', 'SOC-NS-FWPolicy_premium','DefaultDnatRuleCollectionGroup')]"
]
(Also, confirm that the KeyVault information is not missing after the redeployment is complete)
In summary, you may need to export firewall settings when creating child policies, restoring from a wrong configuration, auditing rules etc. By setting up frequent back up schedule, you can create a historical record of your configuration.
For more information about Azure firewall use cases and governance information, see the Azure Network Security TechCommunity blog
by Scott Muniz | Jan 18, 2022 | Security, Technology
This article is contributed. See the original author and article here.
CISA has added 13 new vulnerabilities to its Known Exploited Vulnerabilities Catalog, based on evidence that threat actors are actively exploiting the vulnerabilities listed in the table below. These types of vulnerabilities are a frequent attack vector for malicious cyber actors of all types and pose significant risk to the federal enterprise.
| CVE Number |
CVE Title |
Required Action Due Date |
| CVE-2021-32648 |
October CMS Improper Authentication |
2/1/2022 |
| CVE-2021-21315 |
System Information Library for node.js Command Injection Vulnerability |
2/1/2022 |
| CVE-2021-21975 |
Server Side Request Forgery in vRealize Operations Manager API Vulnerability |
2/1/2022 |
| CVE-2021-22991 |
BIG-IP Traffic Microkernel Buffer Overflow Vulnerability |
2/1/2022 |
| CVE-2021-25296 |
Nagios XI OS Command Injection Vulnerability |
2/1/2022 |
| CVE-2021-25297 |
Nagios XI OS Command Injection Vulnerability |
2/1/2022 |
| CVE-2021-25298 |
Nagios XI OS Command Injection Vulnerability |
2/1/2022 |
| CVE-2021-33766 |
Microsoft Exchange Server Information Disclosure Vulnerability |
2/1/2022 |
| CVE-2021-40870 |
Aviatrix Controller Unrestricted Upload of File Vulnerability |
2/1/2022 |
| CVE-2020-11978 |
Apache Airflow Command Injection Vulnerability |
7/18/2022 |
| CVE-2020-13671 |
Drupal Core Unrestricted Upload of File Vulnerability |
7/18/2022 |
| CVE-2020-13927 |
Apache Airflow Experimental API Authentication Bypass Vulnerability |
7/18/2022 |
| CVE-2020-14864 |
Oracle Corporate Business Intelligence Enterprise Edition Path Traversal Vulnerability |
7/18/2022 |
Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known CVEs that carry significant risk to the federal enterprise. BOD 22-01 requires FCEB agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information.
Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the Catalog that meet the meet the specified criteria.
by Contributed | Jan 18, 2022 | Technology
This article is contributed. See the original author and article here.
Hello again! I’m Jeff Sakowicz, Principal Program Management Lead for Application Platform Security within the Microsoft Identity team. Our team’s goal is to foster a secure, trustworthy, and thriving app ecosystem. Part of achieving this goal is enabling apps to support a Zero Trust security model.
This is the second post in our series on why Zero Trust matters for developers. In the previous post, I introduced the Zero Trust principles and how they apply to identity and access management. In this post, I will focus on how you can design apps using the principle of least privileged access with the Microsoft identity platform.
Why should you care about using least privileged access?
In short, by limiting what your app has permission to do, you reduce the potential blast radius of attacks and increase adoption of your apps by customers. In our experience, IT administrators are sensitive to the levels of permission being requested by applications and are applying more scrutiny when deciding whether to grant a given app permissions. When you create an app that asks for a lot of permissions, it will be less likely to be approved or could be denied altogether.
What is overprivilege and what is an overprivileged app?
When an entity asks for, and in some cases is granted, more permissions than it needs, we call it “overprivileged.” In this post we will focus exclusively on overprivileged applications with respect to OAuth2.0 permissions in the Microsoft Identity platform and use example scenarios of client apps that call the Microsoft Graph API. That said, principles in this blog do apply to other permission models and APIs – we’ll cover this more in future posts.
Overprivilege occurs when an app has requested and been granted unused or reducible permissions:
- Unused permission: Permission that is not necessary at all for the desired tasks. For example, a calendar app that obtains the Files.ReadWrite.All permission but doesn’t integrate with any Files APIs has unused permissions.
- Reducible permission: Permission that has a lower-privileged alternative that would still provide the access for required tasks. For example, consider an application that needs to read files from the signed-in user’s OneDrive, but never needs to create new files or modify existing ones. If this app has requested and been granted Files.ReadWrite.All, it has a reducible permission. Instead, it should be requesting Files.Read.
What are the goals in combatting overprivileged apps?
There are three main goals for us in the Microsoft Identity team in terms of combatting overprivileged apps:
- Help developers to build trustworthy apps that are adopted smoothly by avoiding excessive permissions, since requesting unnecessary privileges creates friction with users, IT, and policies applied to app consent within an environment.
- Help IT Admins and other decision makers understand how to identify, request, and grant least privileged permissions in their organization to limit overprivileged apps.
- Prevent attackers from gaining elevated privileges that increase the scope of compromise and enable lateral movement within an environment.
How can you ensure your apps become least privileged?
Here are three high level best practices for developers and IT Admins to keep in mind when thinking about adhering to the least privileged principle for applications:
- Prevent overprivilege by avoiding unused and reducible permissions. Fully understand the permissions required for the API calls that your application needs to make, and only request what is necessary to enable your scenario.
- Audit the privileges that have been previously granted to existing apps in your app portfolio on a regular basis, identifying opportunities for privilege reduction or removal. This means IT admins audit the permissions consent granted to apps within their tenant and developers review the permissions that their apps are requesting.
- Remediate by updating apps to stop requesting unused and reducible permissions and revoke previously granted permissions that are no longer necessary.
Microsoft has tools that help you with this process. For example, when Then, you can find the corresponding permissions from least to most privileged for Microsoft Graph by using this handy permissions reference.
Learn more about specific steps in the documentation here: https://aka.ms/least-privilege.
How to start building Zero Trust readiness
To even learn more, check out the new guidance for developers we’ve published to the Zero Trust Guidance Center. It includes new development and integration resources for developing Zero Trust-ready apps.
For more details, read the full whitepaper for developers that can be downloaded here: Zero Trust for the Microsoft Identity developer
Learn more about Microsoft identity:
Recent Comments