certcommie

Oh my! 🙈 Thanks!

Task 1.4, I wonder what's the point of configuring the VPN tunnel to pass NTP traffic via FTDs whereas the branch PC has direct access to the NTP server via its management NIC. So it would be time synchronized irrespectively of whether the VPN tunnel is functional or not. Any ideas?

Strange, but thanks for the info. Wrong answers is not what one would heartily welcome in a $1600 worth exam, but that's Cisco 🙊.

Any news of the lab changes after the blueprint change?

For theory, INE bundle for CCIE security is massive but (as always) fails to cover some substantial portions - in favour of some time-consuming crap like two courses on Wireshark. Also, it's multi-instructor which is bad. Better than nothing, anyway, but don't expect it alone will prepare you for the exam. For practice, I used Khawar Butt's workbook for v5, does not cover all the blueprint of course, but still useful. Do spend plenty of time building your own topologies and scenarios, especially with ISE and various integrations. CCIE Security is a very integration-heavy exam. Cisco practice labs - I did not try them, but from what I saw on Youtube, they are not very useful unless you're unable to build your own topologies (e.g. in EVE-NG). They don't have the feel of the real exam which is multi-domain and very time-pressing. For DNAC, I would not recommend chasing for the HW resources to deploy it locally, basically what you have to master for CCIE Sec is its intergration with ISE and TrustSec controls and also its northbound APIs. Both things can be studied with Cisco's demo installations.

Q33 is a total mess. I agree with options A, D, H , N and O. Option K looks wrong, I would answer L instead. Messaging on compliance as remediation makes no sense - if you are compliant you need no remediation at all. On the contrary, "message text only" is a valid remediation action in ISE. With that, we need two more options to bring the total to 8. Leaving aside everything which is apparently wrong, we are to choose from F, R, I and J. Picking both options F and R as suggested looks invalid. Patch "presence" cannot be remediation, remediation would be patch "installation". Hence option F does not seem valid. Option R speaks of "posture requirement condition" which is something non-existing in ISE. In ISE, there are posture conditions, posture remediations and posture requirements. Requirements are built in the "if condition then remediation" logic. There are no "requirement conditions". I and J both look tentatively valid. Remediation window is configured under the posture profile. Although the posture profile is not explicitly called "Anyconnect configuration file", essentially it is an Anyconnect configuration file. So one has to choose two options from I, J and R. One of those annoying cases when it's not clear whether the option is deliberately invalid or it's valid but poorly phrased. Maybe the incoming data (absent in the workbook) helps to sort it out.

About the Design solutions, some of those are also suspicious. Q7. In Cisco SAFE guides Web Security is considered to protect the network attack surface. However, here it is mapped to the application attack surface. Also, AVC should be mapped to the application attck serface. Q13. It's not clear whether each product may be used only once or multiple times. If once, then I would go with the suggested answers, but if products can be matched to multple surfaces then ISE is definitely a candidate for all three of them, and I would also add AMP to the network surface to respect AMP for networks. Q18. I would answer 5525, not 5516, because 5516 would not handle a multiprotocol throughput of 1Gbps. The question seems to suggest multiprotocol load.

Solution for 4.2 is wrong. The task says that the policy must allow access only to a single webpage. However, if one creates the URL category as shown in the workbook (matching on the site domain name) it would basically allow all URLs on that site. Instead, one should use the regex section to specify the exact URL. And after that two important changes need be done. Firstly, simply adding this custom category on top of all other categories in the access policy will not prevent the user from accessing other pages, because they will not match the regex and will just fall under some other category or under uncategorized. So in addition to allowing this custom category, one should block all pre-defined categories and also block uncategorized. Secondly, the category should not be included in the identification profile. Because otherwise, if the user tries any another page, this action would not hit the custom identification profile and the traffic will thus be allowed based on the default access policy - which again violates the task requirement. But I see no point in including category and port number in the identification profile anyways. The former will be in any case processed via the custom access policy selected for the identification profile, and ports other than 80 just won't be redirected by the router, to begin with.

Solution for Task 4.8 is I think wrong, SMC does not integrate with FMC via pxGrid. Answer D should be picked instead of this wrong answer, in my opinion. It looks like 4.8 and 4.9 both address the same scenario, so answers about the SMC/Netflow part are just expected in Task 4.9.

Well if the requirements say so, then of course that explains. Task 4.6. The solution is incomplete: configuring mitigation action in Stealthwatch will just trigger installation of Null0 route on the router, but that would not in any way "throttle" ICMP requests. The client will cease to receive ICMP replies from the server, but the requests will still reach the server. To complete the task requirements, one shoud combine this with uRPF on ingress of the router. + some time savers: - In the Stealthwatch policy, it's not needed to add the Sales server in there, because CI is for source, not for destination (TI is for destination). - no need to create a custom flow record, default netflow ipv4 output would work fine - no need for IPFIX probably, the default of v9 should be fine Also, it's strange that the workbook shows installation of Null0 route right after several pings from the client side. The way how it works is this: when the source begins excessively pinging, the ICMP Flood security event is triggered and it contributes to CI and the High CI category event. But the default configuration of ICMP Flood security event has quite high thresholds which would not be exceeded by just pinging once a second. At least in Stealthwatch 7 it is thus, don't know about version 6. So to observe the Null0 route installation one would have to tune the ICMP Flood security event with low threshold specifically for this policy. This does not seem to be required by the task, but just for a note. What's also strange, task 1.2 seems to altogether prohibit ICMP from the client PC to the sales server (only TCP 8080 should be allowed), so the whole 4.6 appears pointless in this light. In the workbook, they add the additional entry to the VPN filter (the DACL-to-be) permitting ICMP to the server, but that does not agree with the task 1.2 requirements.

Some solutions are wrong. E.g. Task 1.2, it clearly speaks of DACL on ISE, not the VPN filter. Also, with this configuration, nothing prevents a Sales user from using the Marketing tunnel-group, and vice versa. Although the two are basically the same, but who knows how it will be graded. Technically one can use just a single tunnel-group with two group policies dynamically assigned from ISE, but for time saving one probably would use the ASDM wizard which makes it quicker with two different tunnel groups, in this case I would go with group-lock on the respective policies. In AuthC/AuthZ policy, no need to match on the device IP address, one can match simply on the device name - a time saver. Also, I'm not sure why they disable profiling and password policies on ISE, typically Cisco does not like when you disable something while not told to. Regarding the identity matching, the setup looks weird. What I would expect are pre-configured identity groups in AD and ISE (or at least in ISE), with subsequent matching on those groups in AuthZ policy. If there are none (like in the workbook), and you match on individual username (which you created yourself), I wonder how it's gonna be checked for grading 🤔

OMG clientless is still there... The old Cisco habit of testing on stuff which is not on the blueprint still lives.

... and spanning-tree portfast if that still does not help

Definitely so.

Use authentication control-direction in on the switchport