In leadership circles, as a personal characteristic, vulnerability in the right proportion is thought to be a good thing (check out the work of Brené Brown). However, when it comes to risk management and protecting assets, being vulnerable is the exact opposite of what we generally shoot for.
In our most recent blog posts, we’ve talked about things that can go wrong and how we categorize threats. We’ve also been thinking about how likely it is that they might be realized and how damaging it would be if they were. A key component in the risk equation is understanding pre-disposing conditions that may make us more prone to suffer a loss due to one of these threats. In risk assessment lingo, we call these things vulnerabilities.
So, what are these vulnerabilities of which we speak? Thinking from an IT systems or security perspective, our minds usually jump to technical vulnerabilities. These are things like mis-configurations of infrastructure components, flaws in application code, unpatched software, etc. These technical flaws are the things that can be identified by numerous vulnerability scanning software products on the market. Some of the more notable examples are products from Tenable-Nessus and Qualys. Most of these types of tools are quite good at identifying systems that are missing patches or may be vulnerable to an attacker due to a technical flaw.
Vulnerability management is a critical process that every organization should have in place. Without some way to know what your vulnerabilities are, you will be hard pressed to say with any degree of confidence whether or not, or to what degree your systems (and your organizations) are at risk.
If you are running regular scans and keeping up with your patch management, that’s fantastic. You are significantly reducing the likelihood that certain (but not all) threat events will be realized. There are other types of vulnerabilities beyond just those that are technical and it’s just as important that you assess for those – you can think of it as an extension of your “scanning.”
So how do we go about “scanning” for these non-technical vulnerabilities? Well, it’s fairly simple really – just ask. There are several considerations here, and when done effectively, the input should come from multiple sources. Here are a few things that can inform us about where we may have non-technical vulnerabilities:
- Results of external or internal audits – Well done audits can provide great information on where the organization is vulnerable. But not every company has these types of audits (especially around IT or Security). If your company has these types of audits performed, embrace the findings as opportunities for improvement.
- Surveys or interviews with internal process and systems owners – You can start by simply asking, “Hey, based on your knowledge of this, where might our process break down – where are we vulnerable?” You will be surprised by the insight you can gain by speaking to people who live with or execute certain processes in your business, day-in and day-out.
- Controls-based assessments – Assessments against frameworks or control catalogues that represent best practices across relevant domains are also a great way to determine if your current processes include controls designed to reduce the likelihood and/or impact of a wide variety of threat events.
Some of the more popular control catalogues and frameworks that consider information systems and security related threats include:
- NIST CyberSecurity Framework – A newer framework of information security control processes applicable across industries and organizations of varying sizes.
- NIST SP 800-53 – A comprehensive control catalogue for federal information systems, often adopted in the private sector for organizations with a need for enhanced security.
- ISO 27001/27002 – International standards for implementing an information security management program and related control guidance.
- CSA-CCM – A framework of control processes developed by the Cloud Security Alliance targeted at cloud service providers for SaaS, IaaS, and PaaS.
- PCI-DSS – Control requirements for merchants and service providers that handle cardholder data (e.g., credit or debit card data).
There are a number of other frameworks available that address specific industry or regulatory requirements such as HIPAA and HITRUST in the healthcare sector. Still others are geared as audit or assurance frameworks (e.g., SOC 2, SOC for Cybersecurity, etc.)
These frameworks vary significantly in their size, intended scope, and level of prescriptiveness.
BALLAST, a risk management automation tool, gives you complete flexibility to assess against one or more of the frameworks outlined above. Because so many companies have multiple compliance obligations around IT security, it also gives you the ability to assess against your primary framework and understand how you compare against others.
In our next post, we will compare and contrast the different frameworks and how they may fit (or not) into your risk assessment methodology. Until then, be sure to save the vulnerability for your personal leadership style and do your best to limit those that open your organization up to risk.
