Cisco 350-701: Implementing and Operating Cisco Security Core Technologies (SCOR)

Computer identity is generally used for authentication/authorization decisions (for example, machine authentication with EAP-TLS or AD machine account lookups) and for policy matching in ISE. It is not a typical “posture assessment” condition because posture is about endpoint security health/compliance (firewall, AV, services, patches), not who/what the endpoint is from an identity perspective.

User identity is evaluated during authentication (802.1X, VPN, etc.) and then used in authorization rules (for example, mapping AD groups to access levels). Posture assessment does not typically “check” user identity as a health requirement; instead, posture checks endpoint configuration and security status, and the posture result can be combined with user identity to decide access.

Default browser is not a standard ISE posture compliance check in the SCOR/NAC context. Posture focuses on security posture indicators (firewall, AV/EDR, disk encryption, patch level, services/processes, registry/files). While endpoint configuration can be broad, “default browser” is not typically used as a security compliance condition in ISE posture policies.

Group policy is not the correct FMC policy construct for this definition. While the phrase sounds generic and could imply settings shared by a group of devices, Cisco FMC uses more specific policy names, and this wording maps to device management policy. Choosing group policy here reflects a terminology trap rather than the actual product feature name. On the exam, be careful to distinguish intuitive wording from official FMC policy taxonomy.

An access control policy defines how traffic is evaluated and handled, including permit, block, trust, and inspection actions. It is centered on security rule logic for network flows rather than on shared device-level operational parameters. Although an ACP can be deployed to multiple devices, that does not make it the policy type described in the question. The prompt is about common aspects of managed devices, not traffic enforcement behavior.

A platform settings policy is used for platform-specific and system-level settings such as SNMP, syslog, NTP, SSH, and other device service parameters. It is narrower in scope and focused on platform behavior rather than serving as the broader shared policy construct described in the question. The exam wording points to a policy representing a shared set of device features and parameters across similar managed devices, which is the role of device management policy. Therefore, platform settings policy is too specific to be the best answer.

RSA SecurID is primarily an external authentication and token-based verification system rather than a directory used for ISE administrative role mapping. It can validate credentials or second-factor tokens, but it is not the identity store classically associated with requiring a local shadow user for ISE admin login. The question is focused on the store type that needs a local ISE representation for RBAC. That requirement is tied to LDAP, not RSA SecurID.

The Internal Database does not require a shadow user because the administrator account already exists locally on Cisco ISE. Since the user is native to ISE, both authentication and authorization can be handled directly without creating any additional representation. Admin roles and permissions are assigned straight to the local account. Therefore, there is no need for a shadow user when using the Internal Database.

Active Directory is a common external identity source for Cisco ISE, but it is not the one that requires manually created shadow users for admin login in the way LDAP does. ISE has native AD integration that supports authentication and group-based authorization workflows without the same shadow-user requirement emphasized for LDAP. This makes AD a plausible distractor, especially because AD uses LDAP-related technologies, but it is not the best answer to this specific question. The exam distinction is that LDAP requires the shadow user for admin access.

Man-in-the-middle attacks are not reliably prevented by MFA. An attacker can proxy the login flow and relay credentials and one-time codes in real time, or steal session cookies after authentication. Only specific MFA implementations that provide origin binding and channel protection (for example, FIDO2/WebAuthn) significantly reduce MITM risk; generic MFA alone is not a guarantee.

DDoS is an availability attack that overwhelms services or network links with traffic. MFA is an authentication/identity control and does not reduce the volume of malicious traffic. DDoS mitigation typically involves rate limiting, scrubbing centers, CDNs/Anycast, WAF protections, and upstream provider cooperation, not stronger user authentication.

Teardrop is a legacy denial-of-service attack exploiting IP fragmentation reassembly issues by sending malformed overlapping fragments. MFA has no relationship to packet fragmentation handling or OS network stack vulnerabilities. Prevention is achieved through patching, modern OS/network stack hardening, and network security controls (IPS/ACLs), not authentication mechanisms.

Cisco Umbrella is primarily a cloud-delivered security platform focused on DNS-layer protection, secure web gateway, and internet access control. Although it uses threat intelligence and can participate in a broader Cisco security ecosystem, it is not the canonical product described as feeding threat intelligence into Threat Intelligence Director for this purpose. The question is asking for the integrated source of threat information used by TID, and Umbrella is not the best match. On the exam, Umbrella is more commonly associated with DNS enforcement and web protection than with serving as TID’s primary intelligence integration in this context.

External Threat Feeds can generally provide indicators of compromise to many threat intelligence platforms, so this option may seem plausible at first glance. However, the question is framed around a Cisco integration and asks what can be integrated with Cisco Threat Intelligence Director to provide threat information for proactive automation. In Cisco product-specific exam wording, Cisco Threat Grid is the expected answer because it is the Cisco-native malware intelligence source integrated with TID. Therefore, while external feeds are conceptually related to threat intelligence, they are not the best answer to this Cisco-focused question.

