While much work remains to be done, the 2007 Report to Congress shows some excellent progress being made by several agencies in critical areas. Get the report at:
http://www.whitehouse.gov/omb/inforeg/reports/2007_fisma_report.pdf
A question recently came up amongst some FISMA-heads thinkers regarding how one might classify (in FIPS-199/SP800-60V2 terms) a device such as a fire-protection panel.
There is universal agreement that virtually every System has some physical components, whether in a data center, a server room or a general office environment, that require the protections to availability mandated by SP800-53 Control PE-13: Fire Protection.* Only the baseline control is required for Low systems while all three Enhancements are required for Moderate and High systems. It is also clear that the requirements of Control PE-13 are pointed directly at devices such as a fire-protection panel.
So if every system must implement some level of PE-13, what Information Type would be associated with that control? Some might suggest D.4.4: Emergency Response Information Type. Others thought maybe C.2.4.3: Service Recovery Information Type was more appropriate. Or, perhaps a case could be made that the fire-protection panel is actually an integral part of the IT Infrastructure, and therefore C.3.5.4: IT Infrastructure Maintenance Information Type might work. I would submit that only the System Owner of the Fire Protection System (a facilities/safety person) should really care what Information Type to assign.
Very few System Owners are directly responsible for the environmental conditions necessary to support an IT (or working) environment, including fire-protection panels. Far more often, these protections are provided at the agency, regional, site or building level for the benefit of the entire organization. Often these types of controls are subject not only to FISMA (and therefore the NIST guidance), but also to state or local requirements.
By the way, the argument of whether a fire-protection panel is or isn’t part of an IT System is, in my opinion, somewhat of a red herring. No matter what you call it, it is a critical element of the protections demanded by PE-13. The residual risk accepted by every Authorizing Official with a system component dependent on the protections of the fire-protection panel did so based on the assumption that the panel was, is and will be operational, and tested (certified) to ensure so to the level mandated by SP800-53A.
So, whether a critical protection component uses a traditional CPU, or memory, or networking is immaterial. If it provides its protections via analog signaling, wired or wireless, stored or ephemeral, it still requires protections and an adequate assurance of operational effectiveness.
Given that PE-13 is a very high candidate for Common Control status, the important questions System Owners should be asking are:
- Who, by name, is the owner of Common Control PE-13 for each environment in which I have a system component?
- What level of protection (controls) were implemented, the baseline control and which enhancements (this goes directly to what Information Type the owner of the fire-protection panel “system” selected)?
- Is that level of protection adequate for my system?
- When was control PE-13 last Certified?
- Show me the results of that Certification (the evidence of operational effectiveness over time per SP800-53A)
- When was the System under which control PE-13 was Certified last Authorized To Operate and for how long?
- Were any residual risks accepted by the Authorizing Official related to the protections afforded by PE-13?
Note that whether a particular organization wishes to accomplish the formal Certification (testing) and Accreditation (acceptance of residual risk) by including the control in a “System” or instead accomplish those same objectives without strictly following the C&A processes defined by SP800-37, is somewhat immaterial. Regardless of how you wrap it up, the important thing is that System Owners can have a high degree of confidence in the continuous operational effectiveness of the Common Controls upon which they are placing reliance. That’s where the rubber meets the road.
*PE-13: FIRE PROTECTION
Control: The organization employs and maintains fire suppression and detection devices/systems that can be activated in the event of a fire.
Supplemental Guidance: Fire suppression and detection devices/systems include, but are not limited to, sprinkler systems, handheld fire extinguishers, fixed fire hoses, and smoke detectors.
Control Enhancements:
(1) The organization employs fire detection devices/systems that activate automatically and notify the organization and emergency responders in the event of a fire.
(2) The organization employs fire suppression devices/systems that provide automatic notification of any activation to the organization and emergency responders.
(3) The organization employs an automatic fire suppression capability in facilities that are not staffed on a continuous basis.
September 6, 2007 from the NIST FISMA Listserv:
1. Consistent with the security standards and guidelines being developed for the Federal Information Security Management Act (FISMA) of 2002 and inputs from a variety of community-wide sources, NIST plans to update its current risk management and Certification and Accreditation (C&A) guidelines. The proposed revisions to NIST Special Publications will incorporate inputs from: (i) the Information System Security/Line of Business C&A Working Group; (ii) the Department of Homeland Security (DHS) National Infrastructure Protection Plan (NIPP) and Sector Specific Plans (SSP); and (iii) the Director of National Intelligence/Department of Defense C&A Transformation Initiative.
There are four major activities associated with the planned revisions to the guidelines:
(i) Develop NIST Special Publication 800-39, Managing Enterprise Risk. This new special publication will formally describe the NIST Risk Management Framework and the associated components that are contained within the framework. Special Publication 800-39 will be the flagship document for the NIST FISMA-related standards and guidelines and provide the overarching risk management strategy for federal agencies with regard to the use of information systems to support critical and sensitive enterprise missions and business functions.
(ii) Revise NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, July 2002. The scope of Special Publication 800-30 will be changed to focus specifically on the risk assessment process as a key component of managing enterprise risk resulting from the operation and use of information systems. Special Publication 800-30, Revision 1, Effective Use of Risk Assessments in Managing Enterprise Risk, will describe how to apply risk assessments at various steps in the Risk Management Framework, for example, when assigning FIPS 199 security categories to information and information systems or when selecting, tailoring, supplementing, and assessing the security controls in an information system.
(iii) Revise NIST Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, May 2004. The revised Special Publication will maintain the stability of the current four-phase security certification and accreditation (C&A) process while expanding the guidelines based on new computing paradigms, lessons learned from the first three years of implementation and use by federal agencies, and the desire for greater efficiencies in the process. The specific planned modifications to Special Publication 800-37 include:
Redefining the C&A process as an integral part of the NIST Risk Management Framework;
Tightly coupling the C&A process to the System Development Life Cycle;
Placing greater emphasis on the continuous monitoring aspects of the C&A process to create a more dynamic, automated tool-driven process;
Expanding the C&A process to apply to the enterprise (infrastructure) level as well as specific information systems; reinforcing the focus on enterprise missions and business functions first and foremost; and
Addressing the application of the C&A process to new enterprise operating paradigms (e.g., service-oriented architectures, software as a service, outsourcing).
(iv) Develop Authorizing Official‚s Handbook. This new special publication (800-series number to be announced at a later date) will describe the authorizing official‚s oversight responsibilities with regard to the implementation of the NIST Risk Management Framework culminating in the information system authorization decision. The guidelines provided in the Authorizing Official‚s Handbook will be tightly coupled to the NIST FISMA-related security standards and guidelines including Special Publication 800-39, Managing Enterprise Risk and the revisions to Special Publications 800-30 and 800-37.
2. The following development schedule is provided to agencies for planning purposes: NIST Special Publication 800-39 Managing Enterprise Risk Initial Public Draft: October 2007 Final Publication: January 2008
NIST Special Publication 800-30, Revision 1 Effective Use of Risk Assessments in Managing Enterprise Risk Initial Public Draft: December 2007 Second Public Draft: March 2008 Final Publication: June 2008
NIST Special Publication 800-37, Revision 1 Guide for the Security Certification and Accreditation of Federal Information Systems Initial Public Draft: January 2008 Second Public Draft: April 2008 Final Publication: July 2008
NIST Special Publication 800-XXX Authorizing Official‚s Handbook Initial Public Draft: January 2008 Second Public Draft: April 2008 Final Publication: July 2008 3. Further information regarding the planned revisions to the NIST risk management guidelines can be obtained from the FISMA Implementation Project at http://csrc.nist.gov/sec-cert or via email at sec-cert@nist.gov.
-- Ron Ross
Project Leader, FISMA Implementation Project
I recently read a new Research Brief published by the National association of State Chief Information Officers (NASCIO). Get the report here: It does a credible job of highlighting the evolving role of the CSO (or CISO) in the state government environment. It is an excellent overview of the challenges facing state security officials from a wide variety of perspectives, including environmental drivers, CISO title variations, governance and reporting structures, breadth and depth of authorities and responsibilities, involvement in privacy issues, education, experience and compensation, and more. However, when it makes that statement on page 3 that "While some federal laws, such as Sarbanes-Oxley and FISMA (the Federal Information security Management Act), may not apply directly to the states, CISOs must still understand their potential influence regarding information security," it fails to explain how FISMA can and should be a key driver in any state CISOs response to the information security challenge.
What the research brief fails to adequately highlight is the fact that while the FISMA legislation is not directly applicable to the states, it did cause the National Institute of Standards and Technology (NIST) to create a security assurance framework that can (and should) be leveraged by state, county, regional and local governmental agencies (and by the private sector too, but that's for another post).
If I were a state CISO, I would immediately mandate the adoption of the NIST framework for all agencies. I'd give a reasonable amount of time (and the necessary resources) to properly define system boundaries, classify those systems in accordance with FIPS-199 (and SP 800-60 which already defines the criticality of many information types that will be found in the state computing environment), select, refine, document and implement controls from SP 800-53 and assess the effectiveness of those controls with SP 800-53A. I would use the power of Certification and Accreditation to provide assurances of system security and ensure the proper accountabilities are known and enforced. After all, when my state systems interact in any way with federal systems, I'm going to be asked by my federal counterparts to provide such assurances in a common language.
NASCIO would do a service to its members by educating them on the NIST FISMA framework and the value it represents in stepping up to appropriate and adequate information security using the same approach and level of rigor required of their federal partners.
For those that missed the great article by Aurobindo Sundaram in the June issue of the ISSA Journal (see http://www.issa.org/cgi/issaopnpg.php?page=journals/2006_June/J0606001.pdf), it is a great overview of the evolution of capability we should expect to see once a common, agreed upon framework like the one provided for us by NIST for FISMA is in place. Agencies will be all over the board in terms of their current security maturity and capability and we should recognize and expect a gradual adoption curve. I hope Congressman Davis reads it and understands the absolute necessity to properly fund and staff this initiative (assuming we really want to improve information security and not just enhance paperwork exercises).
In my mind, the OMB measures leading to the less-than-acceptable grades for most agencies are looking at the wrong metrics, at least for the upcoming year. It’s understandable that in the current phase of adoption of the NIST Security Assurance Framework created in support of the FISMA legislation, we would be looking at what I’d characterize as interim metrics. It’s not unlike the year-one measurements of SOX compliance in the private sector and the reality that most activities that year were geared toward remediation… getting things in place. Over the past couple of years, as 800-53 has become final (and made law by FIPS-200) and 800-53A is nearing reality, we should expect that agencies have been responding to what are now stable minimum security assurance requirements by getting required governance elements in place. That’s a contributing factor to why FISMA compliance feels so much like a paperwork drill to date. We need to learn from the experiences of the private sector in their adoption of methods to achieve compliance with SOX, GLBA, HIPAA, etc. and set our expectations of progress accordingly.
But now that the dust is settling on this new and significant framework provided by NIST, there is IMHO, one and only one metric that matters… are systems accredited? Of course, for that to be the one and only valuable metric, it must mean something. As NIST says, accreditation is “an official management act reflecting their unambiguous acceptance of the risk to the organization’s operations, assets, or staff based on the implementation of a defined set of security controls. By accrediting an information system, a single agency official accepts ultimate responsibility for the security of the system and is fully accountable for any negative impacts to the organization if a breach of security occurs.”
After all, what are we after here? We want an appropriate level of assurance of security control operational effectiveness with accountability. What was it that made private sector CFO’s grab large handfuls of shareholder money and spend it on highly paid security and audit professionals? Did they suddenly get religion and see the value of applying some structure and reliability to the control effectiveness assurance processes? No. What they saw was other CFO’s in orange jumpsuits (see http://www.sox-online.com/hall_of_shame.html).
You want FISMA to work? Do two things:
1) Pay Authorizing Officials more. Or, give them a larger office or a closer parking space. Something to reflect the reality that by signing the authorization to operate, they are accepting PERSONAL risk on behalf of the agency. They are the ultimately accountable official. I have a friend that works for the Department of State. He prefers to get assignments in some remote, third-world post, not because he prefers the beauty of sub-Saharan Africa, but because he makes more money in that post. It’s hardship pay in recognition of the reality that he is accepting some personal inconvenience (and let’s face it, risk) and should be compensated accordingly. So too are Authorizing Officials accepting a measure of personal risk and we should recognize that. In fact, we should underscore that. Doing so will only serve to make them take the act of system authorization seriously.
2) One year after SP 800-53A goes final and FISMA Phase II is complete (which ever comes later), have the DOJ establish a FISMA compliance task force to, initially, provide guidance for agency legal council regarding advice they should be providing to their Authorizing Officials relative to the ramifications of the risk they are personally accepting by virtue of their assignment in the agency. One year after that, the task force begins to monitor the level of due diligence applied to compliance with the letter and spirit of the NIST framework (based on agency management, OIG, CBO, OMB and third-party input) and take appropriate and measured actions where necessary. While respecting employee privacy rights, we should publicize the circumstances and actions of the task force within the Authorizing Official community. Doing so will only serve to make them take the act of system authorization seriously.
Why do I say one year after SP 800-53A goes final and FISMA Phase II is complete (which ever comes later)? Some are expecting full FISMA “compliance” by March 9, 2007, simply because FIPS-200 was signed on March 9, 2006. Let’s be serious here. SP 800-53A is a keystone document in this framework. That’s why it’s taking so long to write. It is an amazing and significant contribution to the information security community. I have private sector clients who are complaining about chartering separate projects and hiring separate auditors to meet HIPAA requirements, and GLBA requirements and SOX requirements, etc. They ask, isn’t there just one security framework that I can implement that will meet all the requirements? From a security perspective, HIPAA focuses on one class of data (personally identifiable health information) and primarily on its confidentiality. GLBA focuses on personally identifiable financial information and primarily on its confidentiality. SOX focuses on data relevant to a firms financial reporting capability, and primarily on its integrity. Isn’t there one framework that takes into account all data types and all protection requirements?
Yes, the NIST Security Assurance Framework. All information types must be considered in terms of their importance to the assets and operations of the agency. All protection profiles are equally considered. Recent data loses cause the spotlight to focus on issues of data confidentially, but let’s not do so at the price of adequate considerations for the protection of its integrity and availability.
Anyway, back to my rational for the timeframes. SP 800-53A sets the standards by which security assurance will be measured. Forget the SP 800-26 self assessment method. It’s okay, but let’s face it, even in its Revision 1, it isn’t exactly a robust set of assessment processes, nor was it intended to be. Nice for FIPS 199 Low systems, but I’d be hesitant to rely on it for control effectiveness assessments in years 1 and 2 of the 3 year accreditation cycle. For Moderate and High systems, I’d want to see SP 800-53A used for every assessment, whether done by internal resources of an external CA. Those poor auditors out there doing SOX audits are dreaming up the audit procedures for each and every audit effort, and no two audit team’s procedures are alike. It’s a mess. You Federal guys don’t know how lucky you are to have SP 800-53A.
And 800-53A isn’t going to be done until December, 2006. You think agencies can step up to full and real compliance between December 2006 and March 2007? Please. If you want real security results, this is going to take time. Oh, and FISMA Phase II won’t be done until early 2007 at best. Only then will agencies have credible, trustable and price competitive resources to turn to for the important function of independent certification agent. Until then, agencies will spend lots of money on Big 4 firms to do what are probably very through audits using their own flavor of effectiveness expectations.
Am I saying that the AO for system that contained the recently stolen VA laptop should be fitted for an orange jumpsuit? Not yet. How can you hold someone accountable for adherence to a security governance framework that isn’t completed yet? Once the ink is dry on the framework (early 2007), give agencies a year or so to integrate the processes and then begin real, meaningful enforcement.
By the way, in case you can’t tell, my experience is on the civilian side with FISMA and NIST. I don’t claim to be an expert in any way with the DoD side of the equation. That said, I have extensive experience in the private sector security assurance arena and I think the Federal community could learn a great deal from the pain the private sector has been going through over the past several years. With the PCAOB attempting to set standards of goodness for control effectiveness assurance across a broad and diverse demographic and a service provider industry as interested in mitigating their own risk exposure as they are that of their audit clients, the parallels to the Federal sector are strong.
I also believe (and preach) that the NIST Security Assurance Framework was created from scratch with the intent and expectation that any organization or enterprise could adopt and adapt it and that doing so was the best way to demonstrate due diligence in security assurance, be you a civilian or DoD federal agency, a state, county or regional government entity, a private sector company, a non-profit, etc. This NIST framework IS the manifestation of security assurance due diligence. As it says in the current version of SP 800-53 (NIST’s emphasis, not mine): “The security control baselines listed in Appendix D should be viewed as foundations or starting points in the selection of adequate security controls for information systems. The baselines represent, for classes of information systems (derived from FIPS 199 security categorizations), the minimum level of due diligence demonstrated by an organization toward the protection of its operations and assets.”
Does this guarantee that no breach of security of any kind will ever occur? Of course not. It simply says that we have taken a rational, well documented approach to the security assurance process (includes risk assessment) and implemented security controls commensurate with the importance and value of the asset.
By the way again, I think NIST really needs to name the security assurance framework they’ve created in support of the FISMA legislation. That’s a mouthful of a way to describe what we mean by FIPS-199 & 200 and SP 800-60, 53, 53A, 37 and maybe 18, 26, 59 and 70). We all know what we mean when we say COBIT or ITIL. My suggestion is we name this framework SATCA, Security Assurance Through Certification and Accreditation. Only once we’ve agreed upon the contents of that framework can we begin to understand what elements of the DITSCAP or NIACAP or other DoD specific requirement is not met by the NIST framework. I’d submit that we won’t find many.
The agencies I’ve been working with have been applying resources to this issue (FISMA compliance) for several years. After all, we’ve always had information security activities going on, it’s jus that now we’re aligning everyone on the same sheet of music. As you might expect, every system in every agency is in some state of evolution. The challenge is to bring all systems, even legacy ones that will likely be retired in the near future, and new ones that are still in some phase of development (yes, we have requirements to link control definition as early as possible), into a compliant state.
Knowing how much work that is, most agencies are tackling this on all fronts. They are spending money on education amongst the community involved in some aspect of C&A, they are hiring contractors or dedicating resources to some of the foundational tasks (where they’re non-existent or inadequate, get security plans in place, install change management, incident response, configuration management, risk assessment policies and procedures). Some have contracted with external firms to act as independent certification agents for moderate and high impact systems. Others are trying to staff up internal resources to fulfill the certification agent function.
In other words, it’s all over the board. I’d say all agencies have at least inventoried all systems, defined system (accreditation) boundaries, and classified the system as Low, Moderate or High in accordance with FIPS-199 (and SP 800-60). Whether ALL systems were captured in that inventory process, and whether accreditation boundaries were adequately defined and documented, and whether the rigorous process defined by the NIST framework to arrive at the impact level designation, well, that’s another story. But I’d say that most organizations believe they’ve completed these steps already. I guarantee you that as they get into the real control selection, refinement, documentation, implementation and assessment process, they’re going to find lots of opportunities to refine accreditation boundaries and challenge impact level assumptions, and adjustments will and should be made. We should expect that.
That said, most organizations are now focusing on stepping up to the control assessment requirements, something I don’t think they’ll be able to do in any meaningful way until mid-2007 (SP 800-53A goes final and FISMA Phase II completes).
As to the question of adequacy of the resources to step up to this effort… no, I doubt that any CISO would tell you that they have all the money or resources they need to get this done. The reality is that if you spent billions (not unheard of in the federal sector), and hired thousands, this is still going to take time to complete. We’re talking about significant cultural changes. That doesn’t mean we throw up our hands and look for another solution. It means we work diligently on making progress, setting reasonable expectations and, most importantly, hold people (by people, I mean Authorizing Officials) accountable when they fall short of that standard.
I must also say that it gives me comfort to see that virtually everyone I’ve come into contact with in the federal security community has a full and complete appreciation for the urgency of closing existing known vulnerabilities. These are conscientious, intelligent and engaged individuals who have a keen appreciation for their role in protecting the public trust. In many cases, given their credentials and experience, they could probably be making a lot more money in the private sector right now, but they continue to serve. Even most contractors seem to feel a sense of duty.
One last point on the resource issue. I was at the FISMA Phase II workshop in April and there were scores of firms there interested in becoming credentialed by NIST to provide C&A (or at least Certification Agent) services for federal agencies. I fully anticipate state, local and regional agencies, non-profits, and eventually the private sector will adopt and adapt the security assurance framework created by NIST in support of FISMA, so hopefully, these firms will be busy for the next several years, serving much more than "just" the federal civilian sector.
Of course, there will be revisions over the next several years to many existing NIST documents to bring them up to the components and language of the current framework, but Dr. Ross and his team have given us a truly elegant security assurance framework, well integrated from top to bottom, from the high level management oversight and risk acceptance view to the detailed control catalog and assessment procedures, this is a significant contribution to the information security community. NIST deserves as many props for giving us this framework as the OGC gets for giving us ITIL. Both great frameworks for their purpose. Of course, the NIST framework is in the public domain. Thank you Department of Commerce.
Will we see a competition between the NIST framework (we need to name that by the way… I’ve suggested SATCA… Security Assurance Through Certification and Accreditation) and the new ISO270001? After all, isn’t that what ISO is doing? Isn’t 27001 essentially an attempt to bolt on an Information Security Management System (ISMS) to the evolving control catalog that has been ISO17799? Something NIST has already done with the SATCA framework (hey, catchy name) with guidance that is well written, by the same smart people, at the same time, well peer reviewed, well funded and managed, and fresh. I don’t know that we’ll ever reconcile the two frameworks, ISO and NIST (hard enough to reconcile the NIST framework with DITSCAP and NIACAP). It will be interesting to watch the “performance” of each framework over the next decade.
The official answer is March 9, 2007. That’s the one year anniversary of the Secretary of Commerce’s signature on FIPS-200, the last piece of the NIST framework that carries the weight of law. I’ve seen some agencies that perceive that to be a hard and fast deadline and are determined to pull out all the stops between now and then to achieve a “compliant state.” Of course, this begs the question: how do you define a compliant state? According to NIST, a compliant state is an Authorization to Operate letter on file for every system, signed by an Authorizing Official. That implies that the agency has, for each system:
1) In accordance with the guidance set out by FIPS-199 (with SP 800-60), accurately defined the system boundary and articulated the hardware, software, data, networks, staff, funding, etc. that comprise each system.
2) Identified all the information types stored, managed, processed or transmitted by each system and documented their importance to the assets, operations and mission of the agency in terms of the potential impacts resulting from the loss of the confidentiality, integrity or availability of the system
3) Selected all the necessary controls (and control enhancements) from SP 800-53 based on the impact level identified above and refined those controls with assignment and selection variables to meet the specific requirements of the system and environment.
4) Applied the scoping guidance outlined in SP 800-53 to rationalize local specific decisions made by appropriate officials about the implementation of the controls.
5) Defined which controls will be deemed common controls (or hybrid controls) and the nature of the control relationship (is the system under review the owner of a control that other systems are basing their assurance upon, or is a control owned by another entity and the system under review will be inheriting the results of another operational effectiveness assessment).
6) Documented all system specific controls (or inherited the documentation of common controls) in the System Security Plan in accordance with SP 800-18 (to include other documentation that will be necessary to demonstrate compliance with many controls, e.g., Risk Assessment, Configuration Management Plan, Incident Response Plan, Contingency Plan, System Interconnection Agreements, etc.).
7) Assessed the operational effectiveness in accordance with the procedures provided in SP 800-53A of the system specific controls with the appropriate level of rigor (depth, coverage and scope) for the system impact level (gathering extensive evidence through a rigorous and well defined process of testing, examination and interviews of individuals, specifications, activities and mechanisms).
8) Thoroughly documented the results of the assessment in the form of a Certification Report that adequately and accurately captures the real state of the security posture for each system in terms the Authorizing Official can understand.
Assuming all that was done and each Authorizing Official was willing to give their personal assurance of the effectiveness of, and assume full accountability for, the security of a system (essentially accepting all residual risk on behalf of the agency), then I’d submit you were FISMA compliant.
The reality is that agencies are scrambling to get things in place. This is very similar to year 1 of Sarbanes-Oxley when companies were jumping through hoops to get the basics in place… policies, procedures, that are fresh and accurate and updated. There is a lot of remediation work going on right now. That’s one reason why FIMSA has been getting such bad press lately. It feels a lot like a paperwork, checklist exercise right now. But that really just a reflection of the phase of our adoption.
But two, maybe three years from now, when the ink is dry on the NIST framework (early 2007), when FISMA Phase II is complete (sometime in 2007) so agencies have a list of credible, trusted, vetted (credentialed) AND cost competitive list of vendors to provide the all important independent Certification Agent function, maybe we’ll be seeing good progress. Remember, unlike their private sector counterparts that have the “luxury” of grabbing handfuls of shareholder money to pay for SOX compliance, federal managers don’t have the budget to get all this done quickly. In many cases, contractors are responsible for managing federal systems and to apply resources to any effort requires contract revisions. And consider the challenge of getting all the involved individuals up to speed on the new framework, when training opportunities are few and far between (for reasons of availability as much as funding), much less trying to rebuild this airplane while it’s in flight and not spill coffee on the passengers. There are lots of big-time system consolidation, re-architecture or replacement projects going on in the federal government right now. Overlaying FISMA compliance requirements on those freight trains can be difficult and potentially dangerous (risky). In all honesty, you couldn’t pay me enough to be an Authorizing Official in the federal government for the next several years.
Anyway, you get my point. REAL compliance, my kind of compliance, will take several years. Not 10, but more than 2 for most agencies. Lots more for some. Between now and then, agencies will get low FISMA grades, agency leaders will continue to be grilled by various congressional committees, systems will be certified and accredited in ways that everyone involved believed was honest and complete based on their knowledge and understanding of the process, Inspectors General will continue to generate serious findings in audits (even more so once we have a final SP 800-53A), AND system vulnerabilities will continue to be exploited and breaches of confidentiality, integrity and availability controls will continue. Each time they occur, holes will be plugged and progress will continue to be made as we move into the second and third years of framework usage (we really need to learn from SOX experiences) and slowly, over a few years, through proactive and reactive steps and as system architectures evolve and security is baked in from the beginning, we may achieve the nirvana of compliance through good security, rather than adequate security through compliance.
I’m not aware of any hammer that is going to fall, or funding that is going to be cut, if real (or even less-than trustworthy) Authorizations to Operate are not on file.
