If you are a reader of certain age, you probably remember the great Britney Spears vs Christina Aguilera debate of late 1999 to early 2000. For the record, I have always been a Christina fan. Between the two, especially in the early days, I thought that Britney was the better entertainer; she definitely put on an amazing show during her concerts. Christina’s voice, though. Her range. It wasn’t even close for me. I always considered her to be the better vocalist. I had this discussion with a co-worker back in the day and she lamented that Christina was wasting her voice on pop music when she should be singing opera.
What does this have to do with Cybersecurity. Nothing. It just seemed like a pleasant way to get back to basics, and and a long road to take us to cyber hygiene.
The past few days I have been looking at cyber hygiene and noticed something. While everyone seems to be talking about it. No one is talking about the same thing. Everyone has a different opinion of what you should do for cyber hygiene, a different checklist, even different services of what they offer to do for you. If you Google cyber hygiene you will get everything from 11 Rules, Three Steps, maybe even 10 Tips. So, this seemed the perfect topic or some pontification fuel.
About the only thing that everyone can agree on is cyber hygiene are those basic or fundamental steps that you take to keep your network or information system from decaying. After that, everyone differs. Systems change over time, and our goal is to keep our systems safe over the long term. I liken this to ATO + six months or longer. What does your system look like six months after you have received your ATO. How about a year or even 18 months. With personal hygiene as the reference point, what are those things that we do on a re-occurring basis to stay healthy?
As X-Tina says, let’s go back to basics. Let’s look at cyber hygiene like we would personal hygiene. What are those things that we do to stay healthy, do not get sick. Host Based Firewalls, Boundary Protection, Anti-Virus Definitions, and Patching. Then let’s look at how you can tell you are getting sick. How do you know you don’t feel right, do you have a fever, congestion, what are your symptoms. Monitor your network management tools, and your self-diagnostics. Finally, I would look at what happens when you get sick. Your incident response plan, policies and procedures.
Don’t Get Sick
Windows and Red Hat both have host based firewalls available, use them. Does it make your system more complicated, maybe. Can enabling the built-in firewall make a difference, yes. I’m not naïve enough to think that either product is the end all, be all of cyber security applications. I’m also not going to debate which product is better. Look at it this way. When you are insulating your home, or re-insulating for that matter. Do you know what layer of insulation is the most important? The first one. Having something is better than having nothing. Make sure the firewall is turned on.
Let’s take this a step farther. Times are changing and we are probably well past the point that we need to look at some Boundary Protection for our interconnected networks. I almost said larger systems there. I’m not going to lie. Most systems tailor out SC-7. It is a level of complexity and cost that can be hard to justify. Frankly, if we are looking at ourselves we have folks running operating systems, applications and features that they are still trying to figure out (I’m looking at you Linux and Splunk). How much sense does it make to drop a firewall and pair of screening routers into our architecture when there is limited ability to configure and maintain them, let alone monitor and respond to alerts. That is why SC-7 gets tailored out most times. I get it. Our portion of the Navy is very stove piped; we do not have a lot of interconnected systems right now. That is starting to change. Everyone wants to move to the cloud or leverage cloud services someplace. The days of trusting a remote client are coming to an end. Life is changing. The environment we are operating in is changing. The risk that we are accepting is changing. We need to change with it. Boundary protection devices may not be required for every network. What I would ask you to do is not automatically tailor out the requirement. Look at it objectively.
In the JSIG, our requirement is to update anti-virus or malware definitions at least or at a minimum of every 30 days. Yep. I went there. The minimum is just that, the minimum. Are there places or cases when you should shrink that threshold down. For sure. I would consider the number of network interconnections the system has. The amount of media that comes onto/off of the system. In short, I would look at the minimum of 30 days and see what could be realistically supported. Obviously, having a centralized tool or application to manage your malware clients makes this easier. At the end of it all, do you really want the minimum to become your standard?
You can call it patching. You can call it flaw remediation. I call it the bane of our existence. I have a Hate/Hate relationship with security patching. It is probably the flossing our teeth of cyber hygiene. It may not cause an issue if you miss flossing your teeth at night, but you are gonna get a cavity. You’ll also hear it from your dentist at your semi-annual visit. It seems like just getting sites/systems to apply security patches in a consistent manner is a challenge.
The JSIG requires that security patching be accomplished within 30 days of release by the vendor. I believe that is what we should strive for. I also believe that we should execute Risk Management when we create our patching plans. What do I mean. Well for starters, if there are news articles about a patch or security vulnerability 30 days is probably too long. Pick whatever news outlet or method you choose to stay current with the world of cyber security. If it makes the headlines, chances are we are already too late. By the same token, I would not wait for your next 30 day patch cycle before applying the patch. I would map the patch management process to patch criticality. Set a different threshold for each. Maybe critical patches are to be deployed in a week; informational or low are 30 or even 45 days. The point of this portion of cyber hygiene is to not get sick. How long can you reasonably go until that patch is applied?
When you are creating your patch management process, we should have a drop everything and patch it now category. We should also look at ways to mitigate the risk until we confirm that the vulnerability has been patched. If flossing and mouthwash go hand in hand, so should verifying that we have corrected the vulnerabilities. We cannot rely on hitting the I believe button on our application that the security update has been applied everywhere and applied correctly. I’ll will resist the urge to hop back onto my soap box here. You should already know my thoughts on this. Keep metrics for your patching.
How Are You Feeling?
How do you know if you are coming down with something? Do you have a cough, sore throat, maybe even have a fever? Illnesses have symptoms. Part of our cyber hygiene should be making sure we have a way to identify symptoms in our information systems as well. Your network management tools are key to figuring out what is going on. Make sure that they are up to date. Like that ex that broke your heart in high school, they will lie to you every chance they get.
Periodically, check all of your network management tools (malware, audit reduction, patching, active directory, etc.) and compare their list of clients to a known accurate list of clients. Make sure everyone is on the same sheet of music. You do have a list of what should be on your network, right? Even if you know what should be on your network, when was the last time you checked what was actually on your network? Run a network enumeration tool like NMAP and know for sure. Every device, every IP is just something that is going to let you down.
Making sure that you know what is on your network is a good place to start. Test your applications and tools to make sure they are telling you what you think they are telling you. Use something like EICAR to see how your AV client responds and alerts when it detects malware. Try and send it as an attachment in an e-mail. What happens. Go through your audit reduction tool and actively look for events. See how they are reported. Make notes, keep copies or screen shots for your Privileged User Guide. It’s going to come in handy.
So, You Got Sick
From a cyber hygiene stand point, we have looked at ways to not get sick (Host Based Firewalls, Boundary Protection, Anti-Virus Definitions, and Patching). We have also looked at the ways you tell if you are getting sick and double checking your network management tools and understanding what is actually on your network. Now, take a moment and figure out what happens when you get sick.
The time to identify that your incident response plan is out of date is not when you are executing your incident response plan. I’m just saying. That is probably the wrong time to identify that you don’t have an incident response plan.
There are a lot of places that you can look for guidance on what should be in an Incident Response Plan (IRP). NIST SP 800-61 is the Computer Security Incident Handling Guide. I would wager there is reference there you could use. Just keep in mind what we have previously said about NIST. They are writing policy with the Internet in mind. They do not have our community at the forefront of their thought. The JSIG however, was written with our community in mind.
Having a policy that checks the blocks is only the tip of this particular iceberg. Do your users know what to do if your AV product flashes an alert on their desktop? Do they even know what the alerts look like? When was the last time you practiced your response, or better yet have you ever practiced your response? When you look at the JSIG (fine the NIST 800-53 for you party poopers), there is a reason that the actual requirement for what is in your Incident Response Plan is IR-8. There are six other controls to keep in mind about your incident response before you even get to writing it down.
When I was a SysAdmin, we had plans for a data spill via e-mail, malware on a file server, etc. Each of these we broke up into steps and put them onto laminated cards. This way, when we had a data spill (for example) whomever was in charge of the Network Control Center could delegate tasks (hand out cards) to individuals and everyone knew what they were supposed to do. If you were handed the card and told to make the notifications guess what. The POCs, phone numbers, and any reporting requirements were there on the laminated card. All you had to do was follow the steps. When you were done, you returned the card and whomever was running the response also knew what steps had been taken. If the step in the process was to isolate an Exchange server. The steps, and what user accounts to use was identified. Cross them off with a dry erase and you were good to go.
Should this be part of every IRP, probably not. Could it be part of yours, maybe. Now, I know that you are one of those high speed, low drag ISSMs that has everything squared away. This idea is old hat to you, because you have already done it. For that, I congratulate you. Way to be on the ball. The question that I would ask, is when was the last time you checked your POC information? People move and phone numbers change. Are the steps you take still accurate? If you have deployed a new application or server are your plans still the same. How about you have a new SysAdmin, do they know what to do? Cyber hygiene is not a one and done. When your dentist asks you the last time you flossed your teeth, don’t respond with “you don’t know, you were there”. This is about ATO + 180 days. What has changed and has your IRP kept up with those changes.
Hopefully, by this point you have seen it is important to brush your teeth every day and wash your hands. Ok. You should have seen the importance of both of these items and other personal hygiene tasks well before now. While I will not say that what we have discussed so far is an all inclusive list. I hope it has given you a starting point to ponder those things to focus on to improve your cyber hygiene.
What did I miss? Share your thoughts and tell me where I went wrong.
It Depends 