Archive for the ‘Voice of the Community’ Category

A playbook for modernizing security operations

February 11th, 2021 No comments

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the latest post from our new Voice of the Community blog series, Microsoft Product Marketing Manager Natalia Godyla talks with Dave Kennedy, Founder and Chief Technology Officer at Binary Defense. Dave shares his insights on security operations—what these teams need to work effectively, best practices for maturing the security operations center (SOC), as well as the biggest security challenges in the years to come.

Natalia: What are the standard tools, roles, frameworks, and services for a security operations team? What are the basic elements a SecOps team needs to succeed?

Dave: Your security operations team must have visibility into your infrastructure, both on and off-premises. Visibility is key because many of these attacks start with one compromised asset or one compromised credential. They spread across the network and in many cases, they wreak a lot of damage. Your endpoints, network infrastructure, and cloud environments are where a lot of these issues happen. I recommend starting with high-risk areas like your endpoints.

Then, you need somewhere to ingest that data, such as security information and event management systems like Microsoft Azure Sentinel, and to go through log analysis and determine if anything has been compromised.

Also, frameworks like the MITRE ATT&CK framework are a great baseline of saying, well, here are specific attacks that we’ve seen in the wild that are mapped to specific adversaries that are in our industry vertical. That can help you prioritize those, get better at detection, and make sure you have the right logs coming into your environment to build detections.

Natalia: How can a team operationalize the MITRE ATT&CK framework?

Dave: When people first look at the MITRE ATT&CK framework, they freak out because it’s so big, but it’s a treasure trove of information. Everybody was focused on a castle mentality of being able to protect everything but what happens when an attacker is in your environment? Protection is still very important and you want to have protective mechanisms in place, but protection takes time and requires cultural changes in many cases. If you’re doing something like multifactor authentication, you have to communicate that to users.

The MITRE ATT&CK framework tells you what happens when attackers have gotten around your preventive controls. What happens when they execute code onto a system and take other actions that allow them to either extract additional information or move to different systems through lateral movement or post-exploitation scenarios and get access to the data? The MITRE ATT&CK framework is a way to conceptualize exactly what’s happening from an attacker’s standpoint and to build detections around those attack patterns.

With the damage we see, it’s usually several hours, days, or months that an attacker has had access to an environment. If we can shave that time down and detect them in the first few minutes or the first few hours of an attack and shut them down, we’ve saved our company a substantial amount of damage. It’s a framework to help you understand what’s happening in your environment and when unusual activities are occurring so you can respond much more effectively.

Natalia: How much of the MITRE ATT&CK framework should a security team build into their detections? How much should they rely on existing tools to map the framework?

Dave: Many tools today have already done a lot of mapping to things like the MITRE ATT&CK framework, but it’s not comprehensive. If you have an endpoint detection and response product, it may cover only 20 percent of the MITRE ATT&CK framework. Mapping your existing tools and technology to the MITRE ATT&CK framework is a very common practice. For instance, you may have an email gateway that uses sandboxing virtualization techniques that detonate potential malware to see whether it’s effective. That’s one component of your technology stack that can help cover certain components of the MITRE ATT&CK framework. You might have web content filtering that covers a different component of the framework, and then you have endpoint detection and responses (EDRs) that cover a percentage of the endpoint detection pieces.

Technology products can help you shave away the amount of effort that goes into the MITRE ATT&CK framework. It’s really important, though, that organizations map those out to understand where they have gaps and weaknesses. Maybe they need additional technology for better visibility into their environment. I’m a huge fan of the Windows systems service, System Monitor (Sysmon). If you talk to any incident responder, they’ll tell you that if they have access to Sysmon data logs, that’s a treasure trove of information from a threat hunting and incident response perspective.

It’s also important to look at it from an adversary perspective. Not every single adversary in the world wants to target your organization or business. If you’re in manufacturing, for instance, you’re not going to be a target of all adversaries. Look at what the adversaries do and what type of industry vertical they’re targeting so you don’t have to do everything in the MITRE ATT&CK framework. You can whittle the framework down to what’s important for you and build your detections based on which adversaries are most likely to target your organization.

