No, You’re a Tool.
Information Systems have grown too large and complicated to even imagine trying to manage them without using automated tools of some kind. It’s not going to happen. Since we are all stuck in the same boat, let’s take some time to talk about ways to make our lives easier. So, let’s level set everyone first. I’m talking about things like: Audit Reduction Tool (ART) (AU-7), centralized malware or anti-virus tool (SI-3), end point security to lock down your ports and drives (AC-6(1)), patch management tools (SI-2) and Gucci network monitoring or hardware and software inventory tools (CM-6, CM-8, CM-11). What. You were surprised to see JSIG references for these applications.
You don’t have to be crazy to do this, but it helps.
Bob Ross
The best piece of advice that I can give you, is to get your policy figured out first then find the application you are going to use to implement it. I’ll say it. It will get ignored. Write your policy. The IT solution should implement the policy. The policy should not implement the IT solution.
The IT solution should implement the policy. The policy should not depend on the IT solution.
-I put it here so you can find it easier
Why is this important? Why am I harping on this? Easy. If you’re surprised that the JSIG has different technical settings for things such as your password policy from what the DISA STIG suggests, raise your hand. You shouldn’t be. The STIG, 800-53, the CNSSI 1253, the JSIG are all designed for different environments. They all apply in different cases. Using CNSSI 1253 or STIG values on your JSIG system is wrong. Just like using JSIG defined values in a NIST 800-53 system.
Your policy is the foundation for your system. You have to get it right first. The NIST 800-53, CNSSI 1253 and the JSIG have different organizational defined values for some controls. This doesn’t mean that you blindly follow the STIG or the SCAP. You follow the policy document that will get you an ATO. If you throw the DISA STIG into the mix, you have four different sources for what a setting should be. From four completely different organizations. Only one of these organizations will give you an ATO. That is who you should be following.
Take a Step 0
This is fundamental. You will fail if you do not have your policy figured out first. It may not be a brilliant ball of flame that is seen from miles around. It may be a slow, painful, agonizing death. Let’s take flaw remediation or patching for example. Think through the following aspects of your patch management policy. How do we find out about new patches? What applications or operating systems will be patched? Where will the patches come from? How or where are patches tested? How often will they be patched? What timeframe will we have to implement patches based on criticality? What metrics will you keep to establish how long it takes to deploy a patch of a given criticality? How will we verify that patches have been correctly applied?
I’m sure that you could come up with more questions to ask before you start reviewing pamphlets and user reviews. The key point is take some time to figure out what you are doing. Draft your policy to answer all of those questions first. Figure out the policy that you are trying to implement and why.
Understand What You Want
Here is a part that everyone messes up the first inspection around. Ok, sometimes the first couple of inspections if I’m being honest. Do. Not. Trust. The. Tool. If the pamphlet or your SysAdmin tells you that the agent will automagically install on every system. Do not trust it. Remember what we just said. Go back to your policy. For example. If it is supposed to manage the anti-virus client on all of the Windows systems on your network. How many Windows systems is that, by the way? How do you check that it has been installed on all of the Windows systems? Do not trust that the agent will be deployed by Active Directory. Verify it for yourself. This will be critical at the timeframe that I call ATO+180 days. Meaning six months after you deploy your new application or receive your ATO. After you upgrade/replace your workstations. How are you going back and checking that all of your systems have the agent installed? How are you checking that dead systems have been removed from the application?
Your application only knows what it knows about your network. Active Directory doesn’t really care about your Red Hat workstations. If you have them on your network, you better care about them. Things break. All the time. If they didn’t we wouldn’t need SysAdmins. Your application knows about it’s portion of the network. You should be wise about the rest.
Huh! I should think that you Jedi would have more respect for the difference between knowledge and… heh heh heh… wisdom.
-Dexster Jettster
Fortunately, this is easy to do. It can also be sexy. I use something like the below on every inspection or security assessment I perform. Add a column for each of the network or automated tools that you use. Add a row for what type of devices makes sense. If you manage it with an application, I would add it.
| Known List | Active Directory | Patch Management | Audit Reduction Tool | End Point Security | NESSUS Enumeration | |
| Windows Workstations | ||||||
| Windows Servers | ||||||
| Linux Systems | ||||||
| Switches/Routers |
So easy even a DAO can do it
All you have to do is write the number in the box. Open up AD and write down the total number of workstations and servers that it knows about. Open up your ART, AV, whatever monitoring tool you use. Now that you are done, compare the results to the truth. You know what is on your network, right? Do not let yourself or the SysAdmin talk yourself into results. Do not try to make sense of the results while you are filling out the table. Wait until the end. Record what the tool knows about the network. If there are 30 workstations on your network; AD has 45 listed because 15 are dead boxes that have been replaced. Guess what number should be in that box, 45. Don’t worry about having clean up work to do. Here’s a hint; you’re going to have work to do. Clean it up. Better yet, update the procedures/process that you have for deploying new workstations to ensure the old machines are removed.
There will be some discrepancies. Switches and routers don’t show up in Active Directory and are probably not anti-virus clients. Know what the answer should be and then see if your applications are correct.
This table tells me so much about how well a Cybersecurity staff is performing. If it’s all over the place, I have a high degree of confidence that they do not have a grasp of their network. If it’s tight, I’m confident that they’re on it. If it’s perfect, they’re brown nosing me and cleaned it up last week before their inspection. The most revealing is when the ISSO and SysAdmins start arguing over it.
Bring Sexy Back
You like that don’t you. It’s OK to admit it. You’ve seen easy, now you’re wondering about sexy. Here’s how sexy works. All of your network management tools should be able to export a list of clients into either a CSV format or MS Excel. If not, something you can get to either of those formats, easily. The data may not be clean, but the only thing you are after is the list of clients and the application.
Take these files and import them as tables into MS Access. Following me so far. Get the clients that each of your applications knows about, and whatever your true listing is. Access has a wizard that will help you build what is called an Unmatched Query. Meaning. Access will sort through your lists and tell you which of the one is not found in the other. So, you can quickly compare your let’s say Hardware listing to your ART and know which clients do not have the Splunk agent installed. Or, which systems are still showing up in Solarwinds that have been taken out of service.
Bam!
-Emeril Lagasse
Don’t Trust Them
If you do not trust your network management applications to install correctly, you absolutely should not trust anything they tell you. Until you test them. And test them repeatedly. If you are relying on an end point security tool to keep users from plugging USB drives into your network, do not just hope you set it up right. Get some test media and check. Verify that it not only works correctly, but it alerts and integrates with your ART right. Regardless of the tool, there is one thing that you can do to make sure that you understand the tool and what it is doing. Test. Test the ever living snot out of it.
The only way you get assurance is through testing.
-CISSP Instructor whose name I cannot remember. Great instructor, though. Seriously
If you’re using USB Detect to identify thumb drive usage; then you better have a stable of USB drives that you can test with. Some drives that are authorized for use. Some that are not. When an unauthorized device is inserted, what happens? What alerts are generated? Does an event hit your audit logs? Every possible manner of testing you can think of, do it. What is better than just testing your product? Keep a copy of the results. You should have a Privileged User Guide (PUG). Put a screenshot of the results in your PUG. That way you know what an anomaly looks like.
If you have an anti-virus suite test it using the EICAR test string. No. Do your own Google. I gave you two freebies already, Easy and Sexy. This one you have to do on your own. Do not assume how the system will react when it detects malware; find out. Better to find out when you test it that the event forwarding isn’t configured correctly than during an inspection. Worse, a security incident. What does the dashboard show when pick a product detects malware? Find out.
ConMon Job
You do understand that verifying your network tools is a critical part of Continuous Monitoring right? You are supposed to be checking that your controls implementations are still effective and valid for your environment.
The objective of the continuous monitoring program is to determine if the set of deployed security controls continue to be effective over time in light of the inevitable changes that occur to the system and/or its operational environment.
JSIG Step 6, Monitor
Honestly. I don’t make this up. Systems and organizations change over time. Life happens. The way you implement the controls should change as well. Do not wait for your ATO to expire to make changes. The important nugget to keep in mind here is that you should be periodically checking that your tools and applications are still working like they should. When you changed your service account password annually, double check that the application still works. Go through a big migration or deploy a bunch of new workstations, double check that your client list is still accurate. Getting ready for an inspection, take a moment and make sure your applications are ship shape and squared away.
No. I’m, I’m simply saying that life, uh… finds a way.
-Ian Malcom
Paradise by the Dashboard Status
If only there was a quick and easy way to check on the status of your network. If only. Dashboard can give you a quick look at what is going on in your network. Only if you use them. Remember. You are in charge. Make your tools work for you. Get familiar with your dashboards and what normal looks like. Please do not let the first time you’ve ever seen the dash board be during an inspection. If your SCA or DAO is asking about the big red checkmark, that is the wrong time for you to notice it. I’ve done it before and I’ll do it again. But if I’m troubleshooting your network and finding out what is wrong with your network clients, I’m not doing it to prove how smart I am. I’m doing it to show you how simple it is. An inspection is the wrong time to find out a workstation has AV definitions are six months out of date.
Test your system and see what your dashboards look like when something is wrong. Better yet. Take a screen shot and add it to your Privileged User Guide, your brain book, whatever it is you call it. Dig into your dashboards and get comfortable. Configure the alerts. Give it a week and then adjust them. Trust me. You’re not going to get the dashboard or the alerts right the first time. Build it. Live it. Tweak it. It’s OK. Remember, this application is here to make your life easier; give you time back in your day. Tweak it so that it does.
Parting Shots
I get asked the question all the time. Which tool/application would I recommend. I always dodge it. For a couple of reasons. First, just because I like a tool or a way of doing this, pretty much means that you won’t. Secondly, if I tell you to use an application, you buy it, and it’s a steaming pile of failure, who’s fault is it? Yeah, I’ll get blamed. Trust me. I have plenty of other things to get blamed for, I don’t need to add your failure to deploy and use an application to the list.
Here’s a secret. Even though the JSIG is a very specific, very technical document there are still 1/2″ margins on every page. You have room, you have space to find your own way before you fall off the page and get hurt. Work with you SCA, your DAO and navigate those margins. Depending on what’s going on, you may have larger or smaller margins to navigate. That’s OK. Talk with them. This is your system. Your network. Make the tools work for you.
Every network tool you are going to find has one thing in common. It doesn’t matter who the vendor is or what they do. They all suck. They’re not made with your system in mind. They’re designed for use in some fictional network that isn’t yours. They suck. The best thing that you can do is keep that in mind
It Depends 