In the last post in my series on Data Security, we defined a process for identifying critical assets and intellectual property—the first of six that are part of implementing a data security practice. After exiting this first process, we will have a list of critical digital assets that are worth protecting. Now it’s time to discuss the second process, namely evaluating threats against and vulnerabilities of these identified critical assets.
And fortunately we have a leg up: since this is such an important process beyond just data security, many professional organizations have defined and documented such an evaluation process. Two are worth our attention. The first is SEI’s Operationally Critical Threat, Asset, and Vulnerability Evaluation. Strange name, yet a wonderful acronym: OCTAVE.
Like most work developed by the SEI, OCTAVE is a framework of multiple processes to help an organization manage information security risks. OCTAVE has an air of military precision—its development was sponsored by the US DoD, after all—yet the framework’s flexibility allows a wide diversity of application.
Of particular importance to our purposes is Phase 2, Section 3.2, Process 6: Perform Infrastructure Vulnerability Evaluation. Just what the doctor ordered, this process documents the inputs, activities, and outputs necessary to perform such an evaluation. It’s such a close match that we’ll just reference the framework and comment that the output of our first process is a required input to OCTAVE.
The second evaluation process we should pay attention to is ISO/IEC 27001, part of the ISO27K family of information security standards. Clause 6.1.2 requires a threat assessment and the earlier 2005 version of the standard also required a vulnerability assessment. Although the current 2013 version does not, most security professionals still conduct both assessments—and we recommend that you do so as well.
Which “flavor of the month” is best suited for your organization may vary depending on its geographic location. If you are USA based, especially when working with government mandates, OCTAVE has an edge. If you are EU based, and also subject to GDPR, ISO/IEC 27001 seems particularly attractive. And before starting this evaluation process, it behooves one to consider both standards and choose the “best of breed” from each.
One strong hint regarding executing this evaluation: be inscrutable when evaluating home-grown assets, such as accounting and payment systems built in-house, for two reasons. First, no other organization will have evaluated such assets for security risks: if we don’t find the vulnerability, no one else will. And second, we must account for any remediation mandated by a future process: we cannot assign that task to someone else!
The output of this evaluation will feed forward to the fourth of six: we will use the output of this evaluation process as an input in to the prioritization process. Our next post will take a slight detour and delve into the third data security practice process, namely assessing our governance and security requirements.
What are your thoughts on evaluating vulnerabilities? Have you participated in such an assessment? Did you follow a formally documented process such as ISO 27001? We’d love to hear from you in the comments below.
Data security and encryption