Cyber threats on enterprise information are growing at an exponential rate. Federal government IT systems are at risk, from email servers to mobile phones to system networks. Security remediation tactics are growing in complexity, and these efforts require persistent attention.
At Blue Mountain Data Systems, we define continuous monitoring as real-time security monitoring rather than the periodic reviews conducted weekly or monthly for compliance purposes.
When providing security support for our clients, we have activities that we look at and test periodically.
Examples: Consider the reports and logs stored by the firewall, the border router, internal routers and switches. A review of these items are done periodically. Something that happened in the past can be discovered. But, that’s really not good enough. The idea of continuous monitoring is to use tools that provide automated methods to alert you.
Tool 1: McAfee Vulnerability Manager. This tool, used for continuous monitoring, assesses the entire network for vulnerabilities on devices. A device could be a workstation, a server, a switch, a router, or an appliance. It checks McAfee on a daily basis (just like your antivirus software), and it picks up new signatures if anything is available. And so it keeps its own database of the potential vulnerabilities as well as fixes to mitigate.
Tool 2: Tenable Nessus Vulnerability Scanner. We use this as our primary tool for external vulnerability testing. It can also be used for penetration tests. One of our techs will take a notebook home to run the test, first clearing it with development and operations staff as well as management. A maintenance window is set in case something breaks. This tool attempts to penetrate the network from an external I.P. address. This process helps you find things that need to be patched or updated.
Tool 3: SAINT Vulnerability Scanner. This tool is used as a secondary external vulnerability scanner. It can also be used for penetration testing as well as internal vulnerability assessments.
Tool 4: Tivoli Endpoint Manager. The tool captures configuration compliance, IT asset inventory (server and workstations only), and vulnerabilities. The tool is also capable of deploying software updates (i.e., patches) and discovering assets via Nmap.
Resource: Hire an outside firm. Hire an outside firm like Cisco or another contractor to do a penetration test. They conduct penetration testing both externally and internally again to see if there are generic administrative passwords being used, or system level passwords that are not complex. This determines whether they can be hacked. Then we run the tools against servers and workstations—obviously, we’re not doing all devices. We perform the tests on a random sample of devices.
Resource: Microsoft & NIST Security Checklists
One part of the security posture performed in the Federal Government is that when you configure a new device with an operating system, there are a series of security checklists you use.
Microsoft and NIST produce security configuration checklists. Note that NIST also endorses checklists that are published by other vendors if they don’t have checklists themselves.
Other parties involved with NIST are DISA, the Defense Information Systems Agency, and the CIS, Center for Internet Security.
When we provide IT security support, we are responsible for picking a checklist, then reporting on the one we’ve selected. Then, Tivoli Endpoint Manager will test it and report back thousands of items that don’t comply. Again, in most cases, the thousands of items that it reports back are false positives.
When Testing, What is a False Positive Compared to a False Negative?
A false positive is something that a tool reports as a vulnerability when it really isn’t. A false negative is when a tool (e.g., IDS, Vulnerability Scanner) does not report an intrusion that occurred or vulnerability that exists.
You also have a whole other bucket of things that are reported as positive where the Federal Agency is willing to accept the risk.
When the Federal Agency is willing to accept the risk, what does that mean?
It might mean that the items that are reported are of little significance, yet it might require many months to fix and put it into compliance. By the time this occurs, there might be another software upgrade and it wouldn’t be worth it. It might be an item that’s internal to the Agency and otherwise fully protected by compensating controls. If we were to mitigate that vulnerability, it could break production applications.
Service accounts represent an example of this, as many products have simple passwords on internal accounts to the software. That’s a common item that surfaces during vulnerability monitoring. The problem with changing those passwords is that each of these devices talks to one another. If you reassign it, it’s going to break things. Notwithstanding this, access to service accounts may, in some cases, permit elevation of access to other devices. In many cases, there may not be a complete enough test environment to go through each one of these services accounts to change them to use complex passwords. A risk assessment should be performed on the various types of service accounts, assessing the level of risk against potential elevation of privileges, and act accordingly.
