Hello everyone! Welcome back to another video.

Introduction to EO-critical software

The executive order 14028

Today we're going to be talking about critical software, and the security measures that need to be put in place to protect it. As you probably know, earlier this year in May 2021, President Biden put out an executive order to increase and improve the cyber security defense of the United States. This was in response to the unprecedented amount of cyber attacks that we have seen, particularly targeted towards the United States throughout 2020 and 2021. As part of this, NIST, the national institution for standards and technology, was tasked to come up with a definition of Critical Software. Today we're going to talk about what that definition is in plain English, and we're going to put up some recommendations that NIST talks about to secure this critical software.

Why the executive order is important for businesses

While this first publication from NIST is really targeted at federal agencies and government bodies, we know that this is going to affect businesses in the long run, as these definitions and security measures become widely adopted. So why is this critical around 75% of applications have at least one security flaw, with 24 of these being considered critical or high severity. And these can be used to gain a foothold into your organization, particularly if these applications are publicly facing. And we know from what we've seen that attackers are becoming increasingly sophisticated. In fact, they operate more like businesses and organizations themselves. A recent study found that a leaked AWS key that was intentionally put into a public GitHub repository was exploited in less than one minute by attackers. So this shows the level of sophistication that we're facing.

What is EO critical software?

NIST has a standard definition for EO-critical software:
EO-critical software is defined as any software that has, or has direct software dependencies upon one or more components, with at least one of these attributes:
- is designed to run with elevated privileges;
- or manage privileges has direct privilege privileged access to networking or computer resources;
- is designed to control access to data or operational technology;
- performs a function critical to trust;
- or performs outside of the normal boundaries with privileged access.

Now you may be wondering what all this means.
Well essentially, what they're saying is that EO-critical software is software that performs access management and plays around with trust. It's software, that if an attacker can get access to or take over, can elevate their privileges in different places, and can authenticate themselves in different networks, or other areas of the organization. It's a way that an attacker could really persist and increase an attack upon an organization.
And we're going to break apart each of these elements to talk about exactly why these elements are so important.

Protecting EO critical software

Why is protecting EO critical software important?

So let's first start with elevated privileges. The amount of damage that an attacker or a software program can do really depends on the privilege that they have. If a program runs with admin-level privileges, it can do almost anything on that system and network. While a guest account in contrast can almost do no damage.
So any software program that's running with elevated privileges is therefore a way higher risk. Because a compromise of this account means that more potential damage can be done. And this is why it needs to be considered as part of that EO-critical software.

The next component talked about having direct access to networks, or privileged access to networks.
A network can really be considered the highway to other points in your organization. So anything that has a direct link to this network, to this highway, is the perfect entry point or initial access point for an attacker to really get their footholds in more critical areas of your organization.

The third point of this was software that controls access to data or operational technology.
This really has two implications:
Firstly, it can be used by hackers to gain access to company data for exfiltration, or encryption in the case of, for instance, a ransomware attack. Or to get access to other technology in the company.
Secondly, it can be used to cripple the business by making these resources unavailable. The two biggest examples that we see in this area are ransomware, which was for example in the colonial pipeline attack earlier this year: it was a ransomware attack. And a distributed denial of service attack, so DDOS. An example of this would be late last year when the New Zealand Stock Exchange went down because of a persistent DDOS attack. No one could access or gain access to the stock exchange
Therefore you can really see that software that controls access to data or operational technologies really needs to be considered in that critical software. Because of the massive effect that it can have if an attacker can infiltrate this. The other area that was talked about by NIST is the idea of Critical Trust software. So what is critical trust software? Well, this is really kind of the gatekeeper within your organization. So this topic really deals with all the software in your company that performs a security function. If an attacker was able to compromise this, they'd really be able to render your company defenseless, or at the very least create blind spots in your company's defense that will allow them to gain access to your company's network and go undetected indefinitely. If you can authenticate yourself correctly then really the alarm bells that would go off on an intruder won't happen. The difference between someone breaking a window into your organization and walking in because they have a working key card. So this critical trust software is really the software that metaphorically can create the key cards into your organization. So again really critical that we highly protect this area.

Now the last area is really kind of like a "blanket" and "everything else that is critical" clause. It's software that operates outside of the normal trust boundaries. So this really refers to any software that's not subject to the normal trust restrictions of your company, and especially those of elevated privileges that can pose way more danger than a normal application.

What are examples of software that are considered EO-critical software?

NIST provides a table of a lot of examples that could be considered, along with the rationale behind each one. If you look at some of them we can see that it's identity credential and access management, otherwise known as ICAM services. And really these manage the authentication and the credentials that are accessing your applications. So it's at that highest level of trust.
We also have examples like operating systems or container environments that really operate outside of those controls of the normal applications, because they're providing really the basis for everything to run. Also software like web browsers: these can be standalone or embedded into other applications and these provide such things as execution environments or their own identity services.
Of course we talked a lot about network, so software that implements protocols and algorithms to control our network. And also the software that's protecting our network, so the firewalls and monitoring the network traffic. These here operate at a different level of criticality that an attack is definitely going to be after.
Other examples are remote access software that really kind of controls who controls access to network servers and other sensitive information, which we've seen obviously an increase of these as remote working has been taken up. And also the software that backs up, and stores, and even encrypts the data that we have.
These are of high value and also would be considered critical software to protect

How to protect EO critical software?

NIST goes on to explain on their website in great detail the security measures that we need to take to be able to protect these software. And this is written in a way that's quite hard to follow that has a lot of links.
So let's break these down and talk about them and what it actually means to implement these security measures?

So firstly, protect EO-critical software and EO-critical software platforms from unauthorized access and usage. Okay, so that's great. How do we actually do that?
Well, the suggestions that NIST goes on to make really fall under areas like implementing multi-factor authentication for all users and administrators.
Uniquely identify and authenticate each service attempting to access the EO-critical software or these software platforms.
We're also going to want to follow privileged access management principles for network-based administration. Some of these examples can include hardening platforms used for administration, logging all the admin sessions, and then requiring unique ids for each administrator.

Now the second security measure that NIST recommends is to protect the confidentiality, integrity, and availability of data used by an EO-critical software and EO-critical software platforms.
So one way to do this is to establish a data inventory. A data inventory is really data sets with metadata that describes their contents. We also want to have fine-grained access control for the data resources, and really enforce the principle of least privilege. The principle of least privilege means that whatever is the lowest level of privilege for a machine, a piece of software, an application, or a human to do their job, we assign them that privilege and nothing more.
Of course, we also need to encrypt our data. We need to be encrypting our data both at rest, so that means when it's stored so in a database, in a data set. And when it's in transit: when it's moving between systems. It also needs to be encrypted and we want to have good encryption, so we need to make sure that we're current with our encryption.
And then of course we also need to back up our data. But backing up our data isn't just good enough. We need to also make sure we have a plan in place of how we actually recover this data in an emergency. The faster that we can do that and the better our process is of backing up regularly, then we can move quickly on this and help protect that critical software. The third security measure that NIST is recommending is to identify, maintain EO-critical software platforms, and the software deployed to those platforms to protect the EO-critical software from exploitation. All right so what does that all mean? Basically, it means we need to know what software we're using and what software is critical.
We need to establish and maintain a software inventory of all the platforms that are running our EO-critical software. Remember way back at the start, I briefly mentioned, from this website, that this also refers to components. So it's not just good enough talking about the main critical software that we have we also need to look inside the dependencies, the direct dependencies: Do they have elevated privileges? Do they fall under critical software? So we need an up-to-date inventory of all the software that we need to consider EO-critical software.

Now on any security blog, I don't think you'll be able to get through a single article without talking about patching regularly. So again, now that we have this inventory set up we need to make sure everything's up to date. A lot of security vulnerabilities are out there just because they haven't been patched to the most recent version. So we need to have a plan in place of how to actually patch this. It's all very well saying we're going to patch regularly. But how do we actually update these software? And what is the process involved with that? Another culprit that we often see in attacks is misconfigured infrastructure, misconfigured machines, or applications. So we need to use configuration management here as well. This will really ensure the integrity of the configuration that we're using and means that we're going to be consistent with the configuration that we have, so we can set up proper procedures and policies.
The next security measure is to quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms.
I find the wording of this one quite funny because of course we want to respond quickly, of course, we want to get things back up and running. But the suggestions that they have buried within here are quite valuable.
The first suggestion is really about logging: to ensure that we're actively logging the necessary information about all the security events related to these software. So this means that we can quickly go back, we can identify the problems without active logging then we're really in the blind when a problem arises, and we don't know if the intrusion is still in the systems, if they've been handled correctly, and what other software was affected. So making sure that our critical software has fine-grained logs going through about everything that's happening

Some other obvious ones would be to ensure we have endpoint protection, and also to have ensure we have network protections around these critical software.

And of course one of the most critical areas to respond quickly to threats is human training. Having up-to-date security response teams segmented out where everyone knows what to do, and having security response drills in place so that we can respond quickly. So much of security can all be about defending and preventing attacks, we can often forget that attacks can never be 100% secure. You can never really know that an attack will never happen but what you can do is make sure that you're prepared for it. So assume an attack will take place, and make sure all your staff and all your security teams are trained appropriately to handle this.

On that note, we come to the last section of NIST which is all about humans and security. So strengthening that understanding and performance of human actions that foster the security of EO-critical software and EO-critical software platforms. Now that's almost going to be the last time that I'm going to say EO-critical software. I could repeat what I said before about making sure that all of our employees know what to do in the event of a security breach, so we can get back up and running quickly. But we also need to treat critical software differently. And the first step of treating it differently is letting the people know that are operating in this software that operate in this world that it is critical software, and it needs to be treated differently as such. This means that we need to maintain a greater vigilance of the software, of the logs, of the network traffic, of what's happening within these.
And this all comes down to training the staff that are using it. This doesn't mean training a dedicated security team, this also means training the people that are using the software every day: the system administrators, even the HR department, the onboarding process. Depending on how large your organization is, it's going to depend on who needs to be trained on the importance of this software.

That brings us to the end of the security measures of this, and nearing the end of the video and security implementations like this can be pretty overwhelming. There's a lot to consider and especially when your focus is on maintaining and operating your organization or your company, it can be hard to spend resources in this specific area or hard to convince management to spend resources in this specific area.
And that's why having an executive order like this is actually quite important. And while this really affects government organizations, it can be used as a tool to leverage the importance of this, and really illustrate to organizational owners, directors, and managers, the importance of making sure we have critical software, that our critical software is secure. And implementing these steps earlier in the process is always so much easier
So the best approach to security is to look at the highest standard that you can meet. Take what's applicable to you at your organizational side, and implement it in place early.
It not only will reduce the risk of you having an infiltration or an attack or a breach because someone was gaining access to your critical software, but it also means that when the time comes that you need to implement this, the hard process will already be done and your staff will already be aware of the problem.

Conclusion on EO critical software

So that's it for this video. I hope you found it somewhat useful and we're able to break down some of the technical terms in this, to make it understandable what we need to do to protect our EO-critical software and that is going to be the last time I say EO-critical software in this video. So thanks for watching guys.
I'm MacKenzie, you can always reach out to me on Twitter @advocatemac and send me any questions that you might have: I'm here to help.

‍