Home > Articles > Security Through Network Fundamentals

Security Through Network Fundamentals

Chapter Description

In this sample chapter from Practical Cisco Unified Communications Security, you will explore the dependencies that Unified Communications (UC) systems have on a network while also highlighting the security features that can be implemented to provide additional security to the UC environment.

Secure Network Access

Providing security at the edge of the network is perhaps the most overlooked approach for UC security despite the power that it can bring to an organization and the simplicity involved. Put simply, if an organization can strengthen how users and UC devices join the network, it can help reduce the attack surface that attackers have access to while making it easier to protect against UC attacks. Security at the edge of network access comes in many forms. The oldest, and perhaps most common, is through use of switchport security. The strongest approach is through implementation of 802.1x authentication. The next few sections explain in more detail how port security can help an organization and show how it is configured. After that, we transition over to 802.1x authentication and then wrap up by covering what can be considered the middle ground—MAC Authentication Bypass (MAB) and how MAB can be further secured when using Network Access Control (NAC).

Port Security

The port security feature enables organizations to specify what identities can join the network by specifying which MAC addresses are allowed. Port security has traditionally been popular because it provides an easy way for an organization to limit the number of devices that are allowed to connect to an access port and prevent shadow IT.

As an example, port security can help prevent a user from plugging in an access point that has not been previously sanctioned by the IT department to add wireless capability. Port security is also useful for protecting against attacks against the network, such as flooding the Content Addressable Memory (CAM) table on a switch with false MAC addresses to create a man-in-the-middle attack.

If an organization chooses to use port security at the edge of the network, administrators should know that Cisco switches do not support explicit configuration of MAC addresses for the voice VLAN. Therefore, administrators should consider allowing a maximum of two MAC addresses to connect to each switch port to account for the IP phone and the PC plugged into the back of the IP phone. If any type of port security is enabled on the access VLAN, dynamic port security is automatically enabled on the voice VLAN.

To enable switchport security, you need to take the following steps:

  1. 1. Specify the maximum number of MAC addresses allowed on the network:

    switch(config)# int gig1/0/1
    switch(config-if)# switchport port-security maximum 2
  2. 2. Specify the MAC address that is permitted for the network port(s):

    switch(config-if)# switchport port-security mac-address
  3. 3. Specify what action to take if the switch doesn’t recognize a MAC address that is trying to join the network:

    switch(config-if)# switchport port-security violation restrict
  4. 4. Enable the switch port for port security:

    switch(config-if)# switchport port-security

When the restrict key word is used, and a violation occurs, an SNMP trap is sent, a syslog message is logged, and the violation counter increments. The other options are to protect and shut down. When configured to protect, the switch just drops packets with an unknown source address. When configured for shutdown, the interface becomes error-disabled, an SNMP trap is sent, a syslog message is logged, and the violation counter increments.

Now that we are discussing port security, it is important to understand that a configuration that limits the specific MAC addresses that are allowed to connect to an access port is a potential issue. This type of environment assumes that the environment is static and that a limited number of phones require Moves/Adds/Changes (MAC) around the network. If the desire is to have a dynamic but yet secure environment, the organization can convert from static MAC addresses to dynamic “sticky” MAC addresses, in which the switch converts all of the dynamic MAC addresses to the running configuration on the switch. To enable port security that is dynamic, leverage the mac-address sticky command, as in the following example:

Switch(config)# int gig1/0/11
Switch(config-if)# switchport port-security maximum 2
Switch(config-if)# switchport port-security violation restrict
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# switchport port-security

This option is more flexible because sticky MAC addresses do not automatically become part of the start-up configuration file, which is the configuration used each time the switch restarts. Learned sticky MAC addresses are just added to the running configuration as shown:

switch# sh run int gig1/0/11
Building configuration...
Current configuration : 364 bytes
interface GigabitEthernet1/0/11
 switchport access vlan 20
 switchport mode access
 switchport voice vlan 100
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky f8b7.e294.6d00 vlan voice
 switchport port-security
 spanning-tree portfast

