2.6. The Reporting Mechanism
When it comes to technology, I can't tell you how many times I've heard "Yes, it's a great solution, but the reporting stinks...." Well, the same can apply to NAC/NAP solutions. So, why is reporting important to NAC solutions? It's important for the following reasons:
It is important to understand the current security state of devices, so that intelligent policy-related decisions can be made.
A NAC/NAP solution can help significantly with internal security audits.
High-quality reporting can assist in proving compliance with various regulations, such as the Sarbanes-Oxley Act (SOX), the Health Insurance Portability and Accountability Act (HIPAA), and so on.
Reporting is as much about information gathering as it is about presentation. Having a ton of information in a hard-to-read format doesn't necessarily help out organizations. As with any reporting, it is important that the breadth of information being covered be vast and useful, while its presentation be easy to use and understand.
2.6.1. Knowing the Current State of Devices
One of the most important steps in devising a strategy is knowing what you're up against. This helps in the planning stage, and also helps enterprises make educated decisions on their actions and policies. For example, realizing that a number of computers currently have LimeWire installed would be a good reason to implement a policy that kills that application. The logical way you're going to know if systems have this installed is by looking at the reporting.
When it comes to understanding the current state of your devices, two categories are commonly used: the attributes the system currently has and the items that are missing and should be on the system. Following are some current system attribute examples:
The operating system and version (such as Windows XP SP2)
How much room is left on the drive space
The username of the account logged into the system
Following are some missing system attribute examples:
The system needs Microsoft Patch MS03-023.
Adobe Reader is in need of a critical security hotfix.
The Java application is in need of a critical security hotfix.
The instant messaging application is in need of a critical security hotfix.
Updated antivirus definition signatures are available.
The system allows NULL sessions.
The system uses LM hashes to store passwords.
There isn't an encryption solution on the system.
You may find it difficult to find a NAC/NAP solution that is able to provide reporting on these examples. If you look at something like SMS, it can provide a lot of the information from the first list, and it could be used as a companion to a NAC/NAP solution. SMS may not be an official part of a particular NAC/NAP solution, but it could help with information gathering. It's important for you to know how you will handle that task.
NOTE
Real-time reporting data should be collected from all devices, regardless of their location, and should not be dependent upon mobile devices being physically on the LAN or connected to the LAN via a remote access solution.
In my mind, a really good NAC/NAP solution will also show information regarding what is missing on the machine. Microsoft Patch Tuesday patches, virus definition updates, hot fixes to third-party applications, vulnerable configurations, and so on, need to all be communicated. The "Real Examples from the Field" sidebar shows why this is important.
REAL EXAMPLES FROM THE FIELDAbout a year ago, I was working with a very well-known company in Chicago. I'm sure that many of you have used their products, and you would likely know their name if I told you, but I won't for security reasons. We were working with this company to get them to realize that it was very likely that their mobile devices were not receiving all of the necessary updates and patches when they were mobile. From our own experience, we knew this to be the case. As in a lot of companies, mobile devices only received patches and antivirus updates when the machines physically came back to the LAN. In that type of scenario, we always see those mobile devices missing patches and updates. It never fails with that topology. This particular company had a bunch of really good guys working for it, and they were very nice and capable people. They just didn't think that they had a problem with patching mobile devices. Their internal system always did a good job and that sufficed for them. After pushing them for quite some time, they finally told us to stop talking about the patching of mobile devices. They felt they had it covered and we were starting to annoy them. Rather than give up, we made them a deal. We would run a vulnerability assessment against a sampling of their mobile systems and show the objective and factual reporting data. If that data showed that they had it covered, we would buy them a lunch (we would have bought lunch anyway; they are the customer). If they didn't have it covered, then they would talk to us further about how we could help them. So, I ran my analysis against a number of their mobile systems. These were the same mobile systems that they insisted were covered with their LAN-based patching system. The data came back and we found the following:
Clearly, the systems were not in an ideal state. This was an eye-opener for them. Particularly, they noticed the point about some missing patches being new and some of them being old. What did that mean? Missing new patches is representative of enterprises having difficulty with getting patches disseminated in a timely manner. If a machine is mobile and not on the LAN, and the only way to get a patch is to be on the LAN, a long time is going to pass before that system gets the patch. This is very bad, because the mobile machines are the ones that need the most protection. What really shocked them were the old patches that weren't installed. In particular, they were missing the patch that took care of the GDI+DLL issue from a few years ago. (There was a vulnerability where the simple act of viewing a malicious graphic file could allow a hacker to completely exploit a system.) They knew they had pushed out this patch years ago and certainly remembered this well-known vulnerability. What happened is that they did push out the patch. The machines did receive it, and they were protected. At some point afterward, however, they also pushed out Microsoft Office and Visio applications and updates, which overwrote the fix that the patch had implemented. The systems were no longer protected. This really opened their eyes. I'm pleased to say that they did realize our original point that they had an issue with their mobile devices. Without us being able to prove it with reporting, they wouldn't have believed us. This is also a really good example of the value of being able to report on what is missing on systems. The fact that these devices were missing the Critical patches and antivirus updates had a direct impact on the company's security strategy and policies. It all came down to reporting capability. |
2.6.2. Helping with Audits and Compliance Standards
It seems that no security book today would be complete without mentioning SOX, HIPAA, Gramm Leach Biley (GLB), and so on. While I say that in jest, there is good reason for it. Enterprises are being forced to take adequate steps to protect their data, and are being held accountable if they do not.
Let's take a quick look at HIPAA. Everyone always states how HIPAA and the other regulations are quite vague and do not give specific details on exactly what needs to be done. I don't disagree with that, although actually reading the HIPAA will give you a fairly good understanding of what it is attempting to accomplish. Here's the part of HIPAA to which I pay particular attention:
(2) SAFEGUARDS. — Each person described in section 1172(a) who maintains or transmits health information shall maintain reasonable and appropriate administrative, technical, and physical safeguards —
to ensure the integrity and confidentiality of the information;
to protect against any reasonably anticipated —
threats or hazards to the security or integrity of the information; and
unauthorized uses or disclosures of the information; and
otherwise to ensure compliance with this part by the officers and employees of such person.
With HIPAA and other regulations, there is the area of accountability. Companies and individuals need to sign off that the adequate steps and protections are in place. In some cases, high-ranking individuals are actually signing their personal guarantee that they are abiding with these regulations. With that in mind, wouldn't it make sense to be able to prove that those steps were taking place?
This is exactly where good reporting can help. Rather than sign off and hope that the right things are put into place, it's certainly better to run a report and be able to prove it. Consider the following two scenarios:
Scenario 1 — "I am the CIO of a company that must abide by various regulations and my personal signature holds me personally accountable to these regulations. Although I don't have any insight into the state of my mobile devices while they are mobile, and I have no means to report on the security posture of devices accessing my LAN, my 'gut feeling' is that we are covered, so I'll sign my name."
Scenario 2 — "I am the CIO of a company that must abide by various regulations and my personal signature holds me personally accountable to these regulations. I implemented a NAC solution that controls all devices that can access my LAN and also controls my mobile devices when they are mobile, since these devices also contain data that requires protection under these regulations. I have reviewed a number of reports from these systems that objectively state that only devices that meet our internal standards, which mesh with the regulations to which we are bound, have been granted access to our LAN. The report also clearly shows that mobile devices that are noncompliant are restricted from remotely accessing the network until they are compliant. The report shows that all devices either currently meet the standards we have set forth, are in the active process of meeting those standards and are currently restricted, or have been prohibited from accessing our LAN and the data that is intended to be protected by the regulations."
Without question, it would be advantageous to be the CIO in the second scenario. Being able to prove compliance covers him and he signs his name and accepts accountability based on facts.
Just as good reporting can help with compliance regulations, it can help with internal audits. Think about the list mentioned above that shows a bunch of information about what is on a system and what a system is missing. This is invaluable information for internal security audits.
2.6.3. Reports Help Find the Problem
In my job, I see companies that are totally squared away, some that are in bad shape, and many who are right in the middle. The really squared away companies are quite rare; I see about one to three per year. So, what's the difference between the totally squared away companies and the others? I find that it's usually one of two things:
Teams aren't given the appropriate time, money, or resources to implement the technologies that need to be put into place.
There is apathy and ignorance in various ranks of the organization that do not feel the technologies need to be put into place, or they just don't want to do it.
While working in a consulting capacity, I see these points every day. A big part of what any successful security vendor will do is to address the first point directly. That's how you make a sale. You show them how the solution will benefit them, how they actually can afford it, and how they won't need to hire more people to have it implemented. If you're real good, you show them how the solution will actually free up resources to focus on core company objectives.
The second point drives everyone nuts. Sometimes people just don't get it, and they don't realize they have a problem. Other times, they know they have a problem but simply won't do anything about it. It could be plain laziness; they're getting ready to retire or move to another department; or they are afraid that a project would fail and they would be held accountable.
A tool that comes to the rescue in both of these cases is objective and factual reporting. In the first scenario, reporting helps by enabling the hands-on personnel to show the higher-ups that they have a problem, and that it needs to be addressed. They can then objectively show how inaction can be more costly than providing the necessary time, money, and resources to implement the appropriate solutions. I have personally used reporting for this method, and the results have been fantastic. You really can't argue with facts. Many times, we are able to make one of the prospect's employees look like a hero by showing the need.
Reporting is also very useful when it comes to apathy and ignorance. It's not uncommon for me to run into a scenario where I know a company needs to implement a particular technology, and not doing so puts it at significant risk. For whatever reason, someone isn't doing his or her job and allowing the project to move forward. That's where taking the report and shooting it up the chain of command comes in handy. Showing a director, VP, or C-level executive that the teams beneath them don't have things covered does come in handy. Unfortunately, it's a quick way to lose cooperation and ties to the person who isn't doing his or her job. Sometimes, however, individual personnel aren't doing their jobs, and objective reporting can prove it and fix the problem.