Natalia: If a team has all the basics down and wants to mature their SecOps practices, what do you suggest?

Dave: Most security operations centers are very reactive. Mature organizations are moving toward more proactive hunting or threat hunting. A good example is if you’re sending all of your logs through Azure Sentinel, you can do things like Kusto Query Language and queries in analysis and data sets to look for unusual activity. These organizations go through command line arguments, service creations, parent-child process relationships, or Markov chaining, where you can look at unusual deviations of parent-child process relationships or unusual network activity.

It’s a continual progression starting off with the basics and becoming more advanced over time as you run through new emulation criteria or simulation criteria through either red teaming or automation tools. They can help you get good baselines of your environment and look for unusual traffic that may indicate a potential compromise. Adversary emulations are where you’re imitating a specific adversary attacker through known techniques discovered through data breaches. For example, we look at what happened with the SolarWinds supply chain attack—and kudos to Microsoft for all the research out there—and we say, here are the techniques these specific actors were using, and let’s build detections off of those so they can’t use them again.

More mature organizations already have that in place, and they’re moving toward what we call adversary simulation, where you take a look at an organization’s threat models and you build your attacks and techniques off of how those adversaries would operate. You don’t do it by using the same type of techniques that have previously been discovered. You’re trying to simulate what an attacker would do in an environment and can a blue team identify those.

Natalia: What are best practices for threat hunting?

Dave: Threat hunting varies based on timing and resources. It doesn’t mean you have to have dedicated resources. Threat hunting can be an exercise you conduct once a week, once a month, or once a quarter. It involves going through your data and looking for unusual activity. Look at all service creations. Look at all your command line arguments that are being passed. A large percentage of the MITRE ATT&CK framework can be covered just by parent-child process relationships and command line auditing in the environment. Look at East to West traffic, not just North to South. Look at all your audit logs. Go through Domain Name System (DNS traffic).

For instance, a user was using Outlook and then clicked on an email that opened an Excel document that triggered a macro that then called PowerShell or CMD EXE. That’s an unusual activity that you wouldn’t expect to see from a normal user so let’s hone in on that and figure out what occurred.

You can also conduct more purple teaming engagements, where you have a red team launch attacks and detection teams look through the logs at the same time to build better detections or see where you might have gaps in visibility. Companies that have threat hunting teams make it very difficult for red teamers to get around the different landmines that they’ve laid across the network.

Natalia: What should an incident response workflow look like?

Dave: An alert or unusual activity during a threat hunting exercise is usually raised to somebody to do an analysis. A SOC analyst typically has between 30 seconds and four minutes per alarm to determine whether the alarm is a false positive or something they need to analyze. Obviously, what stands out are things like obfuscation techniques, such as where you have PowerShell with a bunch of code that looks very unusual and obfuscation to try to evade endpoint protection products. Some of the more confusing ones are things like living off the land, which are attacks that leverage legitimate applications that are code signed by the operating system to download files and execute in the future.

A research phase kicks off to see what’s actually going on. If it’s determined that there is malicious activity, usually that’s when incident response kicks in. How bad is it? Have they moved to other systems? Let’s get this machine off the network and figure out everything that’s happening. Let’s do memory analysis. Let’s figure out who the actual attacker was. Can we combine this with red intelligence and determine the specific adversary? What are their capabilities? You start to build the timeline to ensure that you have all the right data and to determine if it’s a major breach or self-contained to one individual system.

We ran several incident response scenarios for customers that were impacted by the supply chain attacks on SolarWinds and the biggest challenge for the customers was their logs didn’t go back that far so it was very difficult for them to say definitively with evidence, that they know what happened.

Natalia: What does an incident responder need to succeed?

Dave: I’d strongly recommend doing an incident response readiness assessment for your organization. I also recommend centralized logging—whether that’s a security information and event management (SIEM) or a data analytics tool or a data lake—that you can comb through. I’m a huge advocate of Sysmon. You can do power execution, command line auditing, DNS traffic, process injection, and parent-child process relationships. I’d also suggest network logs. If you can do full packet captures, which not a lot of organizations can do, that’s also great. If you can pull data packets coming from a secure sockets layer (SSL) or transport layer security (TLS) and do remote memory acquisition, that’s also really important. Can we retrieve artifacts from systems in a very consistent way?