Although effective in securing network access for the common user, switchport security has some downfalls. MAC addresses can easily be spoofed or falsified to allow unauthorized devices onto a network. If attackers do this, they can attack the network segment(s) that they are connected to laterally, unless layer 2 VLAN ACLs (VACLs) are in place. This is one of the reasons why we have previously discussed use of segmentation in the network (macro and micro). In any regard, because organizations understand the limitations of port security, many of them are moving away from this approach and toward 802.1x authentication. The next section discusses this technology in further detail.

802.1x Authentication

The IEEE 802.1x standard method of authentication is widely considered the strongest method of authenticating users and devices to the network. In typical implementations with 802.1x authentication enabled, the access port allows only Extensible Authentication Protocol over LAN (EAPoL), Cisco Discovery Protocol (CDP), and Spanning Tree Protocol (STP) traffic to the port until an endpoint is authenticated. In addition to providing port-based authentication, an architecture that provides 802.1x offers increased visibility that may be useful for security audits, forensics, and troubleshooting. The downside of this method of authentication is that there are several dependencies on the infrastructure components. These components are not typically managed by UC administrators, so there is an element of cooperation and teamwork needed for a fully functional 802.1x solution. The basic components of an 802.1x solution include

  • ▪ Authenticator (Access Switch)

  • ▪ Authentication server, such as Cisco Identity Services Engine (ISE)

  • ▪ Authentication database

  • ▪ Client supplicant

  • ▪ Public key infrastructure (PKI)

The 802.1x authenticator (access switch) helps relay authentication information over Extensible Authentication Protocol (EAP). Common EAP methods in 802.1x environments are EAP-MD5, EAP-FAST, EAP-TLS, and Protected EAP – Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2). EAP-TLS uses certificates for client/server authentication, whereas EAP-MD5, EAP-FAST, and PEAP-MSCHAPv2 use passwords for authentication. Cisco Catalyst switches fully support authentication of UC devices and PCs through the use of multidomain authentication (MDA) configuration parameters.

The authentication server, such as Cisco Identity Services Engine, provides authentication, authorization, and accounting (AAA) for devices trying to access the network by leveraging standards-based protocols, such as EAP over LAN (EAPoL) and Remote Authentication Dial-In User Service (RADIUS). The authentication server enables organizations to create flexible and granular security controls as they request access to the network and once they have authenticated to the network by incorporating authorization policy. In practical terms, this means that administrators can dynamically place authenticated users and devices into separate logical network segments and apply certain security policies to those groups and devices. Within ISE, this is done with downloadable ACLs (dACLs).

An authentication database, such as Microsoft Active Directory or ISE, is a critical component of an 802.1x authentication implementation. The authentication database holds the credentials of the users to be authenticated in a centralized location. This type of solution provides the ability to align with organizational security policies. If users do not update their credentials, they are cut off (or restricted) from acquiring network access based on the authentication policy that is configured.

A client supplicant is software running on a device that attempts to gain access to the network. Operating systems such as Windows and OS X provide native supplicants to aid with 802.1x authentication. Software such as Cisco AnyConnect can run on top of an OS to also provide a supplicant. Last but not least, the firmware on Cisco IP phones also has a native supplicant for performing 802.1x authentication to a network. The next section discusses this topic in further detail.

The current release of the native supplicant inside a Cisco IP phone leverages either EAP-FAST or EAP-TLS for 802.1x authentication. EAP-TLS is the only option that supports X.509 certificates to simplify the 802.1x authentication process. The two different certificate types that are currently supported are the manufacturing installed certificate (MIC) and a locally significant certificate (LSC). A MIC is preinstalled at the factory during manufacturing of the IP phone and signed by one of the Cisco Manufacturing CA certificates:

  • ▪ Cisco Manufacturing CA

  • ▪ Cisco Manufacturing CA SHA2

  • ▪ CAP-RTP-001

  • ▪ CAP-RTP-002

