O ButI used to listen to the Prairie Home Companion radio show on Saturday mornings, while tinkering in the garage. There was always the part of the show that started, “It’s been a quiet week at Lake Woebegon…” and then the stories of the inhabitants would follow, usually funny, often poignant, never truly sad. Not like in our little security world, where the stories are usually sad, often aggravating, and almost never funny. But sometimes it *is* unnervingly quiet. With that in mind I have decided to give our little bit of the security universe a fictitious name just so that I can start off a Security Tidbits with the phrase, “It’s been a quiet week at ‘Make Foebegone’…”. And so now I have, and yes I know it hurts a little to read it.
It’s been a quiet week at Make Foebegone, except for those responsible in Domain 2 of the Certified Information Systems Security Professional (CISSP) security domains. Networks were created and secured, e-mail systems were migrated upward to cloudy providers and QuickBooks was fixed once again in the ritual dance of ‘why-did-they-do this?’ and ‘ok-try-it-now’. But in one little cubicle, right here in our organization, sensitive data was leaked and, most embarrassingly, leaked by me. The leaked data didn’t go far and was caught before it fell into the hands of Bad Actors, but leaked it was, right in the middle of my studying Domain 2. I expect to be teased about this for a while and classified in many embarrassing ways. You’ll get that joke in a minute, right after I tell you more about Domain 2: Asset Security.
Domain 2: Asset Security
An asset can be anything critical to the operation of an organization. Assets can be physical objects such as servers, switches, firewalls, etc. They can be mobile devices, like your phones and tablets, or stationary objects, like your boss right after lunch. An asset can also be digital such as software, or electronic data, which is where Domain 2 of the CISSP model concerns itself. The CISSP breaks down the security landscape/ecosphere into eight ‘domains’ and as I study for my CISSP certification I think of all things computerish in terms of these eight areas:
- Domain 1: Security and Risk Management
- Domain 2: Asset Security
- Domain 3: Security Architecture and Engineering
- Domain 4: Communications and Network Security
- Domain 5: Identity and Access Management
- Domain 6: Security Assessment and Testing
- Domain 7: Security Operations
- Domain 8: Software Development Security
There is much written about Asset Security, because assets are the things of value that we rely upon to make our businesses work. Because they are so important, there are quite a few competing standards and control frameworks for how to manage asset security such as PCI-DSS, OCTAVE, ISO27001-2, COBIT, NIST, and others. All of these frameworks start with classifying software and data assets based on how important they are to the organization. This is vital because securing data takes time and effort, and while it makes sense to encrypt and restrict access to highly sensitive payroll data on a server, you might get an earful for applying the same level of expensive security to the downloaded Ren and Stimpy videos on an engineer’s workstation.
To help folks decide what assets get the most effort, asset control frameworks specify using a data classification structure. The framework descriptions tell you this is important, but they can be a bit vague on specific guidelines. They basically kick the can to you, stating that it’s best you make up your own classifications based on your own criteria. While that kind of makes sense, it’s also not at all helpful. Where do you start? Sometimes it doesn’t really click in your head until you see an example. Here is a familiar one taken from ‘Executive Order 12356 – National Security Information’ and used by our own Homeland Security:
- Top Secret – Applied to information, the unauthorized disclosure could be expected to cause exceptionally grave damage to national security
- Secret – Applied to information, the unauthorized disclosure could be expected to cause serious damage to national security
- Confidential – Applied to information, the unauthorized disclosure could be expected to cause damage to national security
- Unclassified – Data not sensitive
- SBU – Sensitive But Unclassified – Data that is not a matter of national security such as health records of enlisted personnel
- FOUO – For Official Use Only
The idea is to look at characteristics of your data and come up with some sort of pain factor, how much it will hurt the organization, based on these characteristics if something happens to that information. You gather these characteristics by simply asking questions about your data:
- Does it have value?
- Does it fall into a specific category? How important is that category?
- Is there an identified owner? (and how important is *that* person?)
- Is it useful?
- What will it cost to re-acquire or re-create?
- Are there repercussions for not being able to produce it on request? Compliance issues?
- Is there a risk of losing it? How big is that risk?
- What if somebody tampers with it?
- What happens if is not accurate?
How Much Pain Would You Like?
These are examples and you will want to roll your own, but you start to get the idea. You may even want to start with what do you *have* to do to meet compliance standards. Once you have answers to these questions, you weight your classifications to come up with a degree of importance. There are many different ways to value data and you can find some of them here, here and here. Valuing data can be its own discipline, however, and it really boils down to, “How much of a pain will it be if something happens to *this* piece of data?”
Once you classify your data, you write up rules and processes for how it is to be handled and secured based on those classifications, then you implement those rules and processes using tools adequate for the job. I used to do it the other way around. I would focus on the strength and capabilities of the security tools in use and design processes and policies around what the tool could do. Now, I believe that the slick expensive tool that can be used to secure lots of things is less important than designing proper policies about how data should be handled. If an old, simple, yet harder to manage tool is the better way to implement a policy than to use the slick tool, then I stick to the policy and implement using the harder tool. And then I get quietly cursed by the operations folks for making things too hard. Security <> Popularity.
Oh. So *That’s* How It Works
Of course, to do this well you have to understand how your tools secure your data, be the tool be of the slick or the simple variety. My little faux pas here at Make Foebegone happened because I did not understand how an unsophisticated tool works; my screen saver .
Figure 1 – Corporatey Screen Saver
I had taken a picture of some settings on a client device and downloaded it from my camera to a temporary folder on my workstation called ‘Pics’ as an interim step before putting it in secure storage. The picture included some credential info for the device. We make it a rule to secure our workstations from access and prying eyes when we leave them unattended, even for a minute. On top of that, we have a Group Policy Object (GPO) that locks the workstation and kicks off the screen saver if idle for more than a few minutes, even if we are sitting right in front of it. We have a good password policy, we control traffic through the work area, and we have visible cameras and warning signs to dissuade interlopers, so there is a reasonable level of security for any client information that we might have on any machine. I left the picture in the temp folder on my workstation because I felt that my workstation was reasonably secure given the importance of the asset.
While the GPO specifies to use the screen saver to lock our workstations, we all have the latitude to choose what gets displayed. When I set my screen saver up I told it to use images from the Pictures folder, the default, and then used File Explorer to empty the Pictures folder except for one corporate image with our logo in it. But when is the ‘Pictures’ folder not the ‘Pictures’ folder? When it is a Library called ‘Pictures’.
I had chosen to use the default Windows 10 setting using the ‘Pictures’ folder thinking it was just the one folder, but nooooooo. Windows 10 chose the Library called Pictures which also “contained” a Quick Access link to the ‘Pics’ folder where I had my client screenshot. This is one of those instances where Windows tries to help you across the street, but ends up breaking your ankle.
So, when my screen saver kicked in it showed my one chosen photo and then cycled through all of the “sub-folders” in the Library for other images. I walked into work this morning only to be told, first thing, that I was a leaker. Mr. Leaky L. Leakovitch. Leakerific Leaker Extraordinaire. My screen saver had been flashing my client credentials on a continual loop to any passing visitor. Granted I did not create my temporary folder until after setting up the screen saver, and there were other images in the folder ‘Pics’ so it’s not like the image was continually visible, but it got noticed and now I have to hang my head in shame for a while.
My Asset Security procedures failed because I did not fully understand how the security tools that we employed actually worked, and I did not clean up after working with my image. Also, our policy for handling downloaded client data was not strict enough. After moving the sensitive image to our centralized secure storage I should have deleted it from my workstation. If we had a stricter policy I could have avoided my security tool (screen saver) quirkiness and my tool-knowledge gap.
I knew the data was sensitive and thought we had adequate tools in place to secure it, and they do when used properly, so this brings up a few general things to think about:
- Really take a look at your policies and revise/create them to cover data in-motion, in-use and at-rest. *Then* consider what your tools can do and either change how your tools operate in order to meet the policy, or use a tool that does.
- All Asset Security tools should be tested against the policies, not against what they are supposed to be able to do.
- Security should be continually reviewed, and not just by the same people. It helps to have someone review your work (or simply walk by your desk).
- Shortening ‘in-motion’ time (the time it takes to transfer data from place to place) is important, and copies of data are just as important as the originals. Secure those copies to the same level as the original data is secured, no matter where or when it is.
FYI – Some well-known and used Standards and Control Frameworks for Asset Security that you might recognize:
- PCI-DSS – Payment Card Industry Data Security Standards
- OCTAVE – Operationally Critical Threat, Asset and Vulnerability Evaluation
- ISO 17799 and the ISO 27000 Series
- COBIT – COntrol OBjectives for Information and related Technology
- NIST – National Institute of Standards and Technology
- ITIL – Information Technology Infrastructure Library
