Pass Your Microsoft Security SC-200 Exam Easy!

Microsoft SC-200 Microsoft Security Operations Analyst exam dumps vce, practice test questions, study guide & video training course to study and pass quickly and easily. Microsoft SC-200 Microsoft Security Operations Analyst exam dumps & practice test questions and answers. You need avanset vce exam simulator in order to study the Microsoft Security SC-200 certification exam dumps & Microsoft Security SC-200 practice test questions in vce format.

Mitigate threats using Microsoft 365 Defender

5. Azure AD Identity Protection

And welcome back to my course, Microsoft Security Operations Analyst SC 200. Now in this particular lesson, we are going to discuss another tool in the security stack of Microsoft-suited security tools called Azure AD Identity Protection. So Azure AD identity protection helps you automatically detect, remediate, and investigate identity-based risks for your organization. Now let's see and learn what identity protection is and the risks involved in using it. Of course, first of all, identity protection is a solution built into Asia AD that's designed to protect your identities through, let's see, a three-part process. And this process is, as you can see here on the slide, "detect, investigate, and respond." Now first of all, what are the risks? What are the risks? So risks can be described as suspicious activity and actions by users when they sign in or when they take actions after signing in. So that's why risks are categorised in two ways: user risk and sign-in risk. And user risks occur when a user's identity or account has been or may be compromised. So the user's risks include the unusual behavior. The first one over here basically means that, as you can see on the right hand side of the table, the account displayed unusual activity or patterns, and it can be classified as leaked credentials. And here, of course, the user's credentials could have been leaked. Now the sign-in risk in identity protection basically scrutinises each authentication request to judge whether it was authorised by the owner of the identity or not. And the sign-in risk discussed here can include unfamiliar sign-in properties. And this basically means that identity protection learns about the patterns of signing of a particular user, and then when it sees a sign-in happening from a different location, for example, it will basically fire up an alert and detect a sign-in risk. Then you have atypical travel, right? And here, for example, two users sign in from very distant locations in a short period of time, right? Then it detects this anomaly. Then you have the malware-linked IP address, and this basically means a user signs in from an IP address that is known to be associated with malware sites or domains or CNC servers. And the anonymous IP address is a sign-in risk. And here again, the sign-in comes from an anonymous IP address, and these addresses, of course, are detected by Microsoft from their reputational lists. Now let's talk about the Azure AD identity protection workflow. So there are two different ways to detect and handle identity risks—the self-remediation workflow and the administrator workflow. Now for the self-remediation workflow: first of all, as you can see here on the top part of the slide, identity protection uses risk policies, which I will show you in a moment where you can configure them. So it uses risk policies to automatically respond to and detect threats for you, allowing you to figure out a risk policy for identity protection over here. Then of course, you can decide what you want or how you want identity protection to respond to particular types of risks. Then you can choose the user action again to include in the policy. And the action could be a self-service password reset or multifactor authentication enforcement, right? So using the policies will help you save time and automatically remediate this kind of risk. And then of course, identity protection detects the risks. It fires up an alert, and then automatically the user is asked to reset the password to be able to re login.And this is the self-remediation workflow. Now, in the administrator remediation workflow here, you can also have admins decide how a risk should be treated or remediated when it has been detected. Now, this type of remediation workflow helps you make more, let's say, tailored decisions, right? The admin understands the context in which the risk was detected. And in this workflow, the admin configures the risk policy, which then monitors for identity risk. The admin is notified of the risk and thenit investigates the alert appropriately and takes the appropriate,again, action as he or she sees fit. Okay, so now let's talk about detecting risk here in identity protection. Let me just change up the slide we were talking about earlier about the sign-in risk policies and the user risk policies. So what is a sign-in risk policy? You can configure a risk policy to decide how you want identity protection to automatically respond to a particular type of risk. So do you want to block or allow access? Do you want to make your users go through additional authentication before you allow access? These are the questions to consider when configuring sign-in risk policies. Now, your company can also leverage policies and avoid, let's say, hiring external contractors to handle identity-based risks. So a sign-in risk policy basically checks every sign-in and gives it a risk score. This score indicates the probability that the attempt was made by the person whose credentials were used. You decide which level of risk is acceptable by choosing the threshold of low, medium, or high based on the risk level. You choose whether to allow access,automatically block access, or allow accessonly after additional requirements are met. For example, users might be asked to go through multifactor authentication to remediate the detected risks. Now, you can configure the policy in the following way. Here, you select which users you want to target with this policy. Again, you can go for all users or, let's say, a scoped approach, right? Then you configure the conditions, and you configure the controls. In this case, you require multi-factor authentication, and of course you enable the policy. And then you have the same thing about, of course, when a sign-in risk is detected, the user is met with this screen, right? So he will be asked to perform a multi-factor authentication challenge. Now, the same thing goes for the user risk policy. And here, Identity Protection basically learns the user's normal behavioural patterns and then uses this knowledge to calculate the likelihood that the user's identity was compromised. So based on this risk, the admin can decide whether to allow access, block it, or allow access only after additional requirements are met. So this user could, for example, be asked to change their password by using the self-service password they set before they allowed access. As with the sign-in risk policy, you configure the scope of the policy, then the risk conditions, and then you configure the additional options that you want the user to go through. And if user risk is detected, then the user is met with this particular screen. Now, before going on to our next topic, let me show you where you can actually configure these policies. So if I jump on our trial subscription over here, as you can see, we're no longer in Microsoft Security Center, but we are in the Asia portal, which can be accessed at portal Asia.com. Over here. Don't worry, you have all these links in the downloadable resources for this lesson. Now over here, if we type in the global SearchAsia ad, this will take us to Active Directory. Sorry. Active directory. This will take us to the Azure Active Directory. Blade over here on the security blade, and we will select Identity Protection. And here in Identity Protection, you have an overview. Of course. Again, this is a trial tenant, so we have no data. However, as you can see under Protect, you have a user risk policy and a signed in risk policy. So the user is a policy. Again, if I click on it, you can click to select individual groups of users or you can leave the policy enabled for all users. You can also make exclusions from this policy. It's not recommended except for the breakloss accounts or the privileged service accounts, which need to perform automatic finance. Right? Then you configure the user risk to which this policy will be applied. So let's say medium and above. And then, of course, you configure what actions you want to do. You can block access, or you can allow access and require the password change, right? And then, of course, you switch the policy to on to enforce the policy. Then we have the signing risk policy. Again, the scope of the policy is the same as with the other policy—individual groups, individual users, or groups—all users. You can also perform exclusions. Then the sign-in risk for which the policy is applied, medium and above, was only high. And then there are actions that block access or allow access but require multifactor authentication. So these are the two policies that we talked about. We can find here an additional policy, which is very useful if you want to not only enforce but also deploy MFA throughout your organization. You have MFA registration policies in place, which apply to all users. You can leave this to apply to all users or, again, you can scope the policy to be effective for single users or groups of users. You can exclude users as well here. And as you can see here, with this policy, you basically require AJ MFA registration. So what this policy will do is require every user in the tenant and every additional user that you create starting when you enable the policy to register for MFA. So again, this is a very good and very useful way to deploy MFA registration throughout your organization. Okay? So that being said, let's get back to our slides and quickly discuss remediating risks. Because if I go here to look at risky users, risky sign-ins, and risk detections, you obviously see that we have no data here to work on or work with, sorry. So let's get back to the slides, and we will talk separately about this topic on the slides. So let me change the slide, and here we go. This is multifactor authentication, and here we talk about investigating risks. So investigations help you understand how you can improve your identity and security posture, make it possible for you to respond to risks better, and, of course, help you avoid them in the future. Now Identity Protection provides reports that you can use to investigate identity-based risks detected in your organization. These reports come in different types. Each kind of report gives the admin information about certain risks, and the admin can of course take the necessary actions to address those risks. Again we have risk assignments, and here is the information that is included within the risk assignment report, like location, device details, signing confirmations, and so on. Then you have actions that the admin can make so he can confirm the sign-in or he can confirm the user is compromised, and the period covered for this report is 30 days. And then you have the "risky users" report. Here is a list of users who are at risk and those who have had the risk dismissed or remedied. Here the actions would be to reset the password, dismiss the user risk, block the user sign-in, or confirm that the user is compromised. Now the period is not applicable because this report will stay there. You will have risky sign-ins after long periods of time, so you can perform actions on those. Now again, you use these reports to investigate the risks detected by identity protection, and the reports help you understand how, let's say, to better prevent risks and improve your security stance for identities. Now you can also access risk detection type reports, which basically combine information about risky users and risky user detections with risk sign-in detections. So you can use these reports to see how different risk types are related and then, of course, take appropriate action. You can do this in the Azure Portal. Of course, you can download all of these reports. And as you can see here, you have all of these details about the sign-in: the risk info, the device info, the MSA info, and the conditional access policies that were not applied for this particular sign in.And as you can see here, you have the list of sign-ins for this particular user. How do you mitigate risks now? Well, basically, when your investigation is complete, you'll want, of course, to remediate the risks, if you're not already using risk policies to automatically deal with them. So there are different ways to remediate the risks. And of course, let me just go back one slide. Here we go. So there are different ways to remediate the risks, and the methods you use actually depend on your particular organization's needs. So, again, we have self-remediation here. I won't go through the descriptions over there, but please go through them and read them. This is why I left this table for you here in the slides. So with self-remediation here, we're talking about configuring the policies and automatically remediating the risks. Then you can manually reset the password, you can dismiss the user risk detection, or you can close individual risk detections manually. Again, go through the descriptions because you have detailed descriptions over on the right-hand side of the table. Now, the last topic in our lesson is to block users. So user accounts can be blocked by risk policies or manually by the admin. As we've discussed after an investigation, how these user accounts are blocked depends on the type of risk that caused the blockage, right? So accounts that are blocked because of signing risks, herean account blocked because of sign in risks can beunblocked by excluding the user from the policy. The account might be unblocked if the admin asks the userto sign in from a familiar location or a device. Or sometimes sign-ins are blocked from unfamiliar locations on devices. Right, sorry. So there might be an alert for suspicious behaviour based on what's known about the user account sign-in patterns. So the policy can also be disabled if the admin finds issues with the policy. And then you have accounts that are blocked because of user risk. And here an account might be blocked if the user was flagged because of possible risky behavior. The admin can reset the password for the user to unblock the account and remove the block. The admin might dismiss the activity identified as risky or exclude the user from the policy. If the policy is causing problems for many users, of course, as with the other one, the admin can completely disable the policy. So, that being said, this concludes our discussion about Asia and identity protection. I am going to see everyone in the next lesson, where we'll discuss using Microsoft Defender for cloud apps. Yes, I know this is a very long section, probably the longest section in the course, but Microsoft also has a lot of security tools that we need to cover in this section. So until I see you in the next lesson, I hope this has been informative for you, and I thank you for it.

