Azure Sphere Security Research Challenge Now Open

May 5th, 2020 No comments

The Azure Sphere Security Research Challenge is an expansion of Azure Security Lab, announced at Black Hat in August 2019. At that time, a select group of talented researchers was invited to come and do their worst, emulating criminal hackers in a customer-safe cloud environment. This new research challenge aims to spark new high impact …

Azure Sphere Security Research Challenge Now Open Read More »

The post Azure Sphere Security Research Challenge Now Open appeared first on Microsoft Security Response Center.

Azure Sphere Security Research Challenge Now Open

May 5th, 2020 No comments

The Azure Sphere Security Research Challenge is an expansion of Azure Security Lab, announced at Black Hat in August 2019. At that time, a select group of talented researchers was invited to come and do their worst, emulating criminal hackers in a customer-safe cloud environment. This new research challenge aims to spark new high impact …

Azure Sphere Security Research Challenge Now Open Read More »

The post Azure Sphere Security Research Challenge Now Open appeared first on Microsoft Security Response Center.

Lessons learned from the Microsoft SOC—Part 3c: A day in the life part 2

May 5th, 2020 No comments

This is the sixth blog in the Lessons learned from the Microsoft SOC series designed to share our approach and experience from the front lines of our security operations center (SOC) protecting Microsoft and our Detection and Response Team (DART) helping our customers with their incidents. For a visual depiction of our SOC philosophy, download our Minutes Matter poster.

COVID-19 and the SOC

Before we conclude the day in the life, we thought we would share an analyst’s eye view of the impact of COVID-19. Our analysts are mostly working from home now and our cloud based tooling approach enabled this transition to go pretty smoothly. The differences in attacks we have seen are mostly in the early stages of an attack with phishing lures designed to exploit emotions related to the current pandemic and increased focus on home firewalls and routers (using techniques like RDP brute-forcing attempts and DNS poisoning—more here). The attack techniques they attempt to employ after that are fairly consistent with what they were doing before.

A day in the life—remediation

When we last left our heroes in the previous entry, our analyst had built a timeline of the potential adversary attack operation. Of course, knowing what happened doesn’t actually stop the adversary or reduce organizational risk, so let’s remediate this attack!

  1. Decide and act—As the analyst develops a high enough level of confidence that they understand the story and scope of the attack, they quickly shift to planning and executing cleanup actions. While this appears as a separate step in this particular description, our analysts often execute on cleanup operations as they find them.

Big Bang or clean as you go?

Depending on the nature and scope of the attack, analysts may clean up attacker artifacts as they go (emails, hosts, identities) or they may build a list of compromised resources to clean up all at once (Big Bang)

  • Clean as you go—For most typical incidents that are detected early in the attack operation, analysts quickly clean up the artifacts as we find them. This rapidly puts the adversary at a disadvantage and prevents them from moving forward with the next stage of their attack.
  • Prepare for a Big Bang—This approach is appropriate for a scenario where an adversary has already “settled in” and established redundant access mechanisms to the environment (frequently seen in incidents investigated by our Detection and Response Team (DART) at customers). In this case, analysts should avoid tipping off the adversary until full discovery of all attacker presence is discovered as surprise can help with fully disrupting their operation. We have learned that partial remediation often tips off an adversary, which gives them a chance to react and rapidly make the incident worse (spread further, change access methods to evade detection, inflict damage/destruction for revenge, cover their tracks, etc.).Note that cleaning up phishing and malicious emails can often be done without tipping off the adversary, but cleaning up host malware and reclaiming control of accounts has a high chance of tipping off the adversary.

These are not easy decisions to make and we have found no substitute for experience in making these judgement calls. The collaborative work environment and culture we have built in our SOC helps immensely as our analysts can tap into each other’s experience to help making these tough calls.

The specific response steps are very dependent on the nature of the attack, but the most common procedures used by our analysts include:

  • Client endpoints—SOC analysts can isolate a computer and contact the user directly (or IT operations/helpdesk) to have them initiate a reinstallation procedure.
  • Server or applications—SOC analysts typically work with IT operations and/or application owners to arrange rapid remediation of these resources.
  • User accounts—We typically reclaim control of these by disabling the account and resetting password for compromised accounts (though these procedures are evolving as a large amount of our users are mostly passwordless using Windows Hello or another form of MFA). Our analysts also explicitly expire all authentication tokens for the user with Microsoft Cloud App Security.
    Analysts also review the multi-factor phone number and device enrollment to ensure it hasn’t been hijacked (often contacting the user), and reset this information as needed.
  • Service Accounts—Because of the high risk of service/business impact, SOC analysts work with the service account owner of record (falling back on IT operations as needed) to arrange rapid remediation of these resources.
  • Emails—The attack/phishing emails are deleted (and sometimes cleared to prevent recovering of deleted emails), but we always save a copy of original email in the case notes for later search and analysis (headers, content, scripts/attachments, etc.).
  • Other—Custom actions can also be executed based on the nature of the attack such as revoking application tokens, reconfiguring servers and services, and more.

Automation and integration for the win

It’s hard to overstate the value of integrated tools and process automation as these bring so many benefits—improving the analysts daily experience and improving the SOC’s ability to reduce organizational risk.

  • Analysts spend less time on each incident, reducing the attacker’s time to operation—measured by mean time to remediate (MTTR).
  • Analysts aren’t bogged down in manual administrative tasks so they can react quickly to new detections (reducing mean time to acknowledge—MTTA).
  • Analysts have more time to engage in proactive activities that both reduce organization risk and increase morale by keeping them focused on the mission.

Our SOC has a long history of developing our own automation and scripts to make analysts lives easier by a dedicated automation team in our SOC. Because custom automation requires ongoing maintenance and support, we are constantly looking for ways to shift automation and integration to capabilities provided by Microsoft engineering teams (which also benefits our customers). While still early in this journey, this approach typically improves the analyst experience and reduces maintenance effort and challenges.

This is a complex topic that could fill many blogs, but this takes two main forms:

  • Integrated toolsets save analysts manual effort during incidents by allowing them to easily navigate multiple tools and datasets. Our SOC relies heavily on the integration of Microsoft Threat Protection (MTP) tools for this experience, which also saves the automation team from writing and supporting custom integration for this.
  • Automation and orchestration capabilities reduce manual analyst work by automating repetitive tasks and orchestrating actions between different tools. Our SOC currently relies on an advanced custom SOAR platform and is actively working with our engineering teams (MTP’s AutoIR capability and Azure Sentinel SOAR) on how to shift our learnings and workload onto those capabilities.

After the attacker operation has been fully disrupted, the analyst marks the case as remediated, which is the timestamp signaling the end of MTTR measurement (which started when the analyst began the active investigation in step 2 of the previous blog).

While having a security incident is bad, having the same incident repeated multiple times is much worse.

  1. Post-incident cleanup—Because lessons aren’t actually “learned” unless they change future actions, our analysts always integrate any useful information learned from the investigation back into our systems. Analysts capture these learnings so that we avoid repeating manual work in the future and can rapidly see connections between past and future incidents by the same threat actors. This can take a number of forms, but common procedures include:
    • Indicators of Compromise (IoCs)—Our analysts record any applicable IoCs such as file hashes, malicious IP addresses, and email attributes into our threat intelligence systems so that our SOC (and all customers) can benefit from these learnings.
    • Unknown or unpatched vulnerabilities—Our analysts can initiate processes to ensure that missing security patches are applied, misconfigurations are corrected, and vendors (including Microsoft) are informed of “zero day” vulnerabilities so that they can create security patches for them.
    • Internal actions such as enabling logging on assets and adding or changing security controls. 

Continuous improvement

So the adversary has now been kicked out of the environment and their current operation poses no further risk. Is this the end? Will they retire and open a cupcake bakery or auto repair shop? Not likely after just one failure, but we can consistently disrupt their successes by increasing the cost of attack and reducing the return, which will deter more and more attacks over time. For now, we must assume that adversaries will try to learn from what happened on this attack and try again with fresh ideas and tools.

Because of this, our analysts also focus on learning from each incident to improve their skills, processes, and tooling. This continuous improvement occurs through many informal and formal processes ranging from formal case reviews to casual conversations where they tell the stories of incidents and interesting observations.

As caseload allows, the investigation team also hunts proactively for adversaries when they are not on shift, which helps them stay sharp and grow their skills.

This closes our virtual shift visit for the investigation team. Join us next time as we shift to our Threat hunting team (a.k.a. Tier 3) and get some hard won advice and lessons learned.

…until then, share and enjoy!

