Management Options, CIS Benchmarks & AAA

How to think about the management plane

Every firewall rule, IPS policy and port-security setting you configure lives on a device that someone can log in to. Whoever controls the management plane can switch off every other control in one session. That makes it the highest-value target on the network, and it's why these three exam topics belong together.

Ask three questions about any security device:

Keep those three in mind (path, baseline, identity) and the details below stop being a list of products and commands. They're answers to questions an attacker is also asking.

Management options for network security solutions

Every security appliance has to be configured, updated and monitored. Topic 2.4 asks you to select a management option, so the exam gives you a scenario (how many devices, which platforms, where the admins are) and expects you to pick the right manager and the right path. That's three separate choices:

1. Who manages it: one device at a time, or a central manager for many?
2. Which path does management traffic take: the production network (in-band) or a separate one (out-of-band)?
3. Where does the manager run: on your premises, or as a cloud service?

Two ways in: CLI and GUI

Every device gives you at least one of these, usually both:

• CLI (command-line interface): over a console cable (physical access) or SSH (encrypted, over the network). Precise and scriptable, and the baseline for every device.
• GUI (graphical interface): a desktop application (for example Cisco ASDM for the ASA, a Java application) or a web interface over HTTPS. Easier for policy work and visualizing rules.

Neither is better in general. The real question is how many devices you manage this way.

Single-device vs. multidevice managers

Managing one device at a time works for a small environment. It doesn't scale. Picture rolling out a new NTP server to 200 firewalls by hand: slow, error-prone, and every device ends up slightly different.

A multidevice (centralized) manager reaches every registered device. You make a change once (a new NTP server, an access policy, an intrusion rule update) and push it to all of them. For medium and large environments this isn't a convenience, it's how you stay consistent and auditable.

Exam point: an FTD is managed by either FDM or FMC (or cloud-delivered FMC), never both at once. Moving an FTD from FDM to FMC means re-registering it, and the local policy configuration doesn't come with it.

The managers you need to recognize

FDM: Firewall Device Manager. A web GUI built into a single FTD. Good for a branch with one firewall. No central policy, no multi-device reporting.

FMC: Firewall Management Center. The classic central manager for FTD. It runs as a hardware appliance or a virtual machine on your network. FTDs register to it over an encrypted channel (the sftunnel, TCP 8305), and you deploy access control, intrusion, malware and NAT policies to all of them from one console. FMC also collects events for analysis.

ASDM: Adaptive Security Device Manager. A Java GUI for one ASA at a time. Historically there was no good native way to centrally manage many ASAs beyond the ageing Cisco Security Manager. That gap is one reason Security Cloud Control exists.

Catalyst SD-WAN Manager. Manages the SD-WAN fabric: routing, connectivity and templates for SD-WAN routers. Its strength is connectivity rather than unified security policy across firewalls, which is the other gap Security Cloud Control fills.

Security Cloud Control (SCC)

Security Cloud Control is Cisco's cloud-based, AI-assisted management platform for security devices, and it's named in the v2.0 blueprint. It manages policies, objects and configuration across different device types at once, from a browser, with no VPN into a particular site.

Exam-critical lineage: Security Cloud Control is the evolution of Cisco Defense Orchestrator (CDO). Cisco documentation and licensing still use the CDO name in places. If older material or a question says CDO, think Security Cloud Control.

What it manages:

Features worth knowing:

• Cloud-delivered FMC: the FMC experience hosted by Cisco, so you can move FTD management from an on-prem FMC into the cloud.
• Security Analytics and Logging (SAL): cloud log storage and analysis for firewall events.
• ASA-to-FTD migration tooling: manage ASA and FTD side by side and migrate on your own schedule.
• AI Assistant and policy analysis: explain or draft rules in plain language, and find shadowed, duplicate, redundant or expired rules.
• Write once, apply everywhere: create an object (a malicious IP, URL or domain) once and use it on every supported product.
• Change log and out-of-band change detection: every change is recorded with what, when and who. A change made directly on the device, outside SCC, is flagged so you can accept or reject it. That's drift detection, which matters again in the CIS section.
• Templates, bulk CLI, backups and bulk upgrades.

Devices that can't reach the cloud directly connect through a Secure Device Connector (SDC), a small virtual machine on your network that relays between SCC and the device. On-premises management doesn't have to mean "no SCC".

The three goals Cisco gives for SCC:

1. Simplify operations: one place to configure, upgrade and push changes.
2. Enhance security: logs flow into SCC for AI-assisted analysis.
3. Improve clarity: visibility into traffic, threats and events across the estate.

When SCC fits: many devices of mixed types, distributed sites, remote administrators, and cloud-first organizations.

In-band vs. out-of-band management