Tabletop exercises can also get executives and IT on the same page about how to handle incidents and work together. Running through very specific types of scenarios can help you figure out where you have gaps or weaknesses. When I was the Chief Security Officer at Diebold, we would run through three to four tabletop exercises a year and include our senior leadership, like our CEO and CFO, twice a year. It was eye-opening for them because they never really understood what goes into incident response and what can happen from a cyber perspective. We’d run through actual simulations and scenarios of very specific attacks and see how they would respond. Those types of scenarios really help build your team’s understanding and determine where you may need better communication, better tooling, or better ways to respond.

Natalia: What other strategies can security operators implement to try to avoid attacks?

Dave: When you look at layered defense, always improving protection is key. You don’t want to just focus on detection because you’re going to be in firefighting mode all the time. The basics really are a big deal: things like multifactor authentication, patch management, and security architecture.

Reducing the attack surface is important, such as with application control and allowed application lists. Application control is probably one of the most effective ways of shutting down most attacks out there today because you have a good baseline of your organization. That applies very consistently to things like the Zero Trust model. Become more of a service provider for your organization versus providing everything for your organization. Reducing your attack surface will eliminate the noise that incident responders or SOC analysts must deal with and allow them to focus on a lot of the high-fidelity type things that we want to see.

One of the things that I see continuously going into a lot of organizations is that they’re just always in firefighting mode, 90 percent of their alarms are false positives, and they’re in alarm fatigue. Their security operations center isn’t improving on detections. You really need somebody on the strategy side to come in and say: Can we lock our users down in a way that doesn’t hinder the business, but also lowers the attack surface?

Natalia: How does vulnerability assessment strategy fit into a SOC strategy?

Dave: Program vulnerabilities and exposures are key opportunities that attackers will use. When we look at historic data breaches, those that use direct exploitation and not phishing were using common vulnerabilities and exposures (CVE) typically of six months or older that allowed them access to a specific system. That makes it really important to reduce attack surfaces and understand where vulnerabilities are so we can make it a lot more difficult for attackers to get in.

It’s not a zero-day attack that’s hitting companies today. It’s out-of-date systems. It’s not patching appropriately. A lot of companies will do well on the operating system side. They’ll patch their Windows machines, their Linux machines, and Apple. But they fail really hard with the third-party applications and especially the web application tier of the house—middleware, microservices. In almost every case, it comes down to ownership of the application. A lot of times, IT will own the operating system platforms and the infrastructure that it’s on, but business owners typically sponsor those applications and so ownership becomes a very murky area. Is it the business owners that own the updates of the applications or does IT? Make sure you have clear owners in charge of making sure patches go out regularly.

If you’re not going through regular vulnerability assessments and looking for the vulnerabilities in your environment, you’re very predisposed to a data breach that attackers would leverage based on missing patches or missing specific security fixes. The first few stages of an attack are the most critical because that’s where most organizations have built their defenses. In the latter phases of post-exploitation, especially as you get to the exfiltration components, most organizations don’t have good detection capabilities. It’s really important to have those detection mechanisms in place ahead of time and ensure those systems are patched.

Natalia: We often discuss the challenges facing security today. Let’s take a different approach. What gives you hope?

Dave: What gives me hope is the shift in security. Ten years ago, we would go into organizations from a penetration testing perspective and just destroy these companies. And then the next year, we’d go in and we’d destroy these companies again. Their focus was always on the technical vulnerabilities and not on what happens after attackers are in your castle. The industry has really shifted toward the mindset of we have to get better at looking for deviations of patterns of behavior to be able to respond much more effectively. The industry is definitely tracking in the right direction, and that really gives me hope.

Learn how Microsoft Security solutions can help modernize Security Operations.

To learn more about Microsoft Security solutions visit our website. 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.

The post A playbook for modernizing security operations appeared first on Microsoft Security.

The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 2

January 21st, 2021 No comments

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the first post of our new Voice of the Community blog series, Microsoft Product Marketing Manager Natalia Godyla talks with Jake Williams, Founder of Rendition InfoSec. In part two of this blog, Jake shares his best practices on how to structure and evolve red and blue teaming within your organization.

