Part 1 - Building an Effective Risk Registry

Unlocking the Potential of Your Risk Registry

From Data Collection to Risk Analysis: Part 1 - Building an Effective Risk Registry

Sometimes, I find joy in the unusual. A peculiar fascination with collecting things has always been a part of who I am; I can't quite explain it. It doesn't matter what I collect; it simply brings me a sense of contentment. While there's certainly a psychological underpinning to this penchant for collecting, it surprisingly proves beneficial in my professional life. You see, I have a passion for collecting data—yes, data. It's a more affordable and equally satisfying pursuit. But here's the intriguing part: this love for data collection aids me at work.

I delight in amassing data, especially in the form of risk registry entries. While many might consider this a mundane task, I relish it. The reason is simple: it complements my work in continuous risk assessment and turns what might be tedious for some into an exciting endeavor for me. You should see my extensive OneNote files! I have a library of information on all kinds of topics.

I've had the opportunity to work with numerous organizations on their risk registries over the years. Many organizations tend to update their risk registries on an annual basis, and it's often a relatively straightforward process. During these updates, they typically focus on changes within the organization, shifts in industry technology trends, or emerging threat actors. These are all valid considerations, but what truly intrigues me is diving into the less obvious risks, the ones that often get overlooked. These are the risks that might not fit neatly into the "cyber risk" category but are undeniably cyber-adjacent. From an executive's perspective, comprehending all enterprise risks is crucial to coordinating mitigation efforts effectively. This approach ensures that resources aren't wasted on duplicate efforts and are instead committed to addressing the most optimal risks, ultimately leading to better risk reduction across the entire organization.

In my risk registry, I like to have the following fields:

• Risk Identifier

• Risk Description

• Risk Category

• Risk Owner/s

• Threat Type (Threat Actor, Natural, Environmental)

• Source

• Threat Action

• Vulnerabilities (That can be exploited by threat action)

• Tactics, Techniques, and Procedures (TTPs)

• MITRE ATT&CK Framework

• Vector (network-based, physical, wireless, remote access)

• Associated Assets (Linked to inventory of assets: systems, data, hardware, software, services, etc.)

• Mitigating Factors

• Recommendations (Link to POA&M)

• Associated Controls (Link to controls from various frameworks like NIST 800-53, CSF, PCI-DSS, etc) - you can have multiple here

• Likelihood (Very low, Low, Moderate, High, Very high) Gives you a range of 5

• Impact (Very low, Low, Moderate, High, Very high) Gives you a range of 5

• Exposure (A calculation of the probability of risk exposure based on the likelihood estimate) (1-25)

• Loss Type (Confidentiality, Availability, Integrity, Multiple)

• Adverse impact (harm to operations, Harm to assets, Harm to individuals, Harm to other organizations, Harm to nation)

• Priority

• Risk Response Type (risk treatment) (Accept, Transfer, Mitigate, Avoid)

• Risk Response (Applied controls and mitigations) - you can have multiple here each one might have a control type

• Control Type (Preventative, Deterrent, Detective, Corrective, Compensating)

• Risk Response Costs

• Residual Risk

• Status (Active, Inactive)

• Last Review/Update (Date)

• Next Review (Date)

• Notes

Effective risk management demands a robust system for tracking and reviewing past updates, and relying solely on an Excel spreadsheet can be limiting. For a more dynamic and comprehensive approach, I strongly recommend using a relational database. Why? Because within your risk management process, you'll encounter a web of one-to-many, many-to-one, and many-to-many relationships between various data tables. These relationships are not just technical jargon; they play a vital role when generating reports and conducting data queries.

Consider this scenario: a control fails an assessment. With a well-structured database, you should effortlessly access that control's details and instantly view all associated risks. Imagine if, as part of this database, the control assessment could automatically trigger an alert or update the current residual risk when it fails. This isn't just about streamlining your data management; it's about creating the foundation for continuous risk management.

In essence, a relational database empowers you to navigate the intricate web of risks and controls, facilitating a more agile and responsive approach to risk management.

In my risk registry, I've chosen to gather a wealth of information that exceeds the typical scope of most Governance, Risk, and Compliance (GRC) applications and is more intricate than what you'd find in resources like NIST 800-30 Rev 1 or NIST IR 8286. This extensive data collection serves a specific purpose – it equips us with a unique analytical advantage, allowing us to explore the information in innovative ways. Every data point in our registry has a role to play, as it could be connected to various Security Operations (SEC OPS) functions. This interconnected approach not only paves the way for process automation but also enables near-real-time analysis.

