Tuesday, September 23, 2025

CIS Benchmark Cisco Meraki: Network Inventory and Asset Management

This post is focusing on building the Center for Internet Security (CIS) Benchmark for Cisco Meraki. CIS is one of the most respected institutions when it comes to security standards, with CIS Controls being one of the most widely used resources for implementing and securing infrastructures. This benchmark is considered a prescriptive configuration recommendation for Cisco Meraki. This section of the Benchmark will focus on Inventory and Asset Management. 

Why do we need a Benchmark?

Following the configuration guides can sometimes be complicated and without having a logical connection between the different documents, it's almost impossible to ensure that all the necessary security features are enabled. In order to streamline the security implementation, it is recommended to follow security standards. One of the most widely used security standards is CIS Controls, due to its very detailed and practical way of describing the technical and organizational safeguards to build a secure infrastructure. I decided to join CIS as an Editor and Subject-Matter Expert to help the community and the rest of the world. 


Fig.1 CIS Editor with focus on Cisco Meraki

Who is this benchmark for?

This benchmark is intended for system and application administrators, security specialists, auditors, help desk, and platform deployment personnel who plan to develop, deploy, assess, or secure solutions that incorporate Cisco Meraki equipment and solutions.

Network Inventory and Asset Management

Inventory Tracking

Each organization in the Meraki Dashboard has an inventory that tracks Cisco Meraki devices and the networks they belong to. The inventory must be kept up-to-date to manage security effectively. Without a full view of the inventory, it is not possible to ensure proper configuration, patching or security for the assets. 

Fig.1 Organization Inventory

Audit Procedure

Log into the Meraki Dashboard, go to Organization -> Configure  -> Inventory and verify that all claimed devices are in use and assigned to a network.

Mapping: CIS 8.1 Control 1.1, 1.2

Tagging and Naming Convention

Implementing device naming convention and device tagging helps in improving operations, troubleshooting and accountability. Without standardized naming, device management is inefficient, especially in larger deployments. In case of incidents, it is very difficult to identify devices and the troubleshooting process becomes slower. Using a well-defined naming and tagging schema helps the technical staff with operations and the compliance staff with meeting requirements. Maintaining the asset inventory, proper naming and tagging introduces extra overhead. The effort is outweighed by better visibility, reduced risk and more efficient operations. There is no service impact when implementing changes.

Audit Procedure

Verify if the organization has implemented a naming convention schema. Then log into the Meraki Dashboard.

Go to Organization -> Network -> Wireless -> List Verify that the wireless devices have proper naming and tags describing location and ownership.

Go to Organization -> Network -> Switching -> Switches Verify that the Switches have proper naming and tags describing location and ownership.

Go to Organization -> Network -> Security & SD-WAN -> Appliance Status Verify that the Firewalls have proper naming and tags describing location and ownership.

A similar approach should be followed with Mobile Gateways, Cameras and Sensors.

Mapping: CIS 8.1 Control 1.1

Unofficial recommendation. 

Due to the nature of the Benchmark, I won't be able to provide a very detailed guideline in implementing a naming convention and tagging schema. This is very different from organization to organization, and it needs to make sense to the staff that will be using it. There are though some generic guidelines I can provide in this blog post. Some of the key principles to keep in mind are:
  • Documented schema - A document should be written with the structure, so existing and new engineers can easily understand the naming
  • Uniqueness - Every device should have a name that is unique within the domain where it's used.
  • Clarity - The name or tag should make sense and be easy to read. 
  • Scalability - The schema should provide the possibility to add new devices without the risk of running out of space
  • Structure - The name should be split in sections, where each is representing a specific component. 
In medium-sized networks, one of the most common structures I use is BuildingCode-RoomNumber-RackIdentifier-DeviceType-DeviceID. 

Structure: BB-RR-N-DD-II

BB -> Building number (HQ - Headquarters, WH - Warehouse etc.)
RR ->  Room Number ( 204 - Server Room, 103 - Kitchen)
N -> Rack Identifier (R1, R2)
DD -> Device Name (FW, SW, AP)
II -> Device Identifier (01, 10)

While this model might not fit to any customer size, some of the sections can be omitted or expanded based on the installation. Be careful with making too long names or using special characters, which might cause confusion and difficulty in automation. 

Conclusion

The CIS Meraki Benchmark is an important resource to implement and maintain a resilent network. By keeping an up-to-date inventory and using proper naming and tags, we provide better visibility, simplified operations and troubleshooting. Periodical reviews ensure consistency and reduce risk introduced by unauthorized and undocumented assets. 

Call-to-Action

CIS Benchmarks are built by community members like you and me. We need more people like you to come with input and make sure that we are providing real, practical advice to the rest of the world. Please join: CIS WorkBench / Benchmarks

References

https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Organization_Menu/Manage_Tags

https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Renaming_a_Network_or_Organization

https://developer.cisco.com/meraki/api-v1/update-device/

https://developer.cisco.com/meraki/api-v1/update-network/





Thursday, September 18, 2025

CIS Benchmark Cisco Meraki: Administrative and Dashboard Access

