INFOJET.org

The Federal Information Security Modernization Act of 2014 (FISMA) defines incident as an occurrence that (A) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (B) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.

Notification Requirement

Agencies must report information security incidents, where the confidentiality, integrity, or availability of a federal information system of a civilian Executive Branch agency is potentially compromised, to the NCCIC/US-CERT with the required data elements, as well as any other available information, within one hour of being identified by the agency’s top-level Computer Security Incident Response Team (CSIRT), Security Operations Center (SOC), or information technology department. In some cases, it may not be feasible to have complete and validated information for the section below (Submitting Incident Notifications) prior to reporting. Agencies should provide their best estimate at the time of notification and report updated information as it becomes available. Events that have been found by the reporting agency not to impact confidentiality, integrity or availability may be reported voluntarily to US-CERT; however, they may not be included in the FISMA Annual Report to Congress.

In 1986, theUnited States Congress enacted the Computer Fraud and Abuse Act (CFAA), as an amendment to18 U.S.C. 1030. The CFAA has since been amended multiple times to address advancements in technologyand cybercrime. The CFAA criminalizes knowingly accessing a computer without authorization, obtainingprotected information, with the intent to defraud, intentionally causing unauthorized damage to a protectedcomputer, knowingly and with intent to defraud trafficking in passwords or access information, and extortioninvolving computers.

Managing cyber risks requires building a Culture of Cyber Readiness. The Culture of Cyber Readiness has six Essential Elements:

Yourself

You, as leader of your organization are an essential element of your organization’s Culture of Cyber Readiness. Your task for this element is to drive cybersecurity strategy, investment and culture.

Actions For Leaders

Action to Take in Consultation with IT

To learn more about how you can drive cybersecurity strategy, investment and culture, explore the Cyber Essentials Toolkit on this element.

Your Staff

As users of your organization’s digital equipment and systems, your staff are essential elements of your organization’s Culture of Cyber Readiness. Your task for this element is to develop cybersecurity awareness and vigilance.

Actions For Leaders

Actions to Take in Consultation with IT

Your Systems

As the infrastructure that makes your organization operational, your systems are an essential element of your organization’s Culture of Cyber Readiness. Your task for this element is to protect critical assets and applications.

Action For Leaders

Actions to Take in Consultation with IT

Your Surroundings

As your organization’s digital workplace, this is an essential element of your organization’s Culture of Cyber Readiness. Your task for this element is to ensure only those who belong on your digital workplace have access to it.

Actions to Take in Consultation with IT

Your Data

Your data, intellectual property, and other sensitive information is what your organization is built on. As such, it is an essential element of your organization’s Culture of Cyber Readiness. Your task for this element is to make backups and avoid loss of information critical to operations.

Action For Leaders

Actions to Take in Consultation with IT

Your Crisis Response

As your strategy for responding to and recovering from compromise, this is an essential element of your organization’s Culture of Cyber Readiness. Your task for this element is to limit damage and quicken restoration of normal operations.

Actions For Leaders

Action to Take in Consultation with IT

Booting Up: Things to Do First

Even before your organization has begun to adopt a Culture of Cyber Readiness, there are things you can begin doing today to make your organization more prepared against cyber risks.

Backup Data

Employ a backup solution that automatically and continuously backs up critical data and system configurations.

Multi-Factor Authentication

Require multi-factor authentication (MFA) for accessing your systems whenever possible. MFA should be required of all users, but start with privileged, administrative, and remote access users.

Patch &Update Management

Enable automatic updates whenever possible. Replace unsupported operating systems, applications and hardware (replace network hardware like routers 3 years after purchase and computing devices 5 years after purchase). Test and deploy patches quickly.

Recommendations

As technology continues to evolve, cyber threats continue to grow in sophistication and complexity. Cyber threats affect businesses of all sizes and require the attention and involvement of chief executive officers (CEOs) and other senior leaders. To help companies understand their risks and prepare for cyber threats, CEOs should discuss key cybersecurity risk management topics with their leadership and implement cybersecurity best practices. The best practices listed in this document have been compiled from lessons learned from incident response activities and managing cyber risk.

What should CEOs know about the cybersecurity threats their companies face?

What can CEOs do to mitigate cybersecurity threats?

The following questions will help CEOs guide discussions about their cybersecurity risk with management:

Recommended Organizational Cybersecurity Best Practices

The cybersecurity best practices listed below can help organizations manage cybersecurity risks.

