Jump to content

Talk:Federal Information Security Management Act of 2002

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Suggest the article be updated to recognize: the new Federal Information Security Modernization Act of 2014. — Preceding unsigned comment added by 152.133.13.1 (talk) 17:19, 10 February 2016 (UTC)[reply]

Untitled

[edit]

After five years of FISMA, experts agree that little progress has been made in improving the overall security posture of the Federal computing enterprise. The reasons for this are many, but they boil down into the following key categories.

1. FISMA measures the wrong things, measures the wrong things in the wrong ways, and fails to measure the right things. As a result, FISMA the legislation, and FISMA the process, are fatally flawed. For example, 10 points of the annual FISMA grade, or a full alphabetical grade, is devoted to Training. Therefore, and agency can receive all 10 points if its entire population receives a one-hour awareness training on-line course. However, the quality, content and effectiveness of the training is not measured. Another example is Certification and Accreditation, or C&A, which accounts for 20 points or two alphabetical grades. However, C&A is an immense amount of documentation that results in the acceptance of risk, and potentially limitless risk for a system or application. Therefore, it is possible for an agency to claim that 100% of its systems are C&Aed, but yet, not one of the systems might be considered "secure". C&A is a costly and time consuming never-ending exercise aimed at documenting security weaknesses and policy violations. However, the personnel performing these tasks often lack the security skills to accurately assess whether a risk exists, and/or the staff has a vested interest in concealing known weaknesses, to avoid embarrassment or punishment from a failed C&A. The time and money necessary to pursue C&A and thus a passing FISMA grade arguably consume the limited resources that could otherwise be used to improve security.

2. FISMA failed to recognize and overcome the culture of the various departments and agencies, especially those that are geographically distributed and fiercely independent from central authority. Thus, the agency CIOs and their subordinate CISOs are powerless to "enforce" security requirements across the stubbornly independent operating administrations. FISMA chose to use the word "ensure compliance" when defining what the CIO was responsible for accomplishing under the Act, and consciously avoided the use of the term "enforce." General Counsels across the Executive Branch have interpreted "ensure" to mean that the CIO has no real authority under FISMA. The legislators who enacted FISMA chose to ignore the most important aspect of implementing information security across large and complex enterprises -- governance! For this reason alone, FISMA is practically useless.

