This article is contributed. See the original author and article here.
Adobe has released security updates to address vulnerabilities in multiple Adobe products. An attacker could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review Adobe’s Security Bulletins and apply the necessary updates.
This article is contributed. See the original author and article here.
Microsoft has released updates to address multiple vulnerabilities in Microsoft software. A remote attacker can exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review Microsoft’s May 2021 Security Update Summary and Deployment Information and apply the necessary updates.
This article is contributed. See the original author and article here.
Citrix has released security updates to address a vulnerability in Citrix Workspace App for Windows. An attacker could exploit this vulnerability to take control of an affected system.
CISA encourages users and administrators to review Citrix Security Update CTX307794 and apply the necessary updates.
This article is contributed. See the original author and article here.
Juniper Networks has released security updates to address multiple vulnerabilities in various Juniper products. An attacker could exploit some of these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review Juniper’s 2021-05 Out-of-Cycle Security Bulletin and apply the necessary updates.
This article is contributed. See the original author and article here.
Today we’re announcing the general availability (GA) of Azure Service Fabric managed clusters. Azure Service Fabric managed clusters remove the complexity associated with owning and operating Service Fabric clusters by simplifying deployment and management operations.
Azure customers use Service Fabric to manage both stateless and stateful microservices at scale. While our customers love the reliability, scalability, and richness of Service Fabric’s features, they have asked us to simplify the cluster deployment experience. Our customers have also requested simpler Service Fabric certificate management and scaling operations to facilitate deployments, testing, and scaling of their Service Fabric environment.
Service Fabric managed clusters provide a simplified ARM resource model for easier deployments. This resource model eliminates the need to define individual resources such as Virtual Machines (VMs), storage, or Virtual Networks that make up the cluster. Service Fabric managed clusters also eliminate the need for cluster certificate management by providing certificates that are fully managed by Azure. This ensures that customers don’t run into incidents caused by expired cluster certificates. With Service Fabric managed clusters, operations like removing a node type that previously required multiple steps, can now be completed in a single step. In addition, Service Fabric managed clusters provide full support for Service Fabric’s features. All these improvements together allow our customers to focus on their applications instead of infrastructure management.
“We recently started using Service Fabric and given our scale, we were concerned about the operational overhead of setting up our environments. We onboarded to Service Fabric managed clusters and were pleasantly surprised by the ease of deployment. It was a lot easier to read the simplified ARM template, add extensions, and deploy the cluster.” – Azure Usage Billing
“We operate multiple Service Fabric clusters. Rotating cluster certificates was a time-consuming yearly activity that took time away from application development. We were really excited to learn about the fully managed certificates enabled via Service Fabric managed clusters. Our operations team is elated that we no longer worry about an expired certificate bringing our environment down!” – Azure WAN
“Removing node types from a Service Fabric cluster required lots of steps, and time, which made it difficult to plan for our scaling needs. Service Fabric managed clusters make it really easy to add and remove node types with a single operation enabling us to scale on demand!” – Azure SQL Telemetry
Get started with Azure Service Fabric managed clusters
You can use Quickstart templates to get started with Service Fabric managed clusters or see the Azure Service Fabric managed clusters documentation to learn more. Additionally, you can learn more about all the new features in the release notes and submit feedback on the Service Fabric GitHub repository.
This article is contributed. See the original author and article here.
As we prepare to ship version 1.0 of Windows Package Manager, we wanted to provide guidance on how to manage Windows Package Manager using Group Policy.
We first announced the existence of Windows Package Manager at Microsoft Build in 2020. Designed to save you time and frustration, Windows Package Manager is a set of software tools that help automate the process of getting packages (applications) on Windows devices. Users can specify which apps they want installed and the Windows Package Manager does the work of finding the latest version (or the exact version specified) of that application and installing it on the user’s Windows 10 device.
When we released the Windows Package Manager v0.3.1102 preview, we provided an initial set of “Desktop App Installer Policies” Group Policy Administrative Template files (ADMX/ADML)—making it easy for you review and configure Group Policy Objects targeting your domain-joined devices. To download these ADMX files today, visit the Microsoft Download Center.
Not only to these new policies empower you to enable Windows Package Manager, they enable you to control certain commands and arguments, and configure the sources to which your devices connect.
The new Desktop App Installer policies are accessible via the Local Group Policy Editor in Windows 10 as shown here:
Any policies that have been enabled or configured will be shown when a user executes winget –info. The goal is to assist users in troubleshooting unexpected behaviors they may encounter in the Windows Package Manager because of any policies that are enabled or configured. For example, a user may attempt to modify a setting controlled by policy and not be able to understand why the device does not appear to honor their setting.
Before we proceed further, let’s clarify two basic terms used with respect to Windows Package Manager:
This policy controls whether Windows Package Manager can be used by users. Users will still be able to execute the winget command. The default help will be displayed, and users will still be able to execute winget -? to display the help as well. Any other command will result in the user being informed the operation is disabled by Group Policy.
If you enable or do not configure this setting, users will be able to use the Windows Package Manager.
If you disable this setting, users will not be able to use the Windows Package Manager.
This policy controls whether users can change their settings. The settings are stored inside of a .json file on the user’s system. It may be possible for users to gain access to the file using elevated credentials. This will not override any policy settings that have been configured by this policy.
If you enable or do not configure this setting, users will be able to change settings for Windows Package Manager.
If you disable this setting, users will not be able to change settings for Windows Package Manager.
This policy controls whether Windows Package Manager can be configured to enable the ability to override SHA256 security validation in settings. Windows Package Manager compares the installer after it has downloaded with the hash provided in the manifest.
If you enable or do not configure this setting, users will be able to enable the ability to override SHA256 security validation in Windows Package Manager settings.
If you disable this setting, users will not be able to enable the ability to override SHA256 security validation in Windows Package Manager settings.
This policy controls whether users can enable experimental features in Windows Package Manager. Experimental features are used during Windows Package Manager development cycle to provide previews for new behaviors. Some of these experimental features may be implemented prior to the Group Policy settings designed to control their behavior.
If you enable or do not configure this setting, users will be able to enable experimental features for Windows Package Manager.
If you disable this setting, users will not be able to enable experimental features for Windows Package Manager.
This policy controls whether users can install packages with local manifest files. If a user has a manifest available via their local file system rather than a Windows Package Manager source, they may install packages using winget install -m <path to manifest>.
If you enable or do not configure this setting, users will be able to install packages with local manifests using Windows Package Manager.
If you disable this setting, users will not be able to install packages with local manifests using Windows Package Manager.
This policy controls the auto-update interval for package-based sources. The default source for Windows Package Manager is configured such that an index of the packages is cached on the local machine. The index is downloaded when a user invokes a command, and the interval has passed (the index is not updated in the background). This setting has no impact on REST-based sources.
If you disable or do not configure this setting, the default interval or the value specified in settings will be used by Windows Package Manager.
If you enable this setting, the number of minutes specified will be used by Windows Package Manager.
This policy controls the default source included with Windows Package Manager. The default source for Windows Package Manager is an open-source repository of packages located at https://github.com/microsoft/winget-pkgs.
If you enable or do not configure this setting, the default source for Windows Package Manager will be available and can be removed.
If you disable this setting, the default source for Windows Package Manager will not be available.
This policy controls the Microsoft Store as a source included with Windows Package Manager.
If you enable or do not configure this setting, the Microsoft Store source for Windows Package manager will be available and can be removed.
If you disable this setting, the Microsoft Store source for Windows Package Manager will not be available.
This policy controls additional sources configured for Windows Package Manager.
If you do not configure this setting, no additional sources will be configured for Windows Package Manager.
If you enable this setting, additional sources will be added to Windows Package Manager and cannot be removed. The representation for each additional source can be obtained from installed sources using winget source export.
If you disable this setting, no additional sources can be configured by the user for Windows Package Manager.
This policy controls additional sources approved for users to configure using Windows Package Manager.
If you do not configure this setting, users will be able to add or remove additional sources other than those configured by policy.
If you enable this setting, only the sources specified can be added or removed from Windows Package Manager. The representation for each allowed source can be obtained from installed sources using winget source export.
If you disable this setting, no additional sources can be configured by the user for Windows Package Manager.
Version 1.0 of Windows Package Manager will soon ship as an automatic update via the Microsoft Store for all devices running Windows 10, version 1809 and later and we look forward to hearing your feedback. For more information on Windows Package Manager, please see the following resources:
Continue the conversation. Find best practices. Visit the Windows Tech Community.
Stay informed. For the latest updates on new releases, tools, and resources, stay tuned to this blog and follow us @MSWindowsITPro on Twitter.
This article is contributed. See the original author and article here.
This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, Version 9. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.
The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are aware of a ransomware attack affecting a critical infrastructure (CI) entity—a pipeline company—in the United States. Malicious cyber actors deployed DarkSide ransomware against the pipeline company’s information technology (IT) network.[1] At this time, there is no indication that the entity’s operational technology (OT) networks have been directly affected by the ransomware.
CISA and FBI urge CI asset owners and operators to adopt a heightened state of awareness and implement the recommendations listed in the Mitigations section of this Joint Cybersecurity Advisory, including implementing robust network segmentation between IT and OT networks; regularly testing manual controls; and ensuring that backups are implemented, regularly tested, and isolated from network connections. These mitigations will help CI owners and operators improve their entity’s functional resilience by reducing their vulnerability to ransomware and the risk of severe business degradation if impacted by ransomware.
Click here for a PDF version of this report.
Note: the analysis in this Joint Cybersecurity Advisory is ongoing, and the information provided should not be considered comprehensive. CISA and FBI will update this advisory as new information is available.
After gaining initial access to the pipeline company’s network, DarkSide actors deployed DarkSide ransomware against the company’s IT network. In response to the cyberattack, the company has reported that they proactively disconnected certain OT systems to ensure the systems’ safety.[2] At this time, there are no indications that the threat actor moved laterally to OT systems.
DarkSide is ransomware-as-a-service (RaaS)—the developers of the ransomware receive a share of the proceeds from the cybercriminal actors who deploy it, known as “affiliates.” According to open-source reporting, since August 2020, DarkSide actors have been targeting multiple large, high-revenue organizations, resulting in the encryption and theft of sensitive data. The DarkSide group has publicly stated that they prefer to target organizations that can afford to pay large ransoms instead of hospitals, schools, non-profits, and governments.[3],[4]
According to open-source reporting, DarkSide actors have previously been observed gaining initial access through phishing and exploiting remotely accessible accounts and systems and Virtual Desktop Infrastructure (VDI) (Phishing [T1566], Exploit Public-Facing Application [T1190], External Remote Services [T1133]).[5],[6] DarkSide actors have also been observed using Remote Desktop Protocol (RDP) to maintain Persistence [TA0003].[7]
After gaining access, DarkSide actors deploy DarkSide ransomware to encrypt and steal sensitive data (Data Encrypted for Impact [T1486]). The actors then threaten to publicly release the data if the ransom is not paid.[8],[9] The DarkSide ransomware uses Salsa20 and RSA encryption.[10]
DarkSide actors primarily use The Onion Router (TOR) for Command and Control (C2) [TA0011] (Proxy: Multi-hop Proxy [1090.003]).[11],[12] The actors have also been observed using Cobalt Strike for C2.[13]
CISA and FBI urge CI owners and operators to apply the following mitigations to reduce the risk of compromise by ransomware attacks.
AppData/LocalAppData folder.CISA and FBI urge CI owners and operators to apply the following mitigations now to reduce the risk of severe business or functional degradation should their CI entity fall victim to a ransomware attack in the future.
If your organization is impacted by a ransomware incident, CISA and FBI recommend the following actions:
Note: CISA and the FBI do not encourage paying a ransom to criminal actors. Paying a ransom may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or may fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered. CISA and FBI urge you to report ransomware incidents to your local FBI field office.
CISA offers a range of no-cost cyber hygiene services to help CI organizations assess, identify and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.
This article is contributed. See the original author and article here.
During 2016, Microsoft introduced a new product that allowed organizations to implement a sensitivity label taxonomy and empower information workers to leverage these and apply them to documents or emails as part of daily work. This product is known as “Azure Information Protection (AIP)” and uses a client application for the Windows platform which deployed an add-in within Office apps including introducing a new “Sensitivity” button that can be used by information workers to flag documents and emails according to their sensitivity.
Since then, Microsoft’s information protection platform has evolved, implemented across all common platforms (MacOS, iOS, Android, Web) and the Azure Information Protection Client with rich capabilities across Microsoft 365 and is now under the wide umbrella of Microsoft Information Protection offering.
The main change as part of the transition to Microsoft Information Protection is that sensitivity labels are available across all common platforms and do not require an add-in or additional implementation, they are just part of the service offering. If you are using Microsoft 365 apps for Enterprise (formerly known as Office 365 Professional Plus) and you deployed sensitivity labels within your organization, no additional deployment stage is required. The same “Sensitivity” button is now exposed within the application ribbon. This integration is applicable consistently to all supported platforms. Moving forward, this integrated capability is to be known as “Built-in sensitivity labeling.”
Fig. 1: Built-in labeling within Microsoft 365 apps for Enterprise
Using built-in labeling is seamless and does not require any management overhead in addition to cloud-based policy configuration. As part of your existing Microsoft 365 apps deployment, the bits are already available for every information worker without the need for installing additional components. The important aspects to consider are:
This is in line with other initiatives at Microsoft to provide built-in functionality that reduces or eliminates the need to deploy and maintain add-ins and plugins for other security and compliance-related functionality, which can potentially reduce an IT department’s challenges while providing a better user experience with more performance and stability to end users across workloads.
Azure Information Protection Client (or Unified Labeling Client) is an application package for the Windows platform that include 4 components:
Using built-in labeling replaces the first item in the list which is the Azure Information Protection add-in. Other components (described in number two, three, and four) can still be deployed without any dependency on the add-in portion of Azure Information Protection.
If you are using the Azure Information Protection add-in today and wish to use built-in sensitivity labeling instead to gain the benefits described above, then you can disable the add-in, uninstall the complete client, or control the behavior with a group policy. You have the choice to select the best approach which fits your business use cases and needs.
If you are NOT using the Azure Information Protection add-in today and looking to implement sensitivity labels across your organization, we recommend starting directly with built-in sensitivity labeling and deploy Azure Information Protection Client components (items described in number two, three, and four) if desired, but without enabling the AIP plugin for Office apps.
Fig. 2: Built-in labeling within Microsoft 365 apps highlight the sensitive information identifies within a Word document.
Built-in labeling is already available and in use as part of your deployment of sensitivity labels in MacOS, iOS, Android, and web apps. If you deployed your sensitivity labels policies then these are already enabled and deployed (Web apps integration need to be enabled separately as documented). The main requirement here is to ensure that you are using the right Microsoft 365 apps for Windows that support this capability.
Built-in labeling in Microsoft 365 apps for Windows is available in all updated releases with versions newer than 1910+. (How to check your version of Microsoft 365 apps). If you are using an up to date version, no matter if you use Current Channel or Semi-Annual Channel, the capability is there and operational.
We do recommend ensuring your organization Microsoft 365 apps update channel is set to Current Channel or Monthly-Enterprise channel. These channels get the latest and greatest features in a shorter time frame. If your organization is using the Semi-Annual channel, then updates are deferred for a later period. Read more about Microsoft 365 Apps update channels here.
Once you have ensured you are using a version of Microsoft 365 apps that is released after 1910 in your organization, all you need to do is to implement your labeling taxonomy in the Microsoft 365 Compliance portal and publish your labels. You can use the official documentation to understand more on the backend configurations that need to be done.
If you do want to use Azure Information Protection client capabilities side by side with built-in labeling (referring to PowerShell module, Classify & Protect app and, AIP Viewer), you can download and deploy the Azure Information Protection unified labeling client (available to be downloaded from this link). Then configure a Group Policy to ensure that built-in labeling will always override and disable the Azure Information Protection add-in component. Read more about how to configure the group policy here. With this deployment approach you can enjoy both from the benefits of using built-in labeling and additional components.
Azure Information Protection Client and built-in labeling for Microsoft 365 apps do not have feature parity today. As we move forward, built-in labeling will add more capabilities which are currently available in the Azure Information Protection client. It is important to understand that the key features available, which include:
Feature marked as :star: are exclusive to built-in labeling with Microsoft 365 apps.
Read more about the feature comparison between Azure Information Protection Client and built-in labeling for Microsoft 365 apps here.
In addition, see complete roadmap and timelines for additional features within built-in labeling for Microsoft 365 apps here.
In perpetual versions of Microsoft 365 apps (Office 2013, 2016, 2019) built-in labeling is not included, so if you are using one of these versions you will need to use the Azure Information Protection client and add-in for Office instead.
Do note that using built-in labeling does require sensitivity labels to be configured and published in the M365 Compliance portal (or Office 365 Security and Compliance portal). If your sensitivity labels are deployed as part of the Classic platform in Azure, please ensure you are migrating to unified sensitivity labels as documented here.
This article is contributed. See the original author and article here.
Azure support for user-assigned managed identity is now generally available! With today’s release, you can now use the user-assigned managed identity to connect your hubs to resources that support Azure Active Directory (Azure AD) authentication.
There are two different types of managed identities: system-assigned and user-assigned managed identity. In IoT Hub, managed identities can be used for egress connectivity from IoT Hub to Azure blob storage, event hub and service bus resources for message routing, file upload, and bulk device import/export. IoT Hub has the existing support for the system-assigned managed identity, and now we are adding support for user-assigned managed identity as well.
Both system-assigned and user-assigned managed identity come with the common benefits of using the managed identities:
With the support for both system-assigned and user-assigned managed identity in IoT Hub, you’re able to select different types based on your scenarios and requirements.
To get started, create a user-assigned managed identity as a standalone resource and add the identity to your IoT Hub. Instructions and samples are published on our documentation page IoT Hub support for managed identities.
This article is contributed. See the original author and article here.
CISA and the Federal Bureau of Investigation (FBI) have released a Joint Cybersecurity Advisory (CSA) on a ransomware-as-a-service (RaaS) variant—referred to as DarkSide—recently used in a ransomware attack against a critical infrastructure (CI) company.
Cybercriminal groups use DarkSide to gain access to a victim’s network to encrypt and exfiltrate data. These groups then threaten to expose data if the victim does not pay the ransom. Groups leveraging DarkSide have recently been targeting organizations across various CI sectors including manufacturing, legal, insurance, healthcare, and energy.
Prevention is the most effective defense against ransomware. It is critical to follow best practices to protect against ransomware attacks, which can be devastating to an individual or organization and recovery may be a difficult process. In addition to the Joint CSA, CISA and FBI urge CI asset owners and operators to review the following resources for best practices on strengthening cybersecurity posture:
Victims of ransomware should report it immediately to CISA, a local FBI Field Office, or a Secret Service Field Office.
Recent Comments