What are best practices for organizations maturing their blue team?

First and foremost, go in and look at the event logs and turn on all of the logging that you think will be useful. I work with blue teams today up and down the Fortune 500, and I ask, “Where is this in your event logs?” And they say, “I think maybe my endpoint detection and response (EDR) platform may catch that.” Windows catches that. Windows detects the thing we’re talking about if you have it configured. It’s more than 100 event logs, and a lot of them are empty and the ones that are populated are not logging the best things you can log. A lot of the reason for that is logs get big.

The second cybersecurity best practice is to use Group Policy Object (GPO) and increase the size of your event logs dramatically. I think the security event log pegs at 20 megabytes. The way that I explain this to folks is I’ve never been an instant responder and worked the case where I walk in and think, “What am I going to do with all these logs?”

Third, actually walk through the audit policy. I want you to go look at it. If you’re a systems architect or a systems engineer, you have to know what’s even available. Not knowing what’s available from an audit standpoint is almost like going to a restaurant, never reading the menu and saying, “I heard you had a burger so I’m going to have that.” And you have no idea what else could be there that could be way better. Go read the menu. Find out what audit logs are available and increase the size of them dramatically.

We’ve had folks do one but not the other. There was this heartbreaking case a couple of years back where they called, and I ended up being on the flyaway team. When they called, we asked, “What auditing do you have available?” We told them to turn it on and increase the size of the event log, and they did one of those two. And when I got onsite, and I got into that server, there were 18 seconds of security event logs. 18 seconds. It was awesome that they turned some stuff on, but at the same time, I needed the log in general, not 18 seconds of activity. It was just heartbreaking.

What is your guidance to red teamers? What best practices should they consider?

Stop trying to be sexy. Every time there’s a major security conference like a Black Hat or a ShmooCon, I get some red teamers who come back and say, “I just saw this super cool, super awesome technique.” I ask, “Are attackers using that?” and they say, “I’m sure they will be.” When we have credible intelligence that they are, then we’re going to invest that time. Make sure you’re actually providing value back to the organization and understand what that means.

In late 2019, I was at a major insurance company and they have a red team that is about a third of the size of their blue team, which is just wrong. I asked, “Can I see an example of a report?” And the red team leader says, “No.” I said, “You do know I have an NDA with you. We’re physically here at your headquarters.” He said that they only share these reports with management and that executives understand the risks. He said that if they tell the blue team how they’re doing everything, they’ll catch the red team immediately.

The biggest outcome of this exercise became how do we stop doing red team for red team’s sake, such as to be a bunch of cool hackers and go break stuff. How do we turn this around where the red team is providing value to blue team? Security is a service provider to the organization, and red team ultimately should be driven by blue team (their customer). The red team’s goal isn’t to go sneak around and remain undetected for the sake of their egos. The goal is to identify vulnerabilities, missing patches or misconfigurations, or find gaps in coverage for monitoring. The customer for that is blue team. I look at the blue team as tasking the red team and saying, “Here’s what we need from you.” Red team’s hacking, sexy, cool stuff is secondary.

What kind of training would you recommend for red and blue teams?

If I’m a blue teamer, I’m going to be staying on the cutting edge of what’s the latest thing happening with system logs. I’m less about tools than I am about techniques. What do I have available from a detection standpoint? I’m not interested necessarily in my blue teamers going out and trying to figure out how to go through exploits, run exploits. That’s a red team kind of thing.

For a red team, send them to conferences. People don’t like to hear this, but the conferences are going to pay off better than any red team courses for anybody who has got more than a year of red team experience. The reason is the networking. You network, and you start getting put in these private Slack groups or on email lists. Everybody knows everybody. You’re going to hear about those newer techniques. I’m less about formalized training than I am about getting them into networking opportunities.

What do you think red and blue teams will continue to think about even after the pandemic? What changes are going to make long-lasting impacts on the security industry?

