In our last post, Process Driven Approach towards Data Security, we discussed a process-oriented approach to implementing a data security practice. And we discussed that a process is a collection of inputs, activities, and outputs with entry and exit criteria.
Starting in this post, we discuss the first of six processes needed to practice data security, namely identifying your organization’s critical assets, data, and intellectual property. This first process is absolutely necessary, the cornerstone of data security. And if you’re in a rush, skip to the second to last paragraph in this post before deciding you don’t need to perform this process!
Without completing this identification process, we are vulnerable to leaving sensitive data unprotected. Which very well may put us in violation of our own internal compliance standards. Or worst yet, a law with substantial violation penalties.
Let’s start by using the Software Engineering Institute’s definition of a critical asset as an intangible property that impacts confidentiality, integrity, availability, or support business mission and functions. Digging a bit further, the Internal Revenue Service’s Internal Revenue Manual (IRM) 4.48.5 defines intangible property as the following:
- Computer software
- Patents, inventions, formulae, processes, designs, patterns, trade secrets, or know-how
- Copyrights and literary, musical, or artistic compositions
- Trademarks, trade names, or brand names
- Franchises, licenses, or contracts
- Methods, programs, systems, procedures, campaigns, surveys, studies, forecasts, estimates, customer lists, or technical data
Additionally per IRM 4.48.5, intangible property includes other items that “derive [..] value not from physical attributes, but from its intellectual content or other intangible properties.” If these other items impact the business, they are also critical assets.
So what would a process to identify critical assets look like? The major inputs to the process would be people and tools. For people, the accounting, legal, and technology teams must be involved. Accounting is aware of IRM 4.85.5 and its requirements for identifying, documenting, and analyzing intangible property with the specific mission of identifying critical assets. Legal is aware of contracts that impose a burden of care on intangible property owned by other parties. And of course IT knows where the digital assets are stored.
For tools, we would need programs that can identify the absence or presence of critical assets. Examples of this include data discovery tools that scan documents or databases for sensitive information. Usually this includes the technique of regular expression evaluation to determine if a digital asset contains Payment Card Information (PCI), Personal Healthcare Information (PHI), or Personally Identifiable Information (PII). Regular expressions can also be used to determine if a digital asset contains other intangible property belonging to our list of critical assets.
What are the activities for this process? IRM 4.85.5 incorporates guidelines for valuating intangible property. So our first activity would be to assess the current state of these existing valuations. If we are fortunate and such evaluations were conducted in accordance with IRM 4.85.5 both recently and thoroughly, we may be far ahead of the game. If our assessment at this stage shows weakness, a follow-on activity would be to conduct more robust evaluations. Which we need to do to comply with IRM 4.85.5 guidelines anyways.
The next activity would be to work with legal to verify that our identification and valuation of critical assets is complete and correct. We are looking for compliance on several fronts, including contracts regarding digital assets owned via third parties as well as industry and government regulations. If necessary, intermediate results at this stage would indicate if we need to spend more time conducting valuations or not.
The final activity would be to use technology and tools for identifying unknown critical assets. Today’s reality is businesses change: employees come and go, companies merge and divest, product lines grow and contract. And all of these happen in fits and spurts. Given the amount of churn in the typical organization, it is hard to imagine identifying most critical assets without technological assistance.
What are the outputs from this process? As intermediate outputs, IRM 4.85.5 requires creation of several reports. However from a data security practice, we want two things out of this process. First, a list of critical digital assets: as computer security professionals, we can only protect items already in a digital form. And second, a confidence rating from zero to one hundred percent (0-100%) that we have identified all of the critical assets we either have an interest in or obligation to protect—and while interest and obligation are different, both result in a need to protect.
Note at this stage we do not try to prioritize which critical asset might be protected first. All we are seeking is a list of these assets and some measure that we have performed this process well. Prioritization takes place in a later process.
We can start this identification process when we have all of the inputs available and we can stop when our confidence level is high enough. Just as with any other business function, there will come a point where more and more time spent will not produce sufficient value to justify going forward.
Here is a critical observation about this entire critical asset identification process, especially for those of you who jumped forward: since this process derives from the requirements of IRM 4.85.5, failure to identify critical digital assets puts the business at risk not just for a security breach, yet also for accounting, compliance, and regulatory lawsuits. The first part of implementing a data security practice, namely valuating intangible property, is essential to running a business. It’s not fluff: it’s mandatory.
What are your thoughts on identifying critical assets? Have you been part of an accounting, legal, or technical team that participated in such a review? Was the process you followed similar or different? We’d love to hear from you in the comments below.
Data security and encryption