{“lastseen”:”2026-04-29T18:05:41″,”description”:”__The Deputy CISO blog series is where Microsoft _Deputy Chief Information Security Officers_ (CISOs) share their thoughts on what is most important in their respective domains. In this series, you will get practical advice, tactics to start (and stop) deploying, forward-looking commentary on where the industry is going, and more.__ _In this blog, Rico Mariani, Deputy CISO for Microsoft Security Products, Research Infrastructure, and Engineering Systems shares some of his best practices and expertise in conducting risk reviews._\\n\\nThe nature of cyberthreats has never been static, but it\u2019s hard to accurately convey the scale of their recent evolution and proliferation. As we\u2019ve seen in many other arenas, AI has become a very powerful productivity tool for would-be cybercriminals. Between April 2024 and April 2025, Microsoft stopped $4 billion in fraud attempts.1 And as of the writing of the Microsoft Digital Defense Report 2025, we are tracking 100 trillion security signals each day (a 40% increase since 2023).2\\n\\nExplore the latest from the Microsoft Secure Future Initiative\\n\\nThis is why I decided to write a blog about risk reviews. By asking the right questions, risk reviews help us transform the utility of our security data from primarily reactive remediation and response information into key insights helping to inform our proactive security stances. And embracing strong proactive security is something we can all do to mitigate our increased exposure to security threats. \\n\\nRisk reviews are also a topic I\u2019ve lent focus to during my first six months as Deputy CISO for Microsoft Security. It\u2019s a very interesting role for me, as I\u2019ve traditionally described myself as performance specialist and a systems specialist more than a security specialist. It\u2019s not necessarily a distinction of skill set, but more one of mindset, and what I\u2019d like to share with you is actually a bit of a synthesis of my inherent performance- and systems-first way of thinking and things I\u2019ve brought into that practice after working with many of the other Microsoft Deputy CISOs over the last few months.\\n\\nThere are roughly eight points I want to bring up concerning risk reviews in this blog. Each point has the potential to help expose potential security vulnerabilities when brought up with security teams. Together, they represent a structured and approachable way to initiate necessary conversations and drive meaningful results:\\n\\n 1. Assets\\n 2. Applications \\n 3. Authentication \\n 4. Authorization \\n 5. Network isolation \\n 6. Detections \\n 7. Auditing \\n 8. Things not to miss \\n\\n\\n\\nNow, why did I choose to highlight these areas and not others? Generally, I find that looking at problems from the lens of risk management gives me a fresh perspective. When you very consistently ask specific questions around these areas, they often effectively start the conversation you want to have.\\n\\nJust one last thing before we dive in: What I\u2019m about to tell you is only approximately correct. There will be edge cases and exceptions, but generally I think you\u2019ll find this information helpful.\\n\\n## 1\\\\. Assets\\n\\nThe best place to start a review is identifying the assets that you need to protect. This will largely define the scope of the review. A good place to find those assets is, of course, on your architecture diagrams and your threat models. The assets we\u2019re talking about could be storage (where perhaps you\u2019re storing sensitive or otherwise important data) or they could be highly-privileged applications like command-and-control systems or something similar. This is, in short, the list of things that your cyberattacker wants to get to. \\n\\n## 2\\\\. Applications\\n\\nIn the next step, you identify your applications. These are, broadly speaking, the active part of your system. They are the outward-facing surfaces that customers will use and the set of microservices that support your interface. These systems could be providing any set of services that you might need\u2014and herein lies the problem. It\u2019s entirely normal for your applications to require access to your most important assets, but that means the applications themselves can become viable targets for a cyberattacker. So how do we make this situation better? At this point, it\u2019s reasonable to start talking about possible controls. \\n\\nRead up on Zero Trust for source code access.\\n\\n## 3\\\\. Good quality authentication \\n\\nThe next thing you will want to inspect is the form of authentication that your system is using. The best systems are using tokens for authentication, and they are getting these tokens from standard token issuers like, for instance, Microsoft Entra. It\u2019s sometimes viable to have your own token generation system, but remember that such systems tend to have bugs. Those bugs can be exploitable. And even lacking bugs, there could be, say, gaps or vulnerabilities in your token issuing system such that perhaps the tokens cannot be properly scoped. The tokens could also tend to be too long-lived, or difficult to be made fine-grained enough, or lack the capacity to allow for flowing user context from the request to the authorization system. Many such deficiencies are possible. \\n\\nExplore Microsoft Entra unified identity and network access solutions\\n\\nEven with a good quality token issuing system, you can easily find yourself in a situation where the tokens that you\u2019re creating are too fungible, or too powerful, or both. Thinking back to the assets you\u2019re trying to protect and the applications that you have, you can likely categorize some of the applications as having more \u201cpower,\u201d if you will, than others. Sometimes we call these \\”highly privileged applications\u201d because they have the capability to do something that is especially of interest to cyberattackers, like reading a lot of data, changing configuration, or anything like that. \\n\\nTo best manage the privileges associated with these applications, it needs to be the case that the kinds of tokens that they use are as limited as possible. So, a particular token might authorize a capability for a certain customer, on behalf of a certain user, for a certain set of data\u2014and nothing more than that. When privileges are very generic, like \u201cI can do this operation for anyone, anywhere,\u201d things become much more dangerous. So, here the idea is to make sure that the tokens that you\u2019re getting are very specific to the intent that you have and that only the applications that need those tokens can get them, and, again, the tokens are as limited as possible. This goes a long way in reducing the possible damage that a cyberattacker could do if they found such a token errantly stored somewhere. \\n\\nA lot of the things we think about when we\u2019re working with tokens and trying to limit them fall into the category of limiting what a cyberattacker can do if they get a foothold somewhere. This is the Zero Trust model, where you assume breach everywhere. \\n\\nProtect and modernize your organization with a Zero Trust strategy\\n\\nAdditionally, it\u2019s essential to use standard libraries to accurately authenticate with tokens, so that all the aspects and limitations of the token are certain to be honored. \\n\\nLearn about phishing-resistant multifactor authentication from the Microsoft Secure Future Initiative (SFI). \\n\\n## 4\\\\. Good quality authorization \\n\\nGood quality tokens are not going to help you if they\u2019re enforced poorly (or not at all). And bugs can creep into code. Ad hoc authorization code can render the good authentication that you\u2019ve done moot. \\n\\nAny time you can use declarative style patterns that help you verify tokens against incoming APIs and the data that the client is attempting to access with your API, you\u2019ll find yourself in a better place. Simple, consistent authorization yields fewer bugs and therefore less risk. \\n\\n## 5\\\\. Network isolation \\n\\nIn addition to having good quality tokens, it\u2019s important to isolate the pieces of your environment to the maximum extent possible. Again, this is done because it\u2019s prudent to assume that a cyberattacker has a foothold somewhere in your network. The questions are \u201cwhere exactly can that foothold be,\u201d and \u201conce they have that foothold, where in my network can they get to?\u201d If a threat actor can reach any part of your system from any other part of your system, this is obviously less good than if your most sensitive systems can be accessed from exactly one or two key places and nowhere else. When properly controlled, most footholds become useless to a cyberattacker\u2014or at least only indirectly useful. \\n\\nUse service tags to create boundaries around your various assets such that applications are used by exactly those systems that are supposed to be using them and data is accessed by exactly those applications that are supposed to be accessing the data. This goes a long way to take many cyberthreats off the table. \\n\\nNetwork isolation can happen at several levels in the network stack. Popularly, level 7 is used at the perimeter. Maybe this manifests as some kind of HTTP proxy, for example, or an HTTP routing gateway. However, protection is incomplete without additional work happening at level 3 within your network. You want to limit IP traffic to be going to exactly the places that you want it to go. You might use techniques like virtual LANs, or similar constructs like network security groups (NSGs) in Microsoft Azure. The idea is to limit connectivity to exactly what is necessary to do the job and not give the cyberattacker freedom to move around. \\n\\nWith good network isolation comes the ability to log any attempts to gain access at the perimeter, and potentially even internally. Depending on what networking technology you\u2019re using, all of this is great for hunting. We\u2019ll talk about that in the next section. \\n\\nLearn more about network isolation and other best practices from SFI.\\n\\n## 6\\\\. Detections \\n\\nIt\u2019s normal to think about monitoring for reliability. Systems need to stay within their operating parameters in the face of changes and external conditions. But it\u2019s also important to think about detection from the perspective of your threat model. If you identify five or ten risks in your threat model that need controls, it\u2019s useful to think about how you might detect if any of those things are actually happening in your environment. \\n\\nIn this context, one place to look is at the perimeter\u2014by examining your incoming HTTP traffic, for instance. But you can also look anywhere in your environment where you predict that attacks might happen. You might look for badly formatted requests, or fuzzing, or evidence of DDoS attack\u2014whatever is appropriate to the risks you have. The idea is that you want to be able to create alerts if you have evidence of a threat actor operating in your estate. \\n\\nAnd, of course, security products can be very helpful here. \\n\\n## 7\\\\. Auditing\\n\\nWe separate the notions of auditing from detection. Specifically, auditing is what I will call the pieces of data that you would use after a breach to determine the extent of the breach and the customers that were affected by it. In the event that you find a vulnerability without any evidence of threat actor exploitation, you\u2019d want to go and check your auditing again to verify those claims. That way you can have evidence that whatever problem you found was not in fact exploited. If it was exploited, you\u2019ll know to what extent, who was affected, and who needs to be notified. \\n\\nSome parts of your endpoint detection and response (EDR) stream will be very useful for auditing. Additional auditing information can come from the logs you create in your applications that record suitable information concerning recent activity. \\n\\n## 8\\\\. Things not to miss \\n\\nIt\u2019s important to think about all the applications and data that you have in your estate. For instance, it\u2019s easy to overlook the backup data that you have stored. A cyberattacker might not be able to get access to your primary systems but might find that your backups are entirely unprotected and they can just read the backup.\\n\\nSimilarly, support systems often go overlooked. There are frequently important customer support scenarios that require access, and it\u2019s easy to fall into the trap of not giving those systems the highest level of scrutiny. \\n\\nWe should add systems that are under development and test systems to this problematic set. In both these cases, the code that\u2019s running those systems is less trustworthy than normal production code. Development code, for instance, can be presumed to have more bugs than production code. Some of those bugs might be authorization bugs. And if there are authorization bugs, that buggy code might provide access to important assets. Therefore, your plans should include even greater scrutiny when it comes to these kinds of systems. \\n\\nExplore actionable patterns and practices from SFI. \\n\\n## In summary\\n\\nIf you’ve gotten as far as identifying all of your assets, all your applications, and then thinking about the access patterns and controls that you have between them\u2014including authentication, authorization, network isolation, and the use of bug-resistant patterns\u2014you’re in a pretty good place to write a risk summary that can guide your actions for many months. And we haven’t even touched on basic things like vulnerability management, security, bug management, and the usual software lifecycle things that are necessary to keep the system in good health. Combine all of the above and you should have a good-looking risk plan. \\n\\n## Microsoft \\nDeputy CISOs\\n\\n**To hear more from Microsoft Deputy CISOs, check out the OCISO blog series**:\\n\\nTo stay on top of important security industry updates, explore resources specifically designed for CISOs, and learn best practices for improving your organization\u2019s security posture, join the Microsoft CISO Digest distribution list.\\n\\n\\n\\nTo 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 on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity. \\n\\n* * *\\n\\n1Microsoft Cyber Signals Issue 9. \\n\\n2Microsoft Digital Defense Report 2024.\\n\\nThe post 8 best practices for CISOs conducting risk reviews appeared first on Microsoft Security Blog.”,”published”:”2026-04-29T16:00:00″,”modified”:”2026-04-29T16:00:00″,”type”:”mssecure”,”title”:”8 best practices for CISOs conducting risk reviews”,”source”:””,”references”:””,”id”:”MSSECURE:4D240713B4EB1F70022F9ED1658B8F36″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.microsoft.com\/en-us\/security\/blog\/2026\/04\/29\/8-best-practices-for-cisos-conducting-risk-reviews\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-29T18:05:41″,”description”:”__The Deputy CISO blog series is where Microsoft _Deputy Chief Information Security Officers_ (CISOs) share their thoughts on what is most important in their respective…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,110,13,33,7,11,5],"class_list":["post-50231","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-mssecure","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n