This applies to both red and blue teams, and it’s understanding the attack surface. Something that we’ve seen more than any previous year has to be software-as-a-service (SaaS). We shifted to work from home, depending on which part of the country, either over a 24 or a 48-hour period all the way up to maybe a two-week period. By any measure, it’s insanely fast for a lot of folks to do, and so they made a lot of changes to get stuff done without really looking at the long-term security implications.

I’m already discussing with clients how to go back and memorialize what they did as we ran home. In late March, most CISOs I talked to didn’t believe we’d still be at home at the end of the year. They thought this was a one-month or two-month situation so risks we were ready to accept for a month look a whole lot different than risks we’re going to live with in perpetuity.

For the folks rolling into holiday standdown time, now is the time to make some of those changes. On the red team side, another big one is: Know your scope, know your scope, know your scope. Just because I have data in Salesforce doesn’t mean you can go hack Salesforce. Your red team needs to know what they legally can do and what they ethically should do and make sure everyone is aligned there. From a blue team side, you figure out how you want them to evaluate the security of your Salesforce tenant. I think that’s really it, knowing what architecture changes we made as we moved into that fully remote environment, and how many of those need to be revisited. And the answer is a lot of them. I think it’s no secret that a lack of change control drives a lot of breaches.

Any last words of wisdom to help red and blue teams strengthen cybersecurity?

Both red and blue should absolutely be using threat intelligence. That doesn’t mean every org needs a dedicated cyber threat intelligence (CTI) analyst. It doesn’t mean go buy another threat intelligence feed. What I’m looking at is what we need to prioritize not based on what could happen but on what we know is happening. Those are two very different things. When I look at the range of possible bad things that could happen to us, I think: What are we actually seeing in the wild, both in our organizations and in other organizations?

When you learn about a threat that’s targeting a different industry, like healthcare, should you be paying attention to it? The answer is obviously yes, you should be. Just because it’s a big push in one industry doesn’t mean it’s not coming to you. All things equal, I’m going to prioritize more in my vertical, but I have to have an ear to the grindstone for what’s happening in other verticals as well.

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

The post The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 2 appeared first on Microsoft Security.

The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1

January 5th, 2021 No comments

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the first post of our new Voice of the Community blog series, Microsoft Product Marketing Manager Natalia Godyla talks with Jake Williams, Founder of Rendition Infosec. In part one of this blog Jake shares his insights on the 2020 threat landscape—who to watch for and why—and how to think about red and blue teaming within your organization.

Looking back at the threat landscape of 2020, what stands out?  

The biggest thing that stands out has to be the continued ransomware advances. With IANS, I actually coined the term ransomware 2.0 in early 2019. We were trying to differentiate between the drive-by ransomware attacks and what I call the more APT-style ransomware attacks, where they’re doing lateral movement and actively targeting backups before encryption. Disaster recovery (DR) plans work for the former but really not the latter because the latter cases are actively targeting disaster recovery infrastructure. What I saw this year was just a lot of advancement in attacks.

The second thing is that the number of different groups that are using that commodity malware has definitely gone up. They’re using that commodity malware to get back into orbit for initial access into a network. We’re seeing a lot more of that, like TrickBot. Cybersecurity professionals I’m talking to say, “the TrickBot takedown” but it was an interruption, not a takedown, unlike other malware and botnets in the past that have been wiped out. DNSChanger is a good example. DNSChanger was cut off at the knees but not TrickBot. This is a flesh wound.

We’re seeing a lot more of this commodity malware being used as an entryway. This is the stuff that a lot of folks, myself included, have been talking about for years. This is always a risk. You can’t just say, “Don’t worry, Microsoft Defender Antivirus caught and quarantined it so we’re good now.” From maybe mid-September on, it’s been even more viral than the rest of the year put together. It’s really accelerating, too.

What critical threat groups should security teams be actively monitoring? 

The week before last, I was in a dark web forum and an account that I and a number of other folks in the intel community assess with moderate confidence to be associated with Ryuk was advertising for help with their ransomware operations. They’re looking for experienced ransomware operators, and they have a whole set of criteria, including that they want to see a history that you’re getting an average $400,000 payout. They haven’t asked for help in the past. They have more work than they can handle. That gives you an idea of scope, and I think it comes from the commodity malware. Before now, I haven’t seen large, established ransomware groups advertising for help with their operations. If they thought those accesses were going to last forever, they wouldn’t worry about recruiting others right now.

