The NIST Framework: Understanding the Protect Function

The National Institute of Standards and Technology (NIST) Framework provides a common taxonomy and mechanism for organizations to:

1) Describe their current cybersecurity posture;
2) Describe their target state for cybersecurity;
3) Identify and prioritize opportunities for improvement within the context of a continuous and repeatable process;
4) Assess progress toward the target state;
5) Communicate among internal and external stakeholders about cyber security risk.

The Framework Core consists of five concurrent and continuous Functions—Identify, Protect, Detect, Respond, Recover. When considered together, these Functions provide a high-level, strategic view of the life-cycle of an organization’s management of cyber security risk.

In this series of blogs I will examine the Protect function and what that means for organisations, their IT teams, Chief Risk Officers and the C-suite.
It is important to develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services. The Protect Function supports the ability to limit or contain the impact of a potential cyber security event. Examples of outcome Categories within this Function include: Access Control; Awareness and Training; Data Security; Information Protection Processes and Procedures; Maintenance; and Protective Technology. So what is access control?

Access control is about protection of systems from a user ID or password or the ability to gain access to systems or data. That can also extend to physical access to infrastructure. You don’t want people being able to wander into your servers and gaining physical access, for example.
From a user ID and password perspective there are standard guidelines and best practices around issuing and retiring access to systems and data. They typically mean that people only have access to the data and information and systems that is required for their jobs. The principle of least permissions apply and access should not be shared with a colleague, for example.

So two people who work together should not have the same user ID and password even if we are working in the same role because there could come a time when you leave and I leave and then what happens to that user ID? It still remains mine as opposed to a shared one, what does that mean?
User IDs should be unique to the user and they should go through a life cycle. The life cycle for a user ID is typically created when the person joins an organisation or when they require access to a system. Their user ID is created, and permissions are granted, as that person moves through the organisation it may be that their accesses change. This can take two different forms.

Access to systems can be where you have one user ID that accesses all your systems. That is called single sign on and you are just given permission to access other systems. Some systems either don’t allow interaction with single sign on systems (these are rarer these days, but do still exist) or they are so sensitive that people want to have different IDs and passwords issued.

As you move around the organisation you can gain access to new systems but you also lose access to those systems that you don’t require access to any longer. This is something I talked about in my Identify series of blogs earlier this year where I discussed the principle of having access to both sides of the accounting function. In this instance it is about having the ability to switch on or off access as appropriate. You don’t want to accidentally breach your segregation of duties by allowing someone to move over to the accounts receivable side of the business and still have access to other parts of the business where it could create a conflict of interest.

The final step of that life-cycle of access management/control is the deletion or retiring of the account. That happens when someone leaves the organisation or when access to that system is no longer needed. User IDs should be reviewed on a regular basis to ensure that access is only available to those require it (and that no-one has been missed from an earlier process). In my next blog, I look at cyber awareness and training.