P.S. If you are looking for more information on the SOC and other cybersecurity topics, check out previous entries in the series (Part 1 | Part 2a | Part 2b | Part 3a | Part 3b), Mark’s List (https://aka.ms/markslist), and our new security documentation site—https://aka.ms/securtydocs. Be sure to bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Or reach out to Mark on LinkedIn or Twitter.

The post Lessons learned from the Microsoft SOC—Part 3c: A day in the life part 2 appeared first on Microsoft Security.

Mitigating vulnerabilities in endpoint network stacks

May 4th, 2020 No comments

The skyrocketing demand for tools that enable real-time collaboration, remote desktops for accessing company information, and other services that enable remote work underlines the tremendous importance of building and shipping secure products and services. While this is magnified as organizations are forced to adapt to the new environment created by the global crisis, it’s not a new imperative. Microsoft has been investing heavily in security, and over the years our commitment to building proactive security into products and services has only intensified.

To help deliver on this commitment, we continuously find ways to improve and secure Microsoft products. One aspect of our proactive security work is finding vulnerabilities and fixing them before they can be exploited. Our strategy is to take a holistic approach and drive security throughout the engineering lifecycle. We do this by:

  • Building security early into the design of features.
  • Developing tools and processes that proactively find vulnerabilities in code.
  • Introducing mitigations into Windows that make bugs significantly harder to exploit.
  • Having our world-class penetration testing team test the security boundaries of the product so we can fix issues before they can impact customers.

This proactive work ensures we are continuously making Windows safer and finding as many issues as possible before attackers can take advantage of them. In this blog post we will discuss a recent vulnerability that we proactively found and fixed and provide details on tools and techniques we used, including a new set of tools that we built internally at Microsoft. Our penetration testing team is constantly testing the security boundaries of the product to make it more secure, and we are always developing tools that help them scale and be more effective based on the evolving threat landscape. Our investment in fuzzing is the cornerstone of our work, and we are constantly innovating this tech to keep on breaking new ground.

Proactive security to prevent the next WannaCry

In the past few years, much of our team’s efforts have been focused on uncovering remote network vulnerabilities and preventing events like the WannaCry and NotPetya outbreaks. Some bugs we have recently found and fixed include critical vulnerabilities that could be leveraged to exploit common secure remote communication tools like RDP or create ransomware issues like WannaCry: CVE-2019-1181 and CVE-2019-1182 dubbed “DejaBlue“, CVE-2019-1226 (RCE in RDP Server), CVE-2020-0611 (RCE in RDP Client), and CVE-2019-0787 (RCE in RDP client), among others.

One of the biggest challenges we regularly face in these efforts is the sheer volume of code we analyze. Windows is enormous and continuously evolving 5.7 million source code files, with more than 3,500 developers doing 1,100 pull requests per day in 440 official branches. This rapid cadence and evolution allows us to add new features as well proactively drive security into Windows.

Like many security teams, we frequently turn to fuzzing to help us quickly explore and assess large codebases. Innovations we’ve made in our fuzzing technology have made it possible to get deeper coverage than ever before, resulting in the discovery of new bugs, faster. One such vulnerability is the remote code vulnerability (RCE) in Microsoft Server Message Block version 3 (SMBv3) tracked as CVE-2020-0796 and fixed on March 12, 2020.

In the following sections, we will share the tools and techniques we used to fuzz SMB, the root cause of the RCE vulnerability, and relevant mitigations to exploitation.

Fully deterministic person-in-the-middle fuzzing

We use a custom deterministic full system emulator tool we call “TKO” to fuzz and introspect Windows components.  TKO provides the capability to perform full system emulation and memory snapshottting, as well as other innovations.  As a result of its unique design, TKO provides several unique benefits to SMB network fuzzing:

  • The ability to snapshot and fuzz forward from any program state.
  • Efficiently restoring to the initial state for fast iteration.
  • Collecting complete code coverage across all processes.
  • Leveraging greater introspection into the system without too much perturbation.

While all of these actions are possible using other tools, our ability to seamlessly leverage them across both user and kernel mode drastically reduces the spin-up time for targets. To learn more, check out David Weston’s recent BlueHat IL presentation “Keeping Windows secure”, which touches on fuzzing, as well as the TKO tool and infrastructure.

Fuzzing SMB

Given the ubiquity of SMB and the impact demonstrated by SMB bugs in the past, assessing this network transfer protocol has been a priority for our team. While there have been past audits and fuzzers thrown against the SMB codebase, some of which postdate the current SMB version, TKO’s new capabilities and functionalities made it worthwhile to revisit the codebase. Additionally, even though the SMB version number has remained static, the code has not! These factors played into our decision to assess the SMB client/server stack.

After performing an initial audit pass of the code to understand its structure and dataflow, as well as to get a grasp of the size of the protocol’s state space, we had the information we needed to start fuzzing.

We used TKO to set up a fully deterministic feedback-based fuzzer with a combination of generated and mutated SMB protocol traffic. Our goal for generating or mutating across multiple packets was to dig deeper into the protocol’s state machine. Normally this would introduce difficulties in reproducing any issues found; however, our use of emulators made this a non-issue. New generated or mutated inputs that triggered new coverage were saved to the input corpus. Our team had a number of basic mutator libraries for different scenarios, but we needed to implement a generator. Additionally, we enabled some of the traditional Windows heap instrumentation using verifier, turning on page heap for SMB-related drivers.

We began work on the SMBv2 protocol generator and took a network capture of an SMB negotiation with the aim of replaying these packets with mutations against a Windows 10, version 1903 client. We added a mutator with basic mutations (e.g., bit flips, insertions, deletions, etc.) to our fuzzer and kicked off an initial run while we continued to improve and develop further.

Figure 1. TKO fuzzing workflow

A short time later, we came back to some compelling results. Replaying the first crashing input with TKO’s kdnet plugin revealed the following stack trace:

> tkofuzz.exe repro inputs\crash_6a492.txt -- kdnet:conn 127.0.0.1:50002

Figure 2. Windbg stack trace of crash

We found an access violation in srv2!Smb2CompressionDecompress.

Finding the root cause of the crash

While the stack trace suggested that a vulnerability exists in the decompression routine, it’s the parsing of length counters and offsets from the network that causes the crash. The last packet in the transaction needed to trigger the crash has ‘\xfcSMB’ set as the first bytes in its header, making it a COMPRESSION_TRANSFORM packet.

Figure 3. COMPRESSION_TRANSFORM packet details

The SMBv2 COMPRESSION_TRANSFORM packet starts with a COMPRESSION_TRANSFORM_HEADER, which defines where in the packet the compressed bytes begin and the length of the compressed buffer.

typedef struct _COMPRESSION_TRANSFORM_HEADER

{

UCHAR   Protocol[4]; // Contains 0xFC, 'S', 'M', 'B'

ULONG    OriginalMessageSize;

USHORT AlgorithmId;

USHORT Flags;

ULONG Length;

}

In the srv2!Srv2DecompressData in the graph below, we can find this COMPRESSION_TRANSFORM_HEADER struct being parsed out of the network packet and used to determine pointers being passed to srv2!SMBCompressionDecompress.

Figure 4. Srv2DecompressData graph

We can see that at 0x7e94, rax points to our network buffer, and the buffer is copied to the stack before the OriginalCompressedSegmentSize and Length are parsed out and added together at 0x7ED7 to determine the size of the resulting decompressed bytes buffer. Overflowing this value causes the decompression to write its results out of the bounds of the destination SrvNet buffer, in an out-of-bounds write (OOBW).

Figure 5. Overflow condition

Looking further, we can see that the Length field is parsed into esi at 0x7F04, added to the network buffer pointer, and passed to CompressionDecompress as the source pointer. As Length is never checked against the actual number of received bytes, it can cause decompression to read off the end of the received network buffer. Setting this Length to be greater than the packet length also causes the computed source buffer length passed to SmbCompressionDecompress to underflow at 0x7F18, creating an out-of-bounds read (OOBR) vulnerability. Combining this OOBR vulnerability with the previous OOBW vulnerability creates the necessary conditions to leak addresses and create a complete remote code execution exploit.

Figure 6. Underflow condition

Windows 10 mitigations against remote network vulnerabilities

Our discovery of the SMBv3 vulnerability highlights the importance of revisiting protocol stacks regularly as our tools and techniques continue to improve over time. In addition to the proactive hunting for these types of issues, the investments we made in the last several years to harden Windows 10 through mitigations like address space layout randomization (ASLR), Control Flow Guard (CFG), InitAll, and hypervisor-enforced code integrity (HVCI) hinder trivial exploitation and buy defenders time to patch and protect their networks.

For example, turning vulnerabilities like the ones discovered in SMBv3 into working exploits requires finding writeable kernel pages at reliable addresses, a task that requires heap grooming and corruption, or a separate vulnerability in Windows kernel address space layout randomization (ASLR). Typical heap-based exploits taking advantage of a vulnerability like the one described here would also need to make use of other allocations, but Windows 10 pool hardening helps mitigate this technique. These mitigations work together and have a cumulative effect when combined, increasing the development time and cost of reliable exploitation.

Assuming attackers gain knowledge of our address space, indirect jumps are mitigated by kernel-mode CFG. This forces attackers to either use data-only corruption or bypass Control Flow Guard via stack corruption or yet another bug. If virtualization-based security (VBS) and HVCI are enabled, attackers are further constrained in their ability to map and modify memory permissions.

On Secured-core PCs these mitigations are enabled by default.  Secured-core PCs combine virtualization, operating system, and hardware and firmware protection. Along with Microsoft Defender Advanced Threat Protection, Secured-core PCs provide end-to-end protection against advanced threats.

While these mitigations collectively lower the chances of successful exploitation, we continue to deepen our investment in identifying and fixing vulnerabilities before they can get into the hands of adversaries.

 

The post Mitigating vulnerabilities in endpoint network stacks appeared first on Microsoft Security.

Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation

May 1st, 2020 No comments

The latest round of MITRE ATT&CK evaluations proved yet again that Microsoft customers can trust they are fully protected even in the face of such an advanced attack as APT29. When looking at protection results out of the box, without configuration changes, Microsoft Threat Protection (MTP):

  • Provided nearly 100 percent coverage across the attack chain stages.
  • Delivered leading out-of-box visibility into attacker activities, dramatically reducing manual work for SOCs vs. vendor solutions that relied on specific configuration changes.
  • Had the fewest gaps in visibility, diminishing attacker ability to operate undetected.

Beyond just detection and visibility, automation, prioritization, and prevention are key to stopping this level of advanced attack. During testing, Microsoft:

  • Delivered automated real-time alerts without the need for configuration changes or custom detections; Microsoft is one of only three vendors who did not make configuration changes or rely on delayed detections.
  • Flagged more than 80 distinct alerts, and used built-in automation to correlate these alerts into only two incidents that mirrored the two MITRE ATT&CK simulations, improving SOC analyst efficiency and reducing attacker dwell time and ability to persist.
  • Identified seven distinct steps during the attack in which our protection features, which were disabled during testing, would have automatically intervened to stop the attack.

Microsoft Threat Experts provided further in-depth context and recommendations for further investigation through our comprehensive in-portal forensics. The evaluation also proved how Microsoft Threat Protection goes beyond just simple visibility into attacks, but also records all stages of the attack in which MTP would have stepped in to block the attack and automatically remediate any affected assets.

While the test focused on endpoint detection and response, MITRE’s simulated APT29 attack spans multiple attack domains, creating opportunities to empower defenders beyond just endpoint protection. Microsoft expanded defenders’ visibility beyond the endpoint with Microsoft Threat Protection (MTP). MTP has been recognized by both Gartner and Forrester as having extended detection and response capabilities. MTP takes protection to the next level by combining endpoint protection from Microsoft Defender ATP (EDR) with protection for email and productivity tools (Office 365 ATP), identity (Azure ATP), and cloud applications (Microsoft Cloud App Security [MCAS]). Below, we will share a deep-dive analysis and explanation of how MTP successfully demonstrated novel optic and detection advantages throughout the MITRE evaluation that only our solution can provide.

Incident-based approach enables real-time threat prioritization and remediation

Analyzing the MITRE evaluation results from the lens of breadth and coverage, as the diagrams below show, MTP provided exceptional coverage for all but one of the 19 tested attack stages. This means that in real life, the SOC would have received alerts and given full visibility into each of the stages of the two simulated attack scenarios across initial access, deployment of tools, discovery, persistence, credential access, lateral movement, and exfiltration. In Microsoft Threat Protection, alerts carry with them rich context—including a detailed process tree showing the recorded activities (telemetry) that led to the detection, the assets involved, all supporting evidence, as well as a description of what the alert means and recommendations for SOC action. Note that true alerts are attributed in the MITRE evaluation with the “Alert” modifier, and not all items marked as “Tactic” or “Technique” are actual alerts.

MTP detection coverage across the attack kill-chain stages, with block opportunities.

Figure 1: MTP detection coverage across the attack kill-chain stages, with block opportunities.

Figure 1: MTP detection coverage across the attack kill-chain stages, with block opportunities.

Note: Step 10, persistence execution, is registered as a miss due to a software bug, discovered during the test, that restricted visibility on Step 10—“Persistence Execution.” These evaluations are a valuable opportunity to continually improve our product, and this bug was fixed shortly after testing completed.

The MITRE APT29 evaluation focused solely on detection of an advanced attack; it did not measure whether or not participants were able to also prevent an attack. However, we believe that real-world protection is more than just knowing that an attack occurred—prevention of the attack is a critical element. While protections were intentionally turned off to allow the complete simulation to run, using the audit-only prevention configuration, MTP also captured and documented where the attack would have been completely prevented, including—as shown in the diagram above – the very start of the breach, if protections had been left on.

Microsoft Threat Protection also demonstrated how it promotes SOC efficiency and reduces attacker dwell time and sprawl. SOC alert fatigue is a serious problem; raising a large volume of alerts to investigate does not help SOC analysts understand where to devote their limited time and resources. Detection and response products must prioritize the most important attacker actions with the right context in near real time.

In contrast to alert-only approaches, MTP’s incident-based approach automatically identifies complex links between attacker activities in different domains including endpoint, identity, and cloud applications at an altitude that only Microsoft can provide because we have optics into each of these areas. In this scenario, MTP connected seemingly unrelated alerts using supporting telemetry across domains into just two end-to-end incidents, dramatically simplifying prioritization, triage, and investigation. In real life, this also simplifies automated response and enables SOC teams to scale capacity and capabilities. MITRE addresses a similar problem with the “correlated” modifier on telemetry and alerts but does not reference incidents (just yet).

Figure 2: MTP portal showing 2nd day attack incident including correlated alerts and affected assets.

Figure 2: MTP portal showing 2nd day attack incident including correlated alerts and affected assets.

Figure 3: 2nd day incident with all correlated alerts for SOC efficiency, and the attack incident graph.

Figure 3: 2nd day incident with all correlated alerts for SOC efficiency, and the attack incident graph.

Microsoft is the leader in out-of-the-box performance

Simply looking at the number of simulation steps covered—or, alternatively, at the number of steps with no coverage, where less is more—the MITRE evaluation showed MTP provided the best protection with zero delays or configuration changes.

Microsoft believes protection must be durable without requiring a lot of SOC configuration changes (especially during an ongoing attack), and it should not create friction by delivering false positives.

The chart below shows Microsoft as the vendor with the least number of steps categorized as “None” (also referred to as “misses”) out of the box. The chart also shows the number of detections marked with “Configuration Change” modifier, which was done quite considerably, as well as delayed detections (“Delayed” modifier), which indicate in-flight modifications and latency in detections.

Microsoft is one of only three vendors that made no modifications or had any delays during the test.

Microsoft is one of only three vendors that made no modifications or had any delays during the test.

Similarly, when looking at visibility and coverage for the 57 MITRE ATT&CK techniques replicated during this APT29 simulation, Microsoft’s coverage shows top performance at 95 percent of the techniques covered, as shown in the chart below.

A product’s coverage of techniques is an important consideration for customers when evaluating security solutions, often with specific attacker(s) in mind, which in turn determines the attacker techniques they are most concerned with and, consequently, the coverage they most care about.
Figure 5: Coverage across all attack techniques in the evaluation.

Figure 5: Coverage across all attack techniques in the evaluation.

MTP provided unique detection and visibility across identity, cloud, and endpoints

The powerful capabilities of Microsoft Threat Protection originate from unique signals not just from endpoints but also from identity and cloud apps. This combination of capabilities provides coverage where other solutions may lack visibility. Below are three examples of sophisticated attacks simulated during the evaluation that span across domains (i.e., identity, cloud, endpoint) and showcase the unique visibility and unmatched detections provided by MTP:

  • Detecting the most dangerous lateral movement attack: Golden Ticket—Unlike other vendors, MTP’s unique approach for detecting Golden Ticket attacks does not solely rely on endpoint-based command-line sequences, PowerShell strings like “Invoke-Mimikatz”, or DLL-loading heuristics that can all be evaded by advanced attackers. MTP leverages direct optics into the Domain Controller via Azure ATP, the identity component of MTP. Azure ATP detects Golden Ticket attacks using a combination of machine learning and protocol heuristics by looking at anomalies such as encryption downgrade, forged authorization data, nonexistent account, ticket anomaly, and time anomaly. MTP is the only product that provided the SOC context of the encryption downgrade, together with the source and target machines, resources accessed, and the identities involved.
  • Exfiltration over alternative protocol: Catching and stopping attackers as they move from endpoint to cloud—MTP leverages exclusive signal from Microsoft Cloud App Security (MCAS), the cloud access security broker (CASB) component of MTP, which provides visibility and alerts for a large variety of cloud services, including OneDrive. Using the MCAS Conditional Access App Control mechanism, MTP was able to monitor cloud traffic for data exfiltration and raise an automatic alert when a ZIP archive with stolen files was exfiltrated to a remote OneDrive account controlled by the attacker. It is important to note the OneDrive account used by MITRE Redteam was unknown to the Microsoft team prior to being automatically detected during the evaluation.
  • Uncovering Remote System Discovery attacks that abuse LDAP—Preceding lateral movement, attackers commonly abuse the Lightweight Directory Access Protocol (LDAP) protocol to query user groups and user information. Microsoft introduced a powerful new sensor for unique visibility of LDAP queries, aiding security analyst investigation and allowing detection of suspicious patterns of LDAP activity. Through this sensor, Microsoft Defender ATP, the endpoint component of MTP, avoids reliance on PowerShell strings and snippets. Rather, Microsoft Defender ATP uses the structure and fields of each LDAP query originating from the endpoint to the Domain Controller (DC) to spot broad requests or suspicious queries for accounts and groups. Where possible, MTP also combines and correlates LDAP attacks detected on the endpoint by Microsoft Defender ATP with LDAP events seen on the DC by Azure ATP.

Figure 6: Golden Ticket alert based on optics on Domain Controller activity.

Figure 6: Golden Ticket alert based on optics on Domain Controller activity.

Figure 7: Suspicious LDAP activity detected using deep native OS sensor.

Figure 7: Suspicious LDAP activity detected using deep native OS sensor.

Microsoft Threat Experts: Threat context and hunting skills when and where needed

In this edition of MITRE ATT&CK evaluation, for the first time, Microsoft products were configured to take advantage of the managed threat hunting service Microsoft Threat Experts. Microsoft Threat Experts provides proactive hunting for the most important threats in the network, including human adversary intrusions, hands-on-keyboard attacks, or advanced attacks like cyberespionage. During the evaluation, the service operated with the same strategy normally used in real customer incidents: the goal is to send targeted attack notifications that provide real value to analysts with contextual analysis of the activities. Microsoft Threat Experts enriches security signals and raises the risk level appropriately so that the SOC can focus on what’s important, and breaches don’t go unnoticed.

Microsoft Threat Experts notifications stand out among other participating vendors as these notifications are fully integrated into the experience, incorporated into relevant incidents and connected to relevant events, alerts, and other evidence. Microsoft Threat Experts is enabling SOC teams to effortlessly and seamlessly receive and merge additional data and recommendations in the context of the incident investigation.

Figure 8: Microsoft Threat Experts alert integrates into the portal and provides hyperlinked rich context.

Figure 8: Microsoft Threat Experts alert integrates into the portal and provides hyperlinked rich context.

Transparency in testing is key to threat detection, prevention

Microsoft Threat Protection delivers real-world detection, response, and, ultimately, protection from advanced attacks, as demonstrated in the latest MITRE evaluation. Core to MITRE’s testing approach is emulating real-world attacks to understand whether solutions are able to adequately detect and respond to them. We saw that Microsoft Threat Protection provided clear detection across all categories and delivered additional context that shows the full scope of impact across an entire environment. MTP empowers customers not only to detect attacks, offering human experts as needed, and easily return to a secured state with automated remediation. As is true in the real world, our human Threat Experts were available on demand to provide even more context and help with.

We thank MITRE for the opportunity to contribute to the test with unique threat intelligence that only three participants stepped forward to share. Our unique intelligence and breadth of signal and visibility across the entire environment is what enables us to continuously score top marks. We look forward to participating in the next evaluation, and we welcome your feedback and partnership throughout our journey.

Thanks,

Moti and the entire Microsoft Threat Protection team

Related Links:

 

The post Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation appeared first on Microsoft Security.

Zero Trust Deployment Guide for Microsoft Azure Active Directory

April 30th, 2020 No comments

Microsoft is providing a series of deployment guides for customers who have engaged in a Zero Trust security strategy. In this guide, we cover how to deploy and configure Azure Active Directory (Azure AD) capabilities to support your Zero Trust security strategy.

For simplicity, this document will focus on ideal deployments and configuration. We will call out the integrations that need Microsoft products other than Azure AD and we will note the licensing needed within Azure AD (Premium P1 vs P2), but we will not describe multiple solutions (one with a lower license and one with a higher license).

Azure AD at the heart of your Zero Trust strategy

Azure AD provides critical functionality for your Zero Trust strategy. It enables strong authentication, a point of integration for device security, and the core of your user-centric policies to guarantee least-privileged access. Azure AD’s Conditional Access capabilities are the policy decision point for access to resources based on user identity, environment, device health, and risk—verified explicitly at the point of access. In the following sections, we will showcase how you can implement your Zero Trust strategy with Azure AD.

Establish your identity foundation with Azure AD

A Zero Trust strategy requires that we verify explicitly, use least privileged access principles, and assume breach. Azure Active Directory can act as the policy decision point to enforce your access policies based on insights on the user, device, target resource, and environment. To do this, we need to put Azure Active Directory in the path of every access request—connecting every user and every app or resource through this identity control plane. In addition to productivity gains and improved user experiences from single sign-on (SSO) and consistent policy guardrails, connecting all users and apps provides Azure AD with the signal to make the best possible decisions about the authentication/authorization risk.

  • Connect your users, groups, and devices:
    Maintaining a healthy pipeline of your employees’ identities as well as the necessary security artifacts (groups for authorization and devices for extra access policy controls) puts you in the best place to use consistent identities and controls, which your users already benefit from on-premises and in the cloud:

    1. Start by choosing the right authentication option for your organization. While we strongly prefer to use an authentication method that primarily uses Azure AD (to provide you the best brute force, DDoS, and password spray protection), follow our guidance on making the decision that’s right for your organization and your compliance needs.
    2. Only bring the identities you absolutely need. For example, use going to the cloud as an opportunity to leave behind service accounts that only make sense on-premises; leave on-premises privileged roles behind (more on that under privileged access), etc.
    3. If your enterprise has more than 100,000 users, groups, and devices combined, we recommend you follow our guidance building a high performance sync box that will keep your life cycle up-to-date.
  • Integrate all your applications with Azure AD:
    As mentioned earlier, SSO is not only a convenient feature for your users, but it’s also a security posture, as it prevents users from leaving copies of their credentials in various apps and helps avoid them getting used to surrendering their credentials due to excessive prompting. Make sure you do not have multiple IAM engines in your environment. Not only does this diminish the amount of signal that Azure AD sees and allow bad actors to live in the seams between the two IAM engines, it can also lead to poor user experience and your business partners becoming the first doubters of your Zero Trust strategy. Azure AD supports a variety of ways you can bring apps to authenticate with it:

    1. Integrate modern enterprise applications that speak OAuth2.0 or SAML.
    2. For Kerberos and Form-based auth applications, you can integrate them using the Azure AD Application Proxy.
    3. If you publish your legacy applications using application delivery networks/controllers, Azure AD is able to integrate with most of the major ones (such as Citrix, Akamai, F5, etc.).
    4. To help migrate your apps off of existing/older IAM engines, we provide a number of resources—including tools to help you discover and migrate apps off of ADFS.
  • Automate provisioning to applications:
    Once you have your users’ identities in Azure AD, you can now use Azure AD to power pushing those user identities into your various cloud applications. This gives you a tighter identity lifecycle integration within those apps. Use this detailed guide to deploy provisioning into your SaaS applications.
  • Get your logging and reporting in order:
    As you build your estate in Azure AD with authentication, authorization, and provisioning, it’s important to have strong operational insights into what is happening in the directory. Follow this guide to learn how to to persist and analyze the logs from Azure AD either in Azure or using a SIEM system of choice.

Enacting the 1st principle: least privilege

Giving the right access at the right time to only those who need it is at the heart of a Zero Trust philosophy:

  • Plan your Conditional Access deployment:
    Planning your Conditional Access policies in advance and having a set of active and fallback policies is a foundational pillar of your Access Policy enforcement in a Zero Trust deployment. Take the time to configure your trusted IP locations in your environment. Even if you do not use them in a Conditional Access policy, configure these IPs informs the risk of Identity Protection mentioned above. Check out our deployment guidance and best practices for resilient Conditional Access policies.
  • Secure privileged access with privileged identity management:
    With privileged access, you generally take a different track to meeting the end users where they are most likely to need and use the data. You typically want to control the devices, conditions, and credentials that users use to access privileged operations/roles. Check out our detailed guidance on how to take control of your privileged identities and secure them. Keep in mind that in a digitally transformed organization, privileged access is not only administrative access, but also application owner or developer access that can change the way your mission critical apps run and handle data. Check out our detailed guide on how to use Privileged Identity Management (P2) to secure privileged identities.
  • Restrict user consent to applications:
    User consent to applications is a very common way for modern applications to get access to organizational resources. However, we recommend you restrict user consent and manage consent requests to ensure that no unnecessary exposure of your organization’s data to apps occurs. This also means that you need to review prior/existing consent in your organization for any excessive or malicious consent.
  • Manage entitlements (Azure AD Premium P2):
    With applications centrally authenticating and driven from Azure AD, you should streamline your access request, approval, and recertification process to make sure that the right people have the right access and that you have a trail of why users in your organization have the access they have. Using entitlement management, you can create access packages that they can request as they join different teams/project and that would assign them access to the associated resources (applications, SharePoint sites, group memberships). Check out how you can start a package. If deploying entitlement management is not possible for your organization at this time, we recommend you at least enable self-service paradigms in your organization by deploying self-service group management and self-service application access.

Enacting the 2nd principle: verify explicitly

Provide Azure AD with a rich set of credentials and controls that it can use to verify the user at all times.

  • Roll out Azure multi-factor authentication (MFA) (P1):
    This is a foundational piece of reducing user session risk. As users appear on new devices and from new locations, being able to respond to an MFA challenge is one of the most direct ways that your users can teach us that these are familiar devices/locations as they move around the world (without having administrators parse individual signals). Check out this deployment guide.
  • Enable Azure AD Hybrid Join or Azure AD Join:
    If you are managing the user’s laptop/computer, bringing that information into Azure AD and use it to help make better decisions. For example, you may choose to allow rich client access to data (clients that have offline copies on the computer) if you know the user is coming from a machine that your organization controls and manages. If you do not bring this in, you will likely choose to block access from rich clients, which may result in your users working around your security or using Shadow IT. Check out our resources for Azure AD Hybrid Join or Azure AD Join.
  • Enable Microsoft Intune for managing your users’ mobile devices (EMS):
    The same can be said about user mobile devices as laptops. The more you know about them (patch level, jailbroken, rooted, etc.) the more you are able to trust or mistrust them and provide a rationale for why you block/allow access. Check out our Intune device enrollment guide to get started.
  • Start rolling out passwordless credentials:
    With Azure AD now supporting FIDO 2.0 and passwordless phone sign-in, you can move the needle on the credentials that your users (especially sensitive/privileged users) are using on a day-to-day basis. These credentials are strong authentication factors that can mitigate risk as well. Our passwordless authentication deployment guide walks you through how to roll out passwordless credentials in your organization.

Enacting the 3rd principle: assume breach

Provide Azure AD with a rich set of credentials and controls that it can use to verify the user.

  • Deploy Azure AD Password Protection:
    While enabling other methods to verify users explicitly, you should not forget about weak passwords, password spray and breach replay attacks. Read this blog to find out why classic complex password policies are not tackling the most prevalent password attacks. Then follow this guidance to enable Azure AD Password Protection for your users in the cloud first and then on-premises as well.
  • Block legacy authentication:
    One of the most common attack vectors for malicious actors is to use stolen/replayed credentials against legacy protocols, such as SMTP, that cannot do modern security challenges. We recommend you block legacy authentication in your organization.
  • Enable identity protection (Azure AD Premium 2):
    Enabling identity protection for your users will provide you with more granular session/user risk signal. You’ll be able to investigate risk and confirm compromise or dismiss the signal which will help the engine understand better what risk looks like in your environment.
  • Enable restricted session to use in access decisions:
    To illustrate, let’s take a look at controls in Exchange Online and SharePoint Online (P1): When a user’s risk is low but they are signing in from an unknown device, you may want to allow them access to critical resources, but not allow them to do things that leave your organization in a non-compliant state. Now you can configure Exchange Online and SharePoint Online to offer the user a restricted session that allows them to read emails or view files, but not download them and save them on an untrusted device. Check out our guides for enabling limited access with SharePoint Online and Exchange Online.
  • Enable Conditional Access integration with Microsoft Cloud App Security (MCAS) (E5):
    Using signals emitted after authentication and with MCAS proxying requests to application, you will be able to monitor sessions going to SaaS Applications and enforce restrictions. Check out our MCAS and Conditional Access integration guidance and see how this can even be extended to on-premises apps.
  • Enable Microsoft Cloud App Security (MCAS) integration with identity protection (E5):
    Microsoft Cloud App Security is a UEBA product monitoring user behavior inside SaaS and modern applications. This gives Azure AD signal and awareness about what happened to the user after they authenticated and received a token. If the user pattern starts to look suspicious (user starts to download gigabytes of data from OneDrive or starts to send spam emails in Exchange Online), then a signal can be fed to Azure AD notifying it that the user seems to be compromised or high risk and on the next access request from this user; Azure AD can take correct action to verify the user or block them. Just enabling MCAS monitoring will enrich the identity protection signal. Check out our integration guidance to get started.
  • Integrate Azure Advanced Threat Protection (ATP) with Microsoft Cloud App Security:
    Once you’ve successfully deployed and configured Azure ATP, enable the integration with Microsoft Cloud App Security to bring on-premises signal into the risk signal we know about the user. This enables Azure AD to know that a user is indulging in risky behavior while accessing on-premises, non-modern resources (like File Shares) which can then be factored into overall user risk to block further access in the cloud. You will be able to see a combined Priority Score for each user at risk to give a holistic view of which ones your SOC should focus on.
  • Enable Microsoft Defender ATP (E5):
    Microsoft Defender ATP allows you to attest to Windows machines health and whether they are undergoing a compromise and feed that into mitigating risk at runtime. Whereas Domain Join gives you a sense of control, Defender ATP allows you to react to a malware attack at near real time by detecting patterns where multiple user devices are hitting untrustworthy sites and react by raising their device/user risk at runtime. See our guidance on configuring Conditional Access in Defender ATP.

Conclusion

We hope the above guides help you deploy the identity pieces central to a successful Zero Trust strategy. Make sure to check out the other deployment guides in the series by following the Microsoft Security blog.

The post Zero Trust Deployment Guide for Microsoft Azure Active Directory appeared first on Microsoft Security.

Data governance matters now more than ever

April 30th, 2020 No comments

Knowing, protecting, and governing your organizational data is critical to adhere to regulations and meet security and privacy needs. Arguably, that’s never been truer than it is today as we face these unprecedented health and economic circumstances. To help organizations to navigate privacy during this challenging time, Microsoft Chief Privacy Officer Julie Brill shared seven privacy principles to consider as we all collectively move forward in addressing the pandemic.

Organizations are also evaluating security and data governance more than ever before as they try to maintain business continuity amid the crisis. According to a new Harvard Business Review (HBR) research report released today commissioned by Microsoft, 61 percent of organizations struggle to effectively develop strong data security, privacy, and risk capabilities. Together with HBR, we surveyed close to 500 global business leaders across industries, including financial services, tech, healthcare, and manufacturing. The study found that 77 percent of organizations say an effective security, risk, and compliance strategy is essential for business success. However, 82 percent say that securing and governing data is becoming more difficult because of new risks and data management complexities brought on by digital transformation.

In a world in which remote work is the new normal, securing, and governing your company’s most critical data becomes more important than ever before. The increased volume of information and multiple collaboration systems create complexity for managing business records with serious cost and risk implications. As organizations across a variety of industries face ever-increasing regulations, many companies move data to different systems of record to manage them and comply with regulations. However, moving content to a different system, instead of managing it in place, can increase the risk of missing records or not declaring them properly. 

General availability of Microsoft 365 Records Management

Today, we are excited to announce the general availability of Microsoft 365 Records Management to provide you with significantly greater depth in protecting and governing critical data. With Records Management, you can:

  • Classify, retain, review, dispose, and manage content without compromising productivity or data security.
  • Leverage machine learning capabilities to identify and classify regulatory, legal, and business critical records at scale.
  • Help demonstrate compliance with regulations through defensible audit trails and proof of destruction.

You can now access Records Management in the compliance center in Microsoft 365.

Data governance matters now more than ever

Striking the right balance between data governance and productivity: Records Management is built into the Microsoft 365 productivity stack and existing customer workflows, easing the friction that often occurs between enforcing governance controls and user productivity. For example, say your team is working on a contract. Thanks to built-in retention policies embedded in the tools people use every day, they can continue to be productive while collaborating on a contract that has been declared a record—such as sharing, coauthoring, and accessing the record through mobile devices. We have also integrated our disposition process natively into the tools you use every day, including SharePoint and Outlook. Records versioning also makes collaboration on record-declared documents better, so you can track when edits are made to the contract. It allows users to unlock a document with a record label to make edits to it with all records safely retained and audit trails maintained. With Records Management, you can balance rigorous enforcement of data controls with allowing your organization to be fully productive.

Building trust, transparency, and defensibility: Building trust and providing transparency is crucial to managing records. In addition to continuing to audit all events surrounding a record in our audit log, we’re excited to announce the ability to obtain proof of disposal and see all items automatically disposed as part of a record label. Proof of disposal helps provide you with the defensibility you need, particularly to meet legal and regulatory requirements. Learn more in this Microsoft docs page.

Leveraging machine learning for scale: Records Management leverages our broader investments in machine learning across information protection and governance, such as trainable classifiers. With trainable classifiers, you can train the classification engine to recognize data that is unique to your organization. Once you define a record or retention label, you can apply the label to all content that matches a trainable classifier that was previously defined. So, for example, any document that appears to be a contract or have contract-related content will be marked accordingly and automatically classified as a record. For more information on creating trainable classifiers, please see this documentation. Apart from using trainable classifiers, you can also choose to auto-apply retention labels either by matching keywords on the content, its metadata, sensitive information it contains, or as the default for a particular location or folder. These different auto classification methods provide the flexibility you need to manage the constantly increasing volume of data.

Please visit this portal to learn more about Records Management.

Importance of information protection and governance

There’s never been a more important time to ensure your data, especially your most critical data, is protected and governed efficiently and effectively. Records Management is generally available worldwide today, and you can learn even more in our post on Tech Community. Eligible Microsoft 365 E5 customers can start using Records Management in the Compliance Center or learn how to try or buy a Microsoft 365 subscription.

Lastly, as you navigate this challenging time, we have additional resources to help. For more information about securing your organization in this time of crisis, you can visit our Remote Work site. We’re here to help in any way we can.

The post Data governance matters now more than ever appeared first on Microsoft Security.

The Safety Boat: Kubernetes and Rust

April 29th, 2020 No comments

Our team, DeisLabs, recently released a new piece of software called Krustlet, which is a tool for running WebAssembly modules on the popular, open-source container management tool called Kubernetes. Kubernetes is used quite extensively to run cloud software across many vendors and companies and is primarily written in the Go programming language. While there have …

The Safety Boat: Kubernetes and Rust Read More »

The post The Safety Boat: Kubernetes and Rust appeared first on Microsoft Security Response Center.

Ransomware groups continue to target healthcare, critical services; here’s how to reduce risk

April 28th, 2020 No comments

At a time when remote work is becoming universal and the strain on SecOps, especially in healthcare and critical industries, has never been higher, ransomware actors are unrelenting, continuing their normal operations.

Multiple ransomware groups that have been accumulating access and maintaining persistence on target networks for several months activated dozens of ransomware deployments in the first two weeks of April 2020. So far the attacks have affected aid organizations, medical billing companies, manufacturing, transport, government institutions, and educational software providers, showing that these ransomware groups give little regard to the critical services they impact, global crisis notwithstanding. These attacks, however, are not limited to critical services, so organizations should be vigilant for signs of compromise.

The ransomware deployments in this two-week period appear to cause a slight uptick in the volume of ransomware attacks. However, Microsoft security intelligence as well as forensic data from relevant incident response engagements by Microsoft Detection and Response Team (DART) showed that many of the compromises that enabled these attacks occurred earlier. Using an attack pattern typical of human-operated ransomware campaigns, attackers have compromised target networks for several months beginning earlier this year and have been waiting to monetize their attacks by deploying ransomware when they would see the most financial gain.

Many of these attacks started with the exploitation of vulnerable internet-facing network devices; others used brute force to compromise RDP servers. The attacks delivered a wide range of payloads, but they all used the same techniques observed in human-operated ransomware campaigns: credential theft and lateral movement, culminating in the deployment of a ransomware payload of the attacker’s choice. Because the ransomware infections are at the tail end of protracted attacks, defenders should focus on hunting for signs of adversaries performing credential theft and lateral movement activities to prevent the deployment of ransomware.

In this blog, we share our in-depth analysis of these ransomware campaigns. Below, we will cover:

We have included additional technical details including hunting guidance and recommended prioritization for security operations (SecOps).

Vulnerable and unmonitored internet-facing systems provide easy access to human-operated attacks

While the recent attacks deployed various ransomware strains, many of the campaigns shared infrastructure with previous ransomware campaigns and used the same techniques commonly observed in human-operated ransomware attacks.

In stark contrast to attacks that deliver ransomware via email—which tend to unfold much faster, with ransomware deployed within an hour of initial entry—the attacks we saw in April are similar to the Doppelpaymer ransomware campaigns from 2019, where attackers gained access to affected networks months in advance. They then remained relatively dormant within environments until they identified an opportune time to deploy ransomware.

To gain access to target networks, the recent ransomware campaigns exploited internet-facing systems with the following weaknesses:

  • Remote Desktop Protocol (RDP) or Virtual Desktop endpoints without multi-factor authentication (MFA)
  • Older platforms that have reached end of support and are no longer getting security updates, such as Windows Server 2003 and Windows Server 2008, exacerbated by the use of weak passwords
  • Misconfigured web servers, including IIS, electronic health record (EHR) software, backup servers, or systems management servers
  • Citrix Application Delivery Controller (ADC) systems affected by CVE-2019-19781
  • Pulse Secure VPN systems affected by CVE-2019-11510

Applying security patches for internet-facing systems is critical in preventing these attacks. It’s also important to note that, although Microsoft security researchers have not observed the recent attacks exploiting the following vulnerabilities, historical signals indicate that these campaigns may eventually exploit them to gain access, so they are worth reviewing: CVE-2019-0604, CVE-2020-0688, CVE-2020-10189.

Like many breaches, attackers employed credential theft, lateral movement capabilities using common tools, including Mimikatz and Cobalt Strike, network reconnaissance, and data exfiltration. In these specific campaigns, the operators gained access to highly privileged administrator credentials and were ready to take potentially more destructive action if disturbed. On networks where attackers deployed ransomware, they deliberately maintained their presence on some endpoints, intending to reinitiate malicious activity after ransom is paid or systems are rebuilt. In addition, while only a few of these groups gained notoriety for selling data, almost all of them were observed viewing and exfiltrating data during these attacks, even if they have not advertised or sold yet.

As with all human-operated ransomware campaigns, these recent attacks spread throughout an environment affecting email identities, endpoints, inboxes, applications, and more. Because it can be challenging even for experts to ensure complete removal of attackers from a fully compromised network, it’s critical that vulnerable internet-facing systems are proactively patched and mitigations put in place to reduce the risk from these kinds of attacks.

A motley crew of ransomware payloads

While individual campaigns and ransomware families exhibited distinct attributes as described in the sections below, these human-operated ransomware campaigns tended to be variations on a common attack pattern. They unfolded in similar ways and employed generally the same attack techniques. Ultimately, the specific ransomware payload at the end of each attack chain was almost solely a stylistic choice made by the attackers.

diagram showing different attack stages and techniques in each stage that various ransomware groups use

RobbinHood ransomware

RobbinHood ransomware operators gained some attention for exploiting vulnerable drivers late in their attack chain to turn off security software. However, like many other human-operated ransomware campaigns, they typically start with an RDP brute-force attack against an exposed asset. They eventually obtain privileged credentials, mostly local administrator accounts with shared or common passwords, and service accounts with domain admin privileges. RobbinHood operators, like Ryuk and other well-publicized ransomware groups, leave behind new local and Active Directory user accounts, so they can regain access after their malware and tools have been removed.

Vatet loader

Attackers often shift infrastructure, techniques, and tools to avoid notoriety that might attract law enforcement or security researchers. They often retain them while waiting for security organizations to start considering associated artifacts inactive, so they face less scrutiny. Vatet, a custom loader for the Cobalt Strike framework that has been seen in ransomware campaigns as early as November 2018, is one of the tools that has resurfaced in the recent campaigns.

The group behind this tool appears to be particularly intent on targeting hospitals, as well as aid organizations, insulin providers, medical device manufacturers, and other critical verticals. They are one of the most prolific ransomware operators during this time and have caused dozens of cases.

Using Vatet and Cobalt Strike, the group has delivered various ransomware payloads. More recently, they have been deploying in-memory ransomware that utilizes Alternate Data Streams (ADS) and displays simplistic ransom notes copied from older ransomware families. To access target networks, they exploit CVE-2019-19781, brute force RDP endpoints, and send email containing .lnk files that launch malicious PowerShell commands. Once inside a network, they steal credentials, including those stored in the Credential Manager vault, and move laterally until they gain domain admin privileges. The group has been observed exfiltrating data prior to deploying ransomware.

NetWalker ransomware

NetWalker campaign operators gained notoriety for targeting hospitals and healthcare providers with emails claiming to provide information about COVID-19. These emails also delivered NetWalker ransomware directly as a .vbs attachment, a technique that has gained media attention. However, the campaign operators also compromised networks using misconfigured IIS-based applications to launch Mimikatz and steal credentials, which they then used to launch PsExec, and eventually deploying the same NetWalker ransomware.

PonyFinal ransomware

This Java-based ransomware had been considered a novelty, but the campaigns deploying PonyFinal weren’t unusual. Campaign operators compromised internet-facing web systems and obtained privileged credentials. To establish persistence, they used PowerShell commands to launch the system tool mshta.exe and set up a reverse shell based on a common PowerShell attack framework. They also used legitimate tools, such as Splashtop, to maintain remote desktop connections.

Maze ransomware

One of the first ransomware campaigns to make headlines for selling stolen data, Maze continues to target technology providers and public services. Maze has a history of going after managed service providers (MSPs) to gain access to the data and networks of MSP customers.

Maze has been delivered via email, but campaign operators have also deployed Maze to networks after gaining access using common vectors, such as RDP brute force. Once inside a network, they perform credential theft, move laterally to access resources and exfiltrate data, and then deploy ransomware.

In a recent campaign, Microsoft security researchers tracked Maze operators establishing access through an internet-facing system by performing RDP brute force against the local administrator account. Using the brute-forced password, campaign operators were able to move laterally because built-in administrator accounts on other endpoints used the same passwords.

After gaining control over a domain admin account through credential theft, campaign operators used Cobalt Strike, PsExec, and a plethora of other tools to deploy various payloads and access data. They established fileless persistence using scheduled tasks and services that launched PowerShell-based remote shells. They also turned on Windows Remote Management for persistent control using stolen domain admin privileges. To weaken security controls in preparation for ransomware deployment, they manipulated various settings through Group Policy.

REvil ransomware

Possibly the first ransomware group to take advantage of the network device vulnerabilities in Pulse VPN to steal credentials to access networks, REvil (also called Sodinokibi) gained notoriety for accessing MSPs and accessing the networks and documents of customers – and selling access to both. They kept up this activity during the COVID-19 crisis, targeting MSPs and other targets like local governments. REvil attacks are differentiated in their uptake of new vulnerabilities, but their techniques overlap with many other groups, relying on credential theft tools like Mimikatz once in the network and performing lateral movement and reconnaissance with tools like PsExec.

Other ransomware families

Other ransomware families used in human-operated campaigns during this period include:

  • Paradise, which used to be distributed directly via email but is now used in human-operated ransomware attacks
  • RagnarLocker, which is deployed by a group that heavily uses RDP and Cobalt Strike with stolen credentials
  • MedusaLocker, which is possibly deployed via existing Trickbot infections
  • LockBit, which is distributed by operators that use the publicly available penetration testing tool CrackMapExec to move laterally

Immediate response actions for active attacks

We highly recommend that organizations immediately check if they have any alerts related to these ransomware attacks and prioritize investigation and remediation. Malicious behaviors relevant to these attacks that defenders should pay attention to include:

  • Malicious PowerShell, Cobalt Strike, and other penetration-testing tools that can allow attacks to blend in as benign red team activities
  • Credential theft activities, such as suspicious access to Local Security Authority Subsystem Service (LSASS) or suspicious registry modifications, which can indicate new attacker payloads and tools for stealing credentials
  • Any tampering with a security event log, forensic artifact such as the USNJournal, or a security agent, which attackers do to evade detections and to erase chances of recovering data

Customers using Microsoft Defender Advanced Threat Protection (ATP) can consult a companion threat analytics report for more details on relevant alerts, as well as advanced hunting queries. Customers subscribed to the Microsoft Threat Experts service can also refer to the targeted attack notification, which has detailed timelines of attacks, recommended mitigation steps for disrupting attacks, and remediation advice.

If your network is affected, perform the following scoping and investigation activities immediately to understand the impact of this breach. Using indicators of compromise (IOCs) alone to determine impact from these threats is not a durable solution, as most of these ransomware campaigns employ “one-time use” infrastructure for campaigns, and often change their tools and systems once they determine the detection capabilities of their targets. Detections and mitigations should concentrate on holistic behavioral based hunting where possible, and hardening infrastructure weaknesses favored by these attackers as soon as possible.

Investigate affected endpoints and credentials

Investigate endpoints affected by these attacks and identify all the credentials present on those endpoints. Assume that these credentials were available to attackers and that all associated accounts are compromised. Note that attackers can not only dump credentials for accounts that have logged on to interactive or RDP sessions, but can also dump cached credentials and passwords for service accounts and scheduled tasks that are stored in the LSA Secrets section of the registry.

  • For endpoints onboarded to Microsoft Defender ATP, use advanced hunting to identify accounts that have logged on to affected endpoints. The threat analytics report contains a hunting query for this purpose.
  • Otherwise, check the Windows Event Log for post-compromise logons—those that occur after or during the earliest suspected breach activity—with event ID 4624 and logon type 2 or 10. For any other timeframe, check for logon type 4 or 5.

Isolate compromised endpoints

Isolate endpoints that have command-and-control beacons or have been lateral movement targets. Locate these endpoints using advanced hunting queries or other methods of directly searching for related IOCs. Isolate machines using Microsoft Defender ATP, or use other data sources, such as NetFlow, and search through your SIEM or other centralized event management solutions. Look for lateral movement from known affected endpoints.

Address internet-facing weaknesses

Identify perimeter systems that attackers might have utilized to access your network. You can use a public scanning interface, such as shodan.io, to augment your own data. Systems that should be considered of interest to attackers include:

  • RDP or Virtual Desktop endpoints without MFA
  • Citrix ADC systems affected by CVE-2019-19781
  • Pulse Secure VPN systems affected by CVE-2019-11510
  • Microsoft SharePoint servers affected by CVE-2019-0604
  • Microsoft Exchange servers affected by CVE-2020-0688
  • Zoho ManageEngine systems affected by CVE-2020-10189

To further reduce organizational exposure, Microsoft Defender ATP customers can use the Threat and Vulnerability Management (TVM) capability to discover, prioritize, and remediate vulnerabilities and misconfigurations. TVM allows security administrators and IT administrators to collaborate seamlessly to remediate issues.

Inspect and rebuild devices with related malware infections

Many ransomware operators enter target networks through existing infections of malware like Emotet and Trickbot. These malware families, traditionally considered to be banking trojans, have been used to deliver all kinds of payloads, including persistent implants. Investigate and remediate any known infections and consider them possible vectors for sophisticated human adversaries. Ensure that you check for exposed credentials, additional payloads, and lateral movement prior to rebuilding affected endpoints or resetting passwords.

Building security hygiene to defend networks against human-operated ransomware

As ransomware operators continue to compromise new targets, defenders should proactively assess risk using all available tools. You should continue to enforce proven preventive solutions—credential hygiene, minimal privileges, and host firewalls—to stymie these attacks, which have been consistently observed taking advantage of security hygiene issues and over-privileged credentials.

Apply these measures to make your network more resilient against new breaches, reactivation of dormant implants, or lateral movement:

  • Randomize local administrator passwords using a tool such as LAPS.
  • Apply Account Lockout Policy.
  • Ensure good perimeter security by patching exposed systems. Apply mitigating factors, such as MFA or vendor-supplied mitigation guidance, for vulnerabilities.
  • Utilize host firewalls to limit lateral movement. Preventing endpoints from communicating on TCP port 445 for SMB will have limited negative impact on most networks, but can significantly disrupt adversary activities.
  • Turn on cloud-delivered protection for Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
  • Follow standard guidance in the security baselines for Office and Office 365 and the Windows security baselines. Use Microsoft Secure Score assesses to measures security posture and get recommended improvement actions, guidance, and control.
  • Turn on tamper protection features to prevent attackers from stopping security services.
  • Turn on attack surface reduction rules, including rules that can block ransomware activity:
    • Use advanced protection against ransomware
    • Block process creations originating from PsExec and WMI commands
    • Block credential stealing from the Windows local security authority subsystem (lsass.exe)

For additional guidance on improving defenses against human-operated ransomware and building better security posture against cyberattacks in general, read Human-operated ransomware attacks: A preventable disaster.

Microsoft Threat Protection: Coordinated defense against complex and wide-reaching human-operated ransomware

What we’ve learned from the increase in ransomware deployments in April is that attackers pay no attention to the real-world consequences of disruption in services—in this time of global crisis—that their attacks cause.

Human-operated ransomware attacks represent a different level of threat because adversaries are adept at systems administration and security misconfigurations and can therefore adapt to any path of least resistance they find in a compromised network. If they run into a wall, they try to break through. And if they can’t break through a wall, they’ve shown that they can skillfully find other ways to move forward with their attack. As a result, human-operated ransomware attacks are complex and wide-reaching. No two attacks are exactly the same.

Microsoft Threat Protections (MTP) provides coordinated defenses that uncover the complete attack chain and help block sophisticated attacks like human-operated ransomware. MTP combines the capabilities of multiple Microsoft 365 security services to orchestrate protection, prevention, detection, and response across endpoints, email, identities, and apps.

Through built-in intelligence, automation, and integration, MTP can block attacks, eliminate their persistence, and auto-heal affected assets. It correlates signals and consolidates alerts to help defenders prioritize incidents for investigation and response. MTP also provides a unique cross-domain hunting capability that can further help defenders identify attack sprawl and get org-specific insights for hardening defenses.

Microsoft Threat Protection is also part of a chip-to-cloud security approach that combines threat defense on the silicon, operating system, and cloud. Hardware-backed security features on Windows 10 like address space layout randomization (ASLR), Control Flow Guard (CFG), and others harden the platform against many advanced threats, including ones that take advantage of vulnerable kernel drivers. These platform security features seamlessly integrate with Microsoft Defender ATP, providing end-to-end security that starts from a strong hardware root of trust. On Secured-core PCs these mitigations are enabled by default.

We continue to work with our customers, partners, and the research community to track human-operated ransomware and other sophisticated attacks. For dire cases customers can use available services like the Microsoft Detection and Response (DART) team to help investigate and remediate.

 

Microsoft Threat Protection Intelligence Team

 

Appendix: MITRE ATT&CK techniques observed

Human-operated ransomware campaigns employ a broad range of techniques made possible by attacker control over privileged domain accounts. The techniques listed here are techniques commonly used during attacks against healthcare and critical services in April 2020.

Credential access

Persistence

Command and control

Discovery

Execution

Lateral movement

Defense evasion

  • T1070 Indicator Removal on Host | Clearing of event logs using wevutil, removal of USNJournal using fsutil, and deletion of slack space on drive using cipher.exe
  • T1089 Disabling Security Tools | Stopping or tampering with antivirus and other security using ProcessHacker and exploitation of vulnerable software drivers

Impact

The post Ransomware groups continue to target healthcare, critical services; here’s how to reduce risk appeared first on Microsoft Security.

Managing risk in today’s IoT landscape: not a one-and-done

April 28th, 2020 No comments

image for Halina's Blog Post_updated-BANNER

The reality of securing IoT over time

It’s difficult to imagine any aspect of everyday life that isn’t affected by the influence of connectivity. The number of businesses that are using IoT is growing at a fast pace. By 2021, approximately 94 percent of businesses will be using IoT. Connectivity empowers organizations to unlock the full potential of the Internet of Things (IoT)—but it also introduces new cybersecurity attack vectors that they didn’t need to think about before. The reality is, connectivity comes at a cost: attackers with a wide range of motivations and skills are on the hunt, eager to exploit vulnerabilities or weak links in IoT. What does it take to manage those risks?

The cybersecurity threat landscape is ever evolving so a solution’s protection must also evolve regularly in order to remain effective. Securing a device is neither a one-time action nor is it a problem that is solely technical in nature. Implementing robust security measures upfront is not enough—risks need to be mitigated not just once, but constantly and throughout the full lifespan of a device. Facing this threat landscape ultimately means acknowledging that organizations will have to confront the consequences of attacks and newfound vulnerabilities. The question is, how to manage those risks beyond the technical measures that are in place?

A holistic approach to minimizing risk

Securing IoT devices against cyberattacks requires a holistic approach that complements up-front technical measures with ongoing practices that allow organizations to evaluate risks and establish a set of actions and policies that minimize threats over time. Cybersecurity is a multi-dimensional issue that requires the provider of an IoT solution to take several variables into account—it is not just the technology, but also the people who create and manage a product and the processes and practices they put in place, that will determine how resilient it is.

With Azure Sphere, we provide our customers with a robust defense that utilizes the evidence and learnings documented in the Seven Properties of Highly Secured Devices. One of the properties, renewable security, ensures that a device can update to a more secure state even after it has been compromised. As the threat landscape evolves, renewable security also enables us to counter new attack vectors through updates. This is essential, but not sufficient on its own. Our technology investments are enhanced through similar investments in security assurance and risk management that permeate all levels of an organization. The following sections highlight three key elements of our holistic approach to IoT security: continuous evaluation of our security promise, leveraging the power of the security community, and combining cyber and organizational resilience. 

Continuous evaluation of our security promise

All cyberattacks fall somewhere on a spectrum of complexity. On one side of the spectrum are simple and opportunistic attacks. Examples are off-the-shelf malware or attempts to steal data such as credentials. These attacks are usually performed by attackers with limited resources. On the opposite side of the spectrum are threat actors that use highly sophisticated methods to target specific parts of the system. Attackers within this category usually have many resources and can pursue an attack over a longer period of time. Given the multitude of threats across this spectrum, it is important to keep in mind that they all have one thing in common: an attacker faces relatively low risk with potentially very large rewards.

Taking this into account, we believe that in order to protect our customers we need to practice being our own worst enemy. This means our goal is to discover any vulnerabilities before the bad guys do. One proven approach is to test our solution from the same perspective as an attacker. So-called “red teams” are designed to emulate the attacks of adversaries, whereas “purple teams” perform both attacking and defending to harden a product from within.

Our approach to red team exercises is to try to mimic the threat landscape that devices are actually facing. We do this multiple times a year and across the full Azure Sphere stack. This means that our customers benefit from the rigorous security testing of our platform and are able to focus on the security of their own applications. We work with the world’s most renowned security service providers to test our product with a real-world attacker mentality for an extended period of time and from multiple perspectives. In addition, we leverage the full power of Microsoft internal security expertise to conduct regular internal red and purple team exercises. The practice of constantly evaluating our defense and emulating the ever-evolving threat landscape is an important part of our security hygiene—allowing us to find vulnerabilities, update all devices, and mitigate incidents before they even happen.

Leveraging the power of the security community

Another approach to finding vulnerabilities before attackers do is to engage with the cybersecurity community through bounty programs. We encourage security researchers with an interest in Azure Sphere to search for any vulnerabilities and we reward them for it. While our approach to red team exercises ensures regular testing of how we secure Azure Sphere, we also believe in the advantages of the continual and diverse assessment by anyone who is interested, at any point in time.

Security researchers play a significant role in securing our billions of customers across Microsoft, and we encourage the responsible reporting of vulnerabilities based on our Coordinated Vulnerability Disclosure (CVD). We invite researchers from across the world to look for and report any vulnerability through our Microsoft Azure Bounty Program. Depending on the quality of submissions and the level of severity, we award successful reports with up to $40,000 USD. We believe that researchers should be rewarded competitively when they improve the security of our platform, and we maintain these important relationships for the benefit of our customers.

From a risk management perspective, both red and purple team exercises and bug bounties are helpful tools to minimize the risk of attacks. But what happens when an IoT solution provider is confronted with a newly discovered security vulnerability? Not every organization has a cybersecurity incident response plan in place, and 77 percent of businesses do not have a consistently deployed plan. Finding vulnerabilities is important, but it is equally important to prepare employees and equip the organization with processes and practices that allow for a quick and efficient resolution as soon as a vulnerability is found.

Combining cyber and organizational resilience

Securing IoT is not just about preventing attackers from getting in; it’s also about how to respond when they do. Once the technical barrier has been passed, it is the resilience of the organization that the device has to fall back on. Therefore, it is essential to have a plan in place that allows your team to quickly respond and restore security. There are countless possible considerations and moving parts that must all fit together seamlessly as part of a successful cybersecurity incident response. Every organization is different and there is no one-size-fits-all, but a good place to start is with industry best practices such as the National Institute of Standards and Technology (NIST) Computer Security Incident Handling Guide. Azure Sphere’s standard operating procedures are aligned with those guidelines, in addition to leveraging Microsoft battle-tested corporate infrastructure.

Microsoft Security Response Center (MSRC) has been at the front line of security response for more than twenty years. Over time we have learned what it means to successfully protect our customers from harm from vulnerabilities in our products, and we are able to rapidly drive back attacks against our cloud infrastructure. Security researchers and customers are provided with an easy way to report any vulnerabilities and MSRC best-in-class security experts are monitoring communications 24/7 to make sure we can fix an issue as soon as possible.

Your people are a critical asset—when they’re educated on how to respond when an incident occurs, their actions can make all the difference. In addition to MSRC capabilities that are available at any time, we require everyone involved in security incident response to undergo regular and extensive training. Trust is easy to build when things are going right. What really matters in the long term is how we build trust when things go wrong. Our security response practices have been defined with that in mind.

Our commitment to managing the risks you are facing

The world will be more connected than it has ever been, and we believe this requires a strong, holistic, and ongoing focus on cybersecurity. Defending against today’s and tomorrow’s IoT threat landscape is not a static game. It requires continual assessment of our promise to secure your IoT solutions, innovation that improves our defense over time, and working with you and the security community. As the threat landscape evolves, so will we. Azure Sphere’s mission is to empower every organization on the planet to connect and create secured and trustworthy IoT devices. When you choose Azure Sphere, you can rely on our team and Microsoft to manage your risk so that you can focus on the true business value of your IoT solutions and products.

If you are interested in learning more about how Azure Sphere can help you securely unlock your next IoT innovation:

The post Managing risk in today’s IoT landscape: not a one-and-done appeared first on Microsoft Security.

Congratulating Our Top 2020 Q1 Security Researchers!

April 23rd, 2020 No comments

Following the second Security Researcher Quarterly Leaderboard and the 2020 MSRC Most Valuable Security Researchers criteria we published in February 2020, we are excited to announce the 2020 First Quarter (Q1) Security Researcher Leaderboard, listing our top contributing researchers for the last quarter. The top three researchers of the last quarter are: Zhiniang Peng (2870 …

Congratulating Our Top 2020 Q1 Security Researchers! Read More »

The post Congratulating Our Top 2020 Q1 Security Researchers! appeared first on Microsoft Security Response Center.

Protecting your organization against password spray attacks

April 23rd, 2020 No comments

When hackers plan an attack, they often engage in a numbers game. They can invest significant time pursing a single, high-value target—someone in the C-suite for example and do “spear phishing.” Or if they just need low-level access to gain a foothold in an organization or do reconnaissance, they target a huge volume of people and spend less time on each one which is called “password spray.” Last December Seema Kathuria and I described an example of the first approach in Spear phishing campaigns—they’re sharper than you think! Today, I want to talk about a high-volume tactic: password spray.

In a password spray attack, adversaries “spray” passwords at a large volume of usernames. When I talk to security professionals in the field, I often compare password spray to a brute force attack. Brute force is targeted. The hacker goes after specific users and cycles through as many passwords as possible using either a full dictionary or one that’s edited to common passwords. An even more targeted password guessing attack is when the hacker selects a person and conducts research to see if they can guess the user’s password—discovering family names through social media posts, for example. And then trying those variants against an account to gain access. Password spray is the opposite. Adversaries acquire a list of accounts and attempt to sign into all of them using a small subset of the most popular, or most likely, passwords. Until they get a hit. This blog describes the steps adversaries use to conduct these attacks and how you can reduce the risk to your organization.

Three steps to a successful password spray attack

Step 1: Acquire a list of usernames

It starts with a list of accounts. This is easier than it sounds. Most organizations have a formal convention for emails, such as firstname.lastname@company.com. This allows adversaries to construct usernames from a list of employees. If the bad actor has already compromised an account, they may try to enumerate usernames against the domain controller. Or, they find or buy usernames online. Data can be compiled from past security breaches, online profiles, etc. The adversary might even get some verified profiles for free!

Step 2: Spray passwords

Finding a list of common passwords is even easier. A Bing search reveals that publications list the most common passwords each year. 123456, password, and qwerty are typically near the top. Wikipedia lists the top 10,000 passwords. There are regional differences that may be harder to discovery, but many people use a favorite sports teams, their state, or company as a password. For example, Seahawks is a popular password choice in the Seattle area. Once hackers do their research, they carefully select a password and try it against the entire list of accounts as shown in Figure 1. If the attack is not successful, they wait 30 minutes to avoid triggering a timeout, and then try the next password.

Protecting your organization against password spray attacks

Figure 1:  Password spray using one password across multiple accounts.

Step 3: Gain access

Eventually one of the passwords works against one of the accounts. And that’s what makes password spray a popular tactic—attackers only need one successful password + username combination. Once they have it, they can access whatever the user has access to, such as cloud resources on OneDrive. Or use the exploited account to do internal reconnaissance on the target network and get deeper into the systems via elevation of privilege.

Even if the vast majority of your employees don’t use popular passwords, there is a risk that hackers will find the ones that do. The trick is to reduce the number of guessable passwords used at your organization.

Configure Azure Active Directory (Azure AD) Password Protection

Azure AD Password Protection allows you to eliminate easily guessed passwords and customize lockout settings for your environment. This capability includes a globally banned password list that Microsoft maintains and updates. You can also block a custom list of passwords that are relevant to your region or company. Once enabled, users won’t be able to choose a password on either of these lists, making it significantly less likely that an adversary can guess a user’s password. You can also use this feature to define how many sign-in attempts will trigger a lockout and how long the lockout will last.

Simulate attacks with Office 365 Advanced Threat Protection (Office 365 ATP)

Attack Simulator in Office 365 ATP lets you run realistic, but simulated phishing and password attack campaigns in your organization. Pick a password and then run the campaign against as many users as you want. The results will let you know how many people are using that password. Use the data to train users and build your custom list of banned passwords.

Begin your passwordless journey

The best way to reduce your risk of password spray is to eliminate passwords entirely. Solutions like Windows Hello or FIDO2 security keys let users sign in using biometrics and/or a physical key or device. Get started by enabling Multi-Factor Authentication (MFA) across all your accounts. MFA requires that users sign in with at least two authentication factors: something they know (like a password or PIN), something they are (such as biometrics), and/or something they have (such as a trusted device).

Learn more

We make progress in cybersecurity by increasing how much it costs the adversary to conduct the attack. If we make guessing passwords too hard, hackers will reduce their reliance on password spray.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. For more information about our security solutions visit our website. Or reach out to me on LinkedIn or Twitter.

The post Protecting your organization against password spray attacks appeared first on Microsoft Security.

Defending the power grid against supply chain attacks: Part 3 – Risk management strategies for the utilities industry

April 22nd, 2020 No comments

Over the last fifteen years, attacks against critical infrastructure (figure1) have steadily increased in both volume and sophistication. Because of the strategic importance of this industry to national security and economic stability, these organizations are targeted by sophisticated, patient, and well-funded adversaries.  Adversaries often target the utility supply chain to insert malware into devices destined for the power grid. As modern infrastructure becomes more reliant on connected devices, the power industry must continue to come together to improve security at every step of the process.

Aerial view of port and freeways leading to downtown Singapore.

Figure 1: Increased attacks on critical infrastructure

This is the third and final post in the “Defending the power grid against supply chain attacks” series. In the first blog I described the nature of the risk. Last month I outlined how utility suppliers can better secure the devices they manufacture. Today’s advice is directed at the utilities. There are actions you can take as individual companies and as an industry to reduce risk.

Implement operational technology security best practices

According to Verizon’s 2019 Data Breach Investigations Report, 80 percent of hacking-related breaches are the result of weak or compromised passwords. If you haven’t implemented multi-factor authentication (MFA) for all your user accounts, make it a priority. MFA can significantly reduce the likelihood that a user with a stolen password can access your company assets. I also recommend you take these additional steps to protect administrator accounts:

  • Separate administrative accounts from the accounts that IT professionals use to conduct routine business. While administrators are answering emails or conducting other productivity tasks, they may be targeted by a phishing campaign. You don’t want them signed into a privileged account when this happens.
  • Apply just-in-time privileges to your administrator accounts. Just-in-time privileges require that administrators only sign into a privileged account when they need to perform a specific administrative task. These sign-ins go through an approval process and have a time limit. This will reduce the possibility that someone is unnecessarily signed into an administrative account.

 

Image 2

Figure 2: A “blue” path depicts how a standard user account is used for non-privileged access to resources like email and web browsing and day-to-day work. A “red” path shows how privileged access occurs on a hardened device to reduce the risk of phishing and other web and email attacks. 

  • You also don’t want the occasional security mistake like clicking on a link when administrators are tired or distracted to compromise the workstation that has direct access to these critical systems.  Set up privileged access workstations for administrative work. A privileged access workstation provides a dedicated operating system with the strongest security controls for sensitive tasks. This protects these activities and accounts from the internet. To encourage administrators to follow security practices, make sure they have easy access to a standard workstation for other more routine tasks.

The following security best practices will also reduce your risk:

  • Whitelist approved applications. Define the list of software applications and executables that are approved to be on your networks. Block everything else. Your organization should especially target systems that are internet facing as well as Human-Machine Interface (HMI) systems that play the critical role of managing generation, transmission, or distribution of electricity
  • Regularly patch software and operating systems. Implement a monthly practice to apply security patches to software on all your systems. This includes applications and Operating Systems on servers, desktop computers, mobile devices, network devices (routers, switches, firewalls, etc.), as well as Internet of Thing (IoT) and Industrial Internet of Thing (IIoT) devices. Attackers frequently target known security vulnerabilities.
  • Protect legacy systems. Segment legacy systems that can no longer be patched by using firewalls to filter out unnecessary traffic. Limit access to only those who need it by using Just In Time and Just Enough Access principles and requiring MFA. Once you set up these subnets, firewalls, and firewall rules to protect the isolated systems, you must continually audit and test these controls for inadvertent changes, and validate with penetration testing and red teaming to identify rogue bridging endpoint and design/implementation weaknesses.
  • Segment your networks. If you are attacked, it’s important to limit the damage. By segmenting your network, you make it harder for an attacker to compromise more than one critical site. Maintain your corporate network on its own network with limited to no connection to critical sites like generation and transmission networks. Run each generating site on its own network with no connection to other generating sites. This will ensure that should a generating site become compromised, attackers can’t easily traverse to other sites and have a greater impact.
  • Turn off all unnecessary services. Confirm that none of your software has automatically enabled a service you don’t need. You may also discover that there are services running that you no longer use. If the business doesn’t need a service, turn it off.
  • Deploy threat protection solutions. Services like Microsoft Threat Protection help you automatically detect, respond to, and correlate incidents across domains.
  • Implement an incident response plan: When an attack happens, you need to respond quickly to reduce the damage and get your organization back up and running. Refer to Microsoft’s Incident Response Reference Guide for more details.

Speak with one voice

Power grids are interconnected systems of generating plants, wires, transformers, and substations. Regional electrical companies work together to efficiently balance the supply and demand for electricity across the nation. These same organizations have also come together to protect the grid from attack. As an industry, working through organizations like the Edison Electric Institute (EEI), utilities can define security standards and hold manufacturers accountable to those requirements.

It may also be useful to work with The Federal Energy Regulatory Committee (FERC), The North American Electric Reliability Corporation (NERC), or The United States Nuclear Regulatory Commission (U.S. NRC) to better regulate the security requirements of products manufactured for the electrical grid.

Apply extra scrutiny to IoT devices

As you purchase and deploy IoT devices, prioritize security. Be careful about purchasing products from countries that are motivated to infiltrate critical infrastructure. Conduct penetration tests against all new IoT and IIoT devices before you connect them to the network. When you place sensors on the grid, you’ll need to protect them from both cyberattacks and physical attacks. Make them hard to reach and tamper-proof.

Collaborate on solutions

Reducing the risk of a destabilizing power grid attack will require everyone in the utility industry to play a role. By working with manufacturers, trade organizations, and governments, electricity organizations can lead the effort to improve security across the industry. For utilities in the United States, several public-private programs are in place to enhance the utility industry capabilities to defend its infrastructure and respond to threats:

Read Part 1 in the series: “Defending the power grid against cyberattacks

Read “Defending the power grid against supply chain attacks: Part 2 – Securing hardware and software

Read how Microsoft Threat Protection can help you better secure your endpoints.

Learn how MSRC developed an incident response plan

Bookmark the Security blog to keep up with our expert coverage on security matters. For more information about our security solutions visit our website. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

The post Defending the power grid against supply chain attacks: Part 3 – Risk management strategies for the utilities industry appeared first on Microsoft Security.

MITRE ATT&CK APT 29 evaluation proves Microsoft Threat Protection provides deeper end to end view of advanced threats

April 21st, 2020 No comments

As attackers use more advanced techniques, it’s even more important that defenders have visibility not just into each of the domains in their environment, but also across them to piece together coordinated, targeted, and advanced attacks. This level of visibility will allow us to get ahead of attackers and close the gaps through which they enter. To illustrate that imperative, the 2019 MITRE ATT&CK evaluation centered on an advanced nation-state threat actor known to the industry as Advanced Persistent Threat (APT) 29 (also known as Cozy Bear) which largely overlaps with the activity group that Microsoft calls YTTRIUM. . The test involved a simulation of 58 attacker techniques in 10 kill chain categories.

Microsoft participated in the second MITRE ATT&CK endpoint detection product evaluation published today. The evaluation is designed to test security products based on the ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) framework, which is highly regarded in the security industry as one of the most comprehensive catalog of attacker techniques and tactics. Threat hunters use this framework to look for specific techniques that attackers often use to penetrate defenses. Testing that incorporates a comprehensive view of an environment’s ability to monitor and detect malicious activity with the existing tools that defenders have deployed across an organization is critical.

Although this test was focused on endpoint detection and response, MITRE ran the simulated APT29 attack from end to end and across multiple attack domains, meaning defenders benefited from visibility beyond just endpoint protection. This gave Microsoft the unique opportunity to bring Microsoft Threat Protection (MTP) to the test.

Microsoft Threat Protection expands Microsoft Defender ATP from endpoint detection and response (EDR) to an extended detection and response (XDR) solution, and is designed to provide extended detection and response by combining protection for endpoints (Microsoft Defender ATP), email and productivity tools (Office 365 ATP), identity (Azure ATP), and cloud applications (Microsoft Cloud App Security/MCAS). As customers face attacks across endpoints, cloud, applications and identities, MTP looks across these domains to understand the entire chain of events, identifies affected assets, like users, endpoints, mailboxes, and applications, and auto-heals them back to a safe state.

Microsoft Threat Protection delivers coverage across the entire kill chain, not just the endpoint

To fully execute the end to end attack simulation of APT29, MITRE required participants to turn off all proactive protection and blocking capabilities. For Microsoft Threat Protection, this meant that all the capabilities that would normally block this kind of attack such as automatic remediation flows, application isolation, attack surface reduction, network protection, exploit protection, controlled folder access, and next-gen antivirus prevention were turned off. However, Microsoft Threat Protection audit capabilities for these features enabled recording of a variety of points during the attack when MTP (had it been fully enabled) would have prevented or blocked execution, likely stopping the attack in its tracks.

During this evaluation Microsoft Threat Protection delivered on providing the deep and broad optics, near real time detection through automation, and a complete, end-to-end view of the attack story. Here is how Microsoft Threat Protection stood out:

  • Depth and breadth of optics: Our uniquely integrated operating system, directory, and cloud sensors contributed deep and broad telemetry coverage. AI-driven, cloud-powered models collaborating across domains identified malicious activities and raised alerts on attacker techniques across the entire attack kill chain:
    • Microsoft Defender ATP recorded and alerted on endpoint activities including advanced file-less techniques, privilege escalation, and credential theft and persistence – leveraging deep sensors like AMSI, WMI, and LDAP.
    • Azure ATP watched and detected account compromise at the domain level, and lateral movement, such as pass-the-hash and the more sophisticated pass-the-ticket (Golden Ticket attack).
    • Microsoft Cloud App Security identified exfiltration of data to the cloud (OneDrive).
  • Detection and containment in near real time:Nation state attacks of this magnitude can take place over the course of as little as a few hours, which means that Security Operations Centers (SOCs) often have little to no time to respond. Near-real-time automated detection of advanced techniques is critical to address this challenge. Where possible, active blocking, prevention and automatic containment will make the difference between an attempted versus a successful compromise. MTP’s prevention capabilities along with fast detection and behavioral blocking are exactly designed for this purpose.
  • A complete attack story: Throughout this evaluation, Microsoft Defender ATP, Azure ATP, and Microsoft Cloud App Security, combined with the expertise of Microsoft Threat Experts generated nearly 80 alerts – for SOC teams, manually following up on each one of these alerts is overwhelming. MTP consolidated the alerts into just two incidents, dramatically simplifying the volume of triage and investigation work needed. This gives the SOC the ability to prioritize and address the incident as a whole and enables streamlined triage, investigation, and automated response process against the complete attack. With MTP we have built in automation that identifies the complex links between attacker activities and builds correlations across domains that piece together the attack story with all of its related alerts, telemetry, evidence and affected assets into coherent incidents. These comprehensive incidents are then prioritized and escalated to the SOC.

 

Microsoft Threat Experts, our managed threat hunting service, also participated in the evaluation this year. Our security experts watched over the signals collected in real time and generated comprehensive, complementary alerts, which enriched the automated detections with additional details, insights and recommendations for the SOC.

Real world testing is critical

Attackers are using advanced, persistent, and intelligent techniques to penetrate today’s defenses. This method of testing leans heavily into real-world exploitations rather than those found solely in a lab or simulated testing environment. Having been part of the inaugural round of the MITRE ATT&CK evaluation in 2018, Microsoft enthusiastically took on the challenge again, as we believe this to be a great opportunity, alongside listening to customers and investing in research, to continuously drive our security products to excellence and protect our customers.

This year, for the first time, we were happy to answer the community call from MITRE, alongside other security vendors, to contribute unique threat intelligence and research content about APT29, as well as in evolving the evaluation based on the experience and feedback from last year, yielding a very collaborative and productive process.

Thank you to MITRE and our customers and partners for your partnership in helping us deliver more visibility and automated protection, detection, response, and prevention of threats for our customers.

– Moti Gindi, CVP, Microsoft Threat Protection

The post MITRE ATT&CK APT 29 evaluation proves Microsoft Threat Protection provides deeper end to end view of advanced threats appeared first on Microsoft Security.

NERC CIP Compliance in Azure vs. Azure Government cloud

April 20th, 2020 No comments

As discussed in my last blog post on North American Electric Reliability Corporation—Critical Infrastructure Protection (NERC CIP) Compliance in Azure, U.S. and Canadian utilities are now free to benefit from cloud computing in Azure for many NERC CIP workloads. Machine learning, multiple data replicas across fault domains, active failover, quick deployment and pay for use benefits are now available for these NERC CIP workloads.

Good candidates include a range of predictive maintenance, asset management, planning, modelling and historian systems as well as evidence collection systems for NERC CIP compliance itself.

It’s often asked whether a utility must use Azure Government Cloud (“Azure Gov”) as opposed to Azure public cloud (“Azure”) to host their NERC CIP compliant workloads. The short answer is that both are an option.  There are several factors that bear on the choice.

U.S. utilities can use Azure and Azure Gov for NERC CIP workloads. Canadian utilities can use Azure.

There are some important differences that should be understood when choosing an Azure cloud for deployment.

Azure and Azure Gov are separate clouds, physically isolated from each other. They both offer U.S. regions. All data replication for both can be kept within the U.S.

Azure also offers two Canadian regions, one in Ontario and one in Quebec, with data stored exclusively in Canada.

Azure Gov is only available to verified U.S. federal, state, and local government entities, some partners and contractors. It has four regions: Virginia, Iowa, Arizona and Texas. Azure Gov is available to U.S.-based NERC Registered Entities.

We are working toward feature parity between Azure and Azure Gov. A comparison is provided here.

The security controls are the same for Azure and Azure Gov clouds. All U.S. Azure regions are now approved for FedRAMP High impact level.

Azure Gov provides additional assurances regarding U.S. government-specific background screening requirements. One of these is verification that Azure Gov operations personnel with potential access to Customer Data are U.S. persons. Azure Gov can also support customers subject to certain export controls laws and regulations. While not a NERC CIP requirement, this can impact U.S. utility customers.

Azure Table 1

Under NERC CIP-004, utilities are required to conduct background checks.

Microsoft U.S. Employee Background Screening

Microsoft US Employee Background Screening

Microsoft’s background checks for both Azure and Azure Gov exceed the requirements of CIP 004.

NERC is not prescriptive on the background check that a utility must conduct as part of its compliance policies.

A utility may have a U.S. citizenship requirement as part of its CIP-004 compliance policy which covers both its own staff and the operators of its cloud infrastructure. Thus, if a utility needs U.S. citizens operating its Microsoft cloud in order to meet its own CIP-004 compliance standards, it can use Azure Gov for this purpose.

A utility may have nuclear assets that subject it to U.S. Department of Energy export control requirements (DOE 10 CFR Part 810) on Unclassified Controlled Nuclear Information. This rule covers more than the export of nuclear technology outside the United States, it also covers the transmission of protected information or technology to foreign persons inside the U.S. (e.g., employees of the utility and employees of the utility’s cloud provider).

Since access to protected information could be necessary to facilitate a support request, this should be considered if the customer has DOE export control obligations. Though the NERC assets themselves may be non-nuclear, the utility’s policy set may extend to its entire fleet and workforce regardless of generation technology. Azure Gov, which requires that all its operators be U.S. citizens, would facilitate this requirement.

Azure makes the operational advantages, increased security and cost savings of the cloud available for many NERC CIP workloads. Microsoft provides Azure and Azure Gov clouds for our customers’ specific needs.  Microsoft continues its work with regulators to make our cloud available for more workloads, including those requiring compliance with NERC CIP standards. The utility (Registered Entity) is ultimately responsible for NERC CIP compliance and Microsoft continues to work with customers and partners to simplify the efforts to prepare for audits.

Thanks to Larry Cochrane and Stevan Vidich for their leadership on Microsoft’s NERC CIP compliance viewpoint and architecture. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. To learn more about our Security solutions visit our website.

 

(c) 2020 Microsoft Corporation. All rights reserved. This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document is not intended to communicate legal advice or a legal or regulatory compliance opinion. Each customer’s situation is unique, and legal and regulatory compliance should be assessed in consultation with their legal counsel.

The post NERC CIP Compliance in Azure vs. Azure Government cloud appeared first on Microsoft Security.

Secure the software development lifecycle with machine learning

April 16th, 2020 No comments

Every day, software developers stare down a long list of features and bugs that need to be addressed. Security professionals try to help by using automated tools to prioritize security bugs, but too often, engineers waste time on false positives or miss a critical security vulnerability that has been misclassified. To tackle this problem data science and security teams came together to explore how machine learning could help. We discovered that by pairing machine learning models with security experts, we can significantly improve the identification and classification of security bugs.

At Microsoft, 47,000 developers generate nearly 30 thousand bugs a month. These items get stored across over 100 AzureDevOps and GitHub repositories. To better label and prioritize bugs at that scale, we couldn’t just apply more people to the problem. However, large volumes of semi-curated data are perfect for machine learning. Since 2001 Microsoft has collected 13 million work items and bugs. We used that data to develop a process and machine learning model that correctly distinguishes between security and non-security bugs 99 percent of the time and accurately identifies the critical, high priority security bugs, 97 percent of the time. This is an overview of how we did it.

Qualifying data for supervised learning

Our goal was to build a machine learning system that classifies bugs as security/non-security and critical/non-critical with a level of accuracy that is as close as possible to that of a security expert. To accomplish this, we needed a high-volume of good data. In supervised learning, machine learning models learn how to classify data from pre-labeled data. We planned to feed our model lots of bugs that are labeled security and others that aren’t labeled security. Once the model was trained, it would be able to use what it learned to label data that was not pre-classified. To confirm that we had the right data to effectively train the model, we answered four questions:

  • Is there enough data? Not only do we need a high volume of data, we also need data that is general enough and not fitted to a small number of examples.
  • How good is the data? If the data is noisy it means that we can’t trust that every pair of data and label is teaching the model the truth. However, data from the wild is likely to be imperfect. We looked for systemic problems rather than trying to get it perfect.
  • Are there data usage restrictions? Are there reasons, such as privacy regulations, that we can’t use the data?
  • Can data be generated in a lab? If we can generate data in a lab or some other simulated environment, we can overcome other issues with the data.

Our evaluation gave us confidence that we had enough good data to design the process and build the model.

Data science + security subject matter expertise

Our classification system needs to perform like a security expert, which means the subject matter expert is as important to the process as the data scientist. To meet our goal, security experts approved training data before we fed it to the machine learning model. We used statistical sampling to provide the security experts a manageable amount of data to review. Once the model was working, we brought the security experts back in to evaluate the model in production.

With a process defined, we could design the model. To classify bugs accurately, we used a two-step machine learning model operation. First the model learned how to classify security and non-security bugs. In the second step the model applied severity labels—critical, important, low-impact—to the security bugs.

Our approach in action

Building an accurate model is an iterative process that requires strong collaboration between subject matter experts and data scientists:

Data collection: The project starts with data science. We identity all the data types and sources and evaluate its quality.

Data curation and approval: Once the data scientist has identified viable data, the security expert reviews the data and confirms the labels are correct.

Modeling and evaluation: Data scientists select a data modeling technique, train the model, and evaluate model performance.

Evaluation of model in production: Security experts evaluate the model in production by monitoring the average number of bugs and manually reviewing a random sampling of bugs.

The process didn’t end once we had a model that worked. To make sure our bug modeling system keeps pace with the ever-evolving products at Microsoft, we conduct automated re-training. The data is still approved by a security expert before the model is retrained, and we continuously monitor the number of bugs generated in production.

More to come

By applying machine learning to our data, we accurately classify which work items are security bugs 99 percent of the time. The model is also 97 percent accurate at labeling critical and non-critical security bugs. This level of accuracy gives us confidence that we are catching more security vulnerabilities before they are exploited.

In the coming months, we will open source our methodology to GitHub.

In the meantime, you can read a published academic paper, Identifying security bug reports based solely on report titles and noisy data, for more details. Or download a short paper that was featured at Grace Hopper Celebration 2019.

Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. To learn more about our Security solutions visit our website.

The post Secure the software development lifecycle with machine learning appeared first on Microsoft Security.

Security guidance for remote desktop adoption

April 15th, 2020 No comments

As the volume of remote workers quickly increased over the past two to three months, the IT teams in many companies scrambled to figure out how their infrastructures and technologies would be able to handle the increase in remote connections. Many companies were forced to enhance their capabilities to allow remote workers access to systems and applications from their homes and other locations outside the network perimeter. Companies that couldn’t make changes rapidly enough to increase capacity for remote workers might rely on remote access using the remote desktop protocol, which allows employees to access workstations and systems directly.

Recently, John Matherly (founder of Shodan, the world’s first search engine for internet-connected devices) conducted some research on ports that are accessible on the internet, surfacing some important findings. Notably, there has been an increase in the number of systems accessible via the traditional Remote Desktop Protocol (RDP) port and a well-known “alternative” port used for RDP. A surprising finding from John’s research is the ongoing prevalent usage of RDP and its exposure to the internet.

Although Remote Desktop Services (RDS) can be a fast way to enable remote access for employees, there are a number of security challenges that need to be considered before using this as a remote access strategy. One of these challenges is that attackers continue to target the RDP and service, putting corporate networks, systems, and data at risk (e.g., cybercriminals could exploit the protocol to establish a foothold on the network, install ransomware on systems, or take other malicious actions). In addition, there are challenges with being able to configure security for RDP sufficiently, to restrict a cybercriminal from moving laterally and compromising data.

Security considerations for remote desktop include:

  • Direct accessibility of systems on the public internet.
  • Vulnerability and patch management of exposed systems.
  • Internal lateral movement after initial compromise.
  • Multi-factor authentication (MFA).
  • Session security.
  • Controlling, auditing, and logging remote access.

Some of these considerations can be addressed using Microsoft Remote Desktop Services to act as a gateway to grant access to remote desktop systems. The Microsoft Remote Desktop Services gateway uses Secure Sockets Layer (SSL) to encrypt communications and prevents the system hosting the remote desktop protocol services from being directly exposed to the public internet.

Identify RDP use

To identify whether your company is using the Remote Desktop Protocol, you may perform an audit and review of firewall policies and scan internet-exposed address ranges and cloud services you use, to uncover any exposed systems. Firewall rules may be labeled as “Remote Desktop” or “Terminal Services.” The default port for Remote Desktop Services is TCP 3389, but sometimes an alternate port of TCP 3388 might be used if the default configuration has been changed.

Use this guidance to help secure Remote Desktop Services

Remote Desktop Services can be used for session-based virtualization, virtual desktop infrastructure (VDI), or a combination of these two services. Microsoft RDS can be used to help secure on-premises deployments, cloud deployments, and remote services from various Microsoft partners (e.g., Citrix). Leveraging RDS to connect to on-premises systems enhances security by reducing the exposure of systems directly to the internet. Further guidance on establishing Microsoft RDS can be found in our Remote Desktop Services.

On-premises deployments may still have to consider performance and service accessibility depending on internet connectivity provided through the corporate internet connection, as well as the management and maintenance of systems that remain within the physical network.

Leverage Windows Virtual Desktop

Virtual desktop experiences can be enhanced using Windows Virtual Desktop, delivered on Azure. Establishing an environment in Azure simplifies management and offers the ability to scale the virtual desktop and application virtualization services through cloud computing. Leveraging Windows Virtual Desktop foregoes the performance issues associated with on-premises network connections and takes advantage of built-in security and compliance capabilities provided by Azure.

To get more information about setting up, go to our Windows Virtual Desktop product page.

Microsoft documentation on Windows Virtual Desktop offers a tutorial and how-to guide on enabling your Azure tenant for Windows Virtual Desktop and connecting to the virtual desktop environment securely, once it is established.

Secure remote administrator access

Remote Desktop Services are being used not only by employees for remote access, but also by many system developers and administrators to manage cloud and on-premises systems and applications. Allowing administrative access of server and cloud systems directly through RDP elevates the risk because the accounts used for these purposes usually have higher levels of access across systems and environments, including system administrator access. Microsoft Azure helps system administrators to securely access systems using Network Security Groups and Azure Policies. Azure Security Center further enhances secure remote administration of cloud services by allowing “just in time” (JIT) access for administrators.

Attackers target management ports such as SSH and RDP. JIT access helps reduce attack exposure by locking down inbound traffic to Microsoft Azure VMs (Source: Microsoft).

Azure Security Center JIT access enhances security through the following measures:

  • Approval workflow.
  • Automatic removal of access.
  • Restriction on permitted internet IP address.

For more information, visit Azure Security Center JIT.

Evaluate the risk to your organization

Considerations for selection and implementation of a remote access solution should always consider the security posture and risk appetite of your organization. Leveraging remote desktop services offers great flexibility by enabling remote workers to have an experience like that of working in the office, while offering some separation from threats on the endpoints (i.e., user devices, both managed and unmanaged by the organization). At the same time, those benefits should be weighed against the potential threats to the corporate infrastructure (network, systems, and thereby data). Regardless of the remote access implementation your organization uses, it is imperative that you implement best practices around protecting identities and minimizing attack surface to ensure new risks are not introduced.

The post Security guidance for remote desktop adoption appeared first on Microsoft Security.

Afternoon Cyber Tea: Building operational resilience in a digital world

April 13th, 2020 No comments

Operational resiliency is a topic of rising importance in the security community. Unplanned events, much like the one we are facing today, are reminders of how organizations can be prepared to respond to a cyberattack. Ian Coldwell and I explored a variety of options in my episode of Afternoon Cyber Tea with Ann Johnson.

Ian Coldwell is a Kubernetes containers and cloud infrastructure specialist with a background in penetration testing and DevOps. In their role as a consultant, Ian has helped companies bridge the gaps between security and DevOps. It was a real pleasure to discuss what Ian has learned in these roles, and I think you’ll find our discussion valuable.

During our conversation, Ian and I talked about threat modeling and how to best protect your crown jewels. We also explored what it means to bring security into DevOps. Hint: it’s about more than just new tooling. And, we demystified Kubernetes. Do you wonder which projects are a good fit for Kubernetes, and which are not? Are you concerned about how to keep Kubernetes containers secure? Take a listen to Building operational resiliency in a digital work on Afternoon Cyber Tea with Ann Johnson for actionable advice that you can apply to your own SecDevOps organization.

What’s next

In this important cyber series, I talk with cybersecurity influencers about trends shaping the threat landscape in these unprecedented times, and explore the risk and promise of systems powered by artificial intelligence (AI), Internet of Things (IoT), and other emerging tech.

You can listen to Afternoon Cyber Tea with Ann Johnson on:

  • Apple Podcasts—You can also download the episode by clicking the Episode Website link.
  • Podcast One—Includes option to subscribe, so you’re notified as soon as new episodes are available.
  • CISO Spotlight page—Listen alongside our CISO Spotlight episodes, where customers and security experts discuss similar topics such as Zero Trust, compliance, going passwordless, and more.

In the meantime, bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Or reach out to me on LinkedIn or Twitter if you have guest or topic suggestions.

The post Afternoon Cyber Tea: Building operational resilience in a digital world appeared first on Microsoft Security.

Security baseline for Microsoft Edge v81

April 13th, 2020 No comments

We have reviewed the new settings in version 81 of Microsoft Edge and determined that no new security settings are required.  The settings recommended in the version 80 baseline will continue to be the security baseline for version 81!  This means we will not be releasing our typical package.


 


Version 81 of Microsoft Edge adds 15 new computer- and user-based settings.  There are now 285 enforceable Computer Configuration policy settings and 269 User Configuration policy settings.  Using our streamlined approach, our baseline remains at 12 Group Policy settings.  We have attached a spreadsheet with the new settings to make it easier for you to find them.


 


The version 80 package continues to be available as part of the Security Compliance Toolkit. Like all our baseline packages, this package includes:



  • Importable GPOs

  • A script to apply the GPOs to local policy

  • A script to import the GPOs into Active Directory Group Policy

  • A spreadsheet documenting all recommended settings in spreadsheet form (minus the version 81 setting that are attached to this blog)

  • Policy Analyzer rules

  • GP Reports


We always welcome feedback through the Baselines Discussion site.

Categories: Uncategorized Tags:

Enable remote work while keeping cloud deployments secure

April 9th, 2020 No comments

As our customers shift to remote work in response to the COVID-19 outbreak, many have asked how to maintain the security posture of their cloud assets. Azure Security Center security controls can help you monitor your security posture as usage of cloud assets increases. These are three common scenarios:

  1. Enable multi-factor authentication (MFA) to enhance identity protection.
  2. Use just-in-time (JIT) VM access for users that need remote access via RDP or SSH to servers that are in your Azure infrastructure.
  3. Review the “Remediate vulnerabilities control” in Azure Security Center to identify critical security updates needed workloads (servers, containers, databases) that will be accessed remotely.

Read Keeping your cloud deployments secure during challenging times for detailed instructions.

The post Enable remote work while keeping cloud deployments secure appeared first on Microsoft Security.

Categories: Azure Security, Cloud Computing Tags: