IT Compliance Accountability
How well should we do our job? How well should we have to? Where is the line between doing what is right, doing what we should (what we feel like), and what are skillset allows? Many IT departments find themselves just trying to keep their heads above water, let alone actually do their job in the manner they are employed to do. What is the driving factor that determines whether or not we do our job properly?
In the 16+ years I’ve been in the IT field I have found one consistent factor in IT compliance.
People do not do what you expect, rather they do what you inspect.
Does not matter how much you pay someone or how much history you have. Everyone, without exception, must be held accountable through compliance inspection. This is not shocking revelatory information, but what I’ve also found consistently is that many compliance programs themselves are suffering from the same conditions of the networks they are responsible to hold accountable.
What exactly are we discussing? Networks and systems that do not meet the written posture and policy of their employers. The world of Information Technology is a complex one, and it can be tough for a Manager to know whether or not their technicians are properly configuring, patching, securing, and life-cycling within their areas of responsibility. So we have embraced actions to ensure everyone is within compliance and charged the Information Assurance (IA) community with ensuring we meet the expectations of our organizational directives.
Now how does the IA community know if everyone is doing their job or not? We’re going to look at three areas that contribute to the overall problem. Skillset, Systematic Neglect, and Lack of Buy-In.
To highlight this issue I would like to break this down into four categories of compliance approach (all with automated tools):
IT Experts (IT-E)
Mid-Level Experts (ML-E)
IA Technician (IA-T)
IA Operator (IA-O)
IT Experts: The IT-E is one who is an absolute expert in their field. For instance, a network expert who makes the move from the Networks team, to the Information Assurance team. Gaining the additional skillset of the IA community and automated compliance tools benefit the organization tremendously. We are NOT referring to those holding certifications, because truthfully, they are not always synonymous with the expected skillset or even work ethic their reputations tends to infer. We are referring to true experts, whether they hold certifications or not. But an expected resume field would be Cisco CCIE, Microsoft MCSE, Redhat RHCE, Juniper JNCIE, etc.
Mid-Level Experts: The ML-E is one who is very well versed in their field and make the transition to the IA community. They are well capable of maintaining an existing environment, but nowhere near on the probable engineering and innovative level of the IT-E. This is probably where you want most of your IA staff to be pulled from. By building a team of ML-E’s from various fields such as Networks, System Administration, and Software Programming etc. a true multi-faceted team can ensure the organization is meeting the goals in each of their respective IT fields. Expected resume would include Cisco CCNP/CCNA, Microsoft MCSA, Redhat RHCA, Juniper JNCIP, etc.
IA Technician: The IA-T is one who really does not have a background in the other IT fields outside of the basic fundamentals. We’re talking CompTIA level minimum expected knowledge and skillset for each field. This individual would likely have a Security+, Windows OS Certification, Network+, and perhaps CASP or a CISSP. We did NOT include CASP and CISSP at the IT-E and ML-E levels to highlight that CASP and CISSP do NOT qualify individuals for those levels. We’ve found that individuals with only CASP and CISSP are actually part of the problem.
IA Operator: The IA-O is one who is new to the IA field, and getting familiar with IA automated tools and the IT environment overall. The difference we’ve found between the IA-T and the IA-O is that the IA-T can usually “talk the talk” and knows how to leverage their automated tools and reports with the organization leadership to become relevant to non-IT or non-technical personnel.
All of these levels must utilize automated compliance tools such as a Network Compliance Manager (NCM) or Port Scanner. What we’ve found that contributes to the lack of good compliance is a lack of skillset in the IA-T and IA-O levels. They do not really understand the areas they are checking for compliance and therefore often have friction with the other IT departments within an organization.
I once had an Information Assurance Manager deny my Request for Change to migrate from SNMPv2 to SNMPv3 because they said it introduces a vulnerability while we change over in terms of the loss of monitoring capability. Their lack of technical understanding in not knowing that both SNMPv2 and SNMPv3 can run simultaneously on a device and on a Network Management System (NMS) contributed, among other similar issues, to friction between our Network and IA departments.
Admittedly, this was a combination of lack of skillset and arrogance on behalf of the IA Manager.
2. SYSTEMATIC NEGLECT
The easiest system to maintain and operate is the one that is already compliant. The easiest procedures and policies to maintain are the ones that are already in place. Doing the right thing from the beginning is so crucial. What we’ve found is that when a system or procedure is not where it should be, the often found excuse is that, “This is how it has been, and we’re trying to get where we need to be.” It a certain point this becomes a crutch and is no longer valid, the only question is left is if the current responsible staff has actually deceived themselves into believing that statement.
Today, often we see consultant companies and contractors who setup IT systems and infrastructures, who then turn over the finished product to the “in-house” IT personnel. It cannot be understated how vital it is for this handover to be complete, and for the “in-house” staff to instill an cultural environment that is conducive to maintaining the delivered products posture and policies.
We’ve found that this is often not the case. Change can be very difficult to influence in an organization once the established broken “norm” is in effect. The best way to combat this is to ensure it does not happen in the first place. Unfortunately, what is needed is a complete overhaul in organizational leadership to “shake” things up.
Do the correct IA personnel have access to the required automated tools to check all the different systems? If they do have the tools are they employing them properly? Are regular checks being done. Over and again we’ve found that IA personnel do NOT know to properly check all their IT systems, nor do so on a regular basis. What we’ve found is that IA departments are most likely only checking the systems that they themselves are being held accountable for.
What we see is that IA departments, like most other IT departments, have difficulty in holding themselves accountable in holding everyone accountable. This is a combination of a lack of skillset and “going with the flow” of the established “norm”.
Many IA personnel do not properly employ their current suite of tools, but always seem to be talking about and looking for the next tool. New tools should never be discussed if the current tools are not being utilized properly.
3. Lack of Buy-In
Whenever a crucial security incident occurs IT personnel seam to learn very quickly how to shift blame. Survival instinct kicks in and anyone and everyone gets blamed. Ultimately, the single entity that could have of prevented the incident are those who are responsible to ensure IT system compliance.
Had they been checking all the IT departments properly the risks would have of been identified. Even further, once systems are found out of tolerance, the responsible departments must be held accountable to ensure the correct measures are put in place to fix the deficient system.
This does not occur when personnel have no buy-in. Meaning, they have no real tangible and immediate incentive to do get on board with company policy and procedure. If a tree falls in the middle of the woods, and nobody hears it, does it make a sound? Same thing when it comes to IT security and compliance. If there is no real mechanism in place to hold everyone or anyone accountable, what is the incentive to do all the extra hard work and not cut corners. Truly, if nobody is going to check or notice either way, then why bother.
What gets buy-in? Bring in a third party company to do a vulnerability and IT process inspection and do it regularly. Bring some heat without creating a hostile and environment of fear. How can we do this? Offer incentives such as bonuses, vacation, etc. to your people.
Take care of your people and they will take care of you.
Some managers may decide to go the threatening route to ensure IT compliance, and although there is a time for a more strict and stern approach, it should always be the exception and not the rule. Happy employees make happy employers as long as there is accountability.
Of course this is not the end all solution to this topic, and there are many other ways to categorize, classify, and approach the same issues, but it does highlight some very lacking areas and provide some insight in how to tackle the issue.