Welcome to first in a series of posts covering foundational topics in IT risk assessment and management. As a risk analytics company, we are often asked by clients where to start, how to optimize their risk management approach, and what types of practices and considerations should go into risk management program planning and execution. This series will provide some common answers that will be helpful for launching and tuning your programs.
The phrase “Risk Assessment” has become a common part of our technical vernacular, yet it’s quite surprising how variable our understanding is of the phrase and what it actually means. In this post we will explore the concept of the risk assessment, where it fits within an overall risk management program, and how we will typically enter into the risk assessment process.
For starters, let’s address what is not a risk assessment. Quite simply, data collection, such as via a questionnaire, is not itself “risk assessment.” Rather, it’s the analysis and evaluation of all collected data, in context and aimed toward producing a statement on risk that is the core objective of a risk assessment. Simply posing questions to constituents, while potentially worthwhile, is not an act of analysis, and thus we must be very careful not to misconstrue the data collection as the “assessment” itself. This, alas, is a common mistake within organizations involved in IT risk management.
The Risk Management Process
A great starting point for a discussion of risk assessment is to first talk about the overall risk management program and process. (Figure 1) Aligning with the three core sub-processes within ISO 31000’s risk management process, we see that risk assessment is in fact the second step, not the first. Step 1 is to establish context within which we will conduct risk analysis, crucial to the determinations that will inform risk treatment decisions. Let’s drill down into these topics.
Context-setting is a critically important step, and one often overlooked. In setting context, we clearly define target and environment of the assessment: the technologies, the data, the stakeholders, the environment, and the business context (such as a business impact analysis and general rubric for risk tolerance, capacity, and/or appetite). It’s only after framing the context that we can effectively then drill down to the next level and conduct the assessment itself.
Risk Assessment is the step where we implement data collection and analysis in light of the information gathered during context-setting (including the definition of assessment target, risk and business context). We will have already determined what the purpose of the assessment is in terms of the type of decision(s) to be supported, and we should have a solid understanding of how the output should be structured in order to be useful for decision-makers. For example, simply producing a magically calculated aggregate number may not provide any value whatsoever if the purpose of the exercise is to determine whether or not a given environment is adequately secured against a defined threat actor.
Risk Treatment (or remediation)_is the final core sub-process within the risk management process. In this step we take the output of the risk assessment and discuss options with the business owners/stakeholders, such as whether or not the assessed risks are palatable to the business or if additional controls should be adopted to reduce the identified exposure levels. Again, the output of the risk assessment should be in a format that is natively understood by your target audience, and it should align well with the desired use case for the report (that is, it should be tailored to how the report is to be used).
Putting everything together, we find that it is indeed critical that information be gathered first in the context-setting stage before any sort of assessment is actually performed. If one were to rely just on the wording of many regulations and standards, then you might not realize that it’s important to understand where risk assessments fall within the overall risk management process. Getting these steps right will make life easier, as well as lead to much happier customers (the recipients of the assessment output).
What and When Should You Assess?
Now that we have a general understanding of the risk management process and where risk assessments fit overall, the next logical question is “well, when do we need to do these things anyway?” At first blush this may seem like an easy question to answer, but it turns out there isn’t typically just a single answer, there are two or three possible approaches.
You can perform an assessment of varying degrees as a contributing data point for just about any decision. In fact, we do this all the time in our personal lives, implicitly, and without any sort of formal framework. Why in IT we think this has to be overcomplicated is somewhat of a head-scratcher, but in reality there are ways in which we can rapidly collect data and perform analysis toward improving decision quality. The mere step of collecting or maintaining contextual information can make a world of difference in overall decision quality.
When thinking about what to assess and when to assess it, there are a few scoping questions to consider:
These questions are important to understand because the type of assessment you conduct will need to vary in order to meet the needs defined in scoping. Consider these risk assessment scenarios:
Getting engaged to perform a risk assessment can come through a variety of means and methods. At the most basic level, engagement may come through a simple conversation, email, or form-based request. Alternatively, certain types of assessments may be integrated into key processes – such as for procurement, project management, or M&A activities – to ensure that a proper risk assessment (that includes IT/information risk considerations) is performed, and early enough in the project to adequately account for IT or information risk. Lastly, it may also be appropriate to perform portfolio assessments on a regularly scheduled, recurring basis (such as quarterly or annually).
Ownership and Common Actors
The last topic we wish to highlight in this post is the role of people in the risk management and risk assessment processes. As has already been noted, the context-setting stage should capture important information prior to commencing the risk assessment itself. This information must include identifying the owner of the resultant assessment report (the person performing the work is rarely the owner in that risk analysts don’t general own the identified risk). Typically, the owner will be someone in management (either business or technical, depending on the scope of the assessment) who is charged with making a decision or recommendation. It is essential that the risk assessment output be tailored to their specific needs, including ensuring that the report is written in a manner that they can understand and use.
Beyond the risk owner, there will then often be the person performing the risk assessment (we’ll just refer to them as a the “risk analyst” here) and the other stakeholders and subject-matter experts who will help provide valuable inputs for context-setting.
The role of stakeholders and subject-matter experts is not to be understated. The worst thing the risk analyst can do is fail to seek out those people with a vested interest in the project or with specialized knowledge that is important for improving data quality and, by extension, decision quality. For example, IT professionals are notoriously bad at estimating business impact without the assistance of someone from the business. Think of all the IT and cybersecurity “sky is falling” moments trumpeted over the years only to fall flat in the face of reality. The simple fact is that, despite all the problems we see with IT and cybersecurity, businesses still manage to continue to exist and function. That alone is a testament to resiliency.
As such, it is very important not to rely on a single source for all or most of the data. Instead, find the people who truly know the answers (verifiably!) and get them involved in the process (early!).
At the end of the day, all of the considerations discussed within this post are critical to achieving success and demonstrating value. Knowing that risk assessment is not itself a starting point is key. Context is all-important. Good decisions cannot derive from poor assumptions or bad/non-existent data. Further, it’s imperative that the right people be involved and that the output of the risk assessment be properly tuned to the target audience. Tuning the output is also a key facet of context-setting, again highlighting the importance of not jumping into later phases too quickly. And, lastly, remember this motto as pertains to being engaged to perform a risk assessment: Semper Gumby! (always flexible). Work diligently to establish hooks into key processes, but resist the urge to make the risk assessment process so rigid and inflexible that people can only engage the risk analyst through a very narrowly defined set of circumstances. Every opportunity to have a risk management conversation should be welcomed. Creating friendly conditions for engagement and conversation are key to success, both today and in the future.
In future posts we will talk about how to leverage risk assessment standards, some of the key differences between – and considerations for – qualitative vs. quantitative risk assessment, and how to leverage platforms to improve the overall risk management program and process. The next post in this series will look at common risk assessment standards and how to best leverage them within risk management programs.
Brinqa is actively investigating the impact of the Grails Framework Remote Code Execution Vulnerability CVE-2022-35912 disclosed on July 18, 2022. This bulletin contains the latest information as it pertains to the impact of this vulnerability and will be updated as new information becomes available. Based on information in the disclosure from the Grails Foundation, no version of the Brinqa Platform is impacted by this vulnerability. Out of an abundance of caution, we will be releasing an updated version of the 10x Platform this week. This update contains the patched version of Grails addressing the CVE-2022-3591 vulnerability. If you were not already scheduled to be upgraded to this version and would like to be patched, please reach out to your Customer Success Manager for assistance. If you have any questions or concerns, please feel free to reach out to us at email@example.com
As breach remediation costs rise, seemingly in direct proportion to the number of attackers and attacks, what are you doing to manage your cybersecurity vulnerabilities and risks? Sufficient proof is easily found to reinforce that how you respond to threats and breaches can have a significant impact on your business. For example… The 2021 Ponemon Institute Annual Cost of a Breach Report found that the average cost of a breach rose 10% to $4.24M. The report also found that it took an average of 287 days to identify and contain a data breach. Even if you can handle the reputation hit of a breach, and even if your insurer agrees to cover a portion of the damages, do you want to be on the hook for millions of dollars in remediation and restoration costs? Prevention is easier and less expensive. Your data and intellectual property (IP) are often the most valuable assets you own, and as such are deserving of all the resources your team can muster for effective security vulnerability and risk management. Read on to learn more about the cyber risks to watch out for in 2022 and how you can plan and prepare for them. What types of cyberattacks can you expect? Counterintuitive, of course, because many organizations don’t expect their network to be attacked, any more than they expect it to contain dangerous vulnerabilities. You want to believe those events occur to others, not you. Right? Except competent hackers can infiltrate your network and steal your data and IP while remaining undetected. Ransomware attacks For several years now, ransomware attacks have been the fastest growing segment of cybersecurity breaches. Typically, criminals breach an organization and encrypt its data, rendering it unusable. Inaccessible data renders a firm unproductive and unprofitable for as long as the data remains inaccessible. The Colonial Pipeline ransomware attack, for example, led to the shutdown of the largest fuel pipeline in the U.S, which in turn caused fuel shortages across the East Coast. Criminals also threaten to publicize intellectual property (IP) and customer information, unless they receive a ransom. Although small-to-midsize businesses (SMBs) are at the most risk of criminal ransom demands, payouts can reach seven or eight figures. The highest ransom amount confirmed to have been paid is $40 million USD, by CNA Financial, in May 2021. Few SMBs can afford such extravagance. Cloud vulnerabilities The first researchers to discover and report on critical vulnerabilities in the cloud focused on Microsoft Azure infrastructure. In detailing the vulnerabilities, those researchers, who were with Check Point, “wanted to disprove the assumption that cloud infrastructures are secure.” And did they ever disprove it — the discovered vulnerabilities included those that received the highest possible score of 10.0. The qualitative severity ranking of a score of 9.0-10.0 is “critical.” The discovered vulnerabilities allowed malicious actors to compromise applications and data of those using similar cloud infrastructure. Firmware vulnerabilities Firmware vulnerabilities expose not only the major computer manufacturers, but also their customers. Undiscovered firmware vulnerabilities are especially damaging, because they grant criminals free reign over any network on which the devices are installed, leaving networks open until the vulnerability gets reported and patched. As the number of connected devices continues to grow, Internet of Things (IoT) security becomes increasingly important to analyze. Software vulnerabilities Applications contain vulnerabilities. According to Veracode, 75.2% of applications have security flaws, although 24% of those are considered high-severity. Common flaws include: Information leakage. Carriage Return and Line Feed (CRLF) injection. Cryptographic challenges. Code quality. Credentials management. Insider threats Insider theft and trading of secrets is another growing vulnerability area. As demonstrated by recent Cisco and GE breaches, employees with perceived grievances or bad intentions can choose to steal or wreak all kinds of damage on their employers’ data and networks. Carelessness and poor training also contribute to insider threats. Cyber threats to healthcare In recent years criminals have increasingly trained their sights onto hospitals, insurers, clinics, and others in that industry. A 2016 report by IBM and the Ponemon Institute found the frequency of healthcare industry data breaches has been rising since 2010, and it is now among the sectors most targeted by cyberattacks globally. Whether or not the reputation is deserved,healthcare industry computer networks are often considered soft targets by malicious actors. In 2021 Armis discovered nine vulnerabilities in critical systems used by 80% of major North American hospitals. Additionally, rapid health device adoption has increased the number of available targets for malicious breachers. Numerous healthcare devices suffer security flaws, including imaging equipment. Added together, those factors point to an increase in attacks on health care institutions. Attacks against health care networks threaten lives, not just productivity. Criminals might believe health care administrators are willing to pay ransoms faster to retrieve health data and help patients. That’s not always the case, as ransomware allegedly led to the death of an infant and was initially thought responsible for the death of a German patient. Individual medical data – name, birth date, blood type, surgeries, diagnoses, and other personally identifiable information – is particularly interesting to criminals. Once compromised, it’s impossible to restore patient privacy, just as it’s impossible to reverse the social and psychological harm inflicted. Forgotten cyber hygiene When IT professionals are always in stressful firefighting mode, they can’t be expected to remember everything. Sometimes patches fall through the cracks, and those vulnerabilities come back later to bite your network. Your IT department may be aware of old vulnerabilities, but just hasn’t gotten around to applying the necessary patches or closing open holes. A virtual private network (VPN) account that remained open, although no longer in use, was how criminals penetrated Colonial Pipeline. Employees had previously used that account to access the company network remotely. How can you uncover cybersecurity vulnerabilities and risks? It’s easy for consumers to learn what to watch for and what to avoid. They can download, for example, the Annual Data Breach Report from the Identity Theft Resource Center. You, on the other hand, have a network full of devices, endpoints, applications, and the weakest link in the security chain – users. Yes, you can lower the possibility of user negligence with cybersecurity training. Sure, you can find and read reports about currently existing threats. But without a comprehensive vulnerability management program that brings together every vulnerability scanning tool across your entire attack surface, it’s almost impossible to know what’s threatening your network right now. How do you find a vulnerability in YOUR cybersecurity and IT environments? Most organizations rely on several different vulnerability scanning tools to achieve full vulnerability assessment coverage over their IT environments. Most vulnerability scanning tools focus on only one specific aspect of your attack surface — network devices, web applications, open source components, cloud infrastructure, containers, IoT devices, etc. Vulnerability management teams are often left with the unenviable job of bringing these disconnected tools, and the incompatible data they deliver, together into cohesive and consistent programs. Deploying Brinqa vulnerability management software to perform vulnerability enumeration, analysis, and prioritization allows you to effortlessly synchronize and orchestrate the best vulnerability scanning tools for your environment. The Brinqa platform is designed for data-driven, risk-based cybersecurity solutions. Brinqa include risk models for cybersecurity problems like vulnerability management and application security, which are essentially data ontologies developed based on industry standards and best practices to represent these cybersecurity challenges in terms of data. Brinqa data models and risk scores are adaptive, open and configurable, and include not just vulnerability data, but also additional business context from within the organization, as well as external threat intelligence. For example, the data model automatically considers that if a server is internal facing, and it’s for testing code, then it’s going to differ in priority from an external facing server that is hosting an e-commerce site, and which contains customer personal data and information. Similarly, if external threat intelligence discovers that a particular vulnerability is suddenly very popular among malicious actors and is being used to affect breaches, the data model automatically computes and assigns a higher risk score to the vulnerability. First and foremost, we get you away from having to log into numerous different tools to bring all relevant information together and make it usable. Second, we streamline and automate your common vulnerability analysis, prioritization, and remediation use cases. That's the enormous benefit of Brinqa... The centralization is great, but once you start consolidating, enhancing, and contextualizing all of that data, you can provide a level of prioritization that takes your risk response to another level. Beginning with generic, out of the box rules based on best practices, the environment allows every Brinqa customer the flexibility to tailor analysis to their needs, basically giving them a self-service mechanism to implement their own cybersecurity service level agreements (SLAs). The default rules are like templates or starting points, which you adjust and configure as necessary. It is ineffective and inefficient to make decisions on an ad hoc, case by case basis, about what should be fixed and in what order. Once you implement Brinqa, your automated vulnerability remediation and cyber risk response processes deliver effective, consistent, and reliable results. Spend a little time (no money) to see how simple solving a major headache can be, with a free trial. Frequently Asked Questions: What is vulnerability scanning? Vulnerability scanning is the detection and classification of potentially exploitable points on network devices, computer systems, and applications. What is vulnerability remediation? Vulnerability remediation includes the processes for determining, patching, and fixing cybersecurity weaknesses that have been detected in networks, data, hardware, and applications. What is NVD? National Vulnerability Database (NVD) is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). What is CVE? Common Vulnerabilities and Exposures is a list of publicly disclosed cybersecurity vulnerabilities that is free to search, use, and incorporate into products and services. What is CRLF? Carriage Return and Line Feed injection is a cyber attack in which an attacker injects malicious code.
Brinqa is actively investigating the impact of the Log4j library vulnerability CVE-2021-44228 disclosed on Dec 9 2021 and associated CVE’s (2021-45046, 2021-4104). This bulletin contains the latest information as it pertains to the impact of these vulnerabilities on Brinqa and will be updated as new information becomes available. We have been continuously monitoring for Log4j exploit attempts in our environment. At this time, we have not detected any successful Log4j exploit attempts in our systems or hosted solutions. We will continue to monitor our environment for new vulnerability instances and exploit attempts and will update this page as we learn more. The Cybersecurity and Infrastructure Security Agency (CISA) provides a useful summary of Log4J vulnerability guidance that customers may want to reference in addition to any product and version specific recommendations from your Brinqa customer success team. If you have any questions or concerns please feel free to reach out to us at firstname.lastname@example.org