6. Micrososft Defender for Cloud Apps

Come back to my course. Microsoft Security Operations Analyst SC 200 Now in this lesson, we are going to discuss Microsoft Defender for Cloud Apps. Microsoft Defender for Cloud Apps is basically a cloud access security broker, or CASBasb, that operates on multiple clouds. It provides rich visibility, control over data travel, and sophisticated analytics to identify and combat any cyber threats across all your cloud services. Now, let's talk about what exactly a cloud app security broker is and the cloud app security broker framework. So, Cloud App Security Brokers, or Kasby's,are defined by Gartner as a securitypolicy enforcement points placed between cloud serviceconsumers and cloud service providers to basicallycombine and interject enterprise security policies. As cloud-based resources are accessed, Casby's consolidated multiple types of security policy enforcement. In other words, Casbies are the intermediaries between your users and all of the cloud services they access. KASB can assist you in implementing security controls over your users and data. As an example, consider these cloud app security brokers to be corporate network firewalls. Right? Now, Microsoft Defender for Cloud Apps is a case that helps you identify and combat cyber threats across Microsoft and third-party cloud services. Microsoft Defender for Cloud Apps integrates with all the other Microsoft solutions, providing simple deployment, centralised management, and of course, innovative automation capabilities. In the following graphic over here, we see the flow of information in an organization, for example, and you can see how Defender for Cloud Apps functions as the intermediary between apps, data, and users because basically the users come through here, right? And this is like an intermediary between all of these branches over here, right? Okay, so let's see, because there are four basic elements to Microsoft Defender Cloud App Security. You can, first of all, discover and control the use of the shadow it.So, in this case, you can identify cloud app infrastructure as a service platform that your organisation uses. How many cloud apps do you think are used by your users, for example? Well, the apps you don't know about on average aretotaling more than 1000, and these are called shadow it. So these are the apps you don't have access to, correct? When you know which apps are being used, you will better understand and better control your risks. Then you can secure your sensitive data anywhere in the cloud. And here you can understand, classify, and also protect sensitive information when it is at rest. So to help you avoid, for example, accidental data exposure, cloud-based app security Microsoft Defender for Cloud Apps Sorry, because Cloud App Security (the old name) provided data loss prevention capabilities that covered the various, let's say, data leakpoints that exist in organizations. Then you can protect cyber threats andanomalies against cyber threats and anomalies. You can detect unusual behaviour across applications, users, and potential ransomware. Defender for cloud apps employs a variety of detection techniques, including anomaly user entity analytics. Shortly called UEBA. UEBA, right. And Rule Based Activity Detections to show youwho is using the apps in your environmentand how are they using them. And lastly, you can assess thecompliance of your cloud apps. Basically, here you can assess if your cloud apps comply with regulations and industry standards specific to your organization. Defender for Cloud Apps helps you compare your apps and the usage of those apps against relevant compliance requirements, prevent data leaks to noncompliant apps, or limit access to regulated data. Now let's talk about cloud discovery in Microsoft Defender for cloud apps. You can use cloud discovery to see what's going on in your network. You'll see both the cloud apps you expect and the ones you don't expect, signs of shadow IT, and non-sanctioned apps that might be non-compliant with your security and compliance policies. Cloud Discovery analyses your traffic logs against a catalogue of more than 16,000 apps, and it ranks each app and scores it based on more than 80 risk factors to basically give you visibility into cloud use, a shadow of it, and the risk it poses to your organization. Now, the Cloud Discovery Dashboard provides, let's say, an overview of what kind of apps are being used, your open alerts, and the risk levels of the apps in your organization. You can see who your top users are, the top app users, and where each app comes from. You can also filter the data collected by Cloud Discovery to generate specific views depending on what interests you the most. Now, the first step is to get a general picture of your cloud apps, and you can start the Cloud Discovery Dashboard. And then, of course, you can move through the elements in the following order that I've placed here on the screen to understand what's happening in your organization. So first of all, you start with the high-level usage overview over here, and you will see this in the portal itself. to see the overall cloud app usage. You can basically here you can seethe top users and source IP address. Based on this information, you can identify which users in your organisation use cloud apps the most. And you'll probably want to pay attention to these users going forward. Now, if you dig one level deeper, you can see which category of apps your organisation uses the most. So we've talked about top users and IP address, and here again, you can see which category of apps your users are using the most. So you can see how much of this usage is in your environment's sanctioned apps. Then, going even deeper, you can see the Discovered Apps tab. And here you will see all the apps in a specific category. You can also review the risk score for the discovered apps in the app. Risk score overview Each discovered app is assessed against risk factors. As I've mentioned previously, like security, compliance, and regulatory measures, apps are given a score between one and ten, with one being the lowest. Now you can also view where discovered apps are located based on their headquarters on the App Headquarters map. Now, if you find an app that poses risks to your organization, you can flag it as unsanctioned in the discovered apps blade. If your organisation is using Microsoft Defender for Endpoint or a similar solution, any unsanctioned app can be automatically blocked. So, if you use the integration between Microsoft Defender for Endpoint and Microsoft Defender for Cloud Apps, when you mark an app as unsanctioned, it will be blocked automatically. It will actually be added as an indicator in Microsoft Vendor for Endpoint, and it will be blocked across the endpoints in your environment. Now let's see how we can protect the data with conditional access and app control now in Cloud Discovery Basically, again, if we just do a basic recap, cloud discovery helps you understand what's happening in the cloud environment. While this process is important, you can think of your primary goal as being to stop breaches and leaks in real time, right before they put your organisation at risk. You also need a way to enable users to bring their own devices to work while still protecting your organisation from data leaks and data theft. Well, Microsoft Defender for Cloud Apps integrates with identity providers to protect your data and devices with access and session controls through Conditional Access App Control. If you're using, for example, Azure Active Directory as your identity provider, these controls are integrated directly into Defender for Cloud Apps. Conditional Access App Control basically lets you monitor and control user app access and sessions in real time. By integrating with Azure and conditional access, it becomes easy to configure apps to work with conditional access app control. It basically lets you selectively enforce access and session controls on your organization's apps based on any condition. In conditional access, you can use conditions that define, for example, who a user or group is. You can use conditions that define what I mean and which cloud apps are used. You can find conditions where you make a condition for where statement, and this might be which locations and networks the user is coming from, and then a conditional access policy is applied. After you determine the conditions, you can route users to Defender for Cloud Apps, where you can protect the data with Conditional Access AppControl by applying access and session controls. Now, Asia Ad includes built-in policies that you can configure for an easy deployment. After you configure the conditions of a conditional access policy in Azure Ad, you can select the Session tab under Access Controls and then click Use Conditional Access App Control. Now, if you choose to use the custom controls, you will define them in Microsoft Defender for the Cloud Apps Portal. Again, you can access session policies in the Microsoft Defender for Cloud Apps portal to further refine filters or set actions to be taken on a user. You can prevent data exfiltration with conditional access control. So here you can, for example, block the download, cut, copy, and print of sensitive documents on, for example, unmanaged devices, right? Then you can protect the download. So instead of blocking the download of sensitive documents, you can require them to be labelled and protected. With Asia Information Protection, this action ensures that, for example, the document is protected and the user's access is restricted in a potentially risky fashion. You can prevent the upload of unlabeled files, right? So you can enforce the use of labeling. Before a sensitive file is uploaded, distributed, or used by others, it's important to make sure that it has the right label and protection. So you can block a file upload until the content is classified. You can also monitor user sessions for compliance. Here you can monitor risky users when they sign into apps and log their actions from within the session. You can investigate and analyse user behaviour to understand where and under what conditions to apply session policies in the future. Of course, you can block access, and you can block access for specific apps and users depending on several risk factors. For example, you can block a user if they're using a client certificate from a device management platform, right? And then, of course, you can block activities or create custom activities. So some apps have unique scenarios that carry risks. For example, sending messages with sensitive content in apps like Microsoft Teams or Slack In these kinds of scenarios, you can scan the messages for sensitive content and block them in real time. Okay, now let's talk about classifying the sensitive information, because we saw what we can do with conditional access app control, but we also need to classify the information to be able to use those capabilities in conditional access app control. So one of the key elements of the cloud app security broker framework, let's say, is protecting your sensitive information. And sensitive information is a subject phrase, as this can vary from one organisation to another. So what is information protection? Well, an employee might, let's say, accidentally upload the file to the wrong place, or they could send confidential information to someone who shouldn't have it. So as a result, information could be lost or made accessible to the wrong person. Any lost or wrongfully exposed information can have serious legal, financial, or reputational consequences for organizations. So information is vital to any modern organisation, and the best practise is to ensure that it's protected at all times. To help you in this area, Microsoft Defender for Cloud Apps natively integrates with Asia Information Protection, a cloud-based service that helps you classify and protect files and emails across the organization. Now this is done in several phases, so in phase one over here, discover the data. So during this phase, you make sure apps are connectedto Microsoft vendor for cloud apps so it can scanfor and classify data, then apply policies and controls. You can do this in two different ways: either using an app connector or using conditional access app control. Then in phase two, you actually classify the sensitive information. Now you need to decide what counts as sensitive in the context of your organization. Microsoft Defender for cloud apps includes more than 100 predefined sensitive information types and default labels. Sensitive information types and labels define how to handle, for example, passport numbers or national identity numbers. Now these labels will be used by Microsoft's cloud apps when scanning for classify information.Now the labels are personal, public, general confidential, and highly confidential. Now the personal one, this basically definesdata for personal non business data. The public one is data that can be shared for public consumption, such as marketing posters, blog posts, and stuff like that. The general label should be used for data that can't be shared for public consumption but can be shared with external partners, for example, projects, timelines, organisational charts, and stuff like that. The confidential data is data that could damage the organisation if it's shared with unauthorised people. So, for instance, sales accounting and cost forecasting, correct? And the highly confidential one is the very sensitive data that will cause serious damage if shared with unauthorised people, for example, customer details, passwords, or source code. Then we move on to phase three. And in phase three, you actually protect the data. And there are different types of policies that you can create to detect sensitive information and act accordingly. For example, you can create a file policy to scan the content of files in your apps in real time. And for data address, file policies basically let you apply governance actions that can automatically trigger alerts, change sharing access for files, quarantine files, remove files, or move files to a trash folder. Now in phase four over here, you basically monitor, report, and you can actually check the dashboard. It's the one over here to monitor for alerts and the overall health of the environment. So for example, to review the file-related alerts, you can go to the alerts pane and select DLP, which means data loss prevention. And in this category, you will see all the alerts related to data loss prevention, right? You can also investigate a file-related alert to better understand what caused it to be triggered. You can also dismiss any alerts that you believe should be ignored. Now, allow me to quickly show you a table in which you are shown. Basically, when you create a file policy or file alert policy, you will be asked at some point to choose what form appears. So you'll find that information in the following table. So, basically, you need to select the policy severity, and the explanation is on the right side. I'm not going to go through it. You need to choose a category for the policy, and you need to create a filter for the files this policy will act on.You will need to select "Apply to First" and "Apply to Second." Again, the explanations are on the right side. You need to select the content inspection method and then the governance, or the scope of the policy itself. Please review this table, read the explanation to better understand it, and proceed to the next slide, which also concludes our lesson on Microsoft Defender for Cloud Apps. You will have another interactive guided demonstration, this time to familiarise yourself with the Microsoft Cloud Apps portal because we do not have any data to leverage in our demo environment. So I can actually show you something in the Microsoft Defender for Cloud Apps because we don't have any data in this trial tenant. So please go through this guided demonstration, this interactive guide, and here you will basically familiarise yourself with the portal. You will be taken to an interactive page; click here and there and see how to navigate through the portal. You will see what the alerts look like, what the sensitivity labels look like, and so on. So please go and do the interactive guide, and I will see everyone in the next lesson where we'll discuss responding to data loss prevention alerts. Until then, I hope this has been informative for you.