Cybersecurity evolution should eventually lead to a zero-trust environment where devices, services and people will be required to continually request access to critical systems and data. Unless otherwise stated, all access is denied by default in a zero trust environment.

Fast Cybersecurity Policies for broke, time-starved small businesses. If you are a broke small business and do not have any money and little time to spend on making cybersecurity policies, use the US Federal Communications Commission (FCC) CyberPlanner to make policies fast. The FCC policies are somewhat out of date but it will be better to have these policies fast than no policies at all.

Cloud Computing Environment

Introduction

The Federal Government launched the Federal Risk and Authorization Management Program (FedRAMP) in June 2012 to account for the unique security requirements surrounding cloud computing. FedRAMP consists of a subset of NIST Special Publication (SP) 800-53 security controls targeted towards cloud provider and customer security requirements.

Based on NIST guidance, FedRAMP control baseline, industry best practices, and the Internal Revenue Service (IRS) Publication 1075, this guidance document provides agencies guidance for securing FTI in a cloud environment. These requirements are subject to change, based on updated standards or guidance. Agencies and their cloud providers should also review the requirements of FedRAMP and ensure overall compliance with these guidelines.

As defined by the National Institute of Standards and Technology (NIST), “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable, computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and consists of five essential characteristics, three service models and four deployment models.”

As agencies look to reduce costs and improve reliability of business operations, cloud computing offers an alternative to traditional data center models. Cloud solutions reduce direct hardware expenditures and may eliminate redundant operations and consolidate resources.

However, while cloud computing offers many potential benefits, it is not without risk. The primary security concerns with cloud computing are:

Monitoring and addressing security issues that arise with FTI in a cloud environment remain in the purview of the agency. Limiting access to authorized individuals becomes a much greater challenge with the increased availability of data in the cloud, and agencies may have greater difficulties to identify FTI when segregated or commingled in the cloud environment. Agencies that utilize a public cloud model should have increased oversight and governance over the security controls implemented by their cloud provider.

Cloud Computing Definition

Five essential characteristics define a cloud computing environment and differentiate it from a traditional computing environment:

Service and Deployment Models

An agency’s cloud implementation is a combination of a service model and a deployment model.

Service Models

The resource stack provided as part of the cloud solution and the responsibilities which fall between the agency and the cloud provider define service models. NIST SP 800-145 outlines the possible service models that may be employed during a cloud implementation.

Deployment Models

Organizations have several choices for deploying a cloud computing model, as defined by NIST in SP 800-145:

The following table summarizes the four deployment models, and the relationship of system management, ownership and location for each model.

Table 1: Cloud Deployment Models

	System Management	System Owners	System Location
Public	Provider	Provider	Provider Site
Private	Agency or Provider	Agency or Provider	Agency or Provider Site
Community	Agency or Provider	Agency or Provider	Agency or Provider Site
Hybrid	Agency or Provider	Agency or Provider	Agency or Provider Site

The risk to data varies in each of the four deployment models, with of private cloud typically being the lowest risk model, and public cloud being the highest risk model. Depending on the deployment model, compensating controls can be accepted in place of the mandatory requirements provided those compensating controls must provide the same level of protection as mandatory controls for safeguarding FTI.

Security Responsibility

The service and deployment model used in a cloud computing environment will determine the responsibility for security controls implementation between the agency and the cloud provider for the protection of FTI that is stored or processed cloud environment. The delineation of security control responsibility is heavily dependent on the service and deployment models of the solution the agency is adopting. For example, if the solution is a SaaS e-mail solution, the agency may be responsible for a small subset of security control responsibilities including Access Controls. If the agency is deploying their own applications to a PaaS or IaaS solution, they will have greater responsibility for securing the application layer, and potentially the platform and middleware; and may have responsibilities in almost all of the Publication 1075 (NIST 800-53) control families with the exception of possibly the personnel and physical security requirements. Figure 1 is a notional illustration of the differences in scope between the cloud consumer (agency) and cloud provider for each of the service models discussed above.

Figure 1. Security Control Responsibility

Figure 1 is a notional illustration of the differences in scope between the cloud consumer (agency) and cloud provider for each of the service models discussed above.

Defining a Cloud within the context of the Office of Safeguards

The above definitions, largely created by NIST, define cloud computing for the industry at large. Due to the nature of relationships between IRS, partner agencies, consolidated data centers and third-party providers, there are certain circumstances to consider when determining whether FTI resides in a cloud environment:

Examples of Cloud Environments (non-comprehensive) where Safeguards would require a 45-day Notification and would subsequently assess the solution using the Safeguards Cloud Computing Safeguards Computer Security Evaluation Matrix (SCSEM) during an onsite review:

Specific examples where Safeguards would not consider an agency solution to be a cloud environment requiring 45-day notification and use of the Cloud Computing SCSEM during an on-site review.

Mandatory Requirements for FTI in a Cloud Environment

The following mandatory controls are applicable for all cloud service and deployment models. However, as stated earlier, depending on the deployment model, compensating controls can be accepted in place of the mandatory requirements provided those compensating controls afford the same level of protection as mandatory controls for safeguarding FTI. Potential compensating controls will be evaluated by the IRS Office of Safeguards as part of the cloud computing notification (see requirement below).

To utilize a cloud computing model to receive, transmit, store or process FTI, the agency must be in compliance with all Publication 1075 requirements. The following mandatory requirements are in effect for introducing FTI to a cloud environment:

Use tab to go to the next focusable element

FedRAMP Authorization

Agencies maintaining FTI within cloud environments must engage services from FedRAMP certified vendors to complete the authorization framework resulting in an Authority to Operate.

Cloud solutions used to receive, process or store must undergo a complete assessment using the FedRAMP Authorization Framework from an authorized third-party assessment organization (3PAO). The assessment must result in an Authority to Operate granted by the FedRAMP organization. Only FedRAMP-authorized solutions may receive, process, store or transmit FTI. The discovery of FTI in a non-FedRAMP cloud during an onsite Safeguards review will result in a Critical finding.

Onshore Access

Agencies must leverage vendors and services where (i) all FTI physically resides in systems located within the United States; and (ii) all access and support of such data is performed from the United States.

Identification of requirement that FTI may not be accessed by contractors located “offshore”, outside of the United States or its territories. All physical locations where FTI is stored, transmitted, processed and/or received must remain within the United States. This includes all primary and secondary data centers and any backup facilities. Additionally, cloud environments (and any components, including, but not limited to, storage, virtualization, operating systems and networking) may not be accessed by vendor administrators from networks outside the United States. Further, FTI may not be received, stored, processed or disposed via information technology systems located off-shore. The discovery of offshore storage and/or access to FTI during an onsite Safeguards review will result in a Critical finding.

Physical Description

Agencies and their cloud providers must provide a complete listing of all data centers within the cloud environment where FTI will be received, processed, transmitted or stored.

In addition to certifying all data centers, environments and equipment reside onshore, the agency and provider must disclose all physical locations where FTI is received, processed, stored and maintained. Safeguards cannot approve the implementation of cloud solutions without a full understanding of the physical locations where FTI is processed, in addition to understanding the logical protections the solution provides.

45-Day Notification

The agency must notify the IRS Office of Safeguards at least 45 days prior to transmitting FTI into a cloud environment.

To utilize a cloud environment that receives, processes, stores or transmits FTI, the agency must meet the following mandatory notification requirement:

The agency must submit a Cloud Computing Notification (see Publication 1075 Section 9.4.1, Cloud Computing

Environments) to the IRS Office of Safeguards at least 45 days prior to transmitting FTI into a cloud environment.

The IRS strongly recommends that any agency planning on using a cloud computing model to receive, process, store and/or transmit FTI, contact the Office of Safeguards at SafeguardReports@irs.gov to schedule a conference call to discuss the details of the planned cloud computing implementation.

Data Isolation

Software, data and services that receive, transmit, process or store FTI must be isolated within the cloud environment so that other cloud customers sharing physical or virtual space cannot access other customer data or applications.

One of the most common compliance issues with FTI is data location. Use of an agency-owned computing center allows the agency to structure its computing environment and to know in detail where FTI is stored and what safeguards are used to protect the data.

In contrast, a characteristic of many cloud computing services is detailed information about the location of an organization’s data is unavailable or not disclosed to the service subscriber. This makes it difficult to ascertain whether sufficient safeguards are in place and whether legal and regulatory compliance requirements are being met.

IRS Publication 1075, section 5.2, Commingling of FTI, recommends separating FTI from other information to the maximum extent possible. Organizing data in this manner will reduce the likelihood of unauthorized data access and disclosure. If complete separation is not possible, the agency must label FTI down to the data element level. Labeling must occur prior to introducing the data to the cloud and the data must be tracked accordingly through audit trails captured for operating systems, databases and applications that receive, store, process or transmit FTI.