Ultimately, our objective is to track risks meticulously, ensuring awareness and efficient mitigation. It's important to note that you don't necessarily need to adopt an approach as comprehensive as ours. Instead, the key is to collect data that is actionable for you as a risk manager while keeping in mind the information that executives may require for making critical business decisions. There's a balance to strike – the more data you collect, the more opportunities for insights, but there might be a point of diminishing returns where collecting too much data becomes counterproductive. It's a strategic choice that hinges on your specific needs and goals.

Let me illustrate the power of collecting more data with a practical example. While assets may not always find their way into standard risk registries, ensuring good governance of information and technology demands a broader perspective. Ideally, all assets should be meticulously aligned with your mission objectives or enterprise goals. This alignment represents another layer in our relational database, and it's vitally important.

Why, you might wonder? Well, the objective is to establish a direct link between the risks you're managing and your mission. In the event of an adverse event, let's call it "X," impacting the organization, it can have cascading effects on the mission, defined as "Y." At the core of cyber risk and enterprise risk management lies the imperative to align everything with the organization's missions. These missions encompass critical functions, and any disruption can set off a chain reaction that ultimately affects the mission itself.

Consider a local government with a mission centered on public safety. Within this mission, you have critical functions, such as finance-related operations like payroll and procurement. Now, imagine a scenario where the procurement function falters, hindering the purchase of essential items like bullets. The ripple effect is clear – public safety, the heart of the mission, is compromised.

This example underscores the importance of a holistic approach to risk management, where every element, no matter how seemingly small, can have a significant impact on the broader mission of your organization.

The inception of my interest in risk management databases traces back to the early 2000s when I was deeply involved in auditing local governments and consulting for the federal government on the Risk Management Framework (RMF). During that era, most federal agencies operated with a rather convoluted system. System security plans, control assessments, and risk assessments were crammed into Word documents, while Plan of Action and Milestones (POA&M) found refuge in Excel spreadsheets. The process was not just inefficient; it was downright cumbersome. There was no easy way to keep these documents living, updated, and interconnected as they should be. In fact, during one of the RMF classes I was teaching, I couldn't help but highlight the potential for improvement. I proposed that a relational database, specifically tailored to the RMF, could streamline the entire process.

Following that enlightening classroom experience, I found myself sketching out the framework for such a database on a whiteboard for hours. It just so happened that the Chief Information Officer (CIO) for the state of Georgia was in my class and took a keen interest in the concept. Georgia was eager to implement the RMF in a more efficient manner. Back at my office, I attempted to build the database using SharePoint, but creating relationships with tables across different sites proved to be less straightforward than I anticipated. To tackle this challenge, I enlisted the help of my good friend Baz. The end result was a tool that served my audit needs but fell short of being a full-fledged system.

Subsequently, during my tenure at the City of Livermore, I actively sought a Governance, Risk, and Compliance (GRC) application that could match the RMF and meet my integration needs. Regrettably, I couldn't find a solution that aligned perfectly with my vision. Most GRC applications followed their processes, but they didn't seamlessly fit the RMF, at least not as well as my conceptualized database. As a result, I chose a GRC solution that offered the greatest flexibility for customization, allowing me to get as close as possible to what I envisioned.

While the idea of creating a top-notch Governance, Risk, and Compliance (GRC) system tailored to the Risk Management Framework (RMF) might seem like an exciting project, the reality is that time is a precious commodity, and my plate is already overflowing. As much as I'd love to embark on such an endeavor, the GRC market is saturated with options. On one end, there are robust, integrated, and often costly solutions, and on the other, there are cheap, simplistic offerings. What I'm after is the Goldilocks version—just right.

It's a familiar tale in the world of software. Regardless of the field, you often find yourself in the position of having to adapt your processes to fit the application rather than the other way around. It's the eternal quest for the right balance between features, complexity, and cost that aligns with your specific needs.

This blog post has taken us on a bit of a journey, and I appreciate you joining me. However, I've barely scratched the surface of the exciting, out-of-the-box ideas for risks to incorporate into your risk registry. The good news is, that's what Part 2 is all about!

Stay tuned for the next installment, where we'll dive into some novel and thought-provoking risk concepts that can take your risk management strategies to the next level. I can't wait to share these insights with you, and I hope you're as eager as I am for the upcoming post in the next few weeks. Your journey into the world of cutting-edge risk management is just getting started!