7. Respond to DLP Alerts

Everyone, and welcome back to my course, Security Operations Analyst SC 200. Now, in this lesson, we are going to discuss data loss prevention alerts and how to respond to them. So first of all, let's try to describe data loss prevention alerts. As a security operations analyst, you need to understand compliance-related terminology and alerts. The data was on prevention Alerts were shortly issued. DLP alerts will help you in your investigation to find the full scope of an incident. DLP alerts can be generated from Microsoft 365 Compliance or from Microsoft Designer for cloud apps. You might not be the person creating the DLP policies, but it is important for you to understand how they work, to understand them, and to understand if you can actually recommend any changes to those policies. Now, to comply with business standards and industry regulations, organisations basically must protect sensitive information, as we've mentioned in the previous lesson, and prevent its inadvertent disclosure. Let's say. Sensitive information can again include financial data, personal information such as credit card numbers, Social Security numbers, or health records. Now, with DLP, or data loss prevention, you can first identify the sensitive information and its location. What I mean by location is that data-sensitive information could sit in Exchange Online, SharePoint Online, One Drive for Business, or Microsoft Teams, for example. Then you can identify any document containing a credit card number that's stored on one drive for business, for example, where you can monitor just one driver site for specific people. Then you can prevent the accidental sharing of sensitive information. And here, for example, you can identify any document or email containing a health record that's shared with people outside your organisation and then automatically block access to that document or block the email from being sent in the first place. Then you can monitor and protect sensitive information. Over here, you can monitor and protect sensitive information even in the desktop versions of Microsoft apps like Excel, PowerPoint, or Word. So just like an exchange online, SharePoint Online One Drive, these office desktop programmes include the same capabilities to identify sensitive information and apply DLP policies. Again, DLP provides continuous monitoring when people share content in these office programs. Then you can help users learn how to stay compliant without interrupting their workflow. You can educate your users about DLP policies and help them remain compliant without blocking their work. For example, if a user tries to share a document containing sensitive information, of course a DLP policy can send them an email notification and show them a policy tip in the context of the document library that allows them to override the policy if they have a business justification. The same policy tip will also appear in Outlook on the Web. Outlook, Excel, PowerPoint, or Word. And then lastly, you can view the DLP alerts and reports. Now, if you have not worked with DLP, it is important to understand its, let's say, underlying components, and the first ones would be the sensitive information types. A sensitive information type is defined by a pattern that can be identified by a regular expression or a function. So in addition, corroborative evidence such as keywords or check sums can be used to identify the type of sensitive information type.Now, the confidence level and proximity are also used in the evaluation process. Microsoft 365 Compliance comes with built-in insensitivity to information types like credit card numbers, bank accounts, and much, much more. You can also create a custom sensitive information type based on a regular expression or based on keywords, or you can even upload a dictionary file to create that sensitive information type. Then we have the sensitivity labels, and the sensitivity labels basically specify the classification of a document. So this could be terms like "public," "private," or "classified." With these labels, more functionality can be applied to the document, like encryption, and labels are applied to documents either manually by the user or automatically based on the sensitive information types. You have the Data Loss Prevention Policy, which we've discussed, and a TLP policy basically contains a few basic things where to protect the content through locations such as Exchange Online, Share, Point OneDrive, and the like, as well as Microsoft teams like teams, chats, and channel messages, right? Then you need to specify when and how to protect the content by enforcing rules comprised of conditions—the content must match before the rule is enforced. For example, a rule might be configured to look at only content containing Social Security numbers that have been shared with people outside the organization, right? And of course, here you also specify actions that you want the rule to take automatically when any content is matched. Here, for example, a rule might be configured to block access to a document and send both the user and the compliance officer an email notification. Then there's the Defender for Cloud Appsfile Policies, for which I've left you a very comprehensive table in the previous lesson, as well as here as a refresher. File policies can be set to provide continuous compliance counts, legal discovery tasks, DLP for sensitive content shared publicly, and many, many more use cases. Now let's talk about investigating alerts in the Microsoft 365 Compliance Center. Now, of course, we do not have any kind of alerts in our trial tenant to investigate them, but you can go to the Microsoft Defender 365 Compliance Center, and actually this screenshot is from Microsoft Defender for Cloud Apps, which we'll talk about shortly, but you can go to the actual portal and let me show you where to find these. And I'll also show you how to create a compliance policy even though we don't have any data. So in the Security Center over here, if we click on more resources, the first one we can open is the Microsoft 365 Compliance Center. Sorry, again, we have lots and lots of options here. We won't go through them because it's not in the scope of our lesson. However, if we go to alerts, you will see the compliance alerts within your tenant. Now, if we want to create a DLP policy, a Data Loss Prevention policy, we would go to Policies over here and click on Data Loss Prevention. And from the Policies tab, we can actually start creating. You can see that we have two policies that are turned on by default when you create the tenant, but we can create our own policies. And here we can name our policy; let's say test. We can specify if we want to apply it to a particular region or country, right? So let's say the United States of America. Let's click on "next." This is not the name, sorry. By the way, these are the templates that we can use to protect what kind of data we actually want to protect, right? We can go with custom, and we can create our own, or we can go with financial, for example. And we want to protect, let'ssay financial data, us financial data. And this, as it says here, will include credit card numbers, US bank account numbers, and ABA routing numbers. So basically, this policy will target all of these types of data. Right? Now click on "Next." Let's call this test "DLP policy." We leave the description as is. Now we need to basically select the locations that we want to apply this policy to. As you can see, we can apply to all the locations or we can toggle on or off here. And we can apply it only to selected locations like Exchange, Mail devices, teams, chat channels, and so on. So let's click on "Next." Conditional use cannot apply to new locations. Okay, so let's basically take all of these and leave only Exchange Email Exchange online. Right now you can create, review, and customise the default settings on the template or create and customise your own DLP settings. We'll stick with the defaults and click on Next. Again, it detects this kind of content andit detects it when it is shared withpeople outside of the organization, right? the protection actions. You can leave the default on the templates, but again, you can show a policy tip, you can detect specific amounts of sensitive being used, you can send instant reports, you can send alerts, and you can restrict access to or encrypt the content that's matched within the policy. So we'll go with the defaults once more. I just want to show you how to create the rule. Here we go. Let's click on Next if you want to first test your policy. So it will just fire up alerts and show notifications, but it won't actually do anything. It won't block anything, and you can turn it on right away, right? And then you would click on "next reviewor settings" and "submit" to create the policy. And this is basically how you create a data loss prevention policy in the Microsoft 365 Compliance Center. Now let's talk about the other tool with which you can create and use DLP, and that is cloud app security. And, once a Defender for Cloud Apps file policy with a DLP-related configuration is created, file policy violation alerts will be investigated in the alerts area over here, here we go, in the Defender for Cloud Apps. Now for each alert, you can investigate and determine the nature of the violation and the actual required response, right? And here you have the following, and let me just change the slide. You have the serious violations over here, and serious violations require an immediate response. As an example, if there were a suspicious activity alert, you might want to suspend the account until the user changes the password. Or, for a data leak alert, you might want to restrict permissions or quarantine the file. Or if a new app is discovered, you might want to block access to the service on your proxy or firewall until you investigate that app, right? Then you have the questionable violation alert. And the questionable violations actually require further investigation. So you can contact the user, for example, or the user's manager, about the nature of the activity. Or you can leave the activity open until you have more information, right? And then you have the authorised violations or anomalous behaviors. In this case, legitimate use may result in an authorised violation or anomalous behavior. And here you can, of course, after investigation, dismiss the alert. So anytime you dismiss an alert, it's important to submit feedback about why you're dismissing the alert. Because the Defender for Cloud Apps team uses this feedback as an indication of the accuracy of the alert, So this information is then used to fine tune the machine learning mechanism behind the alert and the models of the errors for future alerts. So you can follow these guidelines, say, in deciding how to categorise the alert. So if legitimate use triggers the alert and it isn't a security issue, you can select one of these steps as being positive. And this means the alert is accurate, but the activity is legitimate. You can dismiss the alert and change the reason to "actual severity is lower than" or set the reason to "not interesting," right? Or it may be a false-positive alert. And here you classify it as a false-positive alert. If the alert is inaccurate here, you can dismiss the alert and set the reason to "alert is not accurate." Now, if there's too much noise, let's say to determine the legitimacy of the alert or the accuracy of the alert, you can dismiss it and set the reason to "too many similar alerts." And of course, we have the last one, the true positive alert. And if the alert is related to an actual risky event that was either committed maliciously or unintentionally by an insider or outsider, you should set the event to resolve after all the appropriate actions have been taken to remediate that particular event. Now, even though you are interested in filing policy alerts for DLP, the alerts list will show many different types of alerts, and it is important for you to understand the different alert types because these non-DLP alerts also could provide insight into a security incident. Now, here in the following table, I've provided a list of the types of alerts that can be triggered and recommendations that might be very useful when you want to resolve the alerts. Right? So, once again, we have Activity Policy ViolationAlerts, File Policy ViolationAlerts, and compromised account alerts. inactive account alert type (new admin user, new admin location) new device, suspicious activity, and the use of a personal account. Please again go through the table, read the description of what the alert type means, and also please go through the recommended resolution because it will help you very much in your investigation. And this concludes the discussion about responding to DLP alerts. I will see everyone in the next lesson, where we'll discuss managing the insider risk in Microsoft 365. Until then, I hope this has been informative for you, and thank you for viewing.

