Microsoft has released security updates: Exchange Server 2013, Exchange Server 2016, Exchange Server 2019
Vulnerabilities addressed in the April 2021 security updates were responsibly reported to Microsoft by a security partner. Although we are not aware of any active exploits in the wild, our recommendation is to install these updates immediately to protect your environment.
These vulnerabilities affect Microsoft Exchange Server. Exchange Online customers are already protected and do not need to take any action.
For additional information, please see the Microsoft Security Response Center (MSRC) blog. More details about specific CVEs can be found in Security Update Guide (filter on Exchange Server under Product Family).
New Microsoft Defender for Endpoint capabilities let organizations discover
and secure unmanaged workstations, mobile devices, servers, and network
devices.
Several customers have approached me on how to configure Splunk antivirus
exclusions for processes, folders, and files within Microsoft Defender for
Endpoint on RedHat Enterprise Linux. This quick reference article has
been created to address this common question.
Title:
How far have we come? The evolution of securing identities
Building a timeline of a cyber security incident is one of the most critical
parts of affective incident investigation and response. It is essential in
order to understand the path of the attack, its scope and to determine
appropriate response measures.
Now in public preview, we are redesigning the Azure Sentinel full incident
page to display the alerts and bookmarks that are part of the incident in a
chronological order. As more alerts are added to the incident, and as more
bookmarks are added by analysts, the timeline will update to reflect the
information known on the incidents.
Earlier today, we announced a new set of capabilities for Microsoft Defender for Endpoint that empower organizations
to discover and secure network devices and unmanaged endpoints. This is
especially critical in the new global hybrid working environment, which exposes
the most challenging cybersecurity landscape we’ve ever encountered. This blog provides
more information on the unmanaged endpoint discovery feature while an
additional blog provides more information on how to configure the
network device discovery feature.
The
challenge – unmanaged endpoints
In recent years, the efficacy of Endpoint Protection
(EPP) and Endpoint Detection and Response
(EDR) platforms has continued to increase. With the rise
of unified SIEM and XDR (extended detection and response) solutions,
like Microsoft 365 Defender, the level of
efficacy that our
customers are benefiting from continues to improve. To
fully utilize these solutions to defend your environment, it’s critical to
have full visibility of all the devices in your organization. You can’t protect
what you can’t see!
David Weston, Microsoft Director of Enterprise and OS Security,
advises:
“The
riskiest threat is the one you don’t know about. Unmanaged devices are
literally one of your weakest links. Smart attackers go there first. With
work-from-home, the threat has grown exponentially, making
discovering and applying security controls to these devices mission
critical.”
There have been many examples where unmanaged devices were exploited and led
to a breach, such as the Equifax breach. In this case the breach originated via an
unpatched vulnerability on an internet-facing server. This might have been
easily addressed except for the fact that the server was unmanaged–no one knew
it needed patching. Those responsible for the security profiles and policies of
these devices were basically unaware of its existence.
Unmanaged
endpoint discovery in Microsoft Defender for Endpoint
To address scenarios like this we’re adding unmanaged endpoint discovery to
Microsoft Defender for Endpoint to help customers discover and secure unmanaged
endpoints on their corporate network. This will help detect and report upon any
device seen on a corporate network that can be onboarded and secured by
Microsoft Defender for Endpoint.
As part of this new functionality, two forms of discovery are provided
including Standard and Basic. For public preview all tenants will
initially have Basic discovery configured which uses unicast or
broadcast network events captured by the onboarded devices to discover unmanaged
endpoints. Basic discovery uses the SenseNDR.exe binary for passive network
data collection and no network traffic will be initiated. On May 10,
unless otherwise configured by the tenant, we will automatically switch from
Basic to our recommended form of discovery which is called Standard discovery.
This is an active discovery method where managed devices actively probe the
network to identify unmanaged devices. From here the interfaces on discovered
devices are leveraged to collect threat, vulnerability and metadata used for
device fingerprinting. Standard discovery builds a deeper more complete picture
of the discovered devices than Basic mode and and allows for vulnerability
assessments.
When you go to Microsoft 365 security console you will see two new tiles
available. The first shows “Devices to onboard” and will present all
devices seen in the last 30 days. We also check whether the device has been
seen more than just once over a 3-day period. This prevents a recommendation
appearing to onboard a device that was plugged onto the network once, then
won’t be seen again.
The second tile is “Discovered devices in my network” and will be broken
down into device types.
Once discovered, the devices will appear in the Device
Inventory. Clicking the button to “View recently discovered devices” will take
you straight to where we have a new set of filters available where you can
apply criteria relevant to these new devices, as shown in the screenshot below:
This data is then used as part of the security
recommendations within threat and vulnerability management. You can go to the
Security recommendations section under Vulnerability management and type
“Onboard” into the Search box to see discovered devices eligible for
onboarding:
Once you know about these devices, you can start to onboard them into
Defender for Endpoint. This empowers you to close the unmanaged endpoint gap in
your environment which is an easy target for attackers. By using the
remediation options presented as part of the Security Recommendations, you can
open a ticket in Microsoft Endpoint Manager to remediate and onboard the
device.
Advanced hunting has also been improved to allow you to query these devices
and export data with whatever columns you like:
“Timestamp” and “ReportId” lets you run this as a custom detection. For
example, you could write a rule to generate an alert whenever a device is
connected to a certain subnet.
We have also exposed “Onboarding Status” in the API and in the connector for
Azure Sentinel, to provide visibility into security tooling you might have in
place.
Enabling
discovery
You will see that endpoint discovery is enabled on your
tenant through a banner that appears in Device inventory . This banner
will be available until the automatic switch from Basic to Standard discovery
occurs on May 10th, giving you the option to easily spot and switch over to
Standard discovery as soon as you are ready.
If you don’t want Standard discovery to be automatically
enabled on May 10, you also have the option to go to Device discovery in
settings and select Basic discovery to ensure the automatic change doesn’t
occur.
Controlling
discovery
Although we recommend using Standard discovery, there may be conditions that
justify applying controls to the discovery process. When Standard discovery
actively probes the network, it uses two PowerShell scripts. These PowerShell
scripts are Microsoft signed, and are executed from the following
location:
If you are using other security tooling in your environment, there is a
possibility these scripts could cause alerts to be raised in those
tools. To avoid this situation, we suggest adding the path the scripts are
run from to the allow list within your tooling. We also provide customization
capabilities around which devices will perform Standard discovery and thus run
the scripts. When you enable Standard discovery, the default mode is that all
managed Windows 10 devices perform this task. To change this you can leverage a
tagging feature which enables you to restrict the execution of the Standard
discovery process to only certain devices in your environment.
One caveat: we only recognize tags that have been applied to the device
through the portal (or via the API). You cannot utilize tags that have been set
via the registry on the device.
You may also have situations where devices are set up as
honeypots or have certain networks where you have specific monitoring in place.
You can exclude these from Standard discovery and can configure this through
the Exclusions tab in Device discovery. There, you can specify either a
specific IP address or a subnet to exclude from the Standard discovery mode,
although we will still gather details of devices through the passive discovery
available in Basic discovery.
Discovering
the right devices
One important aspect to this functionality is ensuring it discovers the
correct devices. You don’t want to take your laptop home and then see all your
smart devices, TVs, gaming consoles, etc., showing up in the device inventory
list. Not only does it clutter the inventory, but there are also privacy
implications from discovering personal, at home devices.
The good news: there is built-in logic to prevent this, and a level of
control to define what networks this discovery process runs against. The logic
was designed to differentiate between corporate networks and non-corporate
networks, to avoid discovery of private or public devices not controlled by the
organization. Strict conditions are in place to ensure such devices won’t be
discovered and presented in the portal.
The system differentiates between corporate and non-corporate networks by
correlating common network interfaces identifiers among Microsoft Defender for
Endpoint onboarded devices.
To add an extra layer of control, the following screenshot displays the
Monitored networks tab within Device discovery settings which makes discovered
networks visible and enables you to specifically whether to include or exclude
them.
Disabling…if
you really must!
Finally, if you decide that our new endpoint discovery capability isn’t for
you, a switch is available in the Advanced settings page in the Microsoft
Defender Security Center that allows you to disable the feature (under
“Endpoints” in the settings in the Microsoft 365 security center) . While this
isn’t recommended, we recognize some organizations may require due
diligence to be performed before taking advantage of the feature.
We’re excited to offer you this new functionality and thank you for your
interest in the unmanaged endpoint discovery feature. You will gain enhanced
visibility of your estate, and the power to close down a vector of attack that
attackers increasingly take advantage of.
We encourage you to join us in the public preview program. This program lets
you test new features in their early phases and captures your feedback that
will influence the final product. For those not already enrolled in the
program, we encourage you to participate by turning on preview features.
Once enrolled, we welcome your feedback. More information about this feature
and our broader range of unmanaged devices capabilities can be found in the
Microsoft Defender for Endpoint product documentation.
Registration is now open for Ability Summit
on May 5-6th. This two-day, free digital event brings
together people with disabilities, allies, and accessibility professionals to Imagine, Build, Include, and Empower the future of disability
inclusion and accessibility.
Ability Summit will spotlight current and
future accessibility technologies.
Speakers will include Microsoft
executives, customers, partners, and leaders with disabilities.
Explore the Ability Summit site for more information
about the digital event.
The
NCCoE will solicit participation from industry to demonstrate first-party and
third-party tests and test tools for automation of the CMVP, as well as
first-party processes and means for communicating the results to NIST.
Increased automation is necessary because a number of elements of the current
validation processes are manual in nature, making third-party testing and
government validation of cryptographic modules often incompatible with industry
requirements. In addition to demonstrating tests, tools, and processes, this
project will also result in practice descriptions in the form of white papers,
playbook generation, and implementation demonstrations, which aim to improve
the ability and efficiency of organizations.
The public comment period is open through May 12, 2021. See the publication
details for a copy of the draft and instructions for submitting
comments. You can also help shape and contribute to this project. Join the
Community of Interest by sending an email to applied-crypto-visibility@nist.gov.
CISA has published a Remediating
Microsoft Exchange Vulnerabilities web page that strongly urges all
organizations to immediately address the recent Microsoft Exchange Server
product vulnerabilities. As exploitation of these vulnerabilities is widespread
and indiscriminate, CISA strongly advises organizations follow the guidance
laid out in the web page. The guidance provides specific steps for both leaders
and IT security staff and is applicable for all sizes of organizations across
all sectors.
Apple has released security updates to address vulnerabilities in macOS Big
Sur 11.2, macOS Catalina 10.15.7, and macOS Mojave 10.14.6. An attacker could
exploit these vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review the Apple security
update and apply the necessary updates.
Title:
Multiple Security Updates Affecting TCP/IP: CVE-2021-24074, CVE-2021-24094,
and CVE-2021-24086
URL:https://msrc-blog.microsoft.com/2021/02/09/multiple-security-updates-affecting-tcp-ip/ Published On (YYYY-dd-MM):2021-09-02 Overview:
Today Microsoft released a set of fixes affecting Windows TCP/IP
implementation that include two Critical Remote Code Execution
(RCE) vulnerabilities (CVE-2021-24074, CVE-2021-24094) and
an Important Denial of Service
(DoS) vulnerability (CVE-2021-24086). The two RCE vulnerabilities are
complex which make it difficult to
create functional exploits, so they are not
likely in the short term. We believe attackers will be able to create
DoS exploits much more quickly and expect all three issues might
be exploited with a DoS attack shortly after
release. Thus, we recommend customers move …
