Standard Pre-document Stuff: AMASE (Advanced MAC Address Security for Enterprises) is a conceptual security protocol that is being released for discussion and consideration for development. This protocol and related documentation and/or posts is free for all uses, development, implementation, discussion, and/or dissemination as long as this post and this permission-set is attached to all derivative, non-derivative, and/or future works, discussions, development, solutions, implementations, dissemination, and/or all other uses. The document flow is designed to provide an introduction followed by deeper technical sections. The first section is an overview of AMASE and how its suggested operation. The development or use of AMASE by any entity, party, organization, individual, or group is done so without knowledge, support, guaranty from, or warranty from this author.
Overview: MAC spoofing is a real threat and current solutions can be a bit overwhelming, cumbersome, difficult to use and/or time consuming. This is where AMASE comes into play. AMASE is a conceptual security protocol that reassigns MAC addresses to corporate devices so they are in discreet contiguous blocks based on device type and/or intended use. This is performed by either an ob-device software package or a certificate-supported remote call to obtain the authorized MAC address. This post will cover assumptions, some potential benefits of AMASE, some potential draw-backs of AMASE, how on-device software may work, how remote MAC address management may operate, and potential MAC address blocks for AMASE use.
Assumptions: The assumptions that are known to exist with the AMASE notional security protocol include the following:
• Any personally owned devices will not have MAC addresses or address blocks that overlap with AMASE-available addresses.
• All devices will maintain their MAC address assignments from acquisition through sunset.
• No two organizations will use overlapping blocks of MAC address assignments. (Discussed more later).
Benefits of AMASE: AMASE enables organizations the ability limit the number of devices whom can access discrete network locations based on AMASE groups. AMASE enables the simplification of rogue device identification by alerting on any MAC addresses on the network (or specifically designated network locations) where any non-AMASE MAC address are discovered. All network connected devices can be grouped by MAC address to identify device type, sensitivity level, organization department or office membership, or other organization-defined criteria.
Draw-Backs of AMASE: As the creator of the AMASE notional protocol the author does have an inherent bias that may cause ‘blind-spots’ about the downfalls of AMASE but every effort has been made to list all potential drawbacks. The most prevalent and obvious draw-back would be the potential for two organizations to use overlapping contiguous blocks and this issue is addressed later in this article. Other potential drawbacks may include not provisioning a large enough block of MAC addresses, provisioning AMASE groups with overlapping MAC addresses, and creating too large a block of MAC addresses which might facilitate the ability for an attacker to spoof an authorized address.
On-Device AMASE Implementation: This implementation would be the most cumbersome to set-up, use, and maintain. In this scenario each device has an AMASE module added during the provisioning process. The module uses the host-operating system’s utilities to assign the device an organization specified MAC address, check the MAC address daily and at every reboot, and assign the AMASE MAC address when it is not present on the assigned NIC (network interface card). This idea has been chosen over creating a virtual NIC and filtering all traffic through the virtual NIC to replace the MAC address because in the virtual NIC scenario the non-AMASE address is still present on the device which could enable AMASE bypass attacks. The on-device AMAZE module could be a script file that is run via as a scheduled task or cron job or a compiled application. The script can include a portion that identifies the device AMASE group or type as well to ensure the proper MAC address group is used.
Remote AMASE Implementation: In this scenario an on-device AMASE module uses a private-key AMASE certificate to connect to an AMASE management console, retrieve one available MAC address from the available pool of AMASE MAC addresses, assign the MAC addresses to each of the device’s NICs, then verify the allocation with the AMASE management console. When the device is powered-down the AMASE module reverts the MAC addresses to their originals to permit the device to use non-AMASE MAC addresses on other networks.
AMASE MAC Address Blocks: As there is no publicly assigned “internal use only” MAC address blocs, the ideal approach is to purchase a MAC address block Large/Medium/ Small from a registration authority (ex. https://standards.ieee.org/products-services/regauth/index.html. A less ideal solution would be to “borrow” a publicly assigned organizationally Unique Identifier (OUI) for internal-only use.
Summary: AMASE is a conceptual security protocol that can (potentially) be leveraged to further mature security programs by simplifying the identification of rogue devices, creating MAC addresses isolation, and grouping assets by MAC addresses by organizationally defined criteria. AMASE just might be Amazing but the author is bias so this idea belongs to the critics.