8. Manage Insider Risk Management in Microsoft 365

Hello everyone and welcome back to my course, Microsoft Security Operations Analyst SC 200. Now, this is the last lesson of this section, in which we are going to discuss insider risk management in Office in Microsoft 365. So first of all, what is insider risk management? So insider risk management basically means managing the risk that comes from your inside employees. Trusting employees is basically the key to creating a dynamic and productive workplace. However, with trust comes risk. So companies need to be able to quickly identify and manage risks from insiders. And here I mean employees or contractors; even with corporate access, this is basically to minimise the negative impact on their business. Now, insider threats and risks from illegal, inappropriate, unauthorized, or unethical behaviour and actions are a major issue for all companies and can easily go undetected until it is too late. Again, surveys on the internet show that nearly 90% of organisations are vulnerable to insider risk, and another 53% have confirmed insider risk against their organisation in the previous twelve months. Right? So, first and foremost, the financial impact of insider threats is significant, as companies suffer market, legal, reputational, or productivity losses, correct? So according to other publications and surveys, the average cost of an insider incident arising from negligence is over $300,000. If the insider is malicious, then it is over $750,000. And if you come to think about it, aside from the financial loss, the impacts of insider risk can include damage to brand and reputation, competitive disadvantage, non-compliance with regulations, or even loss of market share. Now. Traditional approaches to identifying insider risks such as user behavior Analytics. Monitoring user activity and data loss prevention can suffer from limitations such as complex deployment scenarios, limited insights, or a lack of workload integration beyond the security operations team. Right. Insider risk management in Microsoft 365 is based on the Microsoft graph, specifically the MicrosoftGraph security services and connectors to human resource systems such as SAP. right, to obtain real-time native signals such as file activity, communications, abnormal user behavior, or resignation dates. Insider risks such as digital IP theft, confidential breach, and HR violations are now addressed by a set of configurable policy templates. Use machine learning and intelligence to correlate the signals to identify hidden patterns and risks that traditional or manual methods might miss. These built-in policy templates allow you to identify and mitigate risky activities while balancing employee privacy versus organisation risk with privacy by design architecture.Finally, an anti-fraud and integrated workflow ensure that the right people across security, HR, or legal—and compliance, of course—are involved to quickly investigate and take action once a risk has been identified. Now, let's take a look at the risks—let's say pinpoints—in the modern workplace. Again, managing and minimising risk in your organisation starts with understanding the types of risks found in the modern workplace. Some risks are driven by external factors, such as bad actors who try to steal employee credentials through brute force or phishing attacks. But other risks are driven by internal events and employee activities that can be eliminated and avoided. Some examples of internal risks are over on the slide, like intellectual property theft, espionage, leaks of sensitive business information, confidentiality violations, sabotage, fraud, insider trading, code of conduct violations, or regulatory compliance violations. and you have them all listed here. Now, insider risks, of course, vary by industry. In healthcare, internal fraud is the most frequently cited type of risk, while sabotage represents the greatest risk for IT businesses. Right? So the path leading to a malicious insider risk varies. It may be that an employee who has a history of violating IT security policies, a negative work event such as a termination or a dispute with a supervisor, or employees who take sensitive data before leaving the company voluntarily, of course, or involuntarily, are the common risk scenarios. The common risk scenarios The insider risk management solution in Microsoft 365 can help you detect, investigate, and take action to actually mitigate internal risks in your organisation in common scenarios, right? What would those common scenarios be? One of the most frequently encountered ones is data theft by a departing employee. When an employee voluntarily or involuntarily leaves the organization, there are often legitimate concerns that the company's customers or employee data are at risk. Employees may innocently assume that project data isn't proprietary, or they may be tempted to take company data for personal gain and in violation of company policy and legal standards. Right. Then we have the leak of sensitive or confidential information. In most cases, employees try their best to properly handle sensitive or confidential information. But occasionally, employees make mistakes and information is accidentally shared outside the organisation or in violation of the information protection policies. For example, sometimes employees may intentionally leak or share sensitive and confidential information with malicious intent or for potential personal gain. Right? And the last common scenario here is actions and behaviour that violate corporate policies. Here, employee-to-employee communications are often a source of inadvertent or malicious violations of corporate policies. These violations frequently include offensive language threats or cyberbullying among employees. This type of activity contributes, of course, to a hostile work environment and can result in legal action against both employees and the larger organization. Now, let's take a look at the insider risk management workflow. First of all, using the policy templates with predefined conditions and, let's say, comprehensive activity signalling across the Microsoft 365 service, you can use actionable insights to quickly identify and resolve risky behavior. Identifying and resolving the internal risk activities and compliance issues with insider risk management in Microsoft 365 uses the following workflow first of all, you have thepolicies and here the policies basically inside the riskmanagement policies, determine which employees are in scope andwhich types of risk indicators are configured for alerts,then we have the alert because a policy matchwill trigger an alert. Insider risk management alerts are automatically generated by risk indicators defined in the risk management policies. These alerts give compliance analysts or investigators an "all-up view," let's say, of the current risk status and allow your organisation to triage and take action for discovered risks. Then we have the triage stage. And here, reviewers can quickly identify Insider Risks alerts and examine each to evaluate and triage. Alerts are resolved by opening a new case, assigning the alert to an existing case, or dismissing the alert. Then of course, we have the investigation phase. And here, cases are manually created from alerts in the situations where further action is needed to address an issue for an employee. And then the Take Action part, the last one over here, And of course, all three of these activities are basically done inside an insider risk case. So the action comes after investigating the details of the case. Of course, you can take action by notifying the employee, resolving the case as benign, or escalating our employee investigation to the data protection officer or the employee's line manager, or by following whatever policies you have in place in your organization. Now, let's talk about managing insider risk policies. First of all, before we can begin creating Insider Risk Policies, there are several, let's say, requirements or prerequisites that need to be met. First of all, you need to turn on auditlogging because Insider Risk Management uses audit logs for user insights and activities configured in policies. And this can be done from the Compliance Center. And I will show you in a moment exactly where you can turn on audit logging. Then you need to assign permissions. A global administrator will need to assign you and other compliance officers permissions for Insider Risk Management. Let's see how it goes by assigning you a role group using the permissions module in the Microsoft 365 Compliance Center. There are four role groups inregards to the Insider Risk Management. First of all, it's the Insider Risk Management Role, and you can use this role group to manage inside risk management for your organisation in a single group. So, by adding all user accounts for designated administrators, analysts, or investigators, you can configure risk management permissions in one single group. This group contains all the insider risk management permissions and roles. Then you have the Insider Risk Management Admin Role Group. And with this one, you use it to initially configure Insider Risk Management and later to segregate Insider Risk Management Administrators into defined groups. Then you have the Insider Risk Management Analyst role group, and you can use this group to assign permissions to users that will have to act as insider risk case analysts. Users in this role group can access all InsiderRisk Management Alerts Cases and Notices templates, but they cannot access the InsiderRisk Content Explorer. Then lastly, you have the insider risk management investigator. And of course, you can use this rolegroup to assign permissions to users that will act as insider risk data investigators. Users in this role group can access all Insider Risk Management alerts, cases, notices templates, and the Content Explorer for all of the cases. Then you have the potential dependencies, and two of the Insider Risk Management templates have dependencies that must be configured for the policy indicators to generate relevant activity alerts. This step might be optional, of course, depending on the policy plan you want to configure for your organization. Then you have the templates. And here I just took as an example the departing employee data theft template. So if you configure a policy with the departing employee data theft template, you will need to configure the Microsoft 365 Human Resources Data Connector so that you can import user and log data from third-party risk management and human resources platforms. Again, a global administrator will need to consent to allow the Office 365 Import service to actually access the data in your organization. Then the user who creates the HRconnector will need to be assigned themailbox import export role in exchange online. Then you have several other templates, like data leak templates, and you can go ahead and create a new insider risk policy. And let's hop onto the portal and let me show you how we would create an insider risk management policy. So, first and foremost, if we go here to more resources in the Microsoft Security Center, we can open the compliance centre once this is opened. First of all, you remember that we said that we needed to turn on audit logging. Now if we go here to the audit blade, you can see that in my subscription over here, it's already turned on. If it wasn't, you would have a big button over here saying "turn on audit logging." You would click on that. It depends on the tenant and the region. It could take several hours for that to happen and for it to be enabled. And now let's go to the inside of risk management over here. Again, here you have an overview of insider risk management. As you can see, you also have some tips here: turn on all the logging to get permissions to choose policy indicators, and then scan for potential insider risks. But if we want to create a policy, we would go to Policies over here and simply just click on "Create Policy." Then, as I've mentioned, these are the templates that you can use, like data theft by departing users, data leaks, and security policy violations. Again, you have several templates here and under Health Record Misuse. So if we would have stuck to the data set by departing users, we would click on Next, then give our policy a name, and next, we would select the users and groups that we want to include as a scope of this policy. Again, you can include all users and groups, but for departing users, you probably want to add a specific group. I will leave it to this for the purposes of our demonstration; we'll click on Next. Then we want to specify what SharePoint size, for example, we want to include in our policy. I won't specify this for the moment, but if you do, you would click on Next over here and you would click on Edit, and let's add this one. Let's say, for example, let's click on "Next." Then you would add the sensitive information types that you want to include in your, let's say, Australian passport number. Without further ado, click Next. Then you add the sensitivity labels of personal, public, and confidential; let's say confidential for all employees, right? And click on "Add Over Here." Then you'd define the triggers, and you can see that we only have one trigger available because we need to configure that HR connector we mentioned earlier. What will stick with the default settings over here? Then you define the indicators, and as you can see, they're all greyed out because you have to turn them on. And you can turn them on by clicking here. Turn Indicators. Turn all the indicators on. You have the option of turning on only a subset of the indicators or turning on all of them. So now it's turning on the indicators here.You can, of course, specify what indicators you want to select for your policy. I'll stick with the defaults and click on Next. Then you can either use the default threshold for all indicators or specify and be very specific over here. As you can see, I'm going to stick to the default, and we will click on Next. We are presenting an overview of the policy, and then we would submit to create the policy. I'm not going to do that. I'm going to cancel out of this, but I just wanted to show you how you can actually create an insider risk management policy. So getting back to our slide, this concludes our discussion of insider risk management in Microsoft 365. But I strongly recommend you go ahead with the guided demonstration with that interactive guide that I've made available for you in previous lessons as well. Again, these are interactive guides available courtesy of Microsoft and their tagline, Interactive Guide Library." This will familiarise you with the portal. This will familiarise you with how to create a policy, how to investigate an insider risk management case, and so on. It takes about 20 minutes to complete this guide, and I strongly recommend that you do so. Again, this concludes the discussion for our lesson—and this includes our section as well. I will see everyone in the next section where we will discuss mitigating threats and using Microsoft Defender for endpoints. Until then, I hope this has been informative for you. And thank you for.

Go to testing centre with ease on our mind when you use Microsoft Security SC-200 vce exam dumps, practice test questions and answers. Microsoft SC-200 Microsoft Security Operations Analyst certification practice test questions and answers, study guide, exam dumps and video training course in vce format to help you study with ease. Prepare with confidence and study using Microsoft Security SC-200 exam dumps & practice test questions and answers vce from ExamCollection.