Where does the management traffic travel?

Why OOB matters most when things go wrong: a DoS attack or a routing failure that takes down the production network takes in-band management with it, exactly when you need access. An out-of-band path keeps you connected to fix the problem, and keeps management protocols out of reach of ordinary users.

What OOB looks like on Cisco platforms:

• FTD: a dedicated Management interface, separate from the data interfaces, used for FMC registration and updates.
• ASA: an interface set with management-only, so it never forwards transit traffic.
• IOS XE: the GigabitEthernet0/0 management port lives in its own VRF (Mgmt-intf), so its routing table is separate from production.
• Console servers for the last-resort path when even the management network fails.

OOB isn't automatically safe. It's still a network: protect it with AAA, ACLs that allow management protocols only from admin subnets, SSH and HTTPS only, and logging. An attacker who reaches the management network reaches everything.

On-premises vs. cloud management

Where does the management platform itself run?

Every management platform needs care: upgrades, disk cleanup, backups, TAC cases. On-prem means your team does that work. Cloud means Cisco does it, in exchange for less direct control and a dependency on internet connectivity.

Selecting a management option

Topic 2.4 says select, so practice choosing. Read the scenario, then pick the smallest answer that meets the requirement.

Management options: exam traps

• SCC = cloud, cross-platform, multidevice. ASA, FTD (cloud-delivered FMC), Meraki MX, SD-WAN, Multicloud Defense, Secure Access. IOS support is limited.
• SCC is the evolution of CDO. Same lineage.
• FDM manages one FTD; FMC manages many. ASDM manages one ASA. An FTD uses FDM or FMC, not both.
• Catalyst SD-WAN Manager handles SD-WAN connectivity, not unified security policy.
• In-band shares the user network (simple, less secure, fails with production). OOB has its own path (secure, survives outages, costs more). OOB is best practice.
• On-prem (FMC): full control, data stays local, you maintain it. Cloud (SCC): access anywhere, Cisco maintains it, needs the internet.
• Secure Device Connector lets SCC manage devices that the cloud can't reach directly.

CIS Benchmarks for hardening devices

A firewall or router has hundreds of settings. How do you know you've locked it down and haven't left a door open? You don't have to invent the answer. CIS Benchmarks are a ready-made, expert-agreed checklist. Topic 2.5 asks you to describe them, with Cisco Secure Firewall (FTD) and Cisco IOS XE as the named examples.

What a CIS Benchmark is

A CIS Benchmark is a set of consensus-based best practices for securely configuring a specific technology: an operating system, a cloud platform, a database, a network device. It's published by the Center for Internet Security (CIS), a nonprofit, and the PDFs are free to download from cisecurity.org after registering.

The key word is consensus. A benchmark isn't one vendor's opinion. Volunteers from consulting, auditing, government, vendors and operations draft and test each recommendation, and the wider community reviews it before and after publication. That's why auditors and regulators accept it.

Analogy: you've just taken over an office building. Before anyone moves in, you walk a checklist: every lock works, cameras cover the doors, the alarm is armed, spare keys are accounted for. A CIS Benchmark is that checklist, written by security experts for one specific product, down to the exact command and how to check it.

Don't confuse the two CIS products:

Why use CIS Benchmarks

Anatomy of a recommendation

Every recommendation follows the same structure, so you get the what, the why, the risk and the proof:

Profile levels:

• Level 1: practical and prudent, a clear security benefit, and it shouldn't break normal operation. The baseline everyone should meet.
• Level 2: defense in depth for environments where security is paramount. It extends Level 1 and may reduce functionality or performance.

Here's what a recommendation looks like, in our own words (modeled on the IOS XE benchmark's style):

The Cisco benchmarks and how they're organized

CIS publishes benchmarks for the Cisco platforms you'll harden, including Cisco IOS XE (16.x and 17.x), Cisco IOS XR, Cisco NX-OS, Cisco Firepower Threat Defense and Cisco ASA 9.x. The blueprint names FTD and IOS XE, so expect those two in questions.

The Cisco network-device benchmarks are organized around the three planes you already know:

Notice how this reads like a checklist version of earlier topics: SSHv2, SNMPv3 authPriv, authenticated NTP, AAA, routing authentication, uRPF. The benchmark is the standardized, auditable form of "harden the three planes".

FTD vs. IOS XE: where the hardening lives

The goals are the same on both platforms. Where you apply them differs:

From benchmark to fleet: harden, audit, monitor drift

The trap is to apply a benchmark once and call it done. Say you manage 80 firewalls and push a hardened configuration to all of them. Over the next year someone enables Telnet "just for a minute", an upgrade changes a default, a contractor adds a local account. That's configuration drift: the gap between your approved secure baseline and what's actually running.

