Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

3 Security Issues Overlooked By the NIST Framework

NIST cybersecurity framework
(Source: Pixabay)

For most companies, the first port of call when it comes to designing a cybersecurity strategy is the National Institute of Standards and Technology (NIST) Cybersecurity Framework.

This is good since the framework contains much valuable information and can form a strong basis for companies and system administrators to start to harden their systems. Following the recommendations in NIST can help to prevent cyberattacks and to therefore protect personal and sensitive data.

However, NIST is not a catch-all tool for cybersecurity. There are a number of pitfalls of the NIST framework that contribute to several of the big security challenges we face today. In this article, we’ll look at some of these and what can be done about them.

Log files and audits

Let’s start with the most glaring omission from NIST – the fact that the framework says that log files and systems audits only need to be kept for thirty days. When you think about the information contained in these logs, how valuable it can be during investigations into cyber breaches, and how long the average cyber forensics investigation lasts, it’s obvious that this is far too short a time to hold these records.

We need to raise this omission first because it is the most obvious way in which companies and cybersecurity professionals alike can be misled by the NIST framework. For many firms, and especially those looking to get their cybersecurity in order before a public launch, reaching compliance with NIST is regarded as the gold standard. Surely, if you are compliant with NIST, you should be safe enough when it comes to hackers and industrial espionage, right?

Well, not exactly. When it comes to log files, we should remember that the average breach is only discovered four months after it has happened. If you are following NIST guidelines, you’ll have deleted your security logs three months before you need to look at them. Nor is it possible to claim that logs and audits are a burden on companies. Because of the rise of cheap, unlimited cloud storage options (more on which in a moment), it’s possible to store years’ worth of logs without running into resource limitations.

In short, NIST dropped the ball when it comes to log files and audits. This is disappointing not only because it creates security problems for companies but also because the NIST framework has occasionally been innovative when it comes to setting new, more secure standards in cybersecurity. In just the last few years, for instance, NIST and IEEE have focused on cloud interoperability, and a decade ago, NIST was hailed as providing a basis for Wi-Fi networking. Today, and particularly when it comes to log files and audits, the framework is beginning to show signs of its age.

The cloud

Another issue with the NIST framework, and another area in which the framework is fast becoming obsolete, is cloud computing. Or rather, contemporary approaches to cloud computing.

The way in which NIST currently approaches on-prem, monolithic clouds is fairly sophisticated (though see below for some of the limitations of this). The problem is that many (if not most) companies today don’t manage or secure their own cloud infrastructure. Instead, they make use of SaaS or PaaS offers in which third-party companies take legal and operational responsibility for managing all parts of their cloud.

The issue with these models, when it comes to the NIST framework, is that NIST cannot really deal with shared responsibility. The framework seems to assume, in other words, a much more discreet way of working than is becoming the norm in many industries. Complying with NIST will mean, in this context, that you are on top of all the parts of your systems you manage yourself – but unfortunately, you will have little to no control over those parts that are managed remotely.

Again, this matters because companies who want to take cybersecurity seriously but who lack the in-house resources to develop their own systems are faced with contradictory advice. According to cloud computing expert Barbara Ericson of Cloud Defense, “Security is often the number one reason why big businesses will look to private cloud computing instead of public cloud computing.”

If companies really want to ensure that they have secure cloud environments, however, there is a need to go way beyond the standard framework. You should ensure that you have in place legally binding agreements with your SaaS contractors when it comes to security for your systems, and also explore the additional material that NIST have made available on working in these environments – their Cloud Computing and Virtualization series is a good place to start.

The problem with RBAC

Our final problem with the NIST framework is not due to omission but rather to obsolescence. One of the outcomes of the rise of SaaS and PaaS models, as we've just described them, is that the roles that staff are expected to perform within these environments are more complex than ever. NIST, having been developed almost a decade ago now, has a hard time dealing with this.

NIST recommends that companies use what it calls RBAC – “Role-Based Access Control” – to secure systems. This is a good recommendation, as far as it goes, but it becomes extremely unwieldy when it comes to multi-cloud security management.

Individual employees are now expected to be systems administrators for one cloud system, staff managers within another, and mere users on a third. Granted, the demand for network administrator jobs is projected to climb by 28% over the next eight years in the United States, which indicates how most companies recognize the need to transfer these higher-level positions to administrative professionals rather than their other employees. Still, for now, assigning security credentials based on employees' roles within the company is very complex.

For these reasons, it’s important that companies use multiple clouds and go beyond the standard RBAC contained in NIST. Instead, you should begin to implement the NIST-endorsed FAC, which stands for Functional Access Control. The central idea here is to separate out “admin” functions for your various cloud systems, which in turn allows you a more granular level of control over the rights you are granting to your employees.

Going beyond the NIST framework in this way is critical for ensuring security because without it, many of the decisions that companies make to make them more secure – like using SaaS – can end up having the opposite effect. This has long been discussed by privacy advocates as an issue. According to London-based web developer and cybersecurity expert Alexander Williams of Hosting Data, you need to be cautious about the cloud provider you use because, “There isn’t any guarantee that the cloud storage service you’re using is safe, especially from security threats. If the service is compromised, its backup safety net could also be removed, putting you in a position where your sensitive data is no longer secure.”

Fit for purpose?

Although, as we’ve seen, the NIST framework suffers from a number of omissions and contains some ideas that are starting to look quite old-fashioned, it's important to keep these failings in perspective. As we've previously noted, the NIST framework provides a strong foundation for most companies looking to put in place basic cybersecurity systems and protocols, and in this context, is an invaluable resource.

NIST is still great, in other words, as long as it is seen as the start of a journey and not the end destination. Today, research indicates that nearly two-thirds of organizations see security as the biggest challenge for cloud adoption, and unfortunately, NIST has little to say about the threats to cloud environments or securing cloud computing systems. Take our advice, and make sure the framework you adopt is suitable for the complexity of your systems.