CSF profiles

Profiles or organizational profiles are what we use to take the CSF core in its kind of conceptual, non-prescriptive, vague glory, and then translate that into tangible actions or tangible goals. So because CSF core is non-prescriptive, it gives us all these cybersecurity risk management outcomes that we might want to pursue, but it doesn't tell us specifically what our end goal should be. So this is where profiles come in. For our organization and its context and its objectives and requirements and expectations and threats and risks and so forth, we can define exactly what, for instance, controls we want to implement to meet each of the outcomes that the CSF core defines. So one way to apply and use profiles is to make two. You can make a current profile, and this is a sober assessment of the current states of your organization, and then a target profile, and this is where you want to be. Then you have these two profiles, you could compare them, find out where the differences are, and then prioritize which deltas you want to address first, maybe on the basis of risk. That's one way to use profiles, but there are other approaches. So you can have even more profiles. You might break down your organization into like different data types. So maybe like protected or sensitive data versus non-sensitive data. You might have two totally separate profiles if you're like in healthcare and you wanna protect patient data, but it doesn't really matter like if the corporate newsletter gets leaked. So that's another thing. You could use additional profiles or I guess subdivide your company or your organization along lines like that. And same goes for like user type. Maybe you have a specific profile for internal users, but a different profile for external users. And you could probably think of some other ways that you might get more granular with these profiles. But at the most basic, it would involve a current profile for your entire organization and all its assets, and then a target profile. and this is the ultimate goal. And then you have to figure out how to get from A to B. Another thing that is available with profiles are community profiles. So these are published, they're kind of more or less kind of freely published with, for the cybersecurity framework. And the idea behind them is that they meet the needs of companies within like a particular industry vertical. So for instance, the profile that an oil and gas company might pursue is probably gonna be similar to what another oil and gas company might pursue or healthcare and healthcare. So because they're in the same industry and they have the same sort of regulatory considerations and kind of threat landscape, it oftentimes makes sense for community profiles to be created and then they can kind of be shared among organizations that have similar kind of contexts with risk. So that's another option. You could take a community profile, if one exists for your industry, or if one doesn't, I guess you'd choose like a similar industry, and then customize it to meet the specific needs of your company. So that's just another type of profile or kind of bit of profile terminology that you might run into. So what this looks like functionally is oftentimes an Excel spreadsheet. And there is a nice spreadsheet that NIST provides that you can use for working with profiles. We have sort of an abridged representation of that here because there's usually a lot more columns. And it looks something like this just to kind of go from left to right. So we have the identifier for a particular subcategory. In this case, we have protect. So that corresponds to the function. We have DS, I think that's data security. I'm like 98% on that. And then it is subcategory or kind of like objective one here. So this identifier kind of gives us exactly where within the CSF core hierarchy, this is located. So that's our ID and there's a description. So this particular one, DS-01 is for data at rest. Specifically, there's another one for data in motion. and the confidentiality, integrity, and availability of that data at rest. So we want to protect all three ideally. So that's like the first column, that's just like the kind of header. I don't know if header is the right word for rows, but this is just like defining what outcome we're interested in. And then we might have additional columns, maybe two, for our current profile and our target profile. And then you might break cells down into sub-cells, for lack of a better term, to correspond to each of the controls that are listed here in the description. So, confidentiality, integrity, and availability. So, our current profile, let's see, for confidentiality, you know, full disk encryption, like BitLocker or FileVault is not being used, but the target is for it to be used universally. That's a good idea because laptops get stolen and we don't want the data on them to be stolen, preferably. integrity? Are we using digital signatures or even like hashing at least to verify the integrity of data? In this case, this organization is currently not, but for critical data, maybe you could think like applications or really sensitive data, they want to move towards signing that. So basically using public key crypto to generate a digital signature that can't be forged. So it guarantees the integrity and the source of data that is signed. And then finally, we have availability. So making sure that this data at rest is available, there's different ways to approach that. You might use RAID, but that's not really backups, right? RAID and backups aren't the same thing. So they're currently using RAID in this fake organization I've made-up, but they aren't using backups. So if like the server bursts into flames, I don't care how many disks are in your RAID array, it's going to be a bad day. So that's our current state, RAID but no backups. But maybe the ultimate state, the target state is, yeah, use RAID. I mean, that's great. That kind of helps with the resiliency of servers, but also make sure that servers are backed up daily. And you might need to be more specific than that. You might have financial transaction servers that need to be backed up on a minute by minute basis. Or it could be on the other end, like archiving servers that very rarely require backups. But in this company, I guess they're all the same and the data has the same priority. So we're just gonna back them all up daily. It's a good start anyway. So that's like an example of how you might use profiles to evaluate your current states, evaluate your target state, and then you can kind of like do an A to B comparison, find out where the gaps are and prioritize accordingly. Let's do a quick knowledge check. So your organization works with two different types of data. there is normal internal data with minimum sensitivity or minimal sensitivity. This is like internal emails or like jokes in teams. And then you have highly sensitive financial data. So maybe it's like credit card data. What is a sensible approach to ensuring the right outcomes and the right level of like security controls are applied for each of those data types? So I'll assume you got it right. So what you can do is you can scope profiles, not just to the current and target state, but also on the basis of the data type. So you could have a current profile for both the normal data and the highly sensitive data, and then a target profile for the normal data and the highly sensitive data. I almost lost my way in that sentence. So it's just another way that you can be even more granular in case your company has these big disparities in terms of sensitivity of data or user types or things along those lines.