The blame lies in a few places.  Some IT audit senior staff generate faulty audit plans.  If you were not taught how to be an independent thinking audit staff member, you will likely not transform into an audit senior staff member who can lead junior staff to become independent, critical thinkers.  Instead of creating checklists and specifically identifying what junior staff should look for in an audit, senior staff should teach the junior members of their team how to think about the system which they are reviewing to figure out what questions and audit procedures will provide the most coverage for the particular system being examined.  Every audit artifact is not equal, and one must think about the evidence provided to determine whether there is a gap or a way for a weakness to slip through the cracks and not appear in this particular piece of evidence.  I cringe when I hear that one of the first steps an auditor has taken is to provide the client a checklist of audit artifacts to request from the client.  One of the first things an auditor must do is interview the client (walk through the process)and gain an understanding of the client’s processes.  After auditors understand the process, only then can a list of artifacts be requested.  It is a grave mistake to assume that one can audit a process simply because you are familiar with the applications or systems in place.

Another place where blame lies is with audit managers who are more concerned with maintaining the contract than providing the client with the ability to decide which issues are significant enough to worry about.  It is my belief that all weaknesses found during an audit should be communicated to the client in writing in some form.  I am not promoting the idea that all findings should make it into the final report, or even that all findings are reportable.  I am saying that in daily interactions, status meetings or briefings the client should be presented a list of every single finding that was observed, this is provides legal/regulatory coverage for the auditors, and it allows the client to make the decision to address or ignore each issue individually.  The way I see it, my integrity as a professional is more important than the contract that I am working under.  If my client is intimidated by a long list of findings, they can either keep me around to help them correct the situation or they can continue to bury their head in the sand and either terminate my contract or I may refuse to return upon the end of that contract.  Auditors are a resource that should be used to help, if we are seen as adversaries to the system admins or management our work will not add any value to their processes.

The purpose of an audit is to find the issues that the client is either not aware of, or trying to hide.  If you use checklists or ignore seemingly minor issues you are failing your client and you are failing the members of the IT audit profession who provide a high quality service to their clients.   Articles such as the examples below can be avoided if annual audits are effective and the client takes steps to resolve the issues presented in their audits.  A little background information for those who may say that these articles are the result of audits…Federal systems are subject to a minimum of 1 assessment (read: audit) each year, and the Inspector General generally only performs a spot check of a few systems each year, per agency.  The system that is the subject of the articles and reports that below could have addressed the issues presented well before the Inspector General(IG) audited this system.  If the annual audits were effective, and the client took actions to correct the findings during any prior year when the IG did not select this system for review these issues would not exist now. 

I have found (and included below) a few Twitter accounts that are great sources of current IT events, IT Security and IT Audit related information.  Of course all sources of information are not created equal, so it is our responsibility as readers to do proper research to verify facts.  Beyond that we should all do more to  network and share information and ideas to improve our industry.

You can start by following me @IT_Audit_Info

And then you should check out these Twitterers:

@infosecstuff

@isaudit

@ITPRO

@CiscoIT

If you know of any other good Social Media sites, blogs,  or Twitter accounts(that are not spammers or advertisers) to follow, please post them in a comment.

We all know that FISMA is better than nothing, and we should know that it was a decent attempt(at the time) by legislators at implementing IT Security within the Federal Government. But the fact is, FISMA is too weak, and too slow to be effective in the world of IT Security as it exists in the year 2010. IT security controls can not go unchecked for 1-3 years while management skips happily along wearing a Certification and Accreditation (false)security blanket. Congress must have recognized this fact as there has been an attempt to update FISMA, although the efforts seem to have stalled in Congress. Reform to FISMA, or a complete replacement which removes system owner’s ability to wriggle out of providing adequate security must happen sooner than later.

What we have today is an IT Security circus caused by the lack of clear, strong guidance/policy with some form of enforcement and punishment for those individuals/agencies who fail to meet the standards. If you put four IT Security professionals in a room to discuss NIST 800-37 and/or 800-53 you will have at least three different interpretations of how to achieve compliance,and they will all use the guidance to prove that their interpretation is correct. Further, until there are some negative consequence that results from poor performance people will not take the implementation of NIST 800-53 Controls and FISMA guidance seriously. To my knowledge no Federal information systems have ever been shut down for non-compliance with NIST controls. To my knowledge the White House OMB has never pulled the plug on a failing system and forced the system owner to reach a state of compliance before granting authorization to resume operation of that system.

Managers must realize that in the current environment IT Security has two parts that are equally important. IT systems must meet FISMA compliance standards, and IT systems must have real IT security measures in place and operating effectively. My argument is, if administrators do the real security work and tighten down their system the Certification and Accreditation process will be a snap. Its much easier to document controls that are in place and operating effectively, than it is to implement a control after you have been visited by your friendly neighborhood auditor. I would dare say that if you have effective controls in place that are not documented your life would be much easier during the audit that the system owner who has tons of documents but few effective controls.

But it seems that the focus of resources on the compliance issues often causes systems to both fail to meet required compliance levels and fail to meet industry standard (common sense)practices. Often in the fog of scrambling to meet compliance goals IT staffers can overlook the basic low hanging fruit that can close many security gaps. Managers must realize that compliance with FISMA and NIST 800-53 controls are the minimum. There are so many more threats to systems out there that are not fully covered by NIST 800-53 that one would be foolish to sleep comfortably knowing that they only meet the minimum requirements of NIST SP 800-53. In order to have effective IT security agencies must go far beyond the minimum.