These certificates are important because for ISE to successfully authenticate a phone onto the network via 802.1x, it needs to be imported into the ISE’s trusted certificate store. From a certificate perspective, one thing that we must discuss is a certificate’s chain of trust. This chain is important because it validates the authenticity of an X.509 server (or phone) certificate. Three components are needed to establish a chain of trust between certificates:

  • Root certificate: An X.509 certificate that belongs to a certificate authority. It is used to issue other certificates.

  • Intermediate certificate: An X.509 certificate that is subordinate to the root and issues server certificates.

  • Server certificate: An X.509 certificate for a specific server or device.

A phone certificate and its certificate trust chain are shown in Figure 3-5.

For ISE to authenticate a phone by its MIC, the manufacturing certificates need to be imported into ISE. You can find the MIC and then export it out of Cisco Unified CM by navigating to Cisco Unified OS Administration > Security > Certificate Management. The certificate should be exported in a .pem format. When importing into ISE, you should navigate to Administration > System > Certificates > Trusted Certificates and then choose Import. Figure 3-6 shows an example of ISE displaying the manufacturing certificates that have been imported.

Now that certificates have been imported into ISE, we can further explain the authentication process. Once ISE receives an authentication request from a client supplicant, it must examine the authentication policy and, ultimately, the sequence of identity stores that can be used in sequential order to authenticate a device. Within ISE, this is known as the identity source sequence. Because IP phones authenticate locally to ISE, a simple identity source sequence can be defined, such as to use only the internal ISE database. After this, you simply need to reference a certificate authentication profile that specifies what attribute to use inside the x.509 certificate to authenticate an IP phone. As shown in Figure 3-7, ISE uses the Subject – Common Name attribute. An example of the identity source sequence is shown in Figure 3-8.

Now that you understand how certificates are used and have a basic understanding of how Cisco ISE uses certificates to authenticate devices, we can discuss the differences in the certificates (MIC versus LSC) and why an organization may choose to use one or the other.

A downfall to using MICs is that it is difficult to prove that the phone belongs to a customer’s Unified CM cluster(s) or that it even belongs on the network. This means that an attacker could place a rogue phone with a MIC on the network and potentially register it if auto-registration is enabled on Unified CM. Locally significant certificates (LSCs) provide an additional layer of security and verification that a phone belongs to the network because LSCs are signed by the Unified CM Publisher’s Certificate Authority Proxy Function (CAPF) certificate based on RFC 5280, which allows Unified CM to take on the role of a root certificate authority. When CAPF facilitates the signing of LSCs, and an administrator intentionally deploys LSCs to IP phones used by UC administrators, an LSC provides a higher level of security and therefore is preferred (and prioritized) by the IP phone over the MIC.

When you’re deciding which certificate to use for implementing 802.1x security on the network, one approach is to begin by using the MIC because it is the quickest and simplest option. When phones are able to join the network and are able to register to Cisco Unified CM, LSCs can be deployed at any time with minimal changes to the network (e.g., modification of authentication policy). It is a good idea to eventually use LSCs for 802.1x authentication because for many organizations, they are useful for encrypting voice and video traffic. We discuss this topic in more detail in Chapter 7, “Encrypting Media and Signaling.”

While 802.1x authentication for Cisco phones has been supported since Unified CM 7.1.2, it is possible that an organization is currently using an IP phone that does not support 802.1x—for example, Cisco IP phones such as 7935, 7936, 7940, and 7960. In some cases, older phone models may have previously supported 802.1x, but with legacy protocols, such EAP-MD5, which have been deprecated. In some cases, the MICs may be expired and therefore no longer valid, so 802.1x authentication with certificates is possible only through use of LSCs. Further, some of the newer TLS 1.2 algorithms used with LSCs may not be supported on legacy phones. Cisco currently recommends checking the release notes for your current version of Unified CM and IP phone firmware to determine support for 802.1x.

Within Cisco’s authentication framework, different modes of deployment are available so that organizations can implement a phased approach for strengthening authentication onto the network. Currently, organizations can use three different deployment modes to ensure that PCs and UC endpoints are not prevented from joining the network:

  • Monitor mode: Provides a nondisruptive environment to monitor the impact that 802.1x can have to the organization without preventing access to the network

  • Low-impact mode: Uses a pre-authentication ACL (PACL) to allow a subset of traffic prior to authentication, such as DHCP requests

  • Closed mode: Prevents access to the network prior to authentication/authorization

