Risk Management in Information Security
So you’ve found some kind of security issue in an application, now what? In many organizations, the security team is either very demanding “this must be fixed” or has no enforcement capability at all “please fix this”. At Microsoft IT, we take a balanced approach that we think is sane and rational, and meets our risk management objectives. In this post, I’ll talk a little about that and how it evolved and where it is going here at Microsoft. Keep in mind that our team does Application Security, so the following discussion will generally be application specific. Some risk concepts are generic, again, I’m talking about those concepts in an Information Security specific context.
Today, when a security issue of any type is found, it is rated in severity. We generally have four levels of severity, from most critical to least critical. The higher the severity, the more scrutiny will be applied to the issue as well as any fixes generated. Where this also becomes more important is that the severity also guides us in who would be required to signoff on any exception.
Now the interesting thing is that we, as the security team, do not force all issues to be fixed immediately, nor can the business outright reject fixing them. In traditional risk management, there are four approaches that can be applied to risk:
- Risk Avoidance
- Risk Reduction
- Risk Acceptance
- Risk Transference
This is exactly how we manage security risk as well. Now in an ideal world, you would be able to avoid all risk; for example if creating a new feature in an application opens up additional risk, you remove that feature. However, obviously, this is not possible or practical in many if not most situations. So now, the risk exists, and it’s unavoidable, what do you do? Well you can reduce it in some way: either you can transfer the risk to another component, team or application, or you can accept the risk. The way we support risk acceptance at Microsoft is that the sponsoring organization’s management would be charged with understanding and accepting the risk. Usually this would not be open-ended either; there would be a remediation plan and timeframe with each issue that would also be approved. If the issue in question is of a critical nature (normally defined as an issue that can affect all of Microsoft, other applications or the data center) then Microsoft’s CISO would also be involved and would have to approve the risk acceptance as well. This process used to be called a GM Exception (The General Manager of the organization would sign off on the risk) but has recently been changed to a CIO Exception. You can read more about our CIO’s here and here. In effect, this is also a risk transference strategy for our team; the security team only identifies the risk, but then the risk is transferred to the sponsoring organization’s management for acceptance. To drive this whole process, we have a dedicated group in our team that manages and tracks all exception requests, approvals and remediation (more on this in another post).
Any good security organization is going to try to facilitate all four approaches to risk, and that is exactly what we do. A sign of immature security organizations (in my personal humble opinion! :) are ones that try to push a risk avoidance approach to all or most risk scenarios. Another big area that we are very active in is the area of risk reduction. Generally we will act as consultants to application teams and try whenever possible to help them find ways to reduce risk to an acceptable level. This is a win-win because the team gets the functionality they want, we get rid of a high severity issue. Examples of this would be a SQL injection filter we are developing, that could be applied to legacy or 3rd party applications that contain a lot of dynamic SQL. Another example would be enforcing more stringent ACLs on a fileshare (instead of \All Authenticated Users a small group of people who actually need access to that particular data).
Another important part of our strategy is to become aware of all possible risks before an application even exists, and that’s why we rely on the threat modeling process as well. You can find more information on threat modeling on our team’s threat modeling blog.
Thanks for reading.
Ahmad Mahdi
Security Technologist
Microsoft – ACE Team