Cisco Stealthwatch, now known as Secure Network Analytics, is focused on network telemetry, behavioral analytics, and anomaly detection. It helps identify suspicious activity in network traffic, but it is not primarily the threat intelligence source integrated with TID for supplying curated malware indicators and intelligence. The question emphasizes providing information about security threats in a way that enables proactive automated response through TID, which aligns more directly with Threat Grid. Stealthwatch is better understood as a network detection and visibility tool rather than the intended TID integration here.

Biometric factor is a legitimate authentication factor category representing something you are, such as a fingerprint or facial scan. However, the question specifically asks for the two most commonly used factors in MFA, and in practice the most common pair is knowledge plus possession, not knowledge plus biometric. Because possession is not offered as an option, selecting biometric reflects the flawed option set rather than the true industry-standard answer. Therefore this option is valid as a factor type but not as one of the two most commonly used factors in the usual MFA context.

Time factor is not a recognized authentication factor category in standard MFA models. Time may be used as an input to generate a one-time password in TOTP systems, but the factor there is possession of the token or authenticator application, not time itself. Time can also be used in access policy decisions such as restricting logins to business hours. It does not independently prove identity as a factor.

Confidentiality factor is not an authentication factor category. Confidentiality is one of the core security objectives in the CIA triad and refers to preventing unauthorized disclosure of information. It is achieved through controls such as encryption, access restrictions, and data classification. None of those make it a factor used to authenticate a user.

Encryption factor is not an authentication factor category. Encryption is a security mechanism used to protect data at rest or in transit and may support authentication protocols, but it is not itself evidence of identity. Authentication factors are based on what a user knows, has, or is. This option confuses a cryptographic control with an identity-verification category.

SHA-96 is not an encryption algorithm; it refers to a truncated hash output often associated with older IPsec integrity checks (e.g., HMAC-SHA-1-96). Hashes (even when truncated) provide integrity/authentication when used as HMAC, but they do not provide confidentiality. Therefore it cannot satisfy “encryption and authentication” by itself.

AES-256 indicates AES with a 256-bit key size, which provides strong encryption. However, AES-256 alone does not provide authentication/integrity unless used in an authenticated mode (like GCM/CCM) or combined with a separate integrity mechanism (like HMAC-SHA). The question asks for both encryption and authentication, so AES-256 alone is incomplete.

SHA-384 is a cryptographic hash function (SHA-2 family) used for integrity and as a building block for HMAC and digital signatures. It does not encrypt data and therefore cannot provide confidentiality. While it can support authentication when used in HMAC, it still would not meet the requirement for both encryption and authentication for data plane communication.

Patching for cross-site scripting (XSS) is a web application security measure. It helps prevent attackers from injecting scripts into web pages and stealing sessions/credentials, but it is not an endpoint control aimed at reducing phishing and social engineering attempts. In exam terms, XSS mitigation belongs to application security/secure coding rather than user endpoint anti-phishing defenses.

Backups to a private cloud improve recovery and business continuity after an incident (for example, ransomware triggered by a phishing email). However, backups do not minimize the chance of becoming a victim of phishing or social engineering; they reduce downtime and data loss after compromise. This is a resilience control, not a preventive endpoint measure.

Input validation and character escaping are secure development practices used to prevent injection flaws (XSS, SQL injection) in applications. While these controls reduce certain web-based attacks, they are not typical endpoint measures for phishing/social engineering. The question focuses on user endpoints and email-borne threats, where filtering and endpoint security agents are the primary mitigations.

Quality of service (QoS) is not the primary or most commonly tested configuration item under FMC Device Platform Settings for managed devices. QoS is generally a traffic-handling feature and, depending on platform and software, may be configured elsewhere or not centrally managed in the same way as core platform parameters. In SCOR context, Device Platform Settings is more strongly associated with system services like NTP/time.

Network address translation (NAT) is configured using a NAT Policy in FMC and then associated with an Access Control Policy/device deployment. NAT is a traffic policy function (how addresses/ports are translated) rather than a platform/system setting. Therefore it is not configured under Device Platform Settings.

An intrusion policy (Snort-based IPS settings) is configured as an Intrusion Policy and applied through the Access Control Policy (ACP) or related policy assignment mechanisms. It governs traffic inspection and detection/prevention behavior, not device platform operations. As such, it is not part of Device Platform Settings.

Incorrect. AD Group Policy management is a Windows Active Directory domain feature (GPO) used primarily for domain-joined Windows systems. While modern Windows can be managed via MDM and can integrate with identity providers, MDM does not “manage AD GPO.” The mechanisms and policy delivery models are different.

Incorrect. Network device management refers to managing infrastructure devices like routers, switches, and firewalls using tools such as NMS/NSM, controllers, or vendor management platforms. MDM targets endpoint devices (phones/tablets/laptops) and their apps/configurations, not network infrastructure configuration and monitoring.