IRS Publication 1075, section 9.3.3, Audit & Accountability, states audit logs must enable tracking activities taking place on the system. It also contains requirements for creating audit-related processes at both the application and system levels. Within the application, auditing must be enabled to the extent necessary to capture access, modification, deletion and movement of FTI by each unique user. This auditing requirement also applies to data tables or databases embedded in or residing outside of the application. Included in that section, as well, is the requirement for agencies to “coordinate the access and protection of audit information” with its cloud providers.

Service Level Agreements (SLA) and Contracts

The agency must establish security policies and procedures based on IRS Publication 1075 for how FTI is stored, handled and accessed inside the cloud through a legally binding contract or SLA with their third-party cloud provider.

While the agency may not have direct control over FTI at all times, they ultimately maintain accountability while it is in the cloud, and the ownership rights over the data must be firmly established in the service contract to enable a basis for trust. The SLA is a mechanism to mitigate security risk that comes with the agency’s lack of visibility and control in a cloud environment. It is important that agencies establish SLAs with cloud providers that clearly identify Publication 1075 security control requirements and determine who has responsibility (provider, customer) for their implementation. At a minimum, SLAs with cloud providers must include:

IRS Publication 1075, Exhibit 7 contract language;
Identification of computer security requirements the cloud provider must meet per IRS Publication 1075, section 9, Computer System Security, which provides the security control requirements to include in agreements with third-party cloud providers;
Identification of requirements for cloud provider personnel who have access to FTI. All cloud provider personnel with logical FTI access must have a justifiable need for that access and submit to a background investigation;
Identification of requirements for incident response to ensure cloud providers follow the incident notification procedures required by IRS Publication 1075. In the event of an unauthorized disclosure or data breach, the cloud provider and agency must report incident information to the appropriate Agent-in-charge, TIGTA and the IRS Office of Safeguards within 24 hours according to Publication 1075, section 10, Reporting Improper Inspections or Disclosures;
Agreement on the scope of the security boundary for the section of the cloud where FTI is accessible and systems with FTI reside. The agency must ensure that boundary details are included in the SLA between the two parties;
Clearly state that agencies have the right to require changes to their section of the cloud environment and cloud providers will comply with IT policies and procedures provided by the agency;
IRS Publication 1075, Exhibit 6, Contractor 45-day Notification Procedures contains a requirement for notifying the IRS prior to executing any agreement to disclose FTI to a contractor the cloud provider may utilize, or at least 45 days prior to the disclosure of FTI, to ensure appropriate contractual language is included and that contractors are held to safeguarding requirements and
Identification of cloud provider employee awareness and training requirements for access to FTI and incident response. IRS Publication 1075, 6.2, Training Requirements states employees must be certified to understand the agency’s security policy and procedures for safeguarding IRS information prior to being granted access to FTI, and must maintain their authorization to access FTI through annual recertification.

Data Encryption in Transit

FTI must be encrypted in transit within the cloud environment. All mechanisms used to encrypt FTI must be FIPS 140-2 compliant, and operate utilizing the FIPS 140-2 compliant module. This requirement must be included in the SLA.

IRS Publication 1075 requires encryption of FTI in transit in Section 9.3.16.6, Transmission Confidentiality and Integrity (SC-8). The agency must ensure that encryption requirements are included in contracts with third-party providers. The IRS does not advocate specific mechanisms to accomplish encryption as long as they are FIPS 140-2 compliant and configured securely. Additionally, agencies must retain control of the encryption keys used to encrypt and decrypt the FTI at all times and be able to provide information as to who has access to and knows information regarding the key passphrase.

Data Encryption at Rest

FTI must be encrypted while at rest in the cloud using a NIST-validated, FIPS 140-2 compliant encryption module. Encryption protects the confidentiality and integrity of the data and provides a methodology for segmenting an agency’s data from others while stored. This requirement must be included in the SLA.

In a cloud environment, protection of data and data isolation are a primary concern. Encryption of data at rest provides the agency with assurance that FTI is being properly protected in the cloud. NIST’s SP 800-144 recommends, “Data must be secured while at rest, in transit and in use, and access to the data must be controlled.”

The IRS does not advocate specific mechanisms to accomplish encryption as long as they are FIPS 140-2 compliant and configured securely. Additionally, agencies must retain control of the encryption keys used to encrypt and decrypt the FTI at all times and be able to provide information as to who has access to and knows information regarding the key passphrase. If the agency is able to satisfy this requirement, effectively preventing logical access to the data from the cloud vendor, agencies may use cloud infrastructure for data types that have contractor-access restrictions.