In recent years, the Office of Management and Budget (FISMA's sponsor, and the keeper of the Federal checkbook) and the various federal Offices of the Inspectors General have brought multiple types of pressure to bear on federal agencies to comply with FISMA requirements. It is interesting to this commentator, however, that if a multi-year chart identifying FISMA results exists on-line, it is at least difficult to find. [Personal observation and experience]UnclejackDC (talk) 20:29, 4 April 2008 (UTC)[reply]

3. FISMA created the Chief Information Security Officer (called "senior agency information security officer") and specifically placed that person under the CIO. That construct turns out to be a mistake. The CISO under FISMA must report to the CIO and thus place the security requirements of the department or agency subordinate to the CIO's other priorities, budget pressures, political exigencies or other conditions unrelated to sound and effective security approaches.

4. FISMA was created and managed by a triumvirate of entities with no practical security experience whatsoever. The Congress created and oversees FISMA, through the House Committee on Government Reform. It was born out of the old Year 2000 (Y2K) days, but after the Y2K rollover, the committee needed a new grandstanding event to justify its political existence. It chose information security because it was topical and loosely related to Y2K. Unfortunately, the non-practitioners on the congressional staff adopted the same system-by-system, site-by-site approach for information security that it used in the Y2K days. That approach connotes very little practical understanding of information security, where interconnected infrastructures and distributed enterprise boundaries require equal or greater attention than individual systems and sites. The second element of the triumvirate of 'FISMA keepers' is NIST, the agency responsible for publishing the standards that Federal agencies must adhere to under FISMA. Again, no practitioners exist at NIST, and the result is a massive pile of paper requirements that are impossible to implement and represent a simplistic form of a security-for-the-sake-of-security academician approach. At the same time, the core of FISMA compliance (and C&A) is the NIST Special Publication (SP) 800-53, which is arguably a generic and very low minimum security baseline that lacks specific details necessary to give FISMA any real power to improve security. The third element of the triumvirate is the Office of Management and Budget, which monitors FISMA implementation across the departments and agencies. Again, not a single practitioner can be found anywhere in OMB, and the result is an endless barrage of unfunded requirements heaped upon the departments and agencies. Until such time as actual information security practitioners take charge of the process, FISMA will remain the sad failure that it has become.

5. The worst and scariest aspect of FISMA is that many Federal executives who simply don't know any better and are chasing the 'Potemkin Village' of FISMA compliance and adopting the mindless 'scorecard approach' to security. These executives are completely oblivious to the fact that their computing infrastructure has been penetrated, its sensitive information has been violated, and those who wish to do harm to Federal information resources have succeeded. FISMA aims at giving Federal executives the policy tools necessary for them to gain a more accurate awareness of security across the enterprise. But by relying heavily on C&A and on threatened financial and other penalties from Congress, executives end up getting from their subordinates an inaccurate awareness of risks, a false sense of security, and the erroneous belief that security weaknesses are being resolved.

Thus, FISMA is a paper-based compliance drill and not a rigorous technology-based security program. In the five years of its existence, FISMA has failed to appreciably improve the security of the Federal computing enterprise, and will continue to fail to improve it under its current form and with its current flaws. Nonetheless, billions of taxpayer dollars have been squandered chasing "compliance," while little has been accomplished in actually getting to real security. To the enemies of our nation who wish to visit harm upon our nation's computing infrastructure, this is very good news indeed.

The statements and arguments presented here are seriously flawed.
First, the statements and arguments are not signed. This is a talk page, please take responsibility for your writing.
Second, the first line contains a logical fallacy, appeal to authority, without benefit of citation. What 'experts' are saying this?
Third, the fourth statement is incorrect in substance. NIST had considerable experience and expertise in computer security theory and practice long before FISMA was proposed. I speak from direct experience on that matter having worked at NIST as a security practitioner immediately prior to 9/11/2001 (the date of my abruptly canceled going away party). Additionally, NIST is well practiced at leveraging the experience and expertise of industry into its standards. [Bruce Brody here -- NIST has about a dozen people in this space and not one of them, not a single one, has ever secured a system or managed an enterprise-wide security program. That's not their role. Think of the analogy of a pandemic outbreak of a serious disease. NIST cannot cure the disease. Rather, they publish an encyclopedic guide to the disease, which when fighting the disease in real time, is useless.]
Fourth, FISMA and its supporting documentation don't address the cultures of the agencies because that's the smart thing to do. This is a law attempting to implement security practice throughout a large and varied organization, the US Federal government. They follow two tacts in achieving the goal of improving IT security. 1. Allow for tailoring by agency requirements while providing guidelines for implementation. This allows for differences in organizational needs and requirements. 2. Hold management accountable for the actual security. This is results in those in charge of authorizing the operation of information systems realizing that they will be visibly held to account for failures in security. The law doesn't make threats about what will happen because these are not likely to be enforced (have you ever seen a federal employee fired?) but visibility scares the apparatchiks (having it show up front page, above the fold of the Washington Post is a standard Washington worst-case scenario).
Fifth, C&A is a never-ending and expensive process because information assurance is a never-ending and expensive process.
Sixth, it is "not a rigorous technology-based security program" because treating IT security as strictly a technology problem is bad practice. There are plenty of non-technological faults that can destroy an IT program from water pipes running over your servers to policies which institute bad security practice. FISMA implementation is holistic, not simply focused on a single facet of IT security.
Among the special publications of the National Institute of Standards and Technology governing the FISMA certification and accreditation process is the risk management guide, NIST SP 800-30 [1]. It is by no means a solely technical requirement; at least, not for those of us who know of it and have read it (much less, implemented it). UnclejackDC (talk) 20:10, 4 April 2008 (UTC)[reply]
Seventh, I'm going to stop pointing out failings of the previous statements and arguments because it should be clear by now that there is sufficient cause to regard much of the previous writing with appropriate wariness. I would also point out that some valid opinions are described above but that these opinions should be assessed critically and not taken as statements of fact. DanRP (talk) 13:18, 27 March 2008 (UTC)[reply]

"Fatally Flawed"?

[edit]

I think that while there is significant discussion about why the act fails to address needs, I think that the characterization of the act as "fundamentally flawed" is a statement of opinion, not factual, and as a result, the article contains a basic bias inappropriate to Wiki.

I recommend that we add "has been characterized as" to the "fatally flawed" comment in the introduction. This would encourage the reader to review the "Issues with FISMA" section.

Thoughts?

[Bruce Brody here -- I think the ultimate justification of the "fatally flawed" point is that the staffs of Sen. Carper and Sen. McCain, both of whom are on the Senate Homeland Security Committee, have concluded that change is necessary and a new FISMA is coming. Having worked with both staffs, all I can say at this point is that the "fatal flaws" are being addressed. But it's no longer relevant to debate whether or not FISMA was "faally flawed" because Congress is fixing the "fatal flaws".]

Bdevoe 18:23, 29 March 2007 (UTC)[reply]

That particular statement has probably been changed since then, so I'm content with that particular sentence, but I'm not sure about the immediately following line:

Those detractors are correct to a degree, namely that FISMA alone is not the solution to Federal information security challenges.

This sentence is written as a statement of fact, and as much as I may agree that FISMA is not a solution by itself, it needs re-wording. If there is a cyber-security (or general security) expert who could provide the precise phrasing to indicate that multiple layers of security provide a necessary or valid enhancement, it should improve the article, especially for a sentence at the end of the introduction. Daytonduck 13:08, 20 June 2007 (UTC)[reply]

I would like to see paragraph three have an addition on the order of "While it is true that placing the CISO under the CIO requires the CIO to balance security against other priorities, placing the reporting at the CEO level also has significant drawbacks. Among them, the fact that the arguments about security are less likely to be understood and that the CEO has an even larger priorities and pressures." The reporting structure that we have may not be very good, but it is about as good as it can be. Others are likely to be worse. Jonesjf 20:05, 20 June 2007 (UTC)[reply]

An important legal article that is critical of FISMA was written by Robert Silvers for the New York University Law Review in November 2006 (81 N.Y.U.L. Rev. 1844) entitled "Rethinking FISMA and Federal Information Security Policy". I don't know how to attach it, but perhaps someone can do that. In it, the author notes that FISMA "suffers from serious structural defects that account for its poor performance" and the author rips the organizational and other flaws that FISMA imposes on departments and agencies. If you read this article, then you'll probably conclude that the discussion topic above is a milder critique of FISMA. Babrody 00:30, 8 July 2007 (UTC)babrody[reply]

Review of the article

[edit]

I've reviewed the article. FISMA act is a high level legislation, that contains several amendments to other legislation. To the most part, FISMA defines responsibilities of Federal agencies and contractors in regards to information security. FISMA is one of the key pieces of legislation related to cybersecurity. FISMA is accompanied by a number of NIST publications. As any piece of legislation, FISMA may be subject to critique, which is duly reflected in the "Issues" section of the article. Few additional references to the critique of FISMA can be added to the issues section, however, the purpose of the article is to provide encyclopedic information about the particular piece of legislation "as is", and it's relation to the rest of the body of knowledge on computer security (see Wikipedia:WikiProject Computer Security project ). It is not appropriate to mix critique with each statement of FISMA itself, or one of the accompanying NIST publications. This is affecting the neutrality of the article.

The discussion at this page is mostly related to FISMA itself, not to the article describing FISMA. Opinionated critics of FISMA, who feel that the critique of FISMA requires additional coverage as part of the Wikipedia, may want to add a separate page, and include a link to it from the Issues sections of FISMA. Such article will need to follow the usual "What, Why, When, How, Where" questions, as any article, and should include substantial references, see for guidance How to write a great article. In my opinion, if the above critique points are included directly into the "Issues" section of the FISMA article, then the neutrality of the article will indeed become questionable.

The description of the compliance process needs to be checked with the respect to the wording of FISMA itself. I believe the description is adequate with respect to the general intent of the entire framework defined by FISMA and one or more accompanying NSIT publications), but it does not correspond to the language of the FISMA act alone. Some corrections need to be made.

-- Equilibrioception (talk) 20:34, 1 February 2009 (UTC)[reply]
The reference to the interview of Bruce Brody produced in support of the critique of "FISMA" (including supporting standards) is incorrect. Position of Bruce Brody as summarized in the interview is that "FISMA is a useful exercise that has delivered benefits to agencies, but which doesn't go far enough". In particular, Bruce Brody said: "We have to be very clear and point out that FISMA has done a great service to the community by increasing the awareness of the issue of information security, and by putting in place certain aspects of a governance structure, where the senior agency information security officer is identified, certain roles are ascribed to that person and that person reports to the CIO. Also, the connection of risk-based decisions to budget is another important contribution of FISMA." [Bruce Brody here -- thanks for providing my comments. Yes, I believe FISMA has served a valuable purpose in initiating a dialog and stimulating a focus on information security in the Federal Government. It moved the football to the 30 or 40 yard line. But there are about 60 more yards to the end zone, and the current FISMA won't get us there. The end result is protecting Federal information, systems and networks from those who wish to do them harm, and FISMA in its current form will not provide that protection. In fact, it can be reasonably argued that FISMA is redirecting precious resources to "compliance" and away from "security", and thus, is preventing real security from happening.]
Another reference "Experts fault FISMA" is broken. Federal Computing Week does not have such article. However, in the recent article in FCW [fifth birthday] it is mentioned that FISMA is "one of the most pervasive — and arguably most influential — information security laws to be enacted."
The phrase fundamentally flawed tool was used by the editor of the third article provided as reference, and was not a direct quote of either Mr. Brody or Mr. Paller.
Most of the "FISMA critique" above is aimed at the implementation of FISMA and its supporting standards, rather than the FISMA act itself (see the link to the full text of the FISMA act in the article). Interviews of Mr. Brody and Mr. Paller in FCW and GCN must be referring to the FISMA act and its supporting standards. No reason why an encyclopedia article should not be more precise.
-- Equilibrioception (talk) 23:28, 1 February 2009 (UTC)[reply]
[edit]

Hello fellow Wikipedians,

I have just modified 3 external links on Federal Information Security Management Act of 2002. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:05, 29 September 2017 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Federal_Information_Security_Management_Act_of_2002&oldid=1207196458"