Incorrect. “Critical device management” is not a standard, recognized MDM advantage or feature category in typical enterprise endpoint management frameworks. MDM can apply different policies to different device groups (e.g., executives vs standard users), but the term itself is not a core MDM capability like inventory or app management.

Incorrect. Adding a new authentication rule on the Policy Service Node changes how future authentication requests are evaluated, but it does not by itself identify specific active sessions that must be reauthorized. Existing sessions generally continue until normal reauthentication, session timeout, or an explicit administrator action occurs. CoA is not automatically issued simply because a new authentication rule was added.

Incorrect. Creating a new Identity Source Sequence and referencing it in authentication policy affects how ISE will process subsequent identity lookups. This is a policy configuration change for future authentications rather than an endpoint state change on an active session. By itself, it does not trigger CoA for already connected devices.

Incorrect. Adding a new ISE server with the Administration persona is a deployment management change and has no direct relationship to active RADIUS sessions on NADs. Administration nodes do not perform the dynamic session control function that would cause endpoint reauthorization. Therefore, this event does not constitute a circumstance under which CoA is issued.

Incorrect. This describes a high-value target (C-level), which aligns with “whaling,” a form of spear phishing focused on executives. Deceptive phishing is generally broad and non-targeted, using generic messages sent to many recipients. The defining factor for deceptive phishing is lack of personalization and scale, not the victim’s job title.

Incorrect. Targeting C-level executives is typically called “whaling,” which is a subset of spear phishing. Spear phishing is broader than executive targeting; it can target any role (HR, finance, IT admins) as long as the attack is tailored and directed. Therefore, this option is too narrow and mislabels the concept.

Incorrect. Hijacking or manipulating DNS to redirect a user to a fake site is “pharming,” not deceptive phishing. Deceptive phishing relies on tricking users via fraudulent messages/links, whereas pharming can redirect users even when they enter a legitimate URL. The mechanism described is DNS-based redirection, not a phishing subtype.

Stealthwatch (Cisco Secure Network Analytics) integrated with ISE improves visibility and can trigger responses based on observed network behavior, but it does not perform endpoint posture checks like verifying AV installation or Windows build level prior to admission. It is primarily for detection/analytics rather than pre-access compliance enforcement.

ASA with Dynamic Access Policies (DAP) can enforce posture-like checks for remote-access VPN sessions (often using AnyConnect attributes) and apply per-session policies. However, it is not the best answer for ensuring all endpoints are compliant before access to the corporate network in general (wired/wireless campus). ISE posture is the enterprise NAC approach.

pxGrid is a context-sharing framework that allows ISE to publish identity and session context to other security tools (EDR, SIEM, firewalls) and consume external context. Enabling pxGrid alone does not implement posture assessment or enforce compliance checks; it is an integration mechanism, not the posture engine.

Incorrect. Cisco ISE posture can evaluate compliance and can redirect or restrict a noncompliant endpoint, but it does not natively install the MS17-010 patch itself. Patch deployment is normally handled by tools such as WSUS, SCCM, Intune, or other endpoint management platforms. The wording makes this option too absolute and assigns remediation capability to ISE that it does not directly provide.

Incorrect. Profiling in Cisco ISE is used to identify and classify endpoints based on observed attributes and network behavior, not to validate whether a specific Microsoft patch or hotfix is installed. Patch-level and security-state validation are posture functions, not profiling functions. Therefore this option confuses two distinct ISE capabilities.

Incorrect in the context of choosing the best two mitigations. ISE posture can check whether an endpoint meets a required patch level and can restrict access if it does not, which is useful as an access-control measure. However, it does not directly remove the vulnerability or block the exploit path as effectively as patching the host or stopping SMB exploit traffic with firewall policies. Since only two answers are allowed, D and E are the more direct mitigations to ransomware infection risk.

Incorrect. It is true that DMZ traffic is redirected, because the DMZ subnet `172.16.10.0/24` falls within the ACL entry `172.16.0.0 255.255.0.0`. However, this option is incomplete because the ACL also explicitly matches the inside network `192.168.100.0/24`. Since both source networks are included in the redirect ACL, DMZ-only is not the best answer.

Incorrect. The inside network `192.168.100.0/24` is explicitly matched by the ACL, so inside traffic is indeed redirected. But this option is also incomplete because the ACL additionally matches `172.16.0.0/16`, which includes the DMZ subnet `172.16.10.0/24`. With a global service-policy, both sets of matching traffic are redirected, not just inside traffic.

Incorrect. The ACL uses `permit ip`, which matches all IP traffic, not just TCP. That means TCP, UDP, ICMP, and other IP-based protocols from the matched source networks are eligible for redirection. Also, the policy does not redirect all TCP traffic universally; it redirects only traffic that matches the ACL/class-map criteria.