What is FISMA? The Federal Information Security Management Act explained – Digitalmunition

Featured lady_justice_statue_with_scales_law_books_legal_liability_risk_regulations_compliance_fairness_by_simpson33_gettyimages-1181406745_2400x1600-100860122-large.jpg

Published on March 12th, 2021 📆 | 6221 Views ⚑


What is FISMA? The Federal Information Security Management Act explained

FISMA defininition: What does FISMA stand for?FISMA, or the Federal Information Security Management Act, is a U.S. federal law passed in 2002 that seeks to establish guidelines and cybersecurity standards for government tech infrastructure, and in so doing protect government information and operations. The law was modified in 2014 to put more emphasis on continual monitoring with the passage of the similarly named Federal Information Security Modernization Act; generally, discussions of FISMA refer to the set of regulations established by both these laws.Like most federal cybersecurity laws, FISMA constitutes a complex set of rules that are intended to be at least somewhat flexible. While the initial intention of the law was to establish standards that the IT departments for federal agencies would follow, the sprawling nature of the government and its tight interconnection with private contractors means that the FISMA umbrella covers many, many organizations—including, maybe, yours.Who must comply with FISMA?Originally, FISMA was designed to strengthen IT infrastructure operated and maintained by the U.S. federal government. To that end, as the consultancy Aronson puts it in its whitepaper on FISMA compliance, the law “requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor or other source.”There are a few important things to note in this description. One is the emphasis on “information and information systems.” The rules are really about assessing the security of individual systems, rather than companies or agencies as a whole. And because in practice federal agencies interact with or rely on outside organizations to provide IT services, FISMA rules apply to those organizations as well. These might range from state government agencies helping administer joint state-federal programs like Medicaid to private companies providing the feds with software or services.But because FISMA is primarily written to impose standards on federal agencies, it affects private companies differently than laws like HIPAA, which mandate direct penalties like hefty fines on companies that don’t live up to the rules. By contrast, under FISMA, a person designated an Authorizing Official (AO)—generally, a high-level manager with responsibility over infosec at a federal agency—is in charge of determining if an information system complies with FISMA’s standards, whether that system is run in-house by the agency or is operated by another public body or a private federal contractor. This sign-off is known as an Authority To Operate (ATO), and the AO assumes responsibility for the systems to which they grant ATOs. If there’s a breach or other security failure in a system to which an ATO has been granted, it’s the AO and their team who would take the fall for it—and as you can imagine, there are career consequences for serious breaches.But if the affected system is supplied by a private contractor, that company can’t expect to emerge from the incident unscathed. As RSI Security explains on its blog, contractors who are discovered to have fallen short of FISMA’s requirements probably at the least will find the specific contract for that system cancelled; depending on the severity of the security shortfall, they might also be blackballed from other federal contracts, and company execs might even find themselves hauled before a Congressional hearing to explain themselves.  FISMA vs. FedRAMPBefore we dig into the specifics of the security standards laid down by FISMA, let’s take a moment to discuss another, related bit of jargon important for federal IT security: FedRAMP. Since 2011, the federal government has been working to rationalize its sprawling, fragmented IT infrastructure by moving much of it to the cloud. FedRAMP (the Federal Risk and Authorization Management Program) is a program launched to help certify cloud providers as secure enough for federal use. Specifically, it aims to provide a framework for applying the FISMA rules, most of which were written before the cloud era got underway, to cloud service providers. So, you can think of FedRAMP as a way that FISMA is applied to one specific category of IT. All FedRAMP is about FISMA, but not all FISMA is about FedRAMP.FISMA compliance requirementsLike most federal laws of this type, FISMA outlines somewhat broad principles and delegates the specific rulemaking to a federal agency—the National Institute of Standards and Technology (NIST), in this case. NIST has encapsulated the most important rules in SP 800-53, “Security and Privacy Controls for Information Systems and Organizations,” but other important documents include FIPS-199, “Standards for Security Categorization of Federal Information and Information Systems,” and SP 800-30, “Guide for Conducting Risk Assessment.” There’s a lot of detail in these documents, far beyond the scope of this article. But to give you a sense of what you’re up against, we’ll take a closer look at these high-level requirements of the law:
Keep an inventory of your information systems
Categorize the risk level of your data and systems
Maintain a system security plan
Use security controls
Conduct risk assessments
Certification and accreditation
Continually monitor your systems
Inventorying information systemsFederal agencies must keep track of information systems that they control or operate, as well as the interdependencies between those systems and interdependencies. They also need to keep track of those systems outside agency control, including those within an agency’s encrypted cloud.Categorizing risk: FISMA high, moderate, and lowYou’ll need to categorize all data and IT systems under the FISMA umbrella according to the risk that a breach or other security problem poses to the relevant agency—the risk categories are defined as high, moderate, or low. Low-risk systems generally contain public information that doesn’t require safeguarding. A moderate-risk system may contain sensitive info and will require more security. A high-impact system contains information whose loss or compromise would present a grave risk to the U.S. government. An agency’s encrypted cloud environment must be categorized as well. NIST SP 800-60, “Guide for Mapping Types of Information and Information Systems to Security Categories,” goes into more detail.Maintaining a system security planAll agencies must develop and maintain a plan that defines how that agency will implement security controls; this plan is officially called a System Security Plan, or SSP. The SSP must be updated regularly and include a Plan of Action and Milestones (POA&M). Basically, the purpose is to ensure that agencies are always staying proactive about their security. Using FISMA controlsIn FISMA-speak, controls or security controls are specific countermeasures that can protect the confidentiality, integrity, and availability of an information system. Among other things, NIST SP 800-53 includes an extensive catalog of suggested security controls for FISMA compliance. That doesn’t mean you have to implement all of those controls to achieve compliance; rather, you should implement those that are relevant to your organization and systems. The controls you do select should be documented in your SSP.Conducting risk assessmentsAgencies are expected to conduct a risk assessment whenever they make changes to their systems. This process can help determine if additional controls are necessary to provide extra protection. A NIST-defined six-step process known as the Risk Management Framework (RMF) is used to conduct this assessment.  FISMA certification and accreditationCertification and accreditation represent the final step in the process of getting approval for a particular information system for federal government use. In short, certification involves reviewing and documenting all security measures taken in line with the areas outlined above, and accreditation involves presenting that information to the Authorizing Official and receiving the Authorization To Operate. For more details on how this works, see the RSI Security blog post on the subject; the complete process is defined in NIST SP 800-37, “Guide for the Security Certification and Accreditation of Federal Information Systems.”One thing that’s important to keep in mind is that, as with any undertaking of this complexity, the final assessment will be somewhat subjective. Though all the NIST documents we’ve been linking to here to try to quantify matters, in practice the final sign-off decision on a system is made by the Authorizing Officer, a human being. An AO at one agency might grant an ATO to a system, while another agency’s AO might make a different decision about the same system. Conducting continuing monitoringLike any security process, getting FISMA certified isn’t a one-and-done deal. Agencies must monitor systems to detect abnormalities, and perform security impact analyses, ongoing assessments of security controls, and status reporting. That in turn means that contractors have to continuously keep track of their own systems so that they can show the agencies they work with that they’re keeping in line with FISMA’s requirements.FISMA auditThere are a number of processes that might be referred to as a “FISMA audit.” Government agencies must have their FISMA compliance ascertained by the Office of the Inspector General, usually via an audit conducted by a third party; for instance, in 2019 the Department of Energy was audited by the consultancy KPMG. Contractors may also be required to participate in such audits or may have their own audit requirements built into their contract with their agency customers.Contractors wishing to be proactive may themselves pay a third-party company to conduct an audit on their FISMA compliance; KirkpatrickPrice, a consultancy that specializes in such services, has an FAQ outlining what that entails. Any such audit will generally be conducted using the all-important SP 800-53 as a framework. FISMA compliance checklistThat’s a lot of information to process, and it’s really only the tip of the iceberg: there’s a reason so many specialist companies exist to guide you through the FISMA compliance maze. But if you’re looking for a quick-and-dirty checklist on how you should be thinking about a big picture approach to compliance, you could do worse than these three tips from the Digital Guardian blog:
Classify information as it is created: This will allow you to prioritize security controls and policies to apply the highest level of protection to your most sensitive information.
Automatically encrypt sensitive data: This should be a given! Ideally, you would use a tool that can encrypt sensitive data based on its classification level or when it is put at risk.
Maintain written evidence of FISMA compliance: Everything in dealing with the federal government needs to be meticulously documented. Stay on top of FISMA audits by maintaining detailed records of the steps you’ve taken.

Copyright © 2021 IDG Communications, Inc.
originally appeared on Source link

Tagged with:

Leave a Reply