Information security (infosec) risk management can often seem overwhelming and hard.
Organizations can spend considerable resources on infosec programs or solutions, yet they may have challenges in implementing commensurate and demonstrable improvements in reduction or mitigation of day-to-day risks faced by them.
GRC can help lead the way
Infosec Governance, Risk Management, and Compliance (GRC) teams usually have a couple of unique advantages that can help deliver much-needed improvements.
For one, they interact across business and technology areas – as part of risk management or compliance initiatives, for example – that other infosec functions do not, at least not as often as GRC teams do. This should help GRC in developing key relationships and influencing stakeholders. Secondly, such interactions can help GRC teams gain a sound understanding of how a risk transcends their organizations as well as its context or relevance to various functions or departments.
The relationships and insights should help in identifying optimal and practical solutions for mitigating the risks.
GRC teams can use these insights to influence strategies and roadmaps in other areas of infosec (e.g. Identity and Access Management, Security Engineering and Operations, Data Protection, etc.) in order to mitigate the risks sooner than later and in an optimal manner.
How can GRC deliver?
What can infosec GRC personnel or teams do to help deliver the wins that might be elusive otherwise? Here are a few thoughts:
Think in terms of risks rather than controls
It is useful to remember that security controls frameworks are general best-practice safeguards written at a point-in-time. It is up to us to determine which of the controls can help deliver the best returns in risk mitigation for our contexts. It is also often the case that what (control/s) might make sense in one situation may not necessarily be the best option in another, even within the same organization.
Use compliance initiatives as the means and not the end
Security compliance mandates exist for a reason, which is usually the implementation of security safeguards for assuring and demonstrating that specific types of data (depending on the mandate or regulation) are protected from loss or unauthorized access.
Considering the fundamental purpose of compliance mandates, it does not usually matter how much resources or time that we spend on the compliance programs (i.e. means), if we can’t prevent or detect, respond to or contain data breaches or losses (i.e. the outcome).
Compliance obligations are often useful in getting the budget allocations that might not be possible otherwise. It is important that we use compliance budgets effectively to achieve meaningful ends or outcomes in security risk management.
Predominant bias for action and operationalization
Delivering outcomes in risk management requires timely action and operationalization of safeguards. These safeguards should be an appropriate mix of technology or process capabilities that can help assure the outcomes.
Every recommendation or mandate that a GRC team puts out must be actionable given the realities each organization is faced with. Further, relevant stakeholders must agree to implementing or operationalizing them in a reasonable timeframe.
Awareness and knowledge of current state and capabilities
Getting stakeholder agreement or buy-in often depends on how realistic it is for the stakeholder teams to implement GRC teams’ recommendations.
It is critical for the GRC teams to have accurate and substantive knowledge of the current state and existing/new capabilities that can be leveraged realistically. Any remediation recommendation put out by the GRC team must be practical and effective in achieving the required risk posture.
Seek stakeholder engagement and facilitate consensus in risk mitigation
One can usually mitigate security risks or compliance gaps in more ways than one. GRC teams should identify the options and seek feedback through consultation.
The feedback should be used to discuss or articulate pros and cons with stakeholders before arriving at a consensus recommendation.
Involve personnel with implementation and operations experience or exposure
Identifying and validating the right risk mitigation option(s) will often need one or more people that have practical knowledge or implementation (of one or more technologies or processes) and/or operations experience.
GRC teams may not have such skillsets within their personnel and therefore may need to seek involvement or assistance from other specialist security teams such as Security Architecture, Network Security, IAM, SIEM or Security Operations, Applications Security, and so on.
Hire expertise as needed but remain in-charge
Depending on the scope of certain assessment or compliance initiatives, GRC teams may not have the experience or specialist skillsets among their team members or personnel from other internal teams in their security programs. The teams may need to hire temporary expertise by way of contractors or consultants in such cases.
Regardless of whether additional expertise is hired internally or externally, GRC teams must retain thought leadership and direction of risk management initiatives. Any inputs from specialists must be evaluated appropriately and the GRC teams must decide the right course of action in consultations with stakeholders.
Be abreast of current threat environment and possibilities in technology and operations
Maintaining thought and directional leadership of risk management decisions will require GRC teams to remain abreast of evolving threats relevant to a particular context (e.g. an application being assessed) as well as how specific solutions based on one or more technologies and/or processes could be optimally used for risk mitigation. The team may not have the deep specialty or expertise (that may be hired as discussed in 7 above) but they must have appropriate knowledge and aptitude for leading risk management initiatives by leveraging such expertise.
Bridge gaps between infosec silosIt is not unusual for various teams within a security program to be operating in silos. Consider the following two examples:
- Identity Governance Administration (IGA) solutions or teams may not quite be providing the identity context data that would be valuable for detection in security operations and solutions such as Security Information Event Management (SIEM) and/or User Entity Behavioral Analytics (UEBA).
- On the reverse side, the SIEM/UEBA solution team may not quite reach out to the IGA team to suggest how certain resource-intensive access certifications could be either replaced or made more effective by a detection/monitoring use case that leverages identity context and user activity logs.
As part of discussing the risk assessment report of a key application, for example, the GRC team can bring the IGA and SIEM/UEBA teams together and help deliver improved access assurance levels for the application.
If GRC teams were to constantly look for such opportunities in each of their assessments, they could contribute to improved overall integration and outcomes for the entire security program.
Have consultative rather than audit mindsets
Many of the recommendations discussed above require one to have a problem-solving mindset which is different from the mindset one might have when conducting audits or performing compliance assessments.
GRC teams can fare much better by using an approach that is creative, collaborative, and consultative.
Don’t let the perfect be enemy of the good
Finally, risk mitigation solutions don’t have to be perfect. They only need to be good enough to ward off an adversary or delay them enough that they go elsewhere. Perfect solutions may often need time and resources to implement. Even if one went down the path of implementing such a solution, one might not want to leave the risk open in the meanwhile. One may want to implement a good-enough solution that can serve as an effective stop-gap measure.
GRC teams must play an effective role in identifying and driving the implementation of such good-enough solutions or quick-wins in risk management.
I hope this post has been useful in terms of generating some actionable ideas you could consider for implementation in your own programs. If you would like us to discuss any of these or other ideas in further detail, please send us a note.
We look forward to hearing from you!