The real workflow is a loop:

1. Choose the profile (Level 1, or Level 2 where justified) and record any exceptions with a reason.
2. Build a golden configuration or template from it.
3. Apply it centrally (FMC platform settings, Security Cloud Control templates, configuration management tools).
4. Audit regularly against the benchmark: CIS-CAT Pro, vulnerability scanners with CIS audit policies, or scripts that run the audit commands.
5. Detect drift between audits: change logs and out-of-band change detection in Security Cloud Control, config archive and diff, syslog alerts on %SYS-5-CONFIG_I.
6. Remediate and go back to step 4.

Exam link: this is why centralized management (2.4) and benchmarks (2.5) go together. A multidevice manager is how you apply a baseline to a fleet and catch drift across it.

Benchmarks are one component of security, not the whole of it. A perfectly hardened device running vulnerable software is still vulnerable. Use benchmarks alongside patching, vulnerability management and monitoring.

CIS Benchmarks: exam traps

• CIS Benchmark = consensus-based configuration guide for a specific technology, free from the Center for Internet Security.
• Four benefits: reduce attack surface, prevent misconfiguration, standardize, support compliance.
• Level 1 = safe baseline, minimal impact. Level 2 = defense in depth, may reduce functionality.
• Automated (tool-checkable) vs. Manual (human verification).
• Each recommendation has an audit procedure (how to check) and a remediation procedure (how to fix).
• Cisco network-device benchmarks are organized by management, control and data plane.
• Benchmarks are the starting point: monitor for configuration drift and re-apply.
• Benchmarks ≠ CIS Controls. Benchmarks are per-product; Controls are organization-wide.

AAA for device and network access

CIS Benchmarks lean heavily on one control: AAA, with central TACACS+ or RADIUS servers and a local fallback account. Topic 2.6 asks you to troubleshoot it, so you need to know how it's built well enough to recognize exactly where it broke.

Authentication, authorization and accounting

Analogy: authentication gets you into the building, authorization decides which rooms you can enter, and accounting is the visitor log at reception. You can pass the first and fail the second.

Why central AAA beats local accounts: with 200 devices and local usernames, removing a departing admin means 200 changes, and you have no record of who typed what. With central AAA, you disable one account on the server, every login is checked in one place, and accounting gives you an audit trail.

Device administration vs. network access

The blueprint says "AAA for device and network access". These are two different jobs, and each has a natural protocol:

Both protocols can do both jobs (RADIUS is often used for device login on non-Cisco gear), but the exam expects the pairing above.

TACACS+ vs. RADIUS

Two details that show up in troubleshooting:

• TCP vs. UDP changes the symptoms. TACACS+ opens a TCP connection first, so you can tell "couldn't connect" (reachability) from "connected but the reply made no sense" (shared key). RADIUS is connectionless, so a dead server and a wrong key can both look like a timeout from the device side.
• The shared secret isn't strong encryption in either protocol. Both rely on MD5-based obfuscation. Use long, unique keys and keep AAA traffic on the management network. Newer options wrap the protocols in TLS: TACACS+ over TLS 1.3 (RFC 9887) and RadSec (RADIUS over TLS, TCP 2083).

How IOS AAA works: aaa new-model and method lists

aaa new-model switches a Cisco device from legacy line passwords to the AAA framework. From that moment, every login path is controlled by AAA.

Lifeboat first. Create a working local admin (username admin1 privilege 15 secret ...) before you type aaa new-model. If no method list is defined, IOS checks the local user database, and without a local account you can lock yourself out.

A method list says how to authenticate (or authorize, or account), and in what order:

aaa authentication login TAC-Login group tacacs+ local

Read it left to right: try the TACACS+ servers first; if none of them answer, use the local database.

The fallback rule that the exam loves: the next method is tried only if the current method returns an error (no server answered). A reject (wrong password from a reachable server) is final. local doesn't rescue a user the server just rejected.

Three more method-list traps:

1. A named list does nothing until it's applied to a line. A typo in the name (TAC-Logn) breaks it too.
2. The default list covers the console. aaa authentication login default group tacacs+ with no local locks the console too when the server is down. Many teams give the console its own list with local first.
3. Authentication isn't authorization. A TACACS+ user lands at privilege 1 unless the server returns a privilege level through aaa authorization exec, or enable is authenticated separately.

Configuring TACACS+ for device administration

A complete, production-style device-administration setup on IOS XE:

! 1. Lifeboat account, then turn on AAA
username admin1 privilege 15 secret <strong-local-password>
aaa new-model
!
! 2. Define the servers and group them
tacacs server ISE-1
 address ipv4 10.10.99.10
 key <long-unique-shared-secret>
