In the post Anatel's Cybersecurity Requirements (Act 77/21), we discussed Anatel's Act 77/21, which defines cybersecurity requirements for telecommunications equipment sold in the country. At that time, we discussed the Act in general and examined its requirements.
In this blog post, we share our experience with a security assessment of an IoT device based on the requirements prescribed by the regulation, providing an overview of the assessment and some of the main practical implications of the Act for device manufacturers.
As part of its analysis of Anatel's Act 77/21, SiDi assessed the compliance with the provisions of a very common IoT device on the market: a smart speaker.
The assessment presented here is merely illustrative and is void for the purposes of homologation/certification before the agency. It is intended solely as a proof of concept for the process of assessing compliance with the requirements set out in Anatel Act 77/21.
The following sections summarize the main aspects of the assessment and describe some of the highlights of the process.
As a starting point for the analysis discussed here, a checklist was drawn up (a document containing a list of requirements prescribed by the standard), in order to guide the analysis process in the light of the provisions. Checklists are a widely used tool in the security testing and analysis niche and their main purpose is to avoid errors and omissions in the evaluation process in terms of guaranteeing its completeness and ensuring broad test coverage.
The checklist developed to carry out the analysis includes 52 test cases, drawn up on the basis of the requirements - and their practical implications - prescribed by the regulatory agency.
The following paragraphs seek to illustrate how these test cases were elucidated, providing an example of test case derivation from one of the items in requirement 4.1 of Act 77/21.
The purpose of the excerpt below is to provide an overview of how, from a high-level requirement of the Act, the derivation of granular test cases took place. Later, in the Analysis Highlights section, the reader will see how the actual verification of some of the test cases that resulted from the derivation process illustrated here took place.
Requirement 4.1 of the Act, in its item "a)", prescribes:
"4.1. When applying for telecommunications product approval from Anatel, the applicant must submit a declaration:
(a) indicating that the product was developed in compliance with the principle of security by design;"
The principle of security by design dictates that software products should, from the outset, be designed to be fundamentally secure. In order to adhere to it, it is expected that, from the earliest stages of the SDLC (Software Development Life Cycle), a software product will incorporate certain security engineering concerns, namely:
Seven points of analysis were then derived from a single requirement. Similarly, test cases were derived from the other security requirements prescribed by Anatel Act 77/21, totaling the 52 cases provided for in the checklist.
In this section, some of the main points of the analysis are presented (non-exhaustive list) and their implications for device manufacturers' SDLC are discussed. For each highlight, the requirement(s) to which they refer are first introduced. Then, the analysis results are presented and their practical implications are discussed.
Among the requirements set out in Act 77/21, requirement 5.1.1, item "c)", prescribes:
"5.1.1 Regarding software/firmware updates:
(c) have mechanisms to inform the user of software/firmware changes implemented due to updates, especially those related to security."
The requirement in question raises the need for manufacturers of devices regulated by Anatel's Act No. 77/21 to make their patching programs (making security updates available for their products) transparent, in order to clarify to users the changes their devices have undergone with each update delivered.
During the evaluation, it was found that although the manufacturer of the smart speaker analyzed provides the end user with information about the software/firmware updates available/applied, it is not possible to know precisely what changes have been implemented due to such updates, nor is there a distinction between security updates and updates of another nature, so that if the analysis described here had any validity, the device would not be in compliance with the provisions.
Act 77/21 also prescribes the adoption of security event logging, as stated in requirement 5.1.3, item "e)" (sic):
"5.1.3 Regarding installation and operation:
(e) implement a tool for recording activities (logs) related to, at a minimum, user authentication, changing system settings and system operation."
During the analysis reported here, it was found that the smart speaker analyzed provides end users with a configuration interface, through which it is possible to access lists of system events.
However, this list is restricted to routine operating events, and it is not possible for the end user - using only the user interfaces provided by the manufacturer - to access logs of more specific events, in order to check entries related to the security-related activities provided for in the regulations, namely: authentication and changing settings. Thus, if the assessment reported here were valid, the smart speaker analyzed would only partially comply with this item of the Act.
This introduces the need for manufacturers to provide means for users to access the security logs of the devices regulated by the Act, either through their own user interface or using interfaces served through other devices, e.g. mobile applications.
Item "f)" of the same requirement prescribes:
"f) Provide documentation describing, as a minimum, the name, version and functionalities of the software/firmware and/or operating system, as well as the full name and version of each open source software incorporated into the system. The documentation may be in electronic format."
Despite providing the software/firmware version of the smart speaker analyzed, the manufacturer does not provide further details. In addition, the manufacturer provides electronic documentation on the device's functionalities.
Finally, the manufacturer provides the portion of the device's code that comes from open source projects, i.e. open source, but there is no structured documentation regarding the code and/or versions of each open source software component incorporated into the system. The required information can be retrieved, however, this could only be done through a technical review of the source code, so if the analysis discussed here had any validity, the device would only partially meet the requirement analyzed.
The requirement in question therefore requires manufacturers to be very transparent about the device's software/firmware, both in terms of its specific functionalities and the use of open source components.
Interestingly, Anatel's Act No. 77/21 prescribes some requirements regarding secure access to the device's settings:
"5.1.4 Regarding access to equipment configuration:
c) Force, on first use, the change of the initial password for access to the equipment configuration."
However, the configuration of the smart speaker analyzed is done automatically, through a mobile application paired via Bluetooth, upon first use, and does not require the user to access a configuration interface through an authentication mechanism. Therefore, here, it remains to be seen what the agency's understanding would be: (i) would the first use of the device in question need to be redesigned to provide for the use of credentials, in order to meet the requirement of alteration upon first authentication, provided for in the Act? Or (ii) due to the nature of the device, for domestic use, would it be exempt from the need to meet this requirement? It is understood that this aspect of the requirement is debatable. Therefore, the results of the analysis reported here on this item are inconclusive.
Requirement 6.1.6 of the Act prescribes:
"6.1.6. Have implemented Coordinated Vulnerability Disclosure processes based on internationally recognized good practices and recommendations."
During the analysis of the device, it was found that, although the manufacturer has a coordinated vulnerability disclosure program, this program does not include the smart speaker whose analysis is reported here. Therefore, if the analysis described here had any validity, the device would not comply with the provisions.
It is worth mentioning that the fact that Act No. 77/21 provides for a coordinated vulnerability disclosure program is an advance that is perfectly in line with a practice that is already widespread in the software industry, such as the coordinated vulnerability disclosure programs of benchmarks in the sector, such as Google (e.g. "Android Security Bulletins" program - covering the Android mobile operating system) and Microsoft (e.g. "Microsoft Security Update Guides" - covering multiple company products).
Of the 52 items checked, if the analysis reported here had any validity, it would be found that the smart speaker analyzed complied with only 9 items of the Act.
As for the others, they are divided into (i) items which the device certainly does not meet, (ii) items which are partially met and (iii) inconclusive items, either because of interpretative issues in the regulations which deserve clarification, or because of a lack of internal information from the manufacturer about the device, to which there was no access during the analysis reported here.
Thus, assuming that the smart speaker analyzed is a representative and average example of the universe of devices that Act 77/21 sets out to regulate, there is a need for device manufacturers to make adjustments so that they can meet the requirements of the Act under discussion.
In addition, there is also a need for clarification from the agency on some of the points set out in the regulation, since not everything that is set out seems to be applicable to the entire universe of devices that Anatel's Act 77/21 potentially proposes to regulate.
As the next steps in the study of Act 77/21, it is suggested that Anatel clarify the requirements whose results were inconclusive in this analysis. It is also suggested that the test reported here be expanded to include devices of other kinds, resulting in a more representative sample of the universe of products regulated by the Act.