By using one of these modes, an organization can deploy security in phases. As an example, an organization can deploy 802.1x in monitor mode in conjunction with MAC Authentication Bypass so that it can monitor network authentication failures and adjust policies on an as-needed basis. This way, leadership can evaluate risks while ensuring operations are not impacted by the addition of more stringent security policy being applied to the network infrastructure, which includes Cisco Catalyst switches, wireless LAN controllers, wireless access points, DNA Center, and ISE. For additional detail about configuring the network infrastructure to support 802.1x and MAB, see the relevant security configuration guide for the version of IOS/IOS-XE software that your organization is using. The next section provides additional detail around benefits and use cases for MAB.

MAC Authentication Bypass (MAB) and Network Access Control (NAC)

MAC Authentication Bypass is helpful for scenarios in which you need to authenticate devices that do not have a client supplicant that will support 802.1x authentication. Devices that do not typically support a client supplicant include fax machines, printers, and IoT devices. When MAB is enabled, the Cisco switch uses an endpoint’s MAC address as the client identity. For a device to join the network with MAB enabled, MAC addresses of endpoints such as IP phones must be whitelisted in a database that is present in Cisco ISE.

One benefit of Cisco’s authentication framework is that it supports flexible authentication methods. As an example, MAB can be enabled as a backup authentication method to 802.1x authentication. An authentication policy that can be created to prioritize 802.1x authentication and to use MAB only as a backup method is shown in Figure 3-9.

When MAB is configured as a backup authentication method, and an administrator designates the voice VLAN as critical, if ISE does not respond to an authentication request, a switch port goes into critical authentication mode. When traffic coming from an endpoint is tagged with the voice VLAN, the endpoint (e.g., IP phone) is put into the voice VLAN that was previously configured on the switch port and allowed onto the network. As previously discussed, the voice VLAN can be learned dynamically through Cisco Discovery Protocol (CDP) or through LLDP. Critical voice VLAN support prevents a scenario in which IP phones become usable because they cannot access the network or the UC infrastructure.

It is worth mentioning that MAB is not truly an authentication method. Because MAC addresses can be easily spoofed, MAB is considered more of a backup authentication method for situations when an endpoint is unable to perform 802.1X authentication. In scenarios that 802.1x cannot be deployed, here are some questions that you should ask:

  • ▪ What are the risks to unauthorized users gaining access to the network infrastructure through a spoofed MAC address?

  • ▪ What is the likelihood of someone gaining access to the network environment?

As an additional security measure, to minimize MAC spoofing, Cisco ISE can be used to provide network access control (NAC) for the network. This is possible because the Cisco ISE profiler can be used to dynamically detect and classify the types of endpoints that are connected to the network. While still using a device’s MAC addresses as the unique identifier, ISE is able to collect various attributes from each endpoint and then use a profiler policy to determine the Total Certainty Factor (TCF) of the credibility of the device. In other words, ISE is able to determine whether a device is really who it says it is. As shown in Figure 3-10, the process is cumulative based on how a device matches the collected attributes to prebuilt or user-defined conditions, which are then correlated with an extensive library of profiles. These profiles include but are not limited to a wide range of device types, such as IP phones, mobile devices, cameras, printers, gaming consoles, and IoT sensors. A TCF that has been assigned to an endpoint, such as a Cisco IP phone, is shown in Figure 3-11.

Once endpoints are classified and granted access to the network, an authorization profile can be created to specify the type of network access that should be granted to a device based on the profile. The theory behind this approach is that because certain devices are more trusted than others, the level of network privileges should reflect it. An example of the controls that administrators have is that different devices can be put into different VLANs and, if necessary, downloadable ACLs (dACLs) can be assigned to limit access to specific resources. This solution helps prevent or limit the exposure of access to a network if an attacker were to spoof MAC addresses to connect to the network. Practically, the authorization policy may have more trust for UC endpoints that are authenticated via 802.1x with an LSC than devices that use MAC Authentication Bypass as an authentication method. An authorization policy is shown in Figure 3-12.

5. Security Features | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020