tacacs server ISE-2
 address ipv4 10.10.99.11
 key <long-unique-shared-secret>
aaa group server tacacs+ ISE-TAC
 server name ISE-1
 server name ISE-2
 ip tacacs source-interface Loopback0
!
! 3. Authentication: servers first, local only if no server answers
aaa authentication login VTY-AUTH group ISE-TAC local
aaa authentication enable default group ISE-TAC enable
!
! 4. Authorization: privilege level from the server, then each level-15 command
aaa authorization exec VTY-AUTHZ group ISE-TAC local
aaa authorization commands 15 VTY-CMD group ISE-TAC local
!
! 5. Accounting: sessions and every level-15 command
aaa accounting exec default start-stop group ISE-TAC
aaa accounting commands 15 default start-stop group ISE-TAC
!
! 6. Apply to the VTY lines, SSH only
line vty 0 15
 login authentication VTY-AUTH
 authorization exec VTY-AUTHZ
 authorization commands 15 VTY-CMD
 transport input ssh
 exec-timeout 10 0

Console authorization: IOS doesn't apply authorization to the console unless you add aaa authorization console. That's deliberate: a broken authorization server shouldn't lock you out of the last-resort path.

Configuring RADIUS for network access

RADIUS shows up in two places: device logins on non-Cisco or mixed fleets, and, much more often, 802.1X and MAB on switch ports and wireless.

radius server ISE-1
 address ipv4 10.10.99.10 auth-port 1812 acct-port 1813
 key <long-unique-shared-secret>
aaa group server radius ISE-RAD
 server name ISE-1
 ip radius source-interface Vlan99
!
aaa authentication dot1x default group ISE-RAD
aaa authorization network default group ISE-RAD
aaa accounting dot1x default start-stop group ISE-RAD
!
! Let ISE change a session after it starts (CoA)
aaa server radius dynamic-author
 client 10.10.99.10 server-key <long-unique-shared-secret>
!
dot1x system-auth-control
!
interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 10
 authentication port-control auto
 mab
 dot1x pae authenticator

Troubleshooting AAA: three layers

Every AAA failure sits in one of three layers. Find the layer first and the fix is obvious:

The toolbox, in the order to use it:

What each failure looks like with TACACS+:

Read the debug, not the summary. With a wrong TACACS+ key, test aaa can print No authoritative response from any server, which sounds like reachability. The debug shows the TCP session opened and the reply failed to decrypt: a key problem. The lab on this page captures exactly that.

With RADIUS, the symptoms are less direct. Because RADIUS runs over UDP and the server validates requests with the shared secret, a wrong key usually means the server drops or rejects the request and the device sees timeouts, or a reply it discards because the authenticator doesn't match. From the switch, a key mismatch can look exactly like a reachability problem. The server's log tells them apart: ISE reports messages such as "Could not locate Network Device or AAA Client" (device not added, or the request came from an unexpected source IP) or "The Message-Authenticator RADIUS attribute is invalid" (shared secret mismatch).

Classic faults beyond the big three:

Troubleshooting network access (802.1X and MAB)

For network access, the switch and ISE together tell the story:

show access-session interface GigabitEthernet1/0/10 details
show aaa servers
test aaa group radius <user> <password> new-code
debug radius authentication

show access-session (on IOS XE) shows the method (dot1x or mab), the status (Authorized, Unauthorized, Running), the VLAN and ACL applied, and the session ID you can search for in ISE.

Hardening the AAA path

AAA protects the management plane, so the AAA path itself has to be protected:

AAA: exam traps

• TACACS+: TCP 49, whole body encrypted, AAA separated, per-command authorization, best for device administration.
• RADIUS: UDP 1812/1813 (legacy 1645/1646), only the password hidden, authentication and authorization combined, best for network access.
• Create a local account before aaa new-model.
• Method lists fall back only on error (no answer), never on a reject.
• A named list must be applied to a line; the default list applies everywhere else, including the console.
• test aaa checks the server without changing the login configuration.
• TACACS+ (check keys) = shared key mismatch; No authoritative response = nobody answered; status = FAIL = bad credentials.
• Ping success doesn't prove AAA reachability (TCP 49 / UDP 1812 can be blocked).
• With RADIUS, a key mismatch often looks like a timeout from the device; check the server's logs.
• aaa authorization network is required for ISE to assign VLANs and ACLs. CoA needs aaa server radius dynamic-author.

Quick reference

Lab for this module

Put the AAA half into practice in the AAA with TACACS+ lab: build TACACS+ login with a local fallback on a real IOS router, prove a server-only user can log in, then break it three ways (wrong key, wrong password, wrong server IP) and read each fault straight from debug tacacs.