There’s definitely a place for dark web monitoring but most organizations don’t have the maturity level where they’re getting a good return on that investment. Because even if I tell you that cybercrime groups are recruiting, how do I take that and turn that into something actionable that will help with detection and prevention? I don’t know how much any guidance I provide will help if you’re not patching domain controllers.

From a cybercrime standpoint, we’re seeing a lot more lateral movement being critical to cybercriminals’ attacks. We’re not seeing as many point attacks where they land a phishing email and bam, they’ve extracted a bunch of data and gone. It sounds almost like a cop-out but focus on lateral movement because it kills two birds with one stone. Nation-state groups have to do a lateral movement. So do cybercrime groups to get maximum payouts. Once they’ve had a bite of that big apple, how do they ever go back? I think you’re seeing more groups spending in some cases up to six weeks in a network before they’re doing data extraction and playing a little bit of a longer game versus that immediate gratification.

Cybersecurity mixes both defensive and offensive practices to combat cybercrime. How should organizations think about red and blue teaming in their organization? Do organizations need both, and why?  

A huge majority of people who get into cybersecurity these days want to be red team. I get it. It’s sexy. Bottom line, if you’re thinking of red team as those folks who are actually attempting to penetrate your internal network, I think the number is 1 to 20, 1 to 25, or something like that compared to blue team. You need a lot less red team focus. I’m not saying that organizations where red team is similarly sized to blue don’t provide value. They definitely do, but it’s a question of could you take those same resources and plug them elsewhere and get more value? I think generally, I need a lot more defense than I need offense.

In way too many organizations that have much more balanced red and blue teams, I see a lot of red teams identifying problems that the blue team simply can’t fix from a resourcing standpoint. I also am working with organizations that have very large red teams but haven’t yet moved into hunt teaming. In those situations, I don’t know whether you put hunt under red or blue. I’m ambivalent there but the bottom line is I do need the red team, but I need them for a lot less than a lot of people use them for. I say that as an ex-government hacker; and I still do red team occasionally, but it’s just not where most organizations are going to get the most significant return on investment. I’m not trying to say red team isn’t important but generally, we need to structure significantly more blue team people than red team, and that’s just an unpopular thing for a lot of people to hear.

If you don’t have a solid blue team and have holes today in your defenses, you shouldn’t have a red team. When people say, “We need our own internal red team,” my question is, “Have you had an external red team come in and do a red team evaluation? And if you have, have you actioned those findings?” Not one of them but all of them. If the answer is no, we need to step back and figure out what we need to do. Let’s make sure that you’ve got a blue team that is functioning today and ready to roll forward with the recommendations from the red team. Separate from pragmatism, there’s also a legality issue. Knowing about something and not doing anything about it puts you in a more legally compromising position than not knowing about it at all.

That’s what we find a lot of folks with internal red teams end up with. They’ve got this red team that is basically pushing identified risks into a funnel. How much are we stuffing that funnel? How much do we need defense versus offense?

How does an organization know when to hire an internal red team? What’s the breaking point?

A lot of that depends on the reaction. How quickly are you actioning those findings? If you’re in a spot where you fix all the findings from the annual red team in two months, that’s when I would say, “Yes, without a shadow of a doubt, let’s go hire a red team.” Because that’s going to give me more of that constant churn of findings. On the other hand, if it takes you nine months to get through those findings, you’re going to have another external red team likely in a month anyway. Where’s our value there? If it takes you somewhere in the middle, a lot of it is going to depend on how much risk do we accept.

When we’re documenting where we have gaps and where we don’t, it comes down to where can I get the best return on my investment for our organization? If I still have a lot of blue team gaps, investing in red team would be throwing more gaps at blue team, which causes huge morale issues.

Keep an eye for the second part of the interview as Jake Williams shares best practices on how to structure and evolve red and blue teaming within your organization.

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

The post The dynamic duo: How to build a red and blue team to strengthen your cybersecurity, Part 1 appeared first on Microsoft Security.