In order for NIST controls to have a bit more value as effective IT Security controls they must define terminology in a manner which removes ambiguity. For example NIST uses terms such as ‘Continuous Monitoring’, which is defined by NIST as monitoring the effectiveness of a particular control ‘at least annually.’ In the land of real IT Security any company that monitored a control’s effectiveness once per year would fail a test of continuous monitoring. I must give NIST some credit as they seem to be moving toward changing the definition to mean something to the effect of “near real time”, but again this term leaves too much to the imagination of an IT manager who does not want to devote the resources necessary to implement a proper automated or frequent manual process which would provide something close to continuous monitoring.

To sum it all up and put a nice little bow on top I will say that organizations need security staff that understand system vulnerabilities and emerging threats, while having the skill necessary to mitigate these risks with available resources instead of the crop of managers who surrender and throw their hands up when times get tough. Security does not have to be all or nothing. NIST needs to change the tone its control language, use precise wording, and and read each document in its entirety before publication to ensure that the top half of the document does not contradict the bottom half. Meanwhile, OMB should provide a stronger hand in enforcing guidance. IT Security will not get the proper level of attention and funding until agencies know that there are consequences to compliance failures, and before you say it… I know that compliance failures are theoretically supposed to impact the budget for the system owner or the agency, but the reality is that failures to comply with NIST guidance result in no negative consequences(that matter) to individuals or the organization responsible.

image from http://srcomblog.files.wordpress.com

If the answer to the question above is no, your IT departments should not be the brick wall preventing the implementation of new technology.  In a properly balanced environment the business units should decide on and approve a particular technology that is needed to perform a business related task.  The IT Department should be involved to assist the business unit’s decision making process to ensure that the best solution to fill the need is acquired.  After a final decision is made by the business unit the IT Department should then determine the best way to implement the desired technology solution.

What I see more often than not, is that IT Departments often times attempt to roadblock any technology implementation which they do not see a need for.  Instead of helping the business unit fill a need, the IT department screams about the fact that the new technology will create security gaps in the network.  This fear tactic often is enough to convince executives that the risks outweigh the benefits.  The fact of the matter is that every application or device in use on a network creates a potential vulnerability.  The job of the IT Department is to mitigate those risks and to provide the best implementation of the technology which will solve the business unit’s need.  The most secure network is one in which no users have access and no data is manipulated, while this is a very secure network, it is useless to a business.

IT managers often forget that their role is to support the business units which generate the profits which fund the IT budgets.   The IT department should not have approval authority over technology implementations, ultimately the business units are responsible for determining what resources they need to operate the business, and line of thinking often requires a shift in the mindset (and/or staff) in the IT department.

Situations where the tail is wagging the dog should be avoided. 

(photo from http://sketchedout.wordpress.com/2008/11/24/wag-the-dog/)

The re-vamped suite of NIST documents (SP 800-53 r3, 800-37 r1, 800-39, etc) are bringing a slightly stronger definition of continuous monitoring into play.  The new definition is far better than the previous vague descriptions of the concept(which is “at least annually”).   Currently in the Federal space continuous monitoring is interpreted to mean annually, for the most part.  I have met very few Federal IT managers who embrace the idea that continuous actually means more than once a year.  Is that due to a lack of understanding of the threats that exist? Or is it a thought process based on limited IT Security funds? Or is it a lack of understanding that FISMA should be about more than a paper drill?  I can not give one answer because I am sure that all of those reasons are valid among many others.

The new terminology refers to continuous monitoring as “near real time” which in my mind does move the bar much closer to a realistic definition, although I would like to see a FISMA update and/or NIST go a bit further and separate “real time” from “periodic”.  Real time monitoring almost always requires an automated tool to aid in 24/7/365 monitoring, while periodic monitoring can occur at a “near real time” frequency such as, hourly, daily, weekly or monthly depending upon how frequently the control activity is executed.  The draft NIST documents mention near real time and continuous monitoring almost interchangeably, while in my mind they can be quite different.  Periodic or near real time monitoring is required the majority of the time, while continuous monitoring (24/7/365) should be reserved for the most critical Security controls, and those which are executed frequently(i.e. attempts to access sensitive data, or multiple invalid login attempts).

Considering the number of incidents of leaks of Federal data, and the fact that there are entities actively attempting to steal sensitive data I feel as if it is time for the Government to encrypt all of its data.  Every hard disk, thumb drive, email, backup media, etc.  Encryption should become the rule instead of the exception.  I find it hard to believe that sensitive data is being stored and transmitted as clear text or by other insecure means.  It would likely be more cost effective for the Government to develop its own advanced encryption suite to address each type of storage media, and distribute it at no charge to all of its agencies than it would be to purchase such technology.

Making data encryption the standard could reduce the amount of resources required for low and moderate rated systems if the goal of system security is ultimately the security of the data.  I am not saying that encryption is the silver bullet to data security, but it should no longer be viewed as optional in these times when social engineering, phishing, and hardware theft/loss are daily occurrences encryption provides the best bang for the buck.

I am aware that data encryption has drawbacks, but in my opinion these drawbacks are by far exceeded by benefits for most users.  For the average Word, Excel, Access, Outlook user hard disk encryption should not cause a noticeable deterioration of system performance.  Only the most hard core users running specialized software which requires massive data transfers at high speeds would be affected, and I would hope that the majority of these users are operating on secure networks and/or they have other encryption solutions already in place.

It would please me very much to see NIST or a much needed FISMA reform move the bar towards standardized data encryption for all media, mobile devices, desktops, and laptops at a minimum.  The costs and risks created by data breaches are far too high to not take simple steps to reduce the impact of such breeches.