Although the Commonwealth has taken, and continues to take, measures to improve its information technology (IT) operations and security, we identified areas where IT administration could be improved to ensure the effective and efficient adoption of Internet of Things (IoT) technology. These areas include improving information security policies, standards, and guidelines; creating an information security incident response plan; and connecting IoT devices to the Commonwealth network with the involvement of the Commonwealth’s chief information officer (CCIO) or his/her designee.
The Commonwealth’s Enterprise Information Security Policy Does Not Offer Guidelines on IoT adoption.
The Commonwealth’s Enterprise Information Security Policy (EISP) does not provide guidance to state agencies regarding the IoT. Specifically, it lacks controls to ensure that a minimum level of security is provided throughout the Commonwealth for the IoT, as well as optional control recommendations based on industry best practices, like those of the National Institute of Standards and Technology (NIST). Without adequate administration through policies, standards, and guidelines, the Commonwealth may be subject to security vulnerabilities that could affect its operations, safety, and privacy.
According to Section 4 of Executive Order 504,
The Commonwealth’s Chief Information Officer . . . shall have the authority to:
- issue detailed guidelines, standards, and policies governing agencies’ development, implementation and maintenance of electronic security plans.
Such guidelines, standards, and policies would support the Commonwealth’s information security goals by protecting its information. To effect proper security over Commonwealth information, the CCIO should establish detailed policies, procedures, and standards regarding the connection, use, and security of IoT devices.
According to a NIST interagency paper, NISTIR 8200—Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things (IoT), the following are examples of gaps between existing cybersecurity standards and those that apply to the IoT:
Cyber Incident Management: best practices for remediation when software patches are not feasible . . .
Network Security: existing standards may require updates and/or new standards will be needed to address IoT networks that have the potential for spontaneous connections . . .
Security Automation & Continuous Monitoring: since the IoT ecosystem is heterogeneous, IoT device manufacturers and security vendors may need to develop device-specific agents and interfaces for monitoring until the standards are tailored for the various IoT use cases and implemented in products . . .
System Security Engineering: need to determine if generic system security engineering standards . . . consider IoT systems.
Reasons for Noncompliance
Management at the Executive Office of Technology Services and Security (EOTSS)7 acknowledged that the office’s policies, procedures, and standards lacked specificity regarding the IoT. EOTSS stated that it was in the process of developing new policies, procedures, and standards. Despite the lack of specific IoT guidance, EOTSS stated that many of the security controls required to mitigate and counter IoT-based attacks were already fundamental to the existing network security, access controls, and other well-established security areas.
The Commonwealth Does Not Have a Formally Documented Information Security Incident Response Plan.
EOTSS has an Enterprise IT Security Incident Response Policy and Enterprise Security Incident Handling Procedures, but it does not have a documented incident response plan. Such a plan would establish specific procedures EOTSS would follow to respond to and resolve any detected incidents affecting the security of the Commonwealth’s IT hardware, software, and data related to IoT devices. Without an incident response plan, the Commonwealth has inadequate assurance that it can effectively respond to and minimize the risk of cyberattacks when they happen.
The NIST Incident Response Plan establishes the following best practices:
a. Develops an incident response plan that:
- Provides the organization with a roadmap for implementing its incident response capability;
- Describes the structure and organization of the incident response capability.
Reasons for Noncompliance
According to EOTSS management, the office has a draft incident response plan but has not yet published it.
The DCAMM Didn't Involve the CCIO in a Project That Connected IoT Devices to MAGNet
The Division of Capital Asset Management and Maintenance (DCAMM) procured the contract for a project that involved connecting IoT devices to the Massachusetts Access to Government Network (MAGNet) without involving the CCIO. Because the CCIO was not given the opportunity to participate in the project, there is inadequate assurance that the connected devices were properly connected, and there is an increased network security risk that IoT devices will be exposed to cyberattacks.
Section 11(a) of Executive Order 549 states,
The CCIO shall supervise all Executive Department IT project selection, development and maintenance, and shall supervise procurement in consultation with the Assistant Secretary for Operational Services.
Reasons for Noncompliance
DCAMM did not contact the CCIO to participate in this project because it classified the project as an energy group project, not an IT project. At the time of our audit, there were no controls in place that would allow the CCIO to monitor executive departments’ compliance with the above requirement, nor are there policies and procedures that require executive agencies to consult with the CCIO on any projects they are undertaking that may contain IT-related components to learn whether the CCIO should be involved in supervising the projects.
- EOTSS should develop guidelines specifically for the IoT in its current EISP and incorporate them into its security policy. It could use NISTIR 8200—Interagency Report on Status of International Cybersecurity Standardization for the Internet of Things (IoT) for reference.
- EOTSS should develop a documented information security incident response plan.
- EOTSS should implement a policy to ensure that all state agencies considering undertaking any projects related to MAGNet contact the CCIO and learn whether the CCIO should be involved in supervising the projects.
The responses to Findings 1a and 1b were provided by EOTSS. Regarding Finding 1a, the agency stated,
EOTSS was established by the Governor on August 1, 2017 replacing the agency commonly known as MassIT. The role of EOTSS was greatly expanded from what had been established for MassIT (or the Information Technology Division) through Executive Orders from previous administrations. These Executive Orders, specifically E.O. 504, gave MassIT limited oversight into IT security across the Commonwealth Executive Department but still allowed for significant fragmentation within IT and IT security.
Following its establishment as the central IT authority for the Executive Department, EOTSS created the first set of comprehensive Enterprise IT Policies and Standards, producing sixteen documents that cover core security principles. These documents will be reviewed annually; supporting documents, including Guidelines and Procedures, will be added as needed. EOTSS leveraged well-established security frameworks, mapping policies and guidelines to the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF), the NIST Cybersecurity Framework (CSF), and the Center for Internet Security’s “Critical Security Controls” (“the CIS Top 20”).
EOTSS recognizes the growing impact of IoT and anticipates the need for additional guidelines. However, as the [Office of the State Auditor, or OSA] report explains, “the adoption of IoT technology has been slow in the Commonwealth.” EOTSS believes that the focus must be on expanding and strengthening the underlying security infrastructure and operations that will be needed to support any such guidelines. Additionally, the growth of IoT has been challenging for many organizations, including those referenced in the [OSA] report. The NIST report cited by [OSA], Draft NISTIR 8200, was released in February of this year, was open for comments until April of this year, and remains a draft publication. This document includes no fewer than seven potential definitions of the term “Internet of Things.” As NIST, CIS, and other high-quality security standards organizations clarify definitions and develop tested guidelines for this rapidly expanding area of technology, EOTSS will ensure that the Commonwealth’s policies and standards include appropriate security controls.
We note that the lack of the specific use of the term “Internet of Things” in our security policies does not indicate the absence of relevant security controls. . . . The majority of the recommendations in the draft NIST report are covered in other EOTSS policies, standards, guidelines and procedures including the following:
- Encryption at rest and in transit
- Identity and Access Management
- Centralized security log aggregation (SIEM [Security Information and Event Management])
- Ongoing discovery and vulnerability scans
While IoT devices represent a new threat vector that requires careful analysis, many of the security controls required to mitigate and counter IoT-based attacks are already fundamental to network security, access control, and other well-established security domains.
Regarding Finding 1b, EOTSS stated,
The Commonwealth Incident Response Plan, which unifies the disparate incident response plans developed under E.O. 504, has been in draft form since February and builds on the policies and procedures described above. We expect to publish this Incident Response Plan in the first quarter of Fiscal Year 2019, and we are happy to provide a copy of the draft document to [OSA]. We also note that the development and implementation of a unified Incident Response Plan for the Executive Department is dependent on a number of EOTSS’ IT transformation initiatives, including the “One Network” project and significant upgrades to end user computing security.
The response to Finding 1c was provided by DCAMM:
DCAMM acknowledges that the CCIO was not directly involved in the procurement for the Commonwealth Building Energy [Intelligence] (CBEI) program. DCAMM would like it noted that internal IT staff was consulted early in the CBEI procurement. In addition to the fact that the CBEI program is aimed at energy consumption reduction, the team determined CBEI was not primarily an IT procurement for several reason, including: each of the agencies involved in the CBEI program is responsible to manage its own MAGNet connections; the meters under the CBEI program were already installed and connected under a prior contract; and this stage of the CBEI program would only read utility data (which is already being reported by utility providers).
DCAMM and EOTSS have been in communication for the past 6 months concerning the CBEI program and other energy coordination opportunities. We will be implementing practices recommended in the course of this review, such as developing clear communication roles and responsibilities for any updates to enterprise security policies.
DCAMM would also like to clarify that in its current state the CBEI program is a monitoring program that does not include remote or automated building management. Though a future phase of this program involves reading Building Management System reports (this has not yet been deployed) there is currently a “read only” connection [that] does not control any building systems. The CBEI program provides participating agencies with real-time data on the energy consumption of its facilities. Each agency and facility is then responsible for adjusting building systems locally based upon the data and with recommendations from DCAMM. Should the CBEI program be expanded in the future to include building system controllability, DCAMM would coordinate with EOTSS and address network security concerns.
As noted above, the policies that EOTSS administered during our audit period made no reference to the IoT. OSA acknowledges that EOTSS had mitigating controls in place that protected the Commonwealth’s IT infrastructure. However, given the unique nature of connecting IoT devices to the Commonwealth’s network, the continued expansion of the use of IoT devices by state agencies, and the potential threats involved with the management of these devices, OSA believes that the Commonwealth’s EISP should provide specific guidance to state agencies regarding the IoT. For example, such guidance could include what controls are needed to ensure that a minimum level of security is provided throughout the Commonwealth for the IoT, as well as optional control recommendations based on industry best practices, such as those recommended in NISTIR 8200. Based on its response, EOTSS is taking measures to address our concerns in this area.
As stated above, during our audit period, EOTSS did have an Enterprise IT Security Incident Response Policy and Enterprise Security Incident Handling Procedures. However, in its response, EOTSS acknowledges that the Commonwealth Incident Response Plan has been in draft form since February. Based on its response, EOTSS is taking measures to publish the Commonwealth Incident Response Plan in the near future.
Based on its response, DCAMM is taking measures to address our concerns regarding working with EOTSS on its CBEI Program. OSA believes that in addition to this, EOTSS should implement a policy to ensure that all state agencies that consider undertaking any projects related to MAGNet contact the CCIO and learn whether the CCIO should be involved in supervising the projects.
|Date published:||September 5, 2018|