This post is focusing on building the Center for Internet Security (CIS) Benchmark for Cisco Meraki. CIS is one of the most respected institutions when it comes to security standards, with CIS Controls being one of the most widely used resources for implementing and securing infrastructures. This benchmark is considered a prescriptive configuration recommendation for Cisco Meraki. The first section of the Benchmark will focus on Administrative and Dashboard Access. 

Why do we need a Benchmark?

Following the configuration guides can sometimes be complicated and without having a logical connection between the different documents, it's almost impossible to ensure that all the necessary security features are enabled. In order to streamline the security implementation, it is recommended to follow security standards. One of the most widely used security standards is CIS Controls, due to its very detailed and practical way of describing the technical and organizational safeguards to build a secure infrastructure. I decided to join CIS as an Editor and Subject-Matter Expert to help the community and the rest of the world. 


Fig.1 CIS Editor with focus on Cisco Meraki

Who is this benchmark for?

This benchmark is intended for system and application administrators, security specialists, auditors, help desk, and platform deployment personnel who plan to develop, deploy, assess, or secure solutions that incorporate Cisco Meraki equipment and solutions.

Administrative and Dashboard Access

Administrative Accounts

There are 2 basic types of dashboard administrators: Organization and Network. Organization administrators have access to the entire organization with all the networks, while network administrators are limited to the individual networks and their devices. We need to make sure to use named accounts that are not shared, in order to minimize the risk of unauthorized access and ensure accurate audit trails. We also need to go through the list periodically and revoke access as necessary. 

Fig.2 Administrative and Dashboard Access (Beta)

Audit Procedure

Log into the Meraki Dashboard, go to Organization -> Configure -> Administrators, and go through the list to make sure there are no shared logins, like "info", "support", "VendorX" etc.

Mapping: CIS 8.1 Control 5.

Network Admin Accounts

Network access need to be granted only where required, preferably in read-only mode. If network-level administrators are granted more privileges than required, they may accidentally or maliciously alter configurations across the networks that they have been granted access to. This can cause service outages, security policy violations or exposure of sensitive data. It is necessary to do periodical review and revoke unnecessary access. 

Audit Procedure

Log into the Meraki Dashboard, go to Organization -> Configure -> Administrators, and go through the list of network accounts to make sure there are no shared logins, like "info", "support", "vendorX" etc.

Mapping: CIS 8.1 Control 5

Role-Based Access Control

Accounts with higher privileges than necessary pose significant security risks. Implementing Role-Based Access Control reduces the attack surface. Failure to implement proper role-based controls in the Meraki Dashboard increases the risk of unauthorized or excessive administrative access. Overprivileged accounts can cause accidental or malicious changes to the organization. Organizational data might also be exposed.

Fig.3 Role-Based Access Control (Beta)

Audit Procedure

Log into the Meraki Dashboard, go to Organization -> Configure -> Administrators, verify the organization and network level access for all accounts, with focus on the custom role assignments. Audit Camera access permissions. Verify if the existing roles match the documented process of the organization for assigning role-based access account. Compare results to the last dated role-based access control audit.

Mapping: CIS 8.1 Control 6.8

Multi-Factor Authentication

Enforcing Two-Factor Authentication protects from unauthorized access in case the password of the administrator is compromised. This reduces the risk of account takeover, unauthorized configuration changes and security breaches.If two-factor authentication (2FA) is not enforced for all Meraki Dashboard logins, accounts are only protected by passwords, which can be targeted with phishing, credential stuffing, and brute-force attacks. A compromised administrator account without MFA can provide attackers with full access to network configurations, client data, and security policies, leading to potential service disruption and security breaches.

Fig.4 Multi-Factor Authentication

Audit Procedure

Log into the Meraki Dashboard, go to Organization -> Settings -> Security. Verify that "Two-Factor authentication" is enabled. Go to Organization -> Configure -> Administrators and verify that users are using 2FA. 

Mapping: CIS 8.1 Control 5.2

Audit Logs

Audit logs need to be enabled and reviewed regularly to ensure accountability, detection of unauthorized changes and support investigations. Without proper audit logging and regular review, malicious or unintentional changes can cause security breaches, service disruption and compliance violations. Audit logs help to mitigate these issues by providing historical data. Audit logs are enabled by default in Cisco Meraki and can't be disabled. Periodical audit procedure should be established to ensure traceability and detect unexpected changes.

Audit Procedure

Log into the Meraki Dashboard, Go to Organization → Monitor → Change Log. Verify that audit logs are being collected. Audit logs can also be fetched through API to external systems like a SIEM. Verify that the periodical review procedure is in place. 

Mapping: CIS 8.1 Control 8.2

Conclusion

The CIS Meraki Benchmark is an important resource to implement and maintain a resilent network. By enforcing named (non-shared) accounts, role-based least privilege, enabling MFA, and reviewing access regularly, you significantly lower the risk of misconfigurations, data exposure, and service interruptions.

Call-to-Action

CIS Benchmarks are built by community members like you and me. We need more people like you to come with input and make sure that we are providing real, practical advice to the rest of the world. Please join: CIS WorkBench / Benchmarks

References