Persistence of Data in Relieved Assets

Storage devices where FTI has resided must be securely sanitized and/or destroyed using methods acceptable by National Security Agency/Central Security Service (NSA/CSS). This requirement must be included in the SLA.

If a storage device fails, or in situations where the data is moved within or removed from a cloud environment, actions must be taken to ensure residual FTI is no longer accessible. The destruction or sanitization methods apply to both individual devices that have failed as well as in situations where the agency removes data from the cloud environment or relocates FTI to another environment.

The technique for clearing, purging and destroying media depends on the type of media being sanitized. Acceptable physical destruction methods would include disintegration, incineration, pulverizing, shredding, or melting. Repurposed media must be purged to ensure no residual FTI remains on the device.

As there are varied approaches towards secure sanitization based on provider specifications, cloud providers should consult their data storage provider to determine the best method to sanitize the asset. If the storage device will no longer be in service, the residual data must be purged using Secure Erase or through degaussing using a NSA/CSS approved degausser.

The cloud provider is required to notify the agency upon destroying or repurposing storage media. The agency must verify that FTI has been removed or destroyed and notify the IRS Office of Safeguards of the destruction of storage media in the agency’s annual Safeguard Security Report (SSR).

Risk Assessments

The agency must conduct an annual assessment of the security controls in place on all information systems used for receiving, processing, storing and transmitting FTI. The IRS Office of Safeguards will evaluate the risk assessment as part of the 45 Day notification requirement.

Agencies are required to conduct a risk assessment (or update an existing risk assessment, if one exists) when migrating FTI to a cloud environment. Subsequently, the risk assessment must be reviewed annually to account for changes to the environment. The implementation and an evaluation of the associated risks should be part of the risk assessment. The IRS Office of Safeguards will evaluate the risk assessment as part of the above notification requirement.

Multi-Factor Authentication

Cloud implementations which truly represent remote access from the internet must incorporate multi-factor authentication.

Remote access to the cloud where the access is available over the public internet requires multi-factor authentication. Multi-factor authentication requires at least two of the three criteria: 1) something a user knows (e.g., password); 2) something a user has (e.g., hardware cryptographic token) and 3) something a user is (e.g., using biometric information).

Security Control Implementation

Customer defined security controls must be identified, documented and implemented. The customer defined security controls, as implemented, must comply with Publication 1075 requirements.

Cloud providers may designate selected controls as customer defined. For customer defined security controls, the agency must identify, document and implement the customer defined controls, in accordance with Publication 1075. Implementation of some controls may need to be done in partnership with the agency’s cloud provider, however the agency has primary responsibility for ensuring it is completed.

The agency’s capability to test the functionality and security control implementation of a subsystem within a cloud environment is more limited than the ability to perform testing within the agency’s own infrastructure. However, other mechanisms such as third-party assessments may be used to establish a level of trust with the cloud provider.

Note: IRS Office of Safeguards will test agency-managed security controls during onsite reviews using the appropriate SCSEM for applications, operating systems, database management systems, etc. This determination will be made based on the cloud service model (i.e., PaaS, IaaS, SaaS) used to process FTI and will be discussed prior to any onsite review. The Office of Safeguards onsite review team will leverage the Cloud Computing SCSEM to assess many of the service provider security control implementations.

Resources

(1) (Policies): FCC Cyberplanner , https://www.fcc.gov/cyberplanner(SANS.org also has nuerous, pre-written cybersecurity policies for small/medium businesses)

Cybercheck all Staff, Devices and Sevices (including all company generated and external APIs (use Salt Security to find and cybercheck APIs)

Fast Incident Response Plan for 1-person business storing all sensitive data on payment processor Square:

If you suspect unauthorized access to your Square account (squareup.com) such as by receiving a message, email or notification from Square indicating your account was accessed when you did not access your account, perform the following incident response steps:

(1) Immediately change your account access information (username, password, authenticator app, biometric settings).

(3) Notify any customers with credit cards saved on file to change their credit card information if it is confirmed that credit card information was obtained. Recommend changing credit card information if unauthorized access occurred but loss of credit card information was not confirmed. (For CA, any CA resident must be notified of a breach, see https://oag.ca.gov/privacy/databreach/reporting)

(4) Report to applicable state and federal agencies if the number of breached records exceeds applicable thresholds for each industry. For CA, report a data breach to the State of CA OAG if the number of breached records (# of CA residents) exceeds 500 (https://oag.ca.gov/privacy/databreach/report-a-breach ).