NIST Overvew: Detect

In order to foster trust in our work Pythia Cyber uses the Cyber Security Framework (CSF) put out by the National Institute of Standards & Technology (NIST) when designing and implementing Cyber Security Programs. We are guided by the NIST CSF if those programs are the modest first steps of new or small organizations, or if those programs are formal, rigorous programs for mature, mid-sized organizations, or anywhere in between.

The NIST CSF mantra is simple: Identify, Protect, Detect, Respond, Recover. But this overview is also very abstract. So this blog post is one of a series to make these concepts a bit more concrete. There will be one blog post for each "pillar" as NIST calls them. This blog post is about Detect.

Detect is the step no one outside of System Administration ever thinks about. The Sys Admins live and breathe Detect, so this blog post is not for them, they don't need it. This blog post is for those who work with them, or who manage them, or who manage their managers.

As mentioned in the Protect blog post, your organization has a Must Protect Now list of cyber assets, whether or not this list is explicit. There are cyber assets your organization has which going to be protected, as best you can, as soon as possible (or is being protected already).

Protect is the first step in a never-ending process. Protect is analogous to your castle walls: you need the protection those walls provide, but you also need sentries to walk those walls and make sure that nothing bad is happening (or about to happen). You need those sentries to be there every hour of every day. There can be no vacation, no sick days, no missing work for bad weather.

This is what the Detect step is like. The Protect step built the walls. Now someone has to guard those walls. As a Sys Admin, you review the logs. You look for the abnormal. The most expensive resource you have is human attention, so you need to be a little creative in order to avoid wasting it in this step. You need to draw people's attention to the abnormal and the unexpected. The abnormal are events that do not usually occur, such as a string of failed login attempts: people rarely need more than two tries to log in. The unexpected are events that you cannot imagine happening under normal usage, such as someone copying your entire database off of your network outside of your normal backup-and-restore procedures.

The Detect step lacks glamour. People usually only notice you doing it when you screw it up. Like dusting or taking out the trash, you need to do it and you need to do it faithfully, but you are unlikely to get much in the way of positive feedback and there is the ever-present risk of negative feedback.

There are two ways that those of you who are not Sys Admins can help out: first, try to be supportive when your Sys Admins need to perform some task during business hours. Yes, this is a pain in the neck for you, but understand that we sometimes have no choice and you probably really want us to prevent whatever it is that we are preventing. Second, try not to generate abnormal or unexpected events just out of laziness: don't lend your credentials to coworkers, don't run software as a favor to coworkers, don't send secret information (credentials, login instructions, etc) in external email and for God's sake please stop writing your passwords on yellow sticky notes that you "hide" in a desk drawer.

This is post describes pillar 3 of 5. Here links to the other posts: [1 2 3 4 5]