CX & PRSM: Contains 309 Test Cases

Test Plan Report
10/15/2013 03:49:52 UTC
Project: CX & PRSM Raptor-Threat Defense # Entity Title contains 309 test cases. Description
1. Verify that the threat ids of the threat objects/entries Verify that the threat ids of the threat objects/entries in the taxonomy file do not change after a software in the taxonomy file do not change after a software image upgrade. image upgrade. 2. Verify that threats may be deprecated, but should never be deleted from the threat taxonomy file. Verify that threats may be deprecated, but should never be deleted from the threat taxonomy file (Thetotal number of entries/ threat objects in the threat taxonomy file after a software image upgrade can only be equal or greater than the previous number).
3. Verify that the Global Threat Profile is set to default threat profile object. Verify that the default threat profile object gets automatically created and cannot be deleted. 4. Verify that a threat profile object can be created and Also verify that more than one threat profile it is possible to create more than one threat profile object with the same name cannot be created. object 5. Verify that a threat profile object can be edited. 6. Verify that a threat profile object can be deleted. 7. Verify filtering of search results for threat profile objects 8. Verify that a threat profile object can be created during policy creation. 9. Verify Access Policy Threat Profile, User Created Use the same threat and try different settings on the slider bar. Traffic should be allowed, denied or ignored as expected. 3 different profiles, each attached to an access policy. Run 3 different PCAPs and verify allow/denied/ignored. Then change the slider bar in each profile to cause the next action. 3 different access policies with same threat profile attached. Run 3 different PCAPS and check allowed/denied/ignored. Then change slider bar in the profile to cause the next action.
10. Verify Multiple threat profiles attached to access policies
11. Verify Same Profile attached to multiple access policies
Cisco Systems, Inc. Cisco Confidential Page 1 of 144
12. Verify Default Profile attached to access policies
2 access policies each with a different user created threat profile plus an any/any access policy with default threat profile attached. Run PCAPs and check allowed/denied/ignored. Then change a second profile to also use the default profile. Procedure: 1. Configure a threat protection object with Deny/Alert boundary at 12. 2. Enable Intrusion Protection at the device Level (and apply license if necessary). 3. Pass pcap 22579-0.pcap (which has one threat with score of 15 and another threat socre of 10) with wireplay. 4. Edit the threat protection object and configure the alert/ignore boundary at 12. Expected Result: 1, 2 & 3. Verify the threat is detected in event tab for Threats, and the event is an HTTP Deny. 4. Verify the threat is detected, and the event is an HTTP Complete (a.k.a Alert)
13. Verify Worst Action is picked in the case of several threats firing at once.
14. Verify Multiple Exception Types in a Threat Profile in a Single access policy 15. Verify Global Threat Profile set to Default Threat Profile
In threat profile, have multiple exceptions of each type, and verify expected action for each threat Access policy with a threat profile configured, Global is left as default. Send a threat that doesn@t match the access policy. Global profile should take effect since nothing in access policies matches. Then add more access policies which won@t match the threat & try again. Access policy with a threat profile configured, Global is set to a user created threat profile. Send a threat that doesn@t match the access policy. Global profile should take effect since nothing in access policies matches. Then add more access policies which won@t match the threat & try again Have a threat profile associated with one access policy, and also a global threat profile. Traffic which matches the access policy should trigger on the access policy, not the global profile. Pending match on 2 Access Policy Threat Profiles (matches on a later stage), then threat is identified, Global Profile should be used. Then multiple late stage Access Policies. Then change the action in the Global Threat profile to the next action and verify it takes effect.
16. Verify Global threat Profile set to User Created Profile
17. Verify Threat Profile Configured for both Access Policy and Global; traffic matches Access policy.
18. Verify Global threat profile takes effect with late stage matches on 2 Access policies with threat profiles.
19. Verify Access policies with threat profiles, #1 matches in response body, #2 matches on source IP, and global profile defined.
Access policy matches in response body (application), #2 access policy matches Source IP. And there is global profile. Traffic going to the Dest URL with a threat in the req URL (or req header or response header) should use Global threat profile. Note: The PCAPs which aren@t firing yet (in the body) are the ones which should let us have pending matches on info in the body, such as different layers of application type. Should alert, but entered in blocked (only). Should alert, but entered in None (only). Should alert, but entered in Alert (only) Should deny, but entered in alert (only). Should deny, but entered in None (only). Should deny, but entered in Deny (only). chunked-8010.pcap chunked.pcap deflate.pcap gzip-8888.pcap gzip.pcap utf-7.pcap utf-7-all.pcap utf-8.pcap
20. Verify Exceptions for a global threat profile (user defined profile has exceptions)
21. Verify threats with encoding in the http body, chunked 22. Verify threats with encoding in the http body, deflate. 23. Verify threats with encoding in the http body, gzip 24. Verify threats with encoding in the http body, utf-7 25. Verify threats with encoding in the http body, utf-8
26. Verify threats with encoding in the http body, utf-16 utf-16be.pcap utf-16be-marker.pcap utf-16le.pcap utf-16le-marker.pcap utf-16le-marker-8000.pcap utf-16le-tcp-3128.pcap utf-16le-tcp-8080.pcap 27. Verify threats with encoding in the http body, utf-32 utf-32be.pcap utf-32be-marker.pcap utf-32le.pcap utf-32le-marker.pcap 28. Verify threats with encoding in the http body, more than one encoding at once chunked-gzip.pcap utf-7-chunked-gzip.pcap utf-16be-chunked.pcap utf-16be-chunked-24326.pcap utf-32le-chunked-gzip.pcap Verify HTTP related threat events in Event Viewer Display (in the new Threat Defense View). Verify threat events can be expanded and details seen.
29. Verify HTTP related threat events in Event Viewer Display. 30. Verify the threat events by switching between real time and historic views. 31. Verify pause and play buttons on real time view for threat events. 32. Verify threat events displayed within the selected custom time range.
33. Verify creation,deletion and application of filtering for threat events 34. Verify custom view creation by addiing the threat related columns to existing views 35. Verify the functionality of non threat related events in threat defense view in event viewer. Generate some events with threats and some events without threats and validate that the events without threats are not seen in the threat defense tab.
36. Verify that the user is able edit an access policy and corresponding threat objects from the event viewer. 37. Verify that a new tab named Threat Defense exists in the Devices page. 38. Verify that a drop down menu of threat profiles will be available for the user to choose from, for the Global threat profile and a Submit button. 39. Verify that the user can pick any of the previously configured threat profiles, including the default threat profile and None as the Global Threat profile and apply it. 40. Verify that the addition/deletion of a threat profile object gets reflected in the available options for Global threat profile. 41. Verify that a fresh software install on the device comes with a pre-selected/enabled Global Threat Profile. 42. Verify that the new attacker/victim fields are populated in the events when threats are detected from the source/client. 43. Verify that the new attacker/victim fields are populated in the events when threats are detected from the destination/server. Verify that the new attacker/victim fields (4 fields to validate: attacker, victim, attacker hostname, and victim hostname) are populated in the events when threats are detected from the source/client. Verify that the new attacker/victim fields (4 fields to validate: attacker, victim, attacker hostname, and victim hostname) are populated in the events when threats are detected from the destination/server. To swap the attacker/victim fields in the events in event viewer, go to /var/data/updater/threat_defense/td_http_sigs.xml, look for a pcap such as 1060 and change the <swap-attacker-victim> field to "true" from the default value of "false" and restart the services. 44. Verify that the new attacker/victim fields are not populated in the events when no threats are detected. Verify that the new attacker/victim fields (4 fields to validate: attacker, victim, attacker hostname, and victim hostname) are not populated in the events in threat defense view and all events view by adding those columns when no threats are detected. Verify that the new attacker/victim fields (4 fields to validate: attacker, victim, attacker hostname, and victim hostname)are populated in the TLS complete/Flow deny events when TLS decryption is enabled and a decryption policy is configured.
45. Verify that the new attacker/victim fields are populated in the TLS complete/Flow deny events when TLS decryption is configured.
46. Verify the functionality of full updates for threat prevention component when an update becomes available..
Verify the functionality of full updates for threat prevention component when an update becomes available. Check the event viewer for the corresponding events in System Event View and the updater_connector.log. Verify the default behavior for threat prevention updates. (i.e., threat prevention component get updated by default on a fresh software install on the device and when the user has not explicitly disabled updates). Verify the functionality when the user has explicitly disabled threat prevention updates in the GUI by selecting "Never check" option for Updates in the Device>>Updates page.
47. Verify the default behavior for threat prevention updates.
48. Verify the functionality when the user has explicitly disabled threat prevention updates.
49. Verify the functionality of threat prevention updates Verify the functionality of threat prevention updates with traffic passing through the device. with traffic running through falcon. 50. Verify the functionality of threat prevention updates Verify the functionality of threat prevention updates when the device reloads in middle of update when falcon reloads (or restart the services) in process. middle of update process. 51. Verify that the drill down page of Top Threats are populated accurately. 52. Verify top threats reporting data changes accordingly with different time ranges in the drill down page. 53. Verify the navigation to event viewer from the dashlets in Top Threats drilldown page. Verify that the drill down page of Top Threats are populated with Threats summary, Top Policies,Top Attackers and Top Victims dashlets and accurately. Verify that reporting data for Top Threats changes accordingly with different time ranges in the drill down page. Verify the navigation to event viewer from from the dashlets (Top Policies, Top Attackers and Top Victims) in the Top Threats drilldown page.
54. Verify that traffic that Threat Prevention identifies as Verify that traffic that Threat Prevention identifies as not being of interest is not scanned by the scanner. not being of interest is not scanned by the scanner. - Send some traffic/pcaps with magic/mime-type that the engines have no signatures for, thru falcon and set the logs to debug level. - Check logs to verify that threat defense engines do not inspect the traffic and a debug message of the format "DEBUG Scanners.HttpThreatProtectionPlugin - Skipping threat scanning@due to nextStage mismatch" is seen. 55. Verify that traffic with magic/mime-type recognized Verify that traffic with magic/mime-type recognized by threat prevention engines still gets scanned by by threat prevention engines still gets scanned by the scanner and threats generated accurately. the scanner and threats generated accurately.
56. Verify threats in non-http-tcp (tls) traffic, access policy.
Configure aggressive, alert only, and ignore all threat profile objects. Configure access policy with threat aggressive threat profile. Add cert used by stunnel as a root cert. Enable decryption and configure a decryption policy that decrypts all tls traffic. Use stunnel and wireplay to replay a pcap of nonhttp-tcp traffic (tls) containing a threat. Verify that threats are scanned in tls_proxy.log (DEBUG LEVEL). Verify that threat events (Flow Deny) are seen in the threat defense events tab with threat fields filled in. Test several pcap files. Change the access policy to use the alert only threat profile & replay the pcap. Verify scanning occurs and that a TLS Complete event is seen with threat fields filled in. Test several pcap files. Change the access policy to use the ignore all threat profile & replay the pcap. Verify scanning occurs and that a TLS Complete event is seen only in the Context Aware tab with no threat fields filled in. Verify there is no event in the Threat Protection tab. Test several pcap files.
57. Verify threats in non-http-tcp (tls) traffic using Global threat profiles 58. Verify header de-obfuscation of percent encoding. 59. Verify header de-obfuscation of reverse traversal. 60. Verify header de-obfuscation of premature request ending. 61. Verify header de-obfuscation of long URL@s.
Repeat above test case Txw1201278c, except use the Global threat profile instead of an Access policy Use wireplay to replay 5035-0_whisker_I1M2.pcap. Verify threat fires. Use wireplay to replay 5035-0_whisker_I2M2.pcap. Verify signature fires. Use wireplay to replay 5035-0_whisker_I3M2.pcap. Check monocle log (at TRACE level) to ensure full string was scanned. Use netcat to send @GET /<~2000 character long string>/../faxsurvey? HTTP/1.0. (Found in file 2000ish_chars_long_url) Verify signature fires. Use wireplay to replay 5035-0_whisker_I5M2.pcap. Verify signature fires Use wireplay to replay 5035-0_whisker_I6M2.pcap. Verify signature fires. Use wireplay to replay 5035-0_whisker_I7M2.pcap. Verify signature fires.
62. Verify header de-obfuscation of parameter hiding. 63. Verify header de-obfuscation of HTTP misencoding (tabs). 64. Verify header de-obfuscation of case sensitivity.
65. Verify header de-obfuscation of windows \ delimiter. Use wireplay to replay 5035-0_whisker_I8M2.pcap. Verify signature fires. 66. Verify header de-obfuscation of session splicing. 67. Verify header de-obfuscation of Microsoft %u encoding. Use wireplay to replay 5035-0_whisker_I9M2.pcap. Verify signature fires Use netcat to send @GET /%u0066axsurve%u0065y HTTP/1.0@<enter><enter> from the client. Verify signature fires.
68. Verify header de-obfuscation of Base 36 encoding. Use netcat to send "GET /%e0%81%9m%dg%81%q1%6osurvey"<enter><e nter> from the client (found in file "base36"). For <enter> use ^V^M Enterkey, so that CR,LF is sent. Verify signature fires. 69. Verify header de-obfuscation of double deobfuscation. Use netcat to send "GET /f%2561xsurvey HTTP/1.0"<enter><enter> from the client (found in file double-deob). For <enter> use ^V^M Enterkey, so that CR,LF is sent. Verify signature fires. Use netcat to send @GET / HTTP/1.0"<enter>"Host: extr%61s.u%62untu.%63om"<enter><enter> from the client (found in file header_for_deob). Verify by looking at TRACE level monocle log that the header was deobfuscated. Note: in a VM, we can only test separate versus combined (cannot test the # of processes because it's always 1 in a VM). Stop services. Edit /etc/model.conf; Change "product" to ASA5512, ASA5515, ASA5525. Start services. Issue ps -ef. For those product names, you should see combined processes (i.e. there are a monocle process(es), but no sherlock process(s)). For any other product strings, the processes are split; i.e. there are equal numbers of monocle processes(es) and sherlock process(es). 72. Verify correct number of monocle/combined, monocle/major, monocle/minor process are spawned on Spyker Hardware 73. Verify correct number of monocle/combined, monocle/major, monocle/minor process are spawned on higher end Saleen hardware 74. Verify correct number of monocle/combined, monocle/major, monocle/minor process are spawned on lower end Saleen hardware Test on at least one Sypker hardware, A or B.
70. Verify header de-obfuscation of info in the header, but not in the first line of the request
71. Verify that processes are spawned correctly in a VM system.
Test on at least one Saleen hardware, 5545 or above Test on at least one Saleen hardware 5512, 5515 or 5525.
75. Verify that Threat Protection event tab displays Configure threat profile objects & attach profile to Action field (instead of Event Type) and populates it either access policy or global threat profile correctly for HTTP events (optional). Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. Verify that HTTP Complete events actually show up in the Threat Protection Events tab with "Info" in the action field. Verify that HTTP Deny events actually show up in the Threat Protection Events tab with "Deny"
76. Verify that Threat Protection event tab displays Configure threat profile objects & attach profile to Action field (instead of Event Type) and populates it either access policy or global threat profile correctly for TLS Proxy events (optional). Use wireplay and stunnel to replay PCAPS with threats in TLS traffic, some of which are allowed and some of which are denied. Verify that TLS Complete events actually show up in the Threat Protection Events tab with "Info" in the action field. Verify that Flow Deny events actually show up in the Threat Protection Events tab with "Deny" in the action field. 77. Verify that the defaults for Threat Protection are updated. Navigate to the Threat Protection tab of the Event Viewer. Verify that the correct set of default fields is displayed: Receive Time, Action, Attacker, Target, Threat, Threat Score, Threat Category, Policy Name, Deny Reason Issue ps -ef. Tail/view the logs for PD Recycle the pde process (heimdall_svc pde recycle) Change the logging level (for now, goes with monocle setting) There is a process running for PD. There are no errors in the pde log files (pde.log and stdout_pde.log (may be 0 length at the beginning) Recycling of process produces logging entries The logging level can be changed. 79. Verify that Threat Protection event tab displays Attacker and Target fields and populates them with user name/hostname/ip address when threats are detected from the source/client. Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Create a realm named xsa of type standard LDAP,a directory and a corresponding auth policy. - From the internal client,authenticate as user jeff.williams/xsaxsa and then use wireplay to replay the above PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. Expected Results: - Verify that HTTP Complete events show up in the Threat Protection Events tab with IP address or hostname (if it exists) in the Attacker field. - Verify that HTTP Complete events show up in the Threat Protection Events tab with username in the Attacker field.
78. Verify predictive defense process and logging.
80. Verify that Threat Protection event tab displays Attacker and Target fields and populates them with user name/hostname/ip address when threats are detected from the destination/server.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - To originate the threats from destination/server, go to /var/data/updater/threat_defense/sigs/td_http_sigs. xml and change swap-attacker-victim flag to true instead of false and restart the services.Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Create a realm named xsa of type standard LDAP,a directory and a corresponding auth policy. - From the internal client,authenticate as user jeff.williams/xsaxsa and then use wireplay to replay the above PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. Expected Results: - Verify that HTTP Complete events show up in the Threat Protection Events tab with IP address or hostname (if it exists) in the Target field. - Verify that HTTP Complete events show up in the Threat Protection Events tab with username in the Target field.
81. Verify that the Attacker/Target dashlets in the Threat protection report are accurately populated with user name/hostname/ipaddress.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Create a realm named xsa of type standard LDAP,a directory and a corresponding auth policy. - From the internal client,authenticate as user jeff.williams/xsaxsa and then use wireplay to replay the above PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - To originate the threats from destination/server, go to /var/data/updater/threat_defense/sigs/td_http_sigs. xml and change swap-attacker-victim flag to true instead of false and restart the services. Replay PCAPS using wire play with threats in HTTP traffic, some of which are allowed and some of which are denied. Expected Results: - Verify that the Top Attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname (if it exists). - Verify that the Top Attackers dashlet in Threat Prevention report landing page is populated correctly with username. - Verify that the Top Targets dashlet in Threat Prevention report landing page is populated correctly with username.
82. Verify threats in non-http-tcp, non-tls traffic (but still Configure aggressive, alert only and ignore all tcp) access policy. threat profile objects. Configure access policy with threat aggressive threat profile. Use wireplay to replay a pcap of non-http-tcp, nontls (but still tcp) traffic containing a threat. Verify that threat events ( Deny) are seen in the threat defense events tab with threat fields filled in. Test several pcap files. Change the access policy to use the alert only threat profile & replay the pcap. Verify scanning occurs and that an Info Action is seen with threat fields filled in. Test several pcap files. Change the access policy to use the ignore all threat profile & replay the pcap. Verify scanning occurs and that a Flow Complete event is seen only in the Context Aware tab with no threat fields filled in. Verify there is no event in the Threat Protection tab. Test several pcap files.
83. Verify threats in non-http-tcp, non-tls (but still tcp) traffic using Global threat profiles 84. Verify threats in http traffic, access policy.
Repeat above test case Txw1363273c, except use the Global threat profile instead of an Access policy Configure aggressive, alert only and ignore all threat profile objects. Configure access policy with threat aggressive threat profile. Use wireplay to replay a pcap of http traffic containing a threat. Verify that threat events ( Deny) are seen in the threat defense events tab with threat fields filled in. Test several pcap files. Change the access policy to use the alert only threat profile & replay the pcap. Verify scanning occurs and that an Info Action is seen with threat fields filled in. Test several pcap files. Change the access policy to use the ignore all threat profile & replay the pcap. Verify scanning occurs and that an HTTP Complete event is seen only in the Context Aware tab with no threat fields filled in. Verify there is no event in the Threat Protection tab. Test several pcap files.
85. Verify threats in http traffic using Global threat profiles
Repeat above test case Txw1363277c, except use the Global threat profile instead of an Access policy
86. Verify that the Top attackers dashlet in the Threat Protection report are accurately populated.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Create a realm named xsa of type standard LDAP,a directory and a corresponding auth policy. - From the internal client,authenticate as user jeff.williams/xsaxsa and then use wireplay to replay the above PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - To originate the threats from destination/server, go to /var/data/updater/threat_defense/sigs/td_http_sigs. xml and change swap-attacker-victim flag to true instead of false and restart the services. Replay PCAPS using wire play with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on Transactions and Data Usage tabs in the Top attackers dashlet. - Click on the available options for Transactions pull down menu in the Top attackers dashlet. - Select different options available in the Time Range pull down menu in the Threat Protection report landing page. Expected Results: - Verify that the Top Attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname (if it exists). - Verify that the Top Attackers dashlet in Threat Prevention report landing page is populated correctly with username. - Verify that the Top Targets dashlet in Threat Prevention report landing page is populated correctly with username. - Verify that the report data changes accordingly and accurately with the selection of Transactions and Data Usage tabs in the Top Attackers dashlet. - Verify that the report data changes accordingly and accurately with the selection of All, Denied and Allowed for Transactions pull down menu Top Attackers dashlet. - Verify that the reporting data in the Top attackers dashlet changes accordingly with different time ranges.
87. Verify the drill down functionality for report data from Top Attackers dashlet in Threat Protection report landing page.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on the ip address/username/username/graphical bar in the Top attackers dashlet. - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on Transactions and Data Usage tabs in each of the dashlets. - Click on the available options for Transactions pull down menu in each of the dash lets in the drill down page. - Select different options available in the Time Range pull down menu in the Top Attackers drill down page. Expected Results: - Verify that the Top attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname or username (if it exists). - Verify that the drill down page specific to the attacker is displayed. Verify that the drill down report page is populated with Attackers summary, Policies detecting maximum threats,Top Targets and Threats dash lets and and accurately. - Verify that the report data changes accordingly and accurately with the selection of Transactions and Data Usage tabs in each of the dash lets in the drill down page. - Verify that the report data changes accordingly and accurately with the selection of All,Denied and Allowed options for Transactions in each of the dash lets in the drill down page. - Verify that the reporting data in the drill down page changes accordingly with different time ranges in all the dash lets.
88. Verify the modal overlay of Top Attackers report.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on the View more in the Top attackers dashlet. - Click on values and percentages in the modal overlay report. - Click on any of the column names in the Top attackers modal overlay. - Select different options available in the Items shown pull down menu in the Top Attackers modal overlay report. - Select different options available in the Time Range pull down menu in the Top Attackers modal overlay report. - Choose attacker (I.e., an entry in the Attackers column) and click on the corresponding number in Transactions column beside it. Expected Results: - Verify that the Top attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname or username (if it exists). - Verify that a modal overlay report displaying all the Top attackers is displayed. - Verify that Top Attackers report data changes accordingly and accurately with the selection of values and percentages. - Verify that the Top attackers report data gets sorted by that column in the descending order. Verify that on clicking the column name a second time, displays the report data sorted by the column in an ascending order. - Verify that the report data changes accordingly and accurately with the selection of 10,100 and 1000 for Items shown pull down menu in Top Attackers modal overlay. - Verify that the reporting data in the Top attackers modal overlay changes accordingly with different time ranges. - Verify that a list of all the transactions/events specific to the attacker are listed in the event viewer.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on the ip address/username/username/graphical bar in the Top attackers dashlet. - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on Transactions and Data Usage tabs in each of the dashlets. - Click on the available options for Transactions pull down menu in each of the dash lets in the drill down page. - Select different options available in the Time Range pull down menu in the Top Attackers drill down page. Expected Results: - Verify that the Top attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname or username (if it exists). - Verify that the drill down page specific to the attacker is displayed. Verify that the drill down report page is populated with Attackers summary, Policies detecting maximum threats,Top Targets and Threats dash lets and and accurately. - Verify that the report data changes accordingly and accurately with the selection of Transactions and Data Usage tabs in each of the dash lets in the drill down page. - Verify that the report data changes accordingly and accurately with the selection of All,Denied and Allowed options for Transactions in each of the dash lets in the drill down page. - Verify that the reporting data in the drill down page changes accordingly with different time ranges in all the dash lets.
Procedure: - Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). - Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. - Click on the View more in the Top attackers dashlet. - Click on values and percentages in the modal overlay report. - Click on any of the column names in the Top attackers modal overlay. - Select different options available in the Items shown pull down menu in the Top Attackers modal overlay report. - Select different options available in the Time Range pull down menu in the Top Attackers modal overlay report. - Choose attacker (I.e., an entry in the Attackers column) and click on the corresponding number in Transactions column beside it. Expected Results: - Verify that the Top attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname or username (if it exists). - Verify that a modal overlay report displaying all the Top attackers is displayed. - Verify that Top Attackers report data changes accordingly and accurately with the selection of values and percentages. - Verify that the Top attackers report data gets sorted by that column in the descending order. Verify that on clicking the column name a second time, displays the report data sorted by the column in an ascending order. - Verify that the report data changes accordingly and accurately with the selection of 10,100 and 1000 for Items shown pull down menu in Top Attackers modal overlay. - Verify that the reporting data in the Top attackers modal overlay changes accordingly with different time ranges. - Verify that a list of all the transactions/events specific to the attacker are listed in the event viewer.
Procedure: Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. Click on the ip address/username/username/graphical bar in the Top attackers dashlet. Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. Click on Transactions and Data Usage tabs in each of the dashlets. Click on the available options for Transactions pull down menu in each of the dash lets in the drill down page. Select different options available in the Time Range pull down menu in the Top Attackers drill down page. Expected Results: Verify that the Top attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname or username (if it exists). Verify that the drill down page specific to the attacker is displayed. Verify that the drill down report page is populated with Attackers summary, Policies detecting maximum threats,Top Targets and Threats dash lets and and accurately.For MDM/SMX verify that Devices dashlet is displayed in the drilldown page and is populated accurately. Verify that the report data changes accordingly and accurately with the selection of Transactions and Data Usage tabs in each of the dash lets in the drill down page. Verify that the report data changes accordingly and accurately with the selection of All,Denied and Allowed options for Transactions in each of the dash lets in the drill down page. Verify that the reporting data in the drill down page changes accordingly with different time ranges in all the dash lets.
Procedure: Configure a threat profile object and attach the created threat profile to an access policy or use the existing global threat profile (optional). Use wireplay to replay PCAPS with threats in HTTP traffic, some of which are allowed and some of which are denied. Click on the View more in the Top attackers dashlet. Click on values and percentages in the modal overlay report. Click on any of the column names in the Top attackers modal overlay. Select different options available in the Items shown pull down menu in the Top Attackers modal overlay report. Select different options available in the Time Range pull down menu in the Top Attackers modal overlay report. Choose an attacker (I.e., an entry in the Attackers column) and click on it. Choose an attacker (I.e., an entry in the Attackers column) and click on the corresponding number in Transactions column beside it. Expected Results: Verify that the Top attackers dashlet in Threat Prevention report landing page is populated correctly with IP address or hostname or username (if it exists). Verify that a modal overlay report displaying all the Top attackers is displayed. Verify that Top Attackers report data changes accordingly and accurately with the selection of values and percentages. Verify that the Top attackers report data gets sorted by that column in the descending order. Verify that on clicking the column name a second time, displays the report data sorted by the column in an ascending order. Verify that the report data changes accordingly and accurately with the selection of 10,100 and 1000 for Items shown pull down menu in Top Attackers modal overlay. Verify that the reporting data in the Top attackers modal overlay changes accordingly with different time ranges. Verify that the drill down page specific to the attacker is displayed. Verify that the drill down report page is populated with Attackers summary, Policies detecting maximum threats,Top Targets and Threats dash lets and and accurately.For MDM/SMX verify that Devices dashlet is displayed in the drilldown page and is populated accurately. Verify that a list of all the transactions/events specific to the attacker are listed in the event viewer.
93. Verify that we can skip scanning traffic for threats based on the NBAR verdict (bittorrent)
Tail the Sherlock log file (at DEBUG level; currently follows HTTP). Default configuration is fine. Pass a pcap containing bittorrent traffic Verify a single copy of a message along the lines of "Skipping threat scanning of body. BAVC verdict: 1022" is seen in the log. Also verify the message "Not submitting event: event was sent back to data plane" is seen. Verify that a Flow Complete message is seen in the Context Aware Security tab of the Event Viewer.
94. Verify Threat protection Overall view is displayed properly 95. Generate Report 96. Time range reports proper threat defense alarms
Threat Protection page shows all necessary dashlets properly and all links work properly Verify that you can generate a report when clicking on Generate report Verify that the proper report generated showing the proper threat defense components based on provided time range Verify that all the links in the dashlets work properly and that proper information is displayed. Verify that the maximum threats works properly Verify that the Policies dashlet report the proper threats verify Data usage in the Policies dashlet works properly. Verify Top attackers dashlet in Threat Protection page works properly. Verify that the Top attackers drop down list works properly Verify that the View More button in Top attacker works properly Verify that the Data usage button is working properly in top Attackers dashlet. Verify that the Top target dashlet is working properly. Verify that the Top target dashlet components and links work properly Verify that Data usage works properly in Top target Verify that threats are displayed properly Verify that top threats works properly Verify that top threats works properly
97. Clicking on different links in Dashlets 98. Policies detecting maximum threats 99. Policies dashlet 10 Data Usage in Policies dashlet 0. 10 Top attackers Dashlet 1. 10 Top attackers drop down list 2. 10 View More in Top attacker dashlet 3. 10 data usage in Top attackers dashlet 4. 10 Top target dashlet 5. 10 Top target dashlet functionality 6. 10 Data usage in Top target 7. 10 Threats 8. 10 Top threats 9. 11 Top threats 0.
11 Verify that LSI POST results are reported properly 1. when POST passes
Procedure: On a Spyker blade (which has LSI hardware) that is functioning properly, issue the following commands to check the reporting of LSI POST: Show platform hardware regex Sho tech support Check system events in the GUI. Expected results: Show platform hardware regex output indicates that LSI POST passed. Show tech support output contains the result of "show platform hardware regex" There is a system event with the status of LSI POST (passed).
11 Verify that LSI status evented properly when LSI 2. card is physically removed
Procedure: Modify a Spyker blade such that LSI card is removed. Once card comes up perform the following checks: Show platform hardware regex Sho tech support Check system events in the GUI. Expected results: Show platform hardware regex output indicates that LSI POST indicates "LSI RegexAccelerator not present" Show tech support output contains the result of "show platform hardware regex" There is a system event with the status of LSI unavailable.
11 Verify that LSI POST results are reported properly 3. when POST fails
Procedure: On a Spyker blade (which has LSI hardware) that is functioning properly, use root access to modify a file that the LSI card needs (Modify /opt/lsi/platform_hooks/load and insert the line "exit 0" at the top of the script). Reboot the card. Issue the following commands to check the reporting of LSI POST: Show platform hardware regex Sho tech support Check system events in the GUI. Expected results: Show platform hardware regex output indicates that LSI POST failed. Show tech support output contains the result of "show platform hardware regex" There is a system event with the status of LSI POST (failed.).
11 Verify that the platform telemetry data is collected Procedure: 4. in the SIGN Up client logs for a standalone ASA-CX Configure a threat profile object and attach the device and is accurate. created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy on the device. Configure file filtering and web reputation profiles on the device. Send some traffic thru the box. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file). Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data for a detailed explanation of all the fields mentioned above and their expected results. 11 Verify that the recently collected platform telemetry Procedure: 5. data reflects the changes accurately after Repeat test steps as mentioned above, in test case adding/deleting one or more policies and profiles. 1. Configure another threat profile object and a couple of more access policies. Attach the newly configured threat profile object to one of the newly configured access policies. Send some traffic thru the box. Delete an access policy. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, total_policies,access_policies,threat_profiles,realms ,applications,and top_applications) are modified accurately in the SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that the access_policies field in the collected platform telemetry data gets updated accurately to reflect the deleted access policy.
11 Verify that the platform telemetry data gets 6. collected and is accurate after the device restarts/reboots.
Procedure: Repeat test steps as mentioned above, in test case 1. Reload/Restart the device. Once the device comes up and becomes operational, send some traffic thru the box. Forcefully kill the sign_up process (Issue a kill or pkill command). Forcefully kill the monitord process. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that the telemetry data gets collected in the signup log after the devices comes up and all the above mentioned fields are accurately populated. Verify that the platform telemetry data gets collected and is accurate after the sign_up process comes back up. Verify that the platform telemetry data gets collected in the signup logs and and is accurate, after the monitord process comes back up.
11 Verify that the platform telemetry data gets Procedure: 7. collected and is accurate after upgrading the stand- Repeat test steps as mentioned above, in test case alone ASA-CX device to a latest software image. 1. Upgrade to latest software image and reload the device. Once the device comes up and becomes operational, send some traffic thru the box. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that the platform telemetry data gets collected in the signup log after the devices comes up and all the above mentioned fields are accurately populated, with the newer software.
11 Verify that the platform telemetry data is collected in Procedure: 8. the SIGN Up client logs for a single, managed ASA- Log into SMX, and discover a ASA-CX device in CX device and is accurate. SMX. Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy in SMX. Configure file filtering and web reputation profiles in SMX. Send some traffic thru the ASA-CX. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data for a detailed explanation of all the fields mentioned above and their expected results.
11 Verify that the platform telemetry data is collected in Procedure: 9. the SIGN Up client logs after adding one or more Repeat test steps as mentioned above, in test case ASA-CX devices to PRSM. 5. Configure a threat profile object and attach the created threat profile to an access policy on another ASA-CX device. Configure file filtering and web reputation profiles on the device as well. Add/discover this ASA-CX in SMX. Configure a couple of access policies on the device-group of the newly discovered ASA-CX device. Send some traffic thru both the ASA-CX devices. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Verify that the following fields (startTimeStamp, endTimeStamp, total_policies,access_policies,web_reputation_profil es,threat_profiles,devices,applications,and top_applications) are modified accurately in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX after adding the new ASA-CX device.
12 Verify that the recently collected platform telemetry 0. data reflects the changes accurately after adding/deleting one or more policies and profiles in PRSM.
Procedure: Repeat test steps as mentioned above, in test case 5. Configure another threat profile object and a couple of more access policies. Attach the newly configured threat profile object to one of the newly configured access policies. Send some traffic thru the box. Delete an access policy and a threat profile. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Verify that the following fields (startTimeStamp, endTimeStamp, total_policies,access_policies,threat_profiles,realms ,applications,and top_applications) are modified accurately in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX/PRSM. Verify that the access_policies and the threat_profiles fields in the collected platform telemetry data gets updated accurately to reflect the deleted policies and profiles.
12 Verify that the platform telemetry data gets 1. collected and is accurate after PRSM reboots/restarts.
Procedure: Repeat test steps as mentioned above, in test case 6. Reload/restart SMX/PRSM. Forcefully kill the sign_up process (Issue a kill or pkill command). Forcefully kill the monitord process. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Verify that the platform telemetry data get collected in the SIGN Up client logs of SMX and is accurate after the PRSM comes up and becomes operational. Verify that the platform telemetry data gets collected and is accurate after the sign_up process comes back up. Verify that the platform telemetry data gets collected in the signup logs and and is accurate, after the monitord process comes back up.
12 Verify that the platform telemetry data gets 2. collected and is accurate after upgrading PRSM/SMX to a latest software image.
Procedure: Repeat test steps as mentioned above, in test case 6. Upgrade the ASA-CX devices and PRSM/SMX to latest software image and reload. Once the devices comes up and PSM becomes operational, send some traffic thru the box. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Verify that the platform telemetry data gets collected in the signup log after the devices comes up and all the above mentioned fields are accurately populated, with the newer software.
12 Verify that the platform telemetry data gets Procedure: 3. collected and is accurate after one or more ASA-CX Repeat test steps as mentioned above, in test case devices reboots/restarts. 6. Reload/restart one of the ASA-CX devices. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Verify that the platform telemetry data get collected in the SIGN Up client logs of SMX and is accurate after the reloaded ASA-CX device comes up and becomes operational. 12 Verify that the platform telemetry data gets 4. collected and is accurate after unmanaging one or more ASA-CX devices to PRSM. Procedure: Repeat test steps as mentioned above, in test case 6. Switch to single-device mode/delete an ASA-CX from SMX/PRSM. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Verify that the devices field in the collected platform telemetry data is are modified accurately in the SIGN Up client logs of SMX after deleting/unmanaging the ASA-CX device. 12 Verify that Threats dashlet works properly in the 5. Network overview page 12 Verify the addition of a new section to the "View 6. Details" pane of the events for threat protection when threats are detected 12 Verify that the threat protection fields are (threat 7. name, score, category, attacker, victim, etc.) populated and are accurate 12 Verify the absence of Threats section in the "View 8. details" pane of the events when no threats are detected. Verify that Threat dashlet works properly in Dashboard -> Network Overview page
12 Verify that threat protection events are sent to 9. SystemEventView 13 Verifying logging format and level changes for 0. telemetry data.
This Test case verifies that a series of events are sent to SystemEventView Procedure: 1. Open up a browser with ASA-CX ip and navigate to Device>>Configuration>>Logging and change the management-plane logging level to TRACE. 2. Open up a ssh session to ASA-CX and go to /cisco/heimdall/etc/monitord.conf and add an argument '-t' to the program_arguments variable. 3. Restart the Cisco services. Expected Results: Verify that a log level message such as " 2013-0212 12:24:38,236 - root - [DEBUG] status: OKid: SET_LOG_LEVEL" is seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). 2. Verify that the logging format of the telemetry data has changed in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that a log level message such as " 2013-0212 12:24:38,236 - root - [DEBUG] status: OK id: SET_LOG_LEVEL" is seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file).
13 Verify that the backend FBNP server is receiving 1. telemetry data for an ASA-CX device in both unmanaged and managed modes.
Procedure: Repeat test steps 1-3 as in test case 1. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qafbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Log into SMX, and discover a ASA-CX device in SMX. Expected Results: Verify that this phone home log provides the info on who made a connection and whether the telemetry package received can be authenticated and decoded successful. A successful telemetry package sent should result a log entries like the following: INFO AUTH SUCCESS <dict/udi>: ip=173.37.9.40, auth={'udi': '0bb93985f42d941e50dc8f022350d1a8033958cdc7 050750aa5c503d0ad5e71e491c060954d870f6fab6 a9d336e59bbdfd4864e8c56552d78702202862f121 4a'}, decrypted=PID: ASA-SSM-10 , SN: JAD1618024A, vln=n/a Verify that this directory contains the actual telemetry packet that was sent from the ASA-CX device and verify that each packet has the following content (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate, just as seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that the telemetry data as described in step2 gets collected in the same phone home log for SMX in the FBNP server.
13 Verify the functionality of good platform telemetry 2. updates on a stand alone CX device.
Procedure: Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy on the device. Configure file filtering and web reputation profiles on the device. Send some traffic thru the box. Shutdown updater (using the CLI, "heimdall_svcdown updater_connector") and update the system. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box again. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file). Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data for a detailed explanation of all the fields mentioned above and their expected results. Validate that the new update is downloaded and applied properly. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows the version and timestamps correctly. Validate that after the update, the platform telemetry data gets collected in the SIGNUP client logs and is accurate.
13 Verify whether platform telemetry update will 3. continue to apply after the ASA-CX device reboots/reloads in middle of update process.
Procedure: Repeat test steps 1-6 in test case 1. Reload/Restart the device. Once the device comes up and becomes operational, send some traffic thru the box. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file). Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data for a detailed explanation of all the fields mentioned above and their expected results. Validate that the new update is downloaded and applied properly after the device comes up and becomes operational. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows the version and timestamps correctly. Validate that after the update, the platform telemetry data gets collected in the SIGNUP client logs and is accurate.
13 Verify the functionality of good platform telemetry 4. updates on a managed ASA-CX device.
Procedure: Log into SMX, and discover a ASA-CX device in SMX. Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy in PRSM/SMX. Configure file filtering and web reputation profiles in PRSM/SMX. Send some traffic thru the device. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") and update the system. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the managed ASA-CX again. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data for a detailed explanation of all the fields mentioned above and their expected results. Validate that the new update is downloaded and applied properly. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows the version and timestamps correctly. Validate that after the update, the platform telemetry data gets collected in the PRSM SIGNUP client logs and is accurate.
13 Verify whether platform telemetry update will 5. continue to apply after PRSM reboots/reloads in middle of update process.
Procedure: Repeat test steps 1-7 in test case 5. Reload/Restart the PRSM. Once PRSM/SMX comes up and becomes operational, send some traffic thru the managed ASA-CX. Expected Results: Verify that the following fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the SIGN Up client logs (in the /var/log/cisco/signup.log file) of SMX. Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data for a detailed explanation of all the fields mentioned above and their expected results. Validate that the new update is downloaded and applied properly after PRSM comes up and the managed ASA-CX becomes operational. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows the version and timestamps correctly. Validate that after the update, the platform telemetry data gets collected in the PRSM SIGNUP client logs and is accurate.
13 Verify that threat profiles work correctly with 3 or 6. more Alert, Deny, and Ignore exceptions.
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for the Profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. 5-Click on Save Policy and commit 6-Pass some traffic using at least 3 pcaps and note the names of the threats. 7-Create an exception for the pcaps by going to Policies, Objects, and click on Profile Edit Object. 8-Expand Advanced threat settings. Enter the name of the threats noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threats to Deny and pass the same pcaps. 11-Change the Action for the same threats to Alert and pass the same pcaps. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored
13 Verify that threat profiles work properly when 7. multiple Exceptions types are created in multiple access policies within a single Threat Profile.
Steps: 1-Create multiple Access policies by going to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for the Profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. 5-Click on Save Policy and commit 6-Pass some traffic using at least 3 pcaps and note the names of the threats. 7-Create an exception for the pcaps by going to Policies, Objects, and click on Profile Edit Object. Repeat for all Policies. 8-Expand Advanced threat settings. Enter the name of the threats noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threats to Deny and pass the same pcaps. 11-Change the Action for the same threats to Alert and pass the same pcaps. 12-Change the Action of the threats one to Alert, another to Deny, and another to ignore and pass traffic. 13-Change the Access policies but keep the Threat Profile. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored 12-Traffic behaves as expected. 13-threats with Deny are blocked, threats with Ignore are ignored, and threats with Alert are allowed but reported in Events and Threat Protection.
13 Verify that Alert, Deny, and Ignore Exceptions work Steps: 8. properly with a Threat profiles with varying level of 1-Navigate UI to add a new Access Policy. Risk acceptance. 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for the Profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. 5-Click on Save Policy and commit 6-Pass some traffic using at least 3 pcaps and note the names of the threats. 7-Create an exception for the pcaps by going to Policies, Objects, and click on Profile Edit Object. 8-Expand Advanced threat settings. Enter the name of the threats noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threats to Deny and pass the same pcaps. 11-Change the Action for the same threats to Alert and pass the same pcaps. 12-Edit the Profile Object and move the Profile slider bars to 100 and save changes and commit. This will allow all traffic and not monitor them. Now pass some traffic. 13-Change the Action for Exception to Alert, then Deny, then Ignore and pass traffic for each action. 14-Change the sliders to the middle of the slider bar and save changes and commit them. And repeat 12-13. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. Verify in Events and Dashboard, Threat protection. 10-Traffic is blocked and monitored. Verify in Events and Dashboard, Threat protection. 11-Traffic is allowed and monitored. Verify in Events and Dashboard, Threat protection. 12-All traffic is allowed and not monitored. Verify in Events and Dashboard, Threat protection. 13-Traffic is allowed but reported for Alert case, Blocked and reported for Deny case, and ignored for Ignore case. 14-Traffic that is in Deny will be blocked, for Ignore it will be ignored and for Alert it will alert. For other traffic it will depend on how they fall in the slider bar.
13 Verify that threat profiles works properly when a 9. non-http-traffic (TLS) is placed as an exception in Exceptions. Make sure it works with Alert, Deny, and Ignore.
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for test profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. 5-Click on Save Policy and commit 6-Pass some non-http-traffic (TLS) traffic (use stunnel to encrypt the traffic and send it over TLS) and note the name of the threat. 7-Create an exception for the pcap by going to Policies, Objects, and click on Profile name Edit Object. 8-Expand Advanced threat settings. Enter the name of the threat noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threat to Deny and pass the same traffic 11-Change the Action for the same threat to Alert and pass the same traffic 12-Edit profile Object and change the slider bar to 100. Here all traffic will be allowed. 13-Repeat the test by passing the same traffic and setting action to Alert, Ignore, and Deny. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored 12-13: when Action is set to Alert traffic is passed, when set to Ignore the traffic passes through and does not get reported, when set to Deny it is blocked and reported in Events and Threat protection page.
14 Verify that threat profiles works properly when a 0. non-http-traffic (TLS) is placed as an exception in Global Exceptions. Make sure it works with Alert, Deny, and Ignore.
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for test profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. Also set this profile to Global profile by going to Device, Threat protection and selecting the profile in drop down list and clicking on submit. 5-Click on Save Policy and commit 6-Pass some non-HTTP TLS traffic (use stunnel to encrypt the traffic and send it over TLS) and note the name of the threat. 7-Create an exception for the pcap by going to Policies, Objects, and click on Profile name Edit Object. 8-Expand Advanced threat settings. Enter the name of the threat noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threat to Deny and pass the same traffic 11-Change the Action for the same threat to Alert and pass the same traffic 12-Edit profile Object and change the slider bar to 100. Here all traffic will be allowed. 13-Repeat the test by passing the same traffic and setting action to Alert, Ignore, and Deny. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored 12-13: when Action is set to Alert traffic is passed, when set to Ignore the traffic passes through and does not get reported, when set to Deny it is blocked and reported in Events and Threat protection page.
14 Verify that threat profiles works properly when a 1. non-HTTP, non-TLS, TCP traffic is placed as an exception in Exceptions. Make sure it works with Alert, Deny, and Ignore.
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for test profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. Also set this profile to Global profile by going to Device, Threat protection and selecting the profile in drop down list and clicking on submit. 5-Click on Save Policy and commit 6-Pass some non-HTTP, non-TLS, TCP traffic using proper pcaps and note the name of the threat. 7-Create an exception for the pcap by going to Policies, Objects, and click on Profile name Edit Object. 8-Expand Advanced threat settings. Enter the name of the threat noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threat to Deny and pass the same traffic 11-Change the Action for the same threat to Alert and pass the same traffic 12-Edit profile Object and change the slider bar to 100. Here all traffic will be allowed. 13-Repeat the test by passing the same traffic and setting action to Alert, Ignore, and Deny. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored 12-13: when Action is set to Alert traffic is passed, when set to Ignore the traffic passes through and does not get reported, when set to Deny it is blocked and reported in Events and Threat protection page.
14 Verify that that Threat Profiles work properly when 2. a non-HTTP, non-TLS, TCP traffic is used within a Global Threat profile.
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for test profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. Also set this profile to Global profile by going to Device, Threat protection and selecting the profile in drop down list and clicking on submit. 5-Click on Save Policy and commit 6-Pass some non-HTTP, non-TLS, TCP traffic using proper pcaps and note the name of the threat. 7-Create an exception for the pcap by going to Policies, Objects, and click on Profile name Edit Object. 8-Expand Advanced threat settings. Enter the name of the threat noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threat to Deny and pass the same traffic 11-Change the Action for the same threat to Alert and pass the same traffic 12-Edit profile Object and change the slider bar to 100. Here all traffic will be allowed. 13-Repeat the test by passing the same traffic and setting action to Alert, Ignore, and Deny. Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored 12-13: when Action is set to Alert traffic is passed, when set to Ignore the traffic passes through and does not get reported, when set to Deny it is blocked and reported in Events and Threat protection page.
14 Verify that http-traffic exception work properly in 3. Access Policy
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for test profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. 5-Click on Save Policy and commit 6-Pass some traffic using pcaps and make sure it is an HTTP pcap traffic e.g. 1052-0.pcap and note the name of the threat. 7-Create an exception for the pcap by going to Policies, Objects, and click on Profile name Edit Object. 8-Expand Advanced threat settings. Enter the name of the threat noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threat to Deny and pass the same traffic 11-Change the Action for the same threat to Alert and pass the same traffic Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored
14 Verify that http-traffic exception work properly in 4. Access Policy within the Global Threat Profile.
Steps: 1-Navigate to Policies, Policies and under Access click on Add new policy 2-Enter a name for Policy Name 3-Expand profile and click on Create new profile 4-Enter a name for test profile Name and take both slider bars to 0. Here all traffic will be blocked and monitored. Click on Save Object. 5-Click on Save Policy and commit. Make this profile the Global Threat profile by going to Device, Threat protection. Select this threat profile and submit. 6-Pass some traffic using pcaps and make sure it is an HTTP pcap traffic e.g. 1052-0.pcap and note the name of the threat. 7-Create an exception for the pcap by going to Policies, Objects, and click on Profile name Edit Object. 8-Expand Advanced threat settings. Enter the name of the threat noted down in Exceptions and select Ignore for Action and click on Apply, Save Object, and commit object. 9-Now pass the same traffic 10-Change the Action for the same threat to Deny and pass the same traffic 11-Change the Action for the same threat to Alert and pass the same traffic Expected Result: 1-6: Access policy, and Threat Profile, is created. Traffic is blocked. Verify in Events and Dashboard, Threat protection 7-9: Traffic is ignored. 10-Traffic is blocked and monitored 11-Traffic is allowed and monitored Steps: 1-Configure a threat profile object and attach the profile to an Access Policy 2-Verify that a list of IPs exist in /var/data/updater2/drop - this might change in future build. 3-Send some traffic thru the box such that the source/destination of IP is on the blacklisted IPs. 4-Try to go to a destination not in the list of IPs.
14 Verify that you can block a list of IPs using 5. /var/data/updater2 in SMX
Expected Results: 1-Access policy and threat profile are created and configured properly. 2-The file and the list of IPs are in the file. 3-The traffic is blocked as expected. Corresponding deny events can be seen in Event Viewer . 4-User can navigate to IPs not in the IP list.
14 Verify that you can block a list of IPs using 6. /var/data/updater2 in PRSM
Steps: 1-In the PRSM configure a threat profile object and attach the profile to an Access Policy 2-Verify that a list of IPs exist in /var/data/updater2/drop - this might change in future build. 3-Send some traffic thru the box such that the source/destination of IP is on the blacklisted IPs. 4-Try to go to a destination not in the list of IPs. 5-Verify that the traffic is blocked and corresponding deny events can be seen in the PRSM Event Viewer. Expected Results: 1-Access policy and threat profile are created and configured properly. 2-The file and the list of IPs are in the file. 3-The traffic is blocked as expected. Corresponding deny events can be seen in Event Viewer . 4-User can navigate to IPs not in the IP list. 5-Traffic is blocked from the IP list and corresponding deny events can be seen in the PRSM Event Viewer.
14 Verify the functionality of cold start recovery for a 7. bad TP signature update that fails in the Switch state on a managed ASA-CX device.
Procedure: Log into SMX, and discover an ASA-CX device in SMX. Repeat the test steps 1- 9 as mentioned above, in test case 1. Expected Results: Validate as mentioned above in test case 1 (steps 1-10).
14 Verify the functionality of cold start recovery 8. manually on an unmanaged ASA-CX device.
Procedure: Manually clear out all the bad tp signatures, by deleting the files: (/var/data/updater/threat_defense/sigs/td_http_sigs. xml /var/data/updater/threat_defense/sigs/td_stream_si gs.xml /var/data/updater/threat_defense/etc/td_http_config. xml /var/data/updater/threat_defense/etc/td_stream_co nfig.xml /cisco/updater/updates/threat_defense/threat_defen se_taxonomy.conf) Send some traffic thru the box. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some pcaps thru the device. Expected Results: Verify that traffic passes thru the box successfully and corresponding events can be seen in the event viewer. Validate that threats cannot be detected and corresponding events are not displayed in the threat protection tab in the event viewer.
14 Verify the functionality of cold start recovery 9. manually on a managed ASA-CX device.
Procedure: Log into SMX, and discover an ASA-CX device in SMX. Repeat test steps 2-5 as mentioned above, in test case 3. Expected Results: Validate as mentioned above in test case 3.
15 Verify the functionality of cold start recovery for a 0. bad TP signature update that fails in the Switch state on a stand alone ASA-CX device.
Procedure: Between each test case, it is advised to erase and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as abo
Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that tp signature update fails in the Switch state and enters the cool down period. Validate that the following msg are displayed in the updater logs(/var/log/cisco/updater_connector.log) : "Some Inspectors failed to switch: .." and "tp updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event, such as "Some scanners failed to switch to tp/threats .. " gets generated and can be seen in the event viewer. Verify that version number for tp signature in the Updater UI (Device>>Updates>>Updates) will change between the updates. Verify that updater will detect the bad signatures and will initiate a cold start to clear out the bad signatures. Validate that all the other processes (such as monocle) start up successfully. Verify that tp signature update then rolls back successfully and the updater UI, reflects that the tp signature component 's version number changes to the same as before the update. Verify that a corresponding system event (Switched to update tp/threats, version. ) gets generated in the event viewer indicating the Cisco Systems, Inc. Cisco Confidential rollback. Page 45 of 144 Verify that traffic passes thru the box successfully after the rollback update. Validate that after the update, that the threats detected earlier, before the update, still fire.
15 The Scroll bar in List of Threat is infinite ie 1. continous to the end
Steps: Navigate to Policies then threats and click on the scroll bar and start scrolling down. Expected Result: An infinite scroll bar is present where it constantly goes to the database and brings in new scrolls to the page. Steps: Navigate to the Policies, Threats page Expected Result: List of threats appear with "Threats" at the top, and Filter field below it with a list of all of threats. Steps: 1-Navigate to Policies, Threats and enter Adobe Acrobat in the Filter field and click on Filter 2-Enter non-alphanumeric characters in the filter field such as ; + ( ) << or >> and click on Filter 3-Clear the Filter field and click on Filter. 4-Search for several threats by name by entering the names in the Filter field and clicking on Filter 5-Search for description of the threat and not the name Expected Result: 1-List of threats will appear that have "Adobe Acrobat" in them 2-list of threats will appear with those characters in them. If no threats have those characters, then an empty list will appear. 3-All threats will appear. You should be able to scroll down to see the last one. 4-all threats will appear with that string in the threat. 5-List of threats will appear that have the string in their description.
15 List of threats appears in Policies, Threats 2.
15 Filter works properly in the list of Threats 3.
15 List of threats are updated with new threats in SMX Procedure: 4. 1-Take a list of threats that appear in Policies, Threats list. 2-Update the SMX device. 3-Verify that there are new updates in the Threats list. Expected Result: Verify that the new threats are listed in the updates. 15 List of threats are updated with new threats in 5. PRSM Procedure: 1-Take a list of threats that appear in Policies, Threats list. 2-Update the SMX device. 3-Verify that there are new updates in the Threats list. Expected Result: Verify that the new threats are listed in the updates.
15 List of threats are updated with some threats being Procedure: 6. deprecated in SMX 1-Take a list of threats that appear in Policies, Threats list. 2-Update the SMX device. 3-Verify that there are threats deprecated/removed from Threats list. Expected Result: Verify that the threats are not listed in the updates. 15 List of threats are updated with some threats being Procedure: 7. deprecated in PRSM 1-Take a list of threats that appear in Policies, Threats list. 2-Update the PRSM device. 3-Verify that there are threats deprecated/removed from Threats list. Expected Result: Verify that the threats are not listed in the updates. 15 Verify no EUN is generated when threats are 8. blocked in a browser with SMX Procedure: 1-Load the appropriate build on an ASA-CX in an umanaged mode. Overwrite the /var/data/updater/threat_defense/sigs/td_http_sigs. xml with the us4510.xml file (You can get this file from Paul G) 2-Make sure to restart services so that monocle picks up the updated signature file. 3-Makue sure you have a policy in place to deny threats. 4-From your box running as your server, open a console and run teh command "python -m SimpleHTTPServer 8000" 5-From your client, open a browser and navigate to http://<server-ip>:8000/vulnerable.php 6-You should see an EUN on your client 7-Edit the swap-attacker-victim field in the signature XML file and set it to false, restart services, rerun the tests. Expected Result: You should NOT see an EUN displayed, and in the monocle logs you should see a log message indicating that the EUN is disabled.
15 Verify no EUN is generated when threats are 9. blocked in a browser with PRSM
Procedure: 1-Load the appropriate PRSM build. Overwrite the /var/data/updater/threat_defense/sigs/td_http_sigs. xml with the us4510.xml file (You can get this file from Paul G) 2-Make sure to restart services so that monocle picks up the updated signature file. 3-Makue sure you have a policy in place to deny threats. 4-From your box running as your server, open a console and run teh command "python -m SimpleHTTPServer 8000" 5-From your client, open a browser and navigate to http://<server-ip>:8000/vulnerable.php 6-You should see an EUN on your client 7-Edit the swap-attacker-victim field in the signature XML file and set it to false, restart services, rerun the tests. Expected Result: You should NOT see an EUN displayed, and in the monocle logs you should see a log message indicating that the EUN is disabled. procedure: 1-Create an authentication Realm in ASACX 2-In the client machine try to browse the internet 3-A popup will appear asking for user name and password 4-enter the username and password from the Realm Expected Result: User name and password are accepted and user can surf the internet.
16 LSI Regex Acceleration: Verify that Authentication 0. works properly in Spyker
16 LSI Regex Acceleration: Huge_ variables are set to procedure: 1. zero in Saleen/VM 1-login to Saleen 2-Navigate to /proc 3-vi meminfo and search Huge_ variables. Expected Result: All Variables that start with Huge should be set to 0 and remain at zero for Saleen and VMs except for Hugepagesize will be at 2048 kB. 16 LSI Regex Acceleration: Huge_ variables are no set procedure: 2. to zero in Spyker 1-login to Saleen 2-pass some pcaps from server to client and generate some traffic 2-Navigate to /proc 3-vi meminfo and search Huge_ variables. Expected Result: All Variables that start with Huge should be set to a value and remain at that value.
16 LSI Regex Acceleration: Restarting services will not procedure: 3. affect operations in Saleen and VMs 1-login to the Saleen machine with putty. 2-su admin 3-Services Stop 4-Services start 5-pass some traffic 6-pass some pcaps 7-check the /proc/meminfo file Expected Result: 1-5: all traffic pass successfully 6-Threats are reported in Event's and Threat protection page and blocked. 7-Huge variables remain at 0 except for Hugepageszies will be at 2048 kB. 16 LSI Regex Acceleration: Restarting services will not procedure: 4. affect operations in Spyker and 1-login to the Spyker machine with putty. 2-su admin 3-Services Stop 4-Services start 5-pass some traffic 6-pass some pcaps 7-check the /proc/meminfo file Expected Result: 1-5: all traffic pass successfully 6-Threats are reported in Event's and Threat protection page and blocked. 7- All Variables that start with Huge should be set to a value other than 0 and remain above 0, Hugepagesize should be at 2048 kB. 16 LSI Regex Acceleration: Verify that Authentication 5. works properly in Saleen procedure: 1-Create an authentication Realm in ASACX 2-In the client machine try to browse the internet 3-A popup will appear asking for user name and password 4-enter the username and password from the Realm Expected Result: User name and password are accepted and user can surf the internet.
16 Verify correct behavior of LSI/VPS when LSI card is Procedure: Bring up an ASACX blade which has 6. present LSI card present. Note, all Spykers as well as Saleens 5525 and above have an LSI card. 1. Check the processes. 2. Issue the cli command: show platform hardware regex 3. Check for a file flag: "/var/log/cisco/boot/lsi.operational". 4. At root prompt, issue "lsmod" command. 5. Check System Events tab in the Event Viewer. Expected Results: 1. Verify that one vps process is running. 2. Verify there is output indicating lsi is present; POST status should be displayed. Also, "show platform hardware regex" should show per engine counters, e.g. "Flow/N...jobs submitted..." etc. 3. Verify it's present. 4. Verify the kernel module cpp_base is listed. 5. Verify there is a System Event present for restoring communication with LSI. 16 Verify correct behavior of LSI/VPS when there is no Procedure: Bring up an ASACX blade which has no LSI card present. Note, Saleen models 5512 7. LSI card present and 5515 do not have LSI card. In addition there's no LSI card on a VM, either. 1. Check the processes. 2. Issue the cli command: show platform hardware regex 3. Check for a file flag: "var/log/cisco/boot/lsi.operational". 4. At root prompt, issue "lsmod" command. 5. Check System Events tab in the Event Viewer. Expected Results: 1. Verify there is no vps process running. 2. Verify there is output indicating lsi not present 3. Verify it's missing. 4. Verify the kernel module cpp_base is not listed. 5. Verify there are no System Events for LSI. 16 Verify correct behavior of LSI/VPS when LSI card is Procedure: Modify an ASACX blade which has an 8. present, but load or POST fails LSI card present, so that POST will fail. In order to make POST fail, modify /opt/lsi/platform_hooks/load to "exit 0" as the first line of the script (before doing anything else). Note, all Spykers as well as Saleens 5525 and above have an LSI card. 1. Check the processes. 2. Issue the cli command: show platform hardware regex 3. Check for a file flag: "var/log/cisco/boot/lsi.operational". 4. At root prompt, issue "lsmod" command. 5. Check System Events tab in the Event Viewer. Expected Results: 1. Verify there is no vps process running. 2. Verify there is output indicating lsi not present 3. Verify it's missing. 4. Verify the kernel module cpp_base is not listed. 5. Verify there is a System Event present indicating a problem with POST/LSI
16 Verify correct behavior of LSI/VPS when LSI driver 9. fails to be reloaded upon VPS restart
Procedure: Modify an ASACX blade which has an LSI card present: starting from a running/working state, modify opt/lsi/platform_hooks/load to fail by adding "exit 1" as opposed to "exit 0", and then restart vps via the "service restart" command. Note, all Spykers as well as Saleens 5525 and above have an LSI card. 1. Issue the cli command: show platform hardware regex 2. Check System Events tab in the Event Viewer. Expected Results: 1. Verify there is output indicating lsi not present 2. Verify there is a system event indicating LSI is unaccessible Procedure: Navigate to /mnt/ folder in Saleen or VM Expected Result: There is no hugetlb folder under /mnt/ Procedure: Navigate to /mnt/ folder in Spyker Expected Result: There is a hugetlb folder under and it is populated with some files Procedure: Verify that decryption works properly in Saleen/VM environments Expected Result: Decryption works properly in Saleen/VM environments Procedure: Verify that decryption works properly in Spyker environments Expected Result: Decryption works properly in Spyker environments Procedure: 1-In a single mode ASA-CX navigate to Dashboard page. 2-Click on Generate Report. Expected Results: Verify that Threat Analysis appears as an option for Report Type Procedure: 1-In a managed mode or PRSM navigate to Dashboard page. 2-Click on Generate Report. Expected Results: Verify that Threat Analysis appears as an option for Report Type
17 LSI Regex Acceleration: Verify that /mnt/ has no 0. hugetlb folder in Saleen/VM
17 LSI Regex Acceleration: Verify that /mnt/ has 1. hugetlb folder in Spyker and it is populated with files
17 LSI Regex Acceleration: Verify that Decryption 2. works properly in Saleen/VM
17 LSI Regex Acceleration: Verify that Decryption 3. works properly in Spyker
17 US5805: Verify Threat Protection appears as an 4. option when selecting Generate Report in single mode or ASA-CX
17 US5805: Verify Threat Protection appears as an 5. option when selecting Generate Report in Manged mode or PRSM
17 US5805: Verify Threat Protection appears as an 6. option when selecting Generate Report in single mode or ASA-CX everywhere Generate Report appears.
Procedure: 1-In a single mode or ASA-CX navigate to all pages that have Generate report eg Network overview, Malicious traffic, Threat protection, Users, Web destinations, Web categories, Policies, User devices, Applications, Application types 2-Click on Generate Report. Expected Results: Verify that Threat Analysis appears as an option for Report Type Procedure: 1-In a managed mode or PRSM navigate to all pages that have Generate report eg Network overview, Malicious traffic, Threat protection, Users, Web destinations, Web categories, Policies, User devices, Applications, Application types 2-Click on Generate Report. Expected Results: Verify that Threat Analysis appears as an option for Report Type
17 US5805: Verify Threat Protection appears as an 7. option when selecting Generate Report in Managed Mode or PRSM everywhere Generate Report appears.
17 US5805: Verify that a report can be successfully Procedure: 8. generated using Threat protection in single mode or 1-In a single mode or ASA-CX navigate to ASA-CX Dashboard. 2-Click on Generate report. 3-Select Threat Analysis and generate a report. Expected Results: A report is generated succesfully. 17 US5805: Verify that a report can be successfully 9. generated using Threat protection in managed mode or PRSM Procedure: 1-In a single mode or ASA-CX navigate to Dashboard. 2-Click on Generate report. 3-Select Threat Analysis and generate a report. Expected Results: A report is generated succesfully.
18 US5805: Verify that a report can be successfully Procedure: 0. generated using Threat protection in single mode or 1-In a single mode or ASA-CX navigate to ASA-CX for all pre-defined Time Ranges Dashboard. 2-Click on Generate report. 3-Select Threat Analysis and generate a report for all pre-defined Time Ranges. Expected Results: A report is generated succesfully. 18 US5805: Verify that a report can be successfully 1. generated using Threat protection in managed mode or PRSM for all pre-defined Time Ranges Procedure: 1-In a single mode or ASA-CX navigate to Dashboard. 2-Click on Generate report. 3-Select Threat Analysis and generate a report for all pre-defined Time Ranges. Expected Results: A report is generated succesfully.
18 US5805: Verify that a report can be successfully Procedure: 2. generated using Threat protection in single mode or 1-In a single mode or ASA-CX navigate to ASA-CX using custom ranges. Dashboard. 2-Click on Generate report. 3-Select Threat Analysis and generate a report for custom time ranges taking hours, days, and months. Expected Results: A report is generated succesfully. 18 US5805: Verify that a report can be successfully 3. generated using Threat protection in managed mode or PRSM using custom Time Ranges Procedure: 1-In managed mode or PRSM navigate to Dashboard. 2-Click on Generate report. 3-Select Threat Analysis and generate a report for custom time ranges taking hours, days, and months. Expected Results: A report is generated succesfully. Procedure: 1-Pass some HTTP Traffic thorugh ASA-CX(single mode) 2-Pass some non-HTTP traffic through ASA-CX. 3-Generate a Threat Analysis Report in the ASACX mode. Expected Results: 1-Generated report reflects the HTTP and nonHTTP traffic correctly and accurately. Procedure: 1-Pass some HTTP Traffic thorugh a managed mode or PRSM. 2-Pass some non-HTTP traffic through a managed mode device or PRSM. 3-Generate a Threat Analysis Report in the PRSM. Expected Results: 1-Generated report reflects the HTTP and nonHTTP traffic correctly and accurately. Procedure: 1-In a single mode or ASA-CX create a few exceptions for threats to Deny, Allow, and ingore threats. 2-Pass several pcaps that are not included in the exceptions in the profile. 3-Pass the traffic in the exceptions. 4-Generate a Threat Analysis report. Expected Results: The report reflects all the passed pcaps correctly and accurately.
18 US5805: Verify that after passing HTTP, and non4. HTTP traffic that these are properly generated in the report in single mode or ASA-CX
18 US5805: Verify that after passing HTTP, and non5. HTTP traffic that these are properly generated in the report in managed mode or PRSM
18 US5805: Verify that when threats are placed as 6. exceptions they are properly reported in single mode or ASA-CX
18 US5805: Verify that when threats are placed as 7. exceptions they are properly reported in managed mode or PRSM
Procedure: 1-In a managed mode or PRSM create a few exceptions for threats to Deny, Allow, and ingore. 2-Pass several pcaps that are not included in the exceptions in the profile. 3-Pass the traffic in the exceptions. 4-Generate a Threat Analysis report. Expected Results: The report reflects all the passed pcaps correctly and accurately. Procedure: 1-In a single mode or ASA-CX navigate to the Dashboard. 2-Click on Genrate report. 3-When Generat report dialog box appears click on the Cancel button. Expected Results: The dailog box is closed and you return to the Dashboard page. Procedure: 1-In managed mode or PRSM navigate to the Dashboard. 2-Click on Genrate report. 3-When Generat report dialog box appears click on the Cancel button. Expected Results: The dailog box is closed and you return to the Dashboard page. Procedure: 1-Generate a Threat Analysis report a single mode device or ASA-CX. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 Policies detecting maximum threats page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. Procedure: 1-Generate a Threat Analysis report a managed mode or PRSM. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 Policies detecting maximum threats page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup.
18 US5805: Verify Cancel works properly in the 8. Generate report dialog box in single mode or ASACX
18 US5805: Verify Cancel works properly in the 9. Generate report dialog box in managed mode or PRSM
19 US5805: Verify that the generated Threat 0. Protection report has the top 25 policies detecting maximum threats page in single mode or ASA-CX.
19 US5805: Verify that the generated Threat 1. Protection report has the top 25 policies detecting maximum threats page in managed mode or PRSM.
19 US5805: Verify that the generated Threat 2. Protection report has the top 25 attackers page in managed mode or PRSM.
Procedure: 1-Generate a Threat Analysis report a single mode device or ASA-CX. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 attackers page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. Procedure: 1-Generate a Threat Analysis report a managed mode or PRSM. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 attackers page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. Procedure: 1-Generate a Threat Analysis report a single mode device or ASA-CX. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 targets page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. Procedure: 1-Generate a Threat Analysis report a managed mode or PRSM. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 targets page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. Procedure: 1-Generate a Threat Analysis report a single mode device or ASA-CX. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 threats page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. 3-Verify that threat score average column has the proper data such as threat score average, threats sent and received. follow the latest mockups for the latest updates.
19 US5805: Verify that the generated Threat 3. Protection report has the top 25 attackers page in single mode or ASA-CX.
19 US5805: Verify that the generated Threat 4. Protection report has the top 25 targets page in single mode or ASA-CX.
19 US5805: Verify that the generated Threat 5. Protection report has the top 25 targets page in managed mode or PRSM.
19 US5805: Verify that the generated Threat 6. Protection report has the top 25 threats page in single mode or ASA-CX.
19 US5805: Verify that the generated Threat 7. Protection report has the top 25 threats page in managed mode or PRSM.
Procedure: 1-Generate a Threat Analysis report a managed mode or PRSM. 2-View the generated Threat Analysis report. Expected Results: 1-Verify that generated report has the top 25 threats page. Refer to the mocukup for details. 2-Verify that all the details are there as per mockup. 3-Verify that threat score average column has the proper data such as threat score average, threats sent and received. follow the latest mockups for the latest updates.
19 US5805: Verify that generate report works properly Procedure: 8. on PRSM when no ASA-CX devices are added. 1-Install and configure a PRSM. 2-Before adding an devices click on the generate report button. Expected Results: 1-Verify that when pressing on generate report button the generate report dialog box appears. 19 US5704: Verify proper update to PDE.log file in 9. ASA-CX Procedure: In ASA-CX make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-updatedlibPD (to update first) restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine update that addes a dynamic library Expected Result: the following line should appear in pde.log @~@LineBrMrk: 2013-03-27 21:38:32, 842 INFO pde.ThreatProtection - PD::start updated version
20 US5704: Verify that libTD.so, libPD.so, and 0. libvelocity.so links and files are created in ASA-CX under /lib64 and /librariers folder after applying a TP engine update
Procedure: Make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-addedso (to update first) tp-20130322_engine-addedso restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine update that addes a dynamic library 2-Start a putty shell to ASA-CX and type ls -l /usr/lib64. 3-type ls -l /cisco/updater/librariers in the putty shell. 4-type ls -l /cisco/updater/staging-librariers/tp/ in the putty shell. Expected Result: 1-The following links will be listed in /usr/lib64 folder: libTD.so, libPD.so, libvelocity.so, and libadded.so without any extensions or numbers added to the link. 2-The following links will be listed in /cisco/updater/librariers/ folder: libTD.so, libPD.so, libvelocity.so, and libadded.so without any extensions or numbers added to the links. 3-The following files will be listed in /cisco/updater/staging-librariers/tp/ folder: libTD.so, libPD.so, libvelocity.so, and libadded.so without any extensions or numbers added to the files. 4-Verify update was succesffull in Device -> Updates. 5-Verify the proper events are generated in system events. 6-Verify threat protection keeps working properly after update completes.
20 US5704: Verify that libTD.so, libPD.so, and 1. libvelocity.so links and files are created in PRSM under /lib64 and /librariers folder after applying a TP engine update
Procedure: Make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-addedso (to update first) restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine update that addes a dynamic library 2-Start a putty shell to PRSM and type ls -l /usr/lib64. 3-type ls -l /cisco/updater/librariers in the putty shell. 4-type ls -l /cisco/updater/staging-librariers/tp/ in the putty shell. Expected Result: 1-The following links will be listed in /usr/lib64 folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the link. 2-The following links will be listed in /cisco/updater/librariers/ folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the links. 3-The following files will be listed in /cisco/updater/staging-librariers/tp/ folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the files. 4-Verify update was succesffull in Device -> Updates. 5-Verify the proper events are generated in system events. 6-Verify Threat Protection works properly fater update completes.
20 US5704: Verify that libTD.so, libPD.so, and 2. libvelocity.so links and files are deleted in ASA-CX under /lib64 and /librariers folder after applying a TP engine rollback
Procedure: This test case must be ran after the test case where serial number was tp-20130322_engine-addedso Make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-good (for rollback to updated version) restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine rollback that rollbacks to the previous version. 2-Start a putty shell to ASA-CX and type ls -l /usr/lib64. 3-type ls -l /cisco/updater/librariers in the putty shell. 4-type ls -l /cisco/updater/staging-librariers/tp/ in the putty shell. Expected Result: 1-The following linsk will be listed in /usr/lib64 folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the link. 2-The following links will be deleted from /cisco/updater/librariers/ folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the links. 3-The following files will be deleted and replaced with the previous versions in /cisco/updater/staginglibrariers/tp/ folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the files. 4-Verify rollback was succesffull in Device -> Updates. 5-Verify the proper events are generated in system events. 6-Verify Threat protection keeps on working after rollback completes.
20 US5704: Verify that libTD.so, libPD.so, and 3. libvelocity.so links and files are deleted in PRSM under /lib64 and /librariers folder after applying a TP engine rollback
Procedure: This test case must be ran after the test case where serial number was tp-20130322_engine-addedso Make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-good (for rollback to updated version) restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine rollback that rollbacks to the previous version. 2-Start a putty shell to PRSM and type ls -l /usr/lib64. 3-type ls -l /cisco/updater/librariers in the putty shell. 4-type ls -l /cisco/updater/staging-librariers/tp/ in the putty shell. Expected Result: 1-The following linsk will be listed in /usr/lib64 folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the link. 2-The following links will be listed in /cisco/updater/librariers/ folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the links. 3-The following files will be listed in /cisco/updater/staging-librariers/tp/ folder: libTD.so, libPD.so, and libvelocity.so without any extensions or numbers added to the files. 4-Verify update was succesffull in Device -> Updates. 5-Verify the proper events are generated in system events. 6-Verify Threat Protection works properly after rollback completes.
20 US5704: verify successful rollback when inspectors Procedure: 4. failt to start up in ASA-CX In ASA-CX Make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-addedso-failnotify restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine rollback that rollbacks to the previous version. 2-Start a putty shell to ASA-CX and type ls -l /usr/lib64. 3-type ls -l /cisco/updater/librariers in the putty shell. 4-type ls -l /cisco/updater/staging-librariers/tp/ in the putty shell. Expected Result: This package will create libadded.so, but then the inspectors will fail to start up causing a roll back. After a rollback completes successfully, you should not see libadded.so links in the following folders: /usr/lib64 /cisco/updater/librariers/ /cisco/updater/staging-librariers/tp/ 20 US5704: verify successful rollback when inspectors Procedure: 5. failt to start up in PRSM In PRSM Make sure services are running if not start them: "/etc/init.d/cisco_services start" vi /cisco/updater/updater_connector.conf allow_overwrite=False (so the values don't change to default values) server_hostname = updater-he-01 serial = tp-20130322_engine-addedso-failnotify restart the updater_connector process using: heimdall_svc recycle updater_connector 1-Apply a TP engine rollback that rollbacks to the previous version. 2-Start a putty shell to ASA-CX and type ls -l /usr/lib64. 3-type ls -l /cisco/updater/librariers in the putty shell. 4-type ls -l /cisco/updater/staging-librariers/tp/ in the putty shell. Expected Result: This package will create libadded.so, but then the inspectors will fail to start up causing a roll back. After a rollback completes successfully, you should not see libadded.so links in the following folders: /usr/lib64 /cisco/updater/librariers/ /cisco/updater/staging-librariers/tp/
20 Verify the functionality of good SAS and TP (AVC 6. signature and TP Signature) updates on a stand alone CX device.
Procedure: Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svcdown updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Navigate to Device>>Configuration>>ASA-CX Logging in the browser and set the logging level of all the components to trace. Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Validate that the new updates are downloaded and applied successfully, from the logs. (/var/log/cisco/updater_connector.log) Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows the version and timestamps correctly and the versions have changed. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update still fire.
20 Verify the functionality of good SAS 7. engine/signature updates and bad TP signature update that fails in the Prepare state on a stand alone ASA-CX device.
Procedure: Between each test case, it is advised to erase and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that TP signature update fails in the PREPARE state and enters the cool down period. Validate that a msg is displayed in the updater logs as "tp updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event, such as "Preparing update failed for tp/threats.." gets generated and can be seen in the event viewer. Validate that the new SAS engine/signature updates are completed and applied successfully from the logs (/var/log/cisco/updater_connector.log). Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows that version number for TD signature component remains the same as before the update. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update, still fire.
20 Verify the functionality of good SAS 8. engine/signature updates and bad TP engine update that fails in the Prepare state on a stand alone ASA-CX device.
Procedure: Between each test case, it is advised to erase and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that TP engine update fails in the PREPARE state and enters the cool down period. Validate that a msg is displayed in the updater logs as "tp updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event, such as "Preparing update failed for tp/engine.." gets generated and can be seen in the event viewer. Validate that the new SAS engine/signature updates are completed and applied successfully from the logs (/var/log/cisco/updater_connector.log). Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows that version number for TD engine component remains the same as before the update. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update, still fire.
20 Verify the functionality of good TP engine/signature Procedure: 9. updates and bad SAS signature update that fails in Between each test case, it is advised to erase the Prepare state on a stand alone ASA-CX device. and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that SAS (in this case, AVC signature) update fails in the PREPARE state and enters the cool down period. Validate that a msg is displayed in the updater logs as "sas updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event, such as "Preparing update failed for avc/dat.." gets generated and can be seen in the event viewer. Validate that the new tp engine/signature updates are completed and applied successfully from the logs (/var/log/cisco/updater_connector.log). Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows that version number for SAS (in this case, AVC signature) component remains the same as before the update. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update, still fire. Cisco Systems, Inc. Cisco Confidential Page 65 of 144
21 Verify the functionality of good TP engine/signature Procedure: 0. updates and bad SAS engine update that fails in Between each test case, it is advised to erase the Prepare state on a stand alone ASA-CX device. and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that SAS (in this case, SAS engine) update fails in the PREPARE state and enters the cool down period. Validate that a msg is displayed in the updater logs as "sas updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event, such as "Preparing update failed for sas engine.." gets generated and can be seen in the event viewer. Validate that the new tp engine/signature updates are completed and applied successfully from the logs (/var/log/cisco/updater_connector.log). Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows that version number for SAS (in this case, SAS engine) component remains the same as before the update. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update, still fire. Cisco Systems, Inc. Cisco Confidential Page 66 of 144
21 Verify the functionality of good TP engine/signature Procedure: 1. updates and bad SAS engine update that fails in the Switch state on a stand alone ASA-CX device. Between each test case, it is advised to erase and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above.
Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that SAS engine update fails in the Switch state and enters the cool down period. Validate that the following msg are displayed in the updater logs : "Failed while switching to new SAS version" and "sas updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event, such as "Switching to new update failed for avc/dat.." gets generated and can be seen in the event viewer. Verify that version number for SAS engine in the Updater UI (Device>>Updates>>Updates) will change between the updates. Validate that the new tp engine/signature updates are completed and applied successfully from the logs (/var/log/cisco/updater_connector.log). Verify that a corresponding system event gets generated and can be seen in the event viewer and the updater UI (Device>>Updates>>Updates) displays the new version number for tp Cisco Systems, Inc. Cisco Confidential engine/signature component. Page 67 of 144 Validate that SAS engine update rolls back successfully and the updater UI, reflects that the SAS engine component 's version number changes to the same as before the update. Verify that a corresponding system event gets
21 Verify the functionality of good TP engine/signature Procedure: 2. updates and bad SAS signature update that fails in the Switch/Commit state on a stand alone ASA-CX Between each test case, it is advised to erase device. and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above.
Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that SAS (in this case, AVC Signature) update fails in the Switch state and enters the cool down period. Validate that the following msg are displayed in the updater logs : "Some Inspectors failed to switch: .." and "tp updates have been disabled. Will resume in 43200 seconds". Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that version number for AVC signature in the Updater UI (Device>>Updates>>Updates) will change between the updates. Validate that the new tp engine/signature updates are completed and applied successfully from the logs (/var/log/cisco/updater_connector.log). Verify that a corresponding system event gets generated and can be seen in the event viewer and the updater UI (Device>>Updates>>Updates) displays the new version number for tp engine/signature component. that SAS (in this case AVC signature) Cisco Systems, Inc. Cisco Validate Confidential update rolls back successfully and the updater UI, Page 68 of 144 reflects that the tp engine and SAS (in this case, AVC signature) component 's version numbers change to the same as before the update. Verify that a corresponding system event gets generated in the event viewer indicating the
21 Verify the functionality of bad TP and bad engine 3. updates that fails in the Switch/Commit state on a stand alone ASA-CX device.
Procedure: Between each test case, it is advised to erase and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Verify that both tp and sas engine updates fails in the Switch state and enters the cool down period. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that version numbers for tp and sas engine in the Updater UI (Device>>Updates>>Updates) will change between the updates. Validate that both SAS and tp engines roll back successfully along with both tp and sas signatures and the updater UI, reflects that all the corresponding component version numbers change to the same as before the update. Verify that a corresponding system event gets generated in the event viewer indicating the rollback. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update, still fire.
21 Verify the functionality of good WBRS incremental Procedure: 4. updates and good TP signature/engine update on a Between each test case, it is advised to erase stand alone ASA-CX device. and install the rpms again, do a config reset and set the logging levels to trace. This will reset version numbers and updater state. Configure a threat profile object and set it to be the most aggressive. Create an access policy and attach the created threat profile to the access policy. Send some traffic thru the box and then some pcaps that fire threats. Open up a browser with ASA-CX ip and navigate to Device>>Updates and make a note of the preupgrade version numbers for TP and SAS engine/signatures. Update the system as follows: Shut down updater (using the CLI, "heimdall_svc down updater_connector") Change the configuration file (/cisco/updater/updater_connector.conf) by setting the variables allow_overwrite to False, server_hostname to the hostname of the updater server being used and the serial to the name of the updater package provisioned in the updater server. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box. Send the same pcaps as above. Expected Results: Verify that traffic passes thru the box . Ensure that threats can be detected and corresponding events are displayed in the threat protection tab in the event viewer. Validate that the new updates are downloaded and applied successfully, from the logs. (/var/log/cisco/updater_connector.log).Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Device>>Updates>>Updates) shows the version and timestamps correctly and the versions have changed. Verify that traffic passes thru the box successfully after the update. Validate that after the update, that the threats detected earlier, before the update still fire.
21 Verify that telemetry is disabled by default on an 5. unmanaged ASA-CX device.
Procedure: Load the latest software image on the device and open a browser with the ip address of the device. Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy on the device. Configure file filtering and web reputation profiles on the device. Send some traffic thru the box. Expected Results: Verify that a welcome screen listing the option for telemetry is displayed. Verify that on clicking the link beneath Telemetry, the user is redirected to a page displaying all the three options for telemetry (Standard/Full,partial,None). Verify that by default the none option is selected for telemetry. Verify that no telemetry data is being collected in the SIGN Up client logs (in the /var/log/cisco/signup.log file) and in the monitord log (/var/log/cisco/monitord.log)
21 Verify that all telemetry data (including merlin Procedure: 6. telemetry) gets collected when Standard/Full option Open a browser with the ip address of the is selected for telemetry in the Network device. Participation page on an unmanaged ASA-CX Configure a threat profile object and attach the device. created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy on the device. Configure file filtering and web reputation profiles on the device. Navigate to Administration>Network participation and click on the button named Partial and save the changes. Send some traffic thru the box. Expected Results: Verify that the following platform telemetry fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that the following merlin telemetry data (startTimeStamp, endTimeStamp,graph_count,graph_bytes,pattern_c ount for each of the http,stream and udp engines and SigID,ThreatID,ThreatLevel,AttackerIP,WebAVC,W ebCAT and WebREP from the Predictive Defense process) is collected and is accurate in the ASACX SIGN Up client logs (in the /var/log/cisco/signup.log file). Refer to the wikis http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data and http://wikicentral.cisco.com/display/PROJECT/Merli n+Telemetry for a detailed explanation of all the fields mentioned above and their expected results.
21 Verify that telemetry is disabled by default in 7. PRSM.
Procedure: Log into SMX. Discover an ASA-CX device. Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy in PRSM. Configure file filtering and web reputation profiles in PRSM. Send some traffic thru PRSM. Expected Results: Verify that a welcome screen listing the option for telemetry is displayed. Verify that on clicking the link beneath Telemetry, the user is redirected to a page displaying all the three options for telemetry (Standard/Full,partial,None). Verify that by default the none option is selected for telemetry. Verify that no telemetry data is being collected in the PRSM on in the managed ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file) and in the monitord log (/var/log/cisco/monitord.log)
21 Verify that all telemetry data (including merlin 8. telemetry ) gets collected when Standard/Full option is selected for telemetry in the Network Participation page in PRSM.
Procedure: Open a browser with the ip address of PRSM and ensure that an ASA-CX is discovered in PRSM. Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy on the device. Configure file filtering and web reputation profiles on the device. Navigate to Administration>Network participation and click on the button named Partial and save the changes. Send some traffic thru the box. Expected Results: Verify that the following platform telemetry fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that the following merlin telemetry data (startTimeStamp, endTimeStamp,graph_count,graph_bytes,pattern_c ount for each of the http,stream and udp engines and SigID,ThreatID,ThreatLevel,AttackerIP,WebAVC,W ebCAT and WebREP from the Predictive Defense process) is collected and is accurate in the PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Refer to the wikis http://wikicentral.cisco.com/display/PROJECT/Falco n+Telemetry+Data and http://wikicentral.cisco.com/display/PROJECT/Merli n+Telemetry for a detailed explanation of all the fields mentioned above and their expected results.
21 Verify that only platform telemetry data gets 9. collected when Partial option is selected for telemetry in the Network Participation page in PRSM.
Procedure: Open a browser with the ip address of PRSM and ensure that an ASA-CX is discovered in PRSM. Configure a threat profile object and attach the created threat profile to an access policy. Create a realm and add corresponding directory config to the realm. Configure an any/any authentication policy (with action:Get identity via active authentication) and associate it with the realm. Enable decryption and configure a decryption policy on the device. Configure file filtering and web reputation profiles on the device. Navigate to Administration>Network participation and click on the button named Partial and save the changes. Send some traffic thru the box. Expected Results: Verify that only following platform telemetry fields (startTimeStamp, endTimeStamp, platform_version,model,product,timezone,db_size,c pu_usage,disk_utilization,total_policies,access_poli cies,decryption_policies,auth_policies,policy_sets,fil e_filtering_profiles,web_reputation_profiles,threat_p rofiles,realms,devices,applications,and top_applications) are populated and are accurate in the PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that only platform telemetry data gets collected in the PRSM signup logs and no merlin telemetry data is present in the logs.
22 US5697: Verify that these strings do not exist in 0. ASA-CX: num_asacx_managed, num_k2_managed, num_asa_managed, num_ha_asa, num_sc_asa, num_transparent_asa, num_routed_asa
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install and configure an ASA-CX. 2-Verify that the following strings do not exist in /var/log/cisco/monitord.log file in an ASA-CX Box: num_asacx_managed, num_k2_managed, num_asa_managed, num_ha_asa, num_sc_asa, num_transparent_asa, num_routed_asa. Expected Results: 1-The above values do not exist in the /var/log/cisco/monitord.log file. Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Enable AD Agent in ASA-CX configuration. 2-View the contents of /var/log/cisco/monitord.log. Expected Results: Verify that the value of ad_agent_configured has changed to 1 from 0.
22 US5697: Verify ad_agent_configured is updated 1. properly when AD Agent is configured in ASA-CX
22 US5697: Verify num_ldap_realms reflects te 2. number of LDAP Realms configured in ASA-CX
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and enable LDAP realm in PRSM. 2-View the contents of /var/log/cisco/monitord.log and 3-Try adding more LDAP realms in PRSM up to 3. 4-Delete The LDAP Realms. Expected Results: 1-Verify that the value of num_ldap_realms has changed to 1 from 0. 2-Verify that num_ldap_realms increments with each ldap added. 3-Verify that the numbers decrease by 1 everytime an LDAP realm is removed.
22 US5697: Verify num_ad_realms reflects the 3. number of AD Realms configured in ASA-CX
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and enable an AD Realm in ASA-CX 2-Add an AD realm in ASA-CX and view the contents of /var/log/cisco/monitord.log. 3-Remove the AD Realm in ASA-CX and view the contents of /var/log/cisco/monitord.log Expected Results: 1-Verify the value of num_ad_realms is changed to 1 in /var/log/cisco/monitord.log when an AD Realm is added in ASA-CX. 2-Verify the value of num_ad_realms is changed to 0 in /var/log/cisco/monitord.log when an AD Realm is removed in ASA-CX. Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and enable few SSO Realms in ASACX 2-Every time an SSO Realm is added in ASA-CX view the contents of /var/log/cisco/monitord.log Expected Results: 1-Every time an SSO realm is added in ASA-CX the value of num_ad_realms increments by 1.
22 US5697: Verify num_sso_realms correctly reflects 4. the total number of SSO Realms configured in ASA-CX.
22 US5697: Verify is_managed is updated properly in 5. ASA-CX when not joined to PRSM.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install and configure an ASA-CX. 2-On the ASA-CX box check for is_managed value in /var/log/cisco/monitord.log file. Expected Results: 1-is_managed is set to 0 when not joined to PRSM. Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-On an ASA-CX check for the value of ui_config_version in /var/log/cisco/monitord.log 2-make some changes to the Database like creating a new policy. 3-check the value of ui_confg_version. Expected Results: 1-The value of ui_config_version is incremented by 1 in ASA-CX everytime a change is made to the database.
22 US5697: Verify ui_config_version on ASA-CX is 6. correct.
22 US5697: Verify core_dumps on a ASA-CX is 7. updated properly when a new core_dumps is created.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install an ASA-CX and navigate to /var/log/cisco/monitord.log. 2-check the value of core_dumps in monitord.log file. 3-Navigate to /var/data/cores and create a new file and wait for a minute. Expected Results: 1-Verify that the value of core_dumps will be incremented each time a new file is created in the /var/data/cores by 1 since the last collection time. 2-Verify that the value of core_dumps will go back to 0 after a core dump collection time. 3-Verify that the names of core_dumps is logged as well.
22 US5697: Verify core_dumps on a ASA-CX is 8. updated properly after the 24 hour period.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install an ASA-CX and navigate to /var/log/cisco/monitord.log. 2-check the value of core_dumps in monitord.log file. 3-Navigate to /var/data/cores and create and create several files and observe the log. 4- observe the log after 24 hours. Expected Results: 1-Verify that the value of core_dumps will be incremented each time a new file is created in the /var/data/cores by 1 in less than 2 minutes and the name of files will be in the log as well. 2-Verify that the total number of files created in the last 24 hours is reflected correctly and the name of files is in the log as well that have been added in the last 24 hours.
22 US5697: Verify ad_agent_configured is updated 9. properly when AD Agent is configured in PRSM
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Enable AD Agent in PRSM configuration. 2-View the contents of /var/log/cisco/monitord.log. Expected Results: Verify that the value of ad_agent_configured has changed to 1 from 0. Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and enable LDAP realm in ASA-CX 2-View the contents of /var/log/cisco//monitord.log and 3-Try adding more LDAP realms in ASA-CX Expected Results: 1-Verify that the value of num_ldap_realms has changed to 1 from 0. 2-Verify that num_ldap_realms increments with each ldap added.
23 US5697: Verify num_ldap_realms reflects te 0. number of LDAP Realms configured in PRSM.
23 US5697: Verify num_ad_realms reflects the 1. number of AD Realms configured in PRSM
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and enable few AD realms in PRSM 2-Add an AD realm in PRSM and view the contents of /var/log/cisco/monitord.log. 3-Remove the AD Realm in PRSM and view the contents of /var/log/cisco/monitord.log Expected Results: 1-Verify the value of num_ad_realms is changed to 1 in /var/log/cisco/monitord.log when an AD Realm is added in PRSM. 2-Verify the value of num_ad_realms is changed to 0 in /var/log/cisco/monitord.log when an AD Realm is removed in PRSM. Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and enable an SSO Realm in PRSM. 2-Every time an SSO realm is added in PRSM view the contents of /var/log/cisco/monitord.log Expected Results: 1-Every time an SSO realm is added in PRSM the value of num_ad_realms increments by 1.
23 US5697: Verify num_sso_realms correctly reflects 2. the total number of SSO Realms configured in PRSM.
23 US5697: Verify is_managed is updated properly in 3. ASA-CX when joined to PRSM.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install and configure an ASA-CX. 2-Join this ASA-CX box to PRSM device. 3-On the ASA-CX box check for is_managed value in /var/log/cisco/monitord.log file. 4-Delete the ASA-CX device from PRSM. Expected Results: 1-Verify that is_managed is equal to 1when joined to PRSM. 2-Verify that the number is reduced to 0 when ASACX is removed from PRSM.
23 US5697: Verify num_asacx_managed on a PRSM 4. is updated properly when an ASA-CX joins the PRSM.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Configure and install an ASA-CX. 2-Install and configure a PRSM box and search the contents of the file /var/log/cisco/monitord.log for num_asacx_managed. 3-Join the ASA-CX to PRSM and search /var/log/cisco/monitord.log on PRSM box 4-Unjoin the ASA-CX from PRSM and search /var/log/cisco/monitord.log Expected Results: 1-Verify that num_asacx_managed on PRSM box before adding the ASA-CX device is 0. 2-Verify that num_asacx_managed on PRSM box will be incremented to 1 once a device is added to PRSM. 3-Verify that num_asacx_managed on PRSM will increment each time a device is added. 4-Verify that num_asacx_managed on PRSM will decrement each time a device is removed.
23 US5697: Verify num_asa_managed on a PRSM is 5. updated properly with each ASA device added or removed.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install and configure a PRSM 2-Check the value of num_asa_managed in /var/log/cisco/monitord.log file. 3-Join an ASA device to the PRSM. 4-Join another device to the PRSM. 5-Remove teh joined ASA devices from PRSM. Expected Results: 1-Verify that the original value of num_asa_managed is 0 since there are no ASA devices being managed by PRSM. 2-Verify that the value of num_asa_managed will get incremented by 1 with each ASA device being added to PRSM. 3-Verify that the value of num_asa_managed will decrement by 1 each time an ASA device is removed from PRSM. 3-Verify it works for both Spyker and Saleen ASAs.
23 US5697: Verify num_ha_asa on a PRSM is Pre-requisite: 6. updated properly when the number of ASA devices 1-To allow telemetry to work or enabled you need on HA are added to PRSM or removed. to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install and configure a PRSM device. Before joining any devices to the PRSM check /var/log/cisco//monitord.log. 2-check for the value of num_ha_asa. 3-Set an ASA device to be HA and join it to PRSM. 4-Set another ASA device to be HA and join it to PRSM. 5-Start removing the ASA Devices. Expected Results: 1-Verify that the value of num_ha_asa is set to 0 when no ASA devices have joined the PRSM. 2-Verify that the value of num_ha_asa is incremented by 1 each time an ASA device is added to PRSM that is set to HA. 3-Verify that the value of num_ha_asa is decremented by 1 each time an ASA device is removed from PRSM that is set to HA.
23 US5697: Verify num_sc_asa on a PRSM is updated Pre-requisite: 7. properly each time single-context ASA device is 1-To allow telemetry to work or enabled you need added. to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install and configure a PRSM device. 2-check for the value of num_sc_asa in /var/log/cisco//monitord.log. 3-Add a Single-context ASA device to PRSM and check for the value of num_sc_asa in /var/log/cisco//monitord.log 4-Unamange the ASA device(s). Expected Results: 1-The originla value of num_sc_asa is equal to 0 when no single-context devices have been added to the PRSM. 2-Each time a single-context ASA device is joined to the PRSM the value of num_sc_asa is incremented by 1. 3-Verify that each time an ASA device is unamanged that variable is reduced by 1.
23 US5697: Verify num_transparent_asa on a PRSM Pre-requisite: 8. is updated properly when ASA device is added that 1-To allow telemetry to work or enabled you need is in transparent mode. to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install a PRSM 2-check the contents of /var/log/cisco/monitord.log 3-Check the value for num_transparent_asa 2-Add ASA devices that is in transparent mode(up to three). 3-Remove the ASA devices. Expected Results: 1-Verify that the initial value of num_transparent_asa is 0 when no ASA devices are added to PRSM that are in transparent mode. 2-Verify that the value of num_transparent_asa is incremented by 1 everytime an ASA device is added to PRSM that is in transparent mode. 3-Verify that the num_transparent_asa is decremented each time an ASA device is removed from PRSM that is in transparent mode
23 US5697: Verify num_routed_asa is updated 9. properly when the number of ASA devices that is added to PRSM that are in a routd mode.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install a PRSM and. 2-check the value of num_routed_asa in /var/log/cisco/monitord.log 2-Add ASA devices to PRSM that is in a routed mode(up to three). 3-Remove the ASA devices from PRSM that are in routed mode. Expected Results: 1-Verify that the default value of num_routed_asa in /var/log/cisco/monitord.log is 0 originally when no ASA devices are connected to PRSM that are in the routd mode. 2-Verify that the value of num_routed_asa in /var/log/cisco/monitord.log increments by 1 everytime an ASA device is added to PRSM that is in the routed mode. 3-Verify that the value of num_routed_asa in /var/log/cisco/monitord.log decrements by 1 everytime an ASA device is removed from PRSM that is in the routed mode.
24 US5697: Verify ui_config_version on PRSM is 0. correct.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-On a PRSM check for the value of ui_config in /var/log/cisco/monitord.log 2-Make some changes for example add a policy. 3-check the value of ui_confi again. Expected Results: 1-The value of ui_config is incremented everytime a change is made to the database in PRSM.
24 US5697: Verify core_dumps on a PRSM is updated Pre-requisite: 1. properly when a new core_dumps is created and 1-To allow telemetry to work or enabled you need after the passage of 24 hours. to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-Install an ASA-CX and navigate to /var/log/cisco/monitord.log. 2-check the value of core_dumps in monitord.log file. 3-Navigate to /var/data/cores and create and create several files and observe the log. 4- observe the log after 24 hours. Expected Results: 1-Verify that the value of core_dumps will be incremented each time a new file is created in the /var/data/cores by 1 in less than 2 minutes and the name of files will be in the log as well. 2-Verify that the total number of files created in the last 24 hours is reflected correctly and the name of files is in the log as well that have been added in the last 24 hours.
24 US5697: Verify is_managed does not exist on 2. PRSM.
Pre-requisite: 1-To allow telemetry to work or enabled you need to go to Administration then Network Participation select Standard (Full) and click on Save and commit changes. 2-You need to go to the file /cisco/heimdall/etc/ monitord.conf and add '-t' to program argument as such: Program_arguments = ['-t'] (this will enable telemetry to gather every minute instead of everyday.) 3-Save the file and run heimdall_svc recycle monitord 4-Set the Management Plane log level to Debug. 5-Run tail -F /cisco/heimdall/etc/monitord.log or simply search the contents of the file. Procedure: 1-On a PRSM box that have ASA or ASA-CX devices added check the /var/log/cisco/monitord.log file. 2-Join an ASA-CX box to PRSM device and check for is_managed value in /var/log/cisco/monitord.log file. 4-Delete the ASA-CX device from PRSM. Expected Results: 1-Verify that is_managed does not exist on PRSM box after step 1, 2, and 3. Procedure Steps: 1. If necessary, clear config on the ASACX, so that only default threat protection is present (global threat profile active for the device, set to the Default Threat Profile). 2. Use wireplay to play several PCAPs, some with a threat score greater than 70, and some with a threat score between 40 and 70, and some with a threat score less than 40. Expected results: 1-2. For PCAPS with a threat score greater than 70, traffic is denied, threats appear in the Context Aware Events tab, and in the Dashboard, Threat Protection section. For PCAPS with a threat score between 40 and 70, traffic is allowed, threats appear in the Context Aware Events tab, and in the Dashboard, Threat Protection section. For PCAPS with a threat score less than 40, traffic is allowed, traffic appears in the Context Aware Events tab but not in the Threat Protection Events tab, and threats don't appear in the Dashboard, Threat Protection section.
24 Verify threat protection with Global Profile, no 3. changes
24 Verify the functionality of threat protection. 4.
Procedure: Create a threat profile object, say Block Threat Profile with the slider bars set to 0. (all the way to the right). In the Advanced Threat Settings section, select a threat (for eg., Microsoft Internet Explorer HTML Form Value Handling Denial of Service Vulnerability) and select an action (eg., Alert) for it. Configure an access policy and attach the above threat profile to the access policy. Send a pcap such as 1052-0.pcap thru the box. Refer to the wiki http://wikicentral.cisco.com/display/PROJECT/Excal ibur+QA+Information for a detailed list of all the pcaps (HTTP and non HTTP) and their corresponding threats and/or port information. Send another pcap such as 15175-0.pcap, which generates the above mentioned threat (Microsoft Internet Explorer HTML Form Value Handling Denial of Service Vulnerability) thru the box. Expected Results: Verify that the traffic is denied and a corresponding Deny event gets generated in the Threat Protection tab of the event viewer with information such as threat score and threat name. Verify the Threat protection and Dashboard reports are appropriately populated. Verify that traffic is allowed and a corresponding Info event gets generated in the threat protection tab of the event viewer and the corresponding threat protection and Dashboard reports are accurately populated.
24 US7590: Verify that Threat list appears when going Procedure: 5. to Components and then Threats 1-Install and configure an ASA-CX. 2-Navigate to Components and then Threats. 3-Hover over the Threats. 4-scroll down as far as possible. 5-enter a criteria for search in the Filter textbox. 6-Repeat the same test for PRSM with and without an ASA-CX managed. Expected Results: 1-Verify that a list of threats will appear. 2-Verify that to the right of each threat a Reference and a desc/reference will appear for each threat as per taxonomy doc. Clicking on the links will send you to the proper websiet. 3-Once you hover over a threat Read More and Go to information site appears. Once you click on the links they will appear on a new browser/popup. 4-The scroll bar is infinite i.e. new threats appear as you scroll down to the last one. 5-The list of threats will appear with the filter criteria. 6-Results are the same for PRSM as with ASA-CX umanaged
24 US7595: Verify that after recycling the VPS doesn't Pre-requisite: 6. break any processes 1-Make sure the build has the new velocity library to support VPS. Procedure: 1-Run top command. Note the value of PID for VPS. Also run ps ax - grep [v]ps or do a pidof vps. 2-Start running a putty sessions and run a tail -F command for the following log files: /var/log/cisco/vps.log, /var/log/cisco/heimdall.log and also vim them or vi. 3-set the data-plane logging level to DEBUG. 4-in a putty session to ASA-CX type heimdall_svc recycle vps. 5-in another putty session run the lsmod command and make sure cpp_base should be there after recylce (very important). Look in the logs vps.log and heimdall.log and make sure vps went down and came up cleanly. Expected Results: 1-in the putty session the PID of VPS should change. This means the old process was killed a new process is created. 2-search for SIGKILL, SIGQUIT and VPS in heimdall file. There shouldn't be any sigkills or sigquits for VPS in the heimdall.log file. Also look for any error messages that might be related to this process. 3-In VPS.log file make sure it is running the loop every second and there are no related error messages. 4-Verify that VPS comes up properly and there are no errors or core files created due to recycle. Also, all components e.g. work properly after recycle. 24 Verify performance when threat protection feature 7. is disabled (Monocle and Sherlock) Procedure: Load the Peregrine/Raptor (REL) image under test and run the Breakingpoint performance test using EMIX traffic (EMIX600 test) on a Spyker A or B. Repeat on a Saleen. Expected Results: Verify that the EMIX performance number with threat protection disabled is within 10% of the corresponding Torino or Barbary image. Per Ranjan, this number is 3.7G for Spkyer A and 6.7G for Spyker B. Saleen numbers can be found at http://wikicentral.cisco.com/display/TORINO/QA+Pe rformance+Tracking+Page+-+Saleen.
24 Verify the functionality of good reputation updates 8. on a stand alone CX device.
Procedure: Configure a threat profile object and attach the created threat profile to an access policy. Ensure that a file containing a black list of ip 's is present at the location /var/data/updater2/drop. Send some traffic thru the box, such that the originating/source ip is from the list of blacklisted ip's. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") and update the system. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box again. Expected Results: Verify that the traffic gets blocked and corresponding deny events can be seen in the event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Validate that the new update is downloaded and applied properly. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates) shows the version and timestamps correctly. Validate that after the update, traffic that was blocked earlier still gets blocked and corresponding deny events can be seen in the event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Ensure that the user can send some more traffic thru the box such that the originating/source ip is from the newly added ip's in the blacklist and gets blocked.
24 Verify whether reputation update will continue to 9. apply after the ASA-CX device reboots/reloads in middle of update process.
Procedure: Repeat test steps 1-5 in test case 1. Reload/Restart the device. Once the device comes up and becomes operational, send some traffic thru the box. Expected Results: Verify that the traffic gets blocked and corresponding deny events can be seen in the event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Validate that the new update is downloaded and applied properly after the device comes up and becomes operational. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates) shows the version and timestamps correctly. Validate that after the update, traffic that was blocked earlier still gets blocked and corresponding deny events can be seen in the event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Ensure that the user can send some more traffic thru the box such that the originating/source ip is from the newly added ip's in the blacklist and gets blocked.
25 Verify the functionality of good reputation updates 0. on a managed ASA-CX device.
Procedure: Log into SMX, and discover a ASA-CX device in SMX/PRSM. Configure a threat profile object and attach the created threat profile to an access policy. Send some traffic thru the box, such that the originating/source ip is from the list of blacklisted ip's. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") and update the system. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the managed ASACX again. Expected Results: Verify that the traffic gets blocked and corresponding deny events can be seen in PRSM event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Validate that the new update is downloaded and applied properly. Verify that a corresponding system event gets generated and can be seen in PRSM event viewer. Verify that the updater UI (Configurations>>Updates) shows the version and timestamps correctly. Validate that after the update, traffic that was blocked earlier still gets blocked and corresponding deny events can be seen in the event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Ensure that the user can send some more traffic thru the box such that the originating/source ip is from the newly added ip's in the blacklist and gets blocked.
25 Verify whether reputation update will continue to 1. apply after PRSM reboots/reloads in middle of update process.
Procedure: Repeat test steps 1-6 in test case 4. Reload/Restart the PRSM. Once PRSM/SMX comes up and becomes operational, send some traffic thru the managed ASA-CX. Expected Results: Verify that the traffic gets blocked and corresponding deny events can be seen in the event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Validate that the new update is downloaded and applied properly after PRSM comes up and the managed ASA-CX becomes operational. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates) shows the version and timestamps correctly. Validate that after the update, traffic that was blocked earlier still gets blocked and corresponding deny events can be seen in PRSM event viewer. Verify that all the other traffic, (not originating from the black listed ip) gets allowed. Ensure that the user can send some more traffic thru the box such that the originating/source ip is from the newly added ip's in the blacklist and gets blocked.
25 Verify that sas telemetry data gets collected when 2. telemetry is enabled and Standard(recommended) option is selected on an unmanaged ASA-CX device.
Procedure: Open a browser with the ip address of the device. Navigate to Administration>Network participation, click on the option Yes to enable Cisco network participation. Select the participation level as Standard(recommended), click on save and commit the changes. Send some traffic thru the box. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qafbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Expected Results: Verify that a log level message indicating that the SAS endpoint is registered with the SIGN Up client is seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that sas telemetry data is collected and is accurate in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that this phone home log provides the info on who made a connection and whether the telemetry package received can be authenticated and decoded successful. Verify that this directory contains the actual telemetry packet that was sent from the ASA-CX device and verify that each packet has the appropriate and accurate SAS telemetry data, just as seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file).
25 Verify that sas telemetry data gets collected when 3. telemetry is enabled and Limited option is selected for telemetry on an unmanaged ASA-CX device.
Procedure: Repeat test steps 1-3 in test case 1. Select the participation level as Limited, click on save and commit the changes. Send some traffic thru the box. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qafbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Expected Results: Verify that a log level message indicating that the SAS endpoint is registered with the SIGN Up client is seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that sas telemetry data is collected and is accurate in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that this phone home log provides the info on who made a connection and whether the telemetry package received can be authenticated and decoded successful. Verify that this directory contains the actual telemetry packet that was sent from the ASA-CX device and verify that each packet has the appropriate and accurate SAS telemetry data, just as seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file).
25 Verify that sas telemetry data does not get collected Procedure: 4. when telemetry is disabled on an unmanaged ASA- Open a browser with the ip address of the device. CX device. Configure a threat profile object and attach the created threat profile to an access policy. Navigate to Administration>Network participation, click on the option No to disable Cisco network participation/telemetry. Click on save and commit the changes. Send some traffic thru the box. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qafbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Expected Results: Verify that no log level message indicating that the SAS endpoint is registered with the SIGN Up client is seen in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that no sas telemetry data is collected in the ASA-CX SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that this directory does not contain any telemetry packet sent from the ASA-CX device.
25 Verify that sas telemetry data gets collected when 5. telemetry is enabled and Standard(recommended) option is selected in an ASA-CX device managed by PRSM.
Procedure: Log into SMX, and discover a ASA-CX device in SMX/PRSM. Configure a threat profile object and attach the created threat profile to an access policy in PRSM. Navigate to Administration>Network participation, click on the option Yes to enable Cisco network participation. Select the participation level as Standard(recommended), click on save and commit the changes. Send some traffic thru the managed ASACX. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qa-fbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Expected Results: Verify that a log level message indicating that the SAS endpoint is registered with the SIGN Up client is seen in PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that sas telemetry data is collected and is accurate in PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that this phone home log provides the info on who made a connection and whether the telemetry package received can be authenticated and decoded successful. Verify that this directory contains the actual telemetry packet that was sent from the managed ASA-CX device and verify that each packet has the appropriate and accurate SAS telemetry data, just as seen in the PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file).
25 Verify that sas telemetry data gets collected when 6. telemetry is enabled and Limited option is selected for telemetry in an ASA-CX device managed by PRSM.
Procedure: Repeat test steps 1-3 in test case 4. Select the participation level as Limited, click on save and commit the changes. Send some traffic thru the managed ASACX. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qa-fbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Expected Results: Verify that a log level message indicating that the SAS endpoint is registered with the SIGN Up client is seen in PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that sas telemetry data is collected and is accurate in PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that this phone home log provides the info on who made a connection and whether the telemetry package received can be authenticated and decoded successful. Verify that this directory contains the actual telemetry packet that was sent from the managed ASA-CX device and verify that each packet has the appropriate and accurate SAS telemetry data, just as seen in the PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file).
25 Verify that sas telemetry data does not get collected Procedure: 7. when telemetry is disabled in an ASA-CX device Log into SMX, and discover a ASA-CX managed by PRSM. device in SMX/PRSM. Configure a threat profile object and attach the created threat profile to an access policy in PRSM. Navigate to Administration>Network participation, click on the option No to disable Cisco network participation/telemetry. Click on save and commit the changes. Send some traffic thru the managed ASACX. Log into the backend FBNP server (i.e., SSH to bastion1.sfo.ironport.com and from there ssh to qa-fbnp-app002.vega.cloud.ironport.com) and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check the logs in /data/ironport/phonehomelogs/ directory. Expected Results: Verify that no log level message indicating that the SAS endpoint is registered with the SIGN Up client is seen in the managed ASA-CX/ PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that no sas telemetry data is collected in the managed ASA-CX/PRSM SIGN Up client logs (in the /var/log/cisco/signup.log file). Verify that this directory does not contain any telemetry packet sent from the managed ASACX device.
25 Verify the functionality of good velocity updates on 8. a stand alone CX device.
Procedure: Configure a threat profile object and attach the created threat profile to an access policy. Send some traffic thru the box. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") and update the system. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the box again. Expected Results: Verify that threats get detected and corresponding events are seen in the event viewer. Validate that the new update is downloaded and applied properly. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates), specifically tp engine shows the version and timestamps correctly. Ensure that VPS process gets recycled by the updater from vps log (located at /var/log/cisco/vps.log) and the version in the test update package is seen in the log after vps is recycled. Validate that after the update, threats still get detected and corresponding events can be seen in the event viewer.
25 Verify whether velocity update will continue to apply Procedure: 9. after the ASA-CX device reboots/reloads in middle Repeat test steps 1-4 in test case 1. of update process. Reload/Restart the device. Once the device comes up and becomes operational, send some traffic thru the box. Expected Results: Verify that threats get detected and corresponding events are seen in the event viewer. Validate that the new update is downloaded and applied properly after the device comes up and becomes operational. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates), specifically tp engine shows the version and timestamps correctly. Ensure that VPS process gets recycled by the updater from vps log (located at /var/log/cisco/vps.log) and the version in the test update package is seen in the log after vps is recycled. Validate that after the update, threats still get detected and corresponding events can be seen in the event viewer.
26 Verify the functionality of velocity update and make Procedure: 0. sure that it fails to apply and rolls back successfully Repeat test steps 1-4 in test case 1. on a stand-alone CX device. Send some traffic thru the box again. Expected Results: Verify that threats get detected and corresponding events are seen in the event viewer. Validate that the new update fails to apply and gets rolled back to the old version successfully. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates), specifically tp engine shows the version and timestamps correctly. Ensure that VPS process gets recycled by the updater from vps log (located at /var/log/cisco/vps.log) and the version in the test update package is seen in the log after vps is recycled. Validate that after the failed update and rollback, threats still get detected and corresponding events can be seen in the event viewer.
26 Verify the functionality of good velocity updates on 1. a managed ASA-CX device.
Procedure: Log into SMX, and discover a ASA-CX device in SMX/PRSM. Configure a threat profile object and attach the created threat profile to an access policy. Send some traffic thru the box. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") and update the system. Start updater again (using the CLI "heimdall_svc up updater_connector"). Send some traffic thru the managed ASACX again. Expected Results: Verify that threats get detected and corresponding events can be seen in PRSM event viewer. Validate that the new update is downloaded and applied properly. Verify that a corresponding system event gets generated and can be seen in PRSM event viewer. Verify that the updater UI (Configurations>>Updates), specifically tp engine shows the version and timestamps correctly. Ensure that VPS process gets recycled by the updater from vps log (located at /var/log/cisco/vps.log)and the version in the test update package is seen in the log after vps is recycled. Validate that after the update, threats still get detected and corresponding events can be seen in PRSM event viewer.
26 Verify whether velocity update will continue to apply Procedure: 2. after PRSM reboots/reloads in middle of update Repeat test steps 1-5 in test case 4. process. Reload/Restart the PRSM. Once PRSM/SMX comes up and becomes operational, send some traffic thru the managed ASA-CX. Expected Results: Verify that threats get detected and corresponding events can be seen in PRSM event viewer. Validate that the new update is downloaded and applied properly after PRSM comes up and the managed ASA-CX becomes operational. Verify that a corresponding system event gets generated and can be seen in PRSM event viewer. Verify that the updater UI (Configurations>>Updates), specifically tp engine shows the version and timestamps correctly. Ensure that VPS process gets recycled by the updater from vps log (located at /var/log/cisco/vps.log)and the version in the test update package is seen in the log after vps is recycled. Validate that after the update, threats still get detected and corresponding events can be seen in PRSM event viewer. 26 Verify the functionality of velocity update and make Procedure: 3. sure that it fails to apply and rolls back successfully Repeat test steps 1-5 in test case 4. on a managed ASA-CX device. Send some traffic thru the managed ASACX device again. Expected Results: Verify that threats get detected and corresponding events can be seen in PRSM event viewer. Validate that the new update fails to apply on PRSM and gets rolled back to the old version successfully. Verify that a corresponding system event gets generated and can be seen in PRSM event viewer. Verify that the updater UI (Configurations>>Updates), specifically tp engine shows the version and timestamps correctly. Ensure that VPS process gets recycled by the updater from vps log (located at /var/log/cisco/vps.log)and the version in the test update package is seen in the log after vps is recycled. Validate that after the failed update, threats still get detected and corresponding events can be seen in PRSM event viewer.
26 Verify File Filtering of downloads, improved MIME4. type handling
Procedure: 1. Create a new File Filtering Profile which blocks downloads of particular file type/subtype (e.g. audio/wav). Enter a few characters in the downloads field & select from the list. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. 2. Attempt to Download a file of that type from a web site or use a file sharing website like FileDropper to download. (Note that if you use dropbox, you need to have encryption enabled & a decryption policy in place.) Attempt to download other types of the same type, but of a different subtype (e.g. audio/mp3). 3. Edit the object and add several more file type/subtype combinations, and make sure that all of the types (text, video, audio, etc.) are tested. Try to test type/subtypes which are more common. 4. Create a new object that blocks downloads of all subtypes within a type (e.g.audio/*) & modify the access policy to use that profile. Try to download a few subtypes within that type, as well as other type/subtypes (which should be allowed, if not blocked). Test all types in turn by editing the profile. Expected results: 1. Verify filtering of the list & selection & that freeform typing is not allowed (i.e. you can only pick from the list). 2. Verify EUN is received & downloads don't occur. Verify downloads are blocked for one type/subtype, but that other subtypes of the same type are allowed. 3. Verify all type/subtype combinations in the download field are blocked, but other type/subtype combination are allowed. 4. Verify all files within a type are blocked, but that other types (which aren't in the field) are allowed. Verify that all file types can be blocked from downloading.
26 Verify File Filtering of uploads, improved MIME-type Procedure: 5. handling 1. Create a new File Filtering Profile which blocks uploads of particular file type/subtype (e.g. audio/wav). Enter a few characters in the uploads field & select from the list. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. 2. Attempt to Upload a file of that type to a web site or use a file sharing website like FileDropper to upload. (Note that if you use dropbox, you need to have encryption enabled & a decryption policy in place.) Attempt to upload other types of the same type, but of a different subtype (e.g. audio/mp3). 3. Edit the object and add several more file type/subtype combinations, and make sure that all of the types (text, video, audio, etc.) are tested. Try to test type/subtypes which are more common. 4. Create a new object that blocks uploads of all subtypes within a type (e.g.audio/*) & modify the access policy to use that profile. Try to download a few subtypes within that type, as well as other type/subtypes (which should be allowed if not blocked). Test all types in turn by editing the profile. Expected results: 1. Verify filtering of the list & selection & that freeform typing is not allowed (i.e. you can only pick from the list). 2. Verify EUN is received (is this always true for uploads?) and uploads don't occur. Verify uploads are blocked for one type/subtype, but that other subtypes of the same type are allowed. 3. Verify all type/subtype combinations in the upload field are blocked, but other type/subtype combination are allowed. 4. Verify all files within a type are blocked, but that other types (which aren't in the field) are allowed. Verify that all file types can be blocked from uploading. 26 Verify File Filtering of mix of uploads and 6. downloads, improved MIME-type handling Procedure: 1. Create a File Filtering profile that contains a mixture of several download types/subtypes (includings type/*) and several upload types (including type/*). Create an any/any access policy (with allow action) and select the file Filtering Profile you created. 2. Edit the File Filtering profile a few times and mix up the types/subtypes that you are testing. Expected Results: 1 & 2. All combinations of uploads and downloads block the files that they should and don't block files that they shouldn't. The profile can be edited and those edits take effect.
26 Verify changes in the MIME file take effect & that 7. errors for entries which "go away" are handled.
1. Create a File Filtering profile that contains a mixture of several download types/subtypes and several upload types. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. 2. Make note of which file types/subtypes are available in the dropdown lists for both upload and download. Stop services. Edit the MIME file (location is something like /cisco/updater/updates/sas/appdata/magic) and carefully remove a few entries from the file. Restart services 3. Create a file filtering profile and attempt to add to both the upload and download fields (which you removed). Don't edit the input from Step 1 yet. 4. Attempt to download and upload files which match the types/subtypes you already defined. Remove those types/subtypes which are no longer valid, add some that are valid and attempt download & upload again. Expected Results: 1, 2 & 3. Verify that the file types/subtypes that you removed are no longer visible, but the rest of the types/subtypes appear properly. 4. Appropriate error messages are issued when outdated types/subtypes are used. Outdated types/subtypes can be removed and valid type/subtypes can be added and function correctly.
26 Verify the functionality of a good update of a new Note: An avc update will not be applied if the 8. MIME file (part of AVC application) on a standalone current (same) version is already installed on the CX device system. When testing updates, you need to ensure that the version of avc dat that you are running is earlier than the one on the update server. After you have applied the update once, you will need to go back to the earlier version. You can do this by uninstalling the current csas rpm and reinstalling it. Procedure: 1. Configure a File Filtering object and note the contents of the file type/subtype list that appears in the Upload and Download fields. Select a couple of entries from the list for each field. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. Attempt to upload/download those file type/subtypes. 2. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") 3. Update the system. (Change the variable, allow_overwrite=False; set the variables server_hostname, serial and pid to appropriate values in the /cisco/updater/updater_connector.conf file) 4. Start updater again (using the CLI "heimdall_svc up updater_connector"). 5. If necessary, stop services, install the current csas rpm and restart services. See note above. 6. Perform step 1 again. Expected Results: 1. Verify that the expected uploads and downloads are blocked. 2, 3 & 4. Verify that the new update is downloaded and applied properly without errors. Check the details in /var/data/cisco/updater_connector.log. Verify that a corresponding system event gets generated and can be seen in the event viewer and in /var/log/cisco/system_events_updater_connector.lo g Verify that the updater UI (Configurations>>Updates) shows the version and timestamps correctly. 5. & 6 Verify that the changes (removals or additions) in the type/subtype list are visible and that File Filtering performs as expected.
26 Verify the functionality of a bad update of a new 9. MIME file (part of AVC application) on a standalone CX device and make sure that it fails to apply and roll back is successful
Note: An avc update will not be applied if the current (same) version is already installed on the system. When testing updates, you need to ensure that the version of avc dat that you are running is earlier than the one on the update server. After you have applied the update once, you will need to go back to the earlier version. You can do this by uninstalling the current csas rpm and reinstalling it. Procedure: 1. Configure a File Filtering object and note the contents of the file type/subtype list that appears in the Upload and Download fields. Select a couple of entries from the list for each field. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. Attempt to upload/download those file type/subtypes. 2. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") 3. Update the system. (Change the variable, allow_overwrite=False; set the variables server_hostname, serial and pid to appropriate values in the /cisco/updater/updater_connector.conf file) 4. Start updater again (using the CLI "heimdall_svc up updater_connector"). 5. If necessary, stop services, install the current csas rpm and restart services. See note above. 6. Repeat step 1. Expected Results: 1. Verify that the expected uploads and downloads are blocked. 2, 3 and 4. Verify that the new update fails to apply and gets rolled back to the old version successfully. Verify that a corresponding system event gets generated and can be seen in the event viewer. Verify that the updater UI (Configurations>>Updates), specifically avc dat shows the version and timestamps correctly. 5. & 6. Verify that the type/subtype lists for upload and download didn't change and that the expected uploads and downloads are blocked
27 Verify the functionality of a good update of a new 0. MIME file (part of AVC application) on a managed CX device
Note: An avc update will not be applied if the current (same) version is already installed on the system. When testing updates, you need to ensure that the version of avc dat that you are running is earlier than the one on the update server. After you have applied the update once, you will need to go back to the earlier version. You can do this by uninstalling the current csas rpm and reinstalling it. Procedure: 1. Log into SMX, and discover a ASA-CX device in SMX/PRSM. 2. Configure a File Filtering object and note the contents of the file type/subtype list that appears in the Upload and Download fields. Select a couple of entries from the list for each field. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. Attempt to upload/download those file type/subtypes. 3. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") 4. Update the system. (Change the variable, allow_overwrite=False; set the variables server_hostname, serial and pid to appropriate values in the /cisco/updater/updater_connector.conf file) 5. Start updater again (using the CLI "heimdall_svc up updater_connector"). 6. If necessary, stop services, install the current csas rpm and restart services. See note above. 7. Repeat Step 2 Expected Results: 1. Verify that CX is successfully managed in PRSM. 2. Verify that the expected uploads and downloads are blocked. 3, 4, & 5. Verify that a corresponding system event gets generated and can be seen in PRSM event viewer. Verify that the updater UI (Configurations>>Updates), specifically avc dat shows the version and timestamps correctly. 6 & 7. Validate that after the update, uploads and downloads are blocked as expected and corresponding events can be seen in PRSM event viewer.
27 Test bad update of a new MIME file (part of AVC 1. application) on a managed CX device
Note: An avc update will not be applied if the current (same) version is already installed on the system. When testing updates, you need to ensure that the version of avc dat that you are running is earlier than the one on the update server. After you have applied the update once, you will need to go back to the earlier version. You can do this by uninstalling the current csas rpm and reinstalling it. Procedure: 1. Log into SMX, and discover a ASA-CX device in SMX/PRSM. 2. Configure a File Filtering object and note the contents of the file type/subtype list that appears in the Upload and Download fields. Select a couple of entries from the list for each field. Create an any/any access policy (with allow action) and select the file Filtering Profile you created. Attempt to upload/download those file type/subtypes. 3. Shutdown updater (using the CLI, "heimdall_svc down updater_connector") 4. Update the system. (Change the variable, allow_overwrite=False; set the variables server_hostname, serial and pid to appropriate values in the /cisco/updater/updater_connector.conf file) 5. Start updater again (using the CLI "heimdall_svc up updater_connector"). 6. If necessary, stop services, install the current csas rpm and restart services. See note above. 7. Repeat step 1. Expected Results: 1. Verify that CX is successfully managed in PRSM. 2. Verify that the expected uploads and downloads are blocked. 3, 4 and 5. Verify that the new update fails to apply and gets rolled back to the old version successfully. Verify that a corresponding system event gets generated and can be seen in the PRSM event viewer. Verify that the updater UI (Configurations>>Updates), specifically avc dat shows the version and timestamps correctly. 6 & 7. Verify that the type/subtype lists for upload and download didn't change and that the expected uploads and downloads are blocked and corresponding events can be seen in PRSM event viewer.
27 Verify access policy when set to Follow Global 2. (Device-Level) threat profile, standalone CX
Procedure: 1. Create Deny all, Alert all and Ignore all threat profiles. 2. Configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 3. Select the Deny all Profile. 4. Play a PCAP with wireplay. 5. Create an any/any access policy. Leave the default profile for the policy at Follow Global (Device-Level) Profile 6. Play a PCAP with wireplay. 7. Change Global (Device-Level) Profile to Alert only. Play a PCAP with Wireplay. 8. Change Global (Device-Level) Profile to Ignore only. Play a PCAP with Wireplay. Expected Results: 1. Verify Profiles can be created. 2. Verify Intrusion Protection defaulted to Off but can be turned on. 3. Verify Profile choices are Default, plus the 3 you created. 4. Verify threat is denied. 5. Verify Profile default is Follow Global (DeviceLevel) Profile. Verify Profile choices are Default, Follow Global, plus the 3 you created. 6. Verify threat is denied. 7. Verify threat is alerted. 8. Verify threat is ignored. Procedure: 1. Create Deny all threat profile. 2. Configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 3. Select the Deny all Profile (as the Global (Device-Level) Profile) 4. Play a PCAP with wireplay 5. Create an any/any access policy. For threat profile, select none. 6. Play a PCAP with wireplay. Expected Results: 1. Verify Profile can be created. 2,3 & 4. Verify threat is detected and evented according to the Default Threat Profile (and the particular PCAP that is played). 5 & 6. Verify threat is ignored & the Access policy name shows in the event for the traffic in the Context Aware Events tab.
27 Verify access policy when set to None profile, 3. standalone CX
27 Verify setting global (Device-Level) threat profile 4. policy to None (as the default & when setting is changed to none), standalone CX
Procedure: 1. Configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 2. Leave the global (Device-Level) setting at its default 3. Play a PCAP with wireplay 4. Select the Default Threat profile (for global (Device-Level))) 5. Play a PCAP with wireplay 6. Select none (or blank) as the global (DeviceLevel) threat profile 7. Play a PCAP with wireplay Expected Results: 1, 2, and 3. Verify the default setting is none (or blank). Verify the threat is ignored & the Implicit Allow policy name shows in the event for the traffic in the Context Aware Events tab. 4 & 5. Verify threat is detected and evented according to the Default Threat Profile (and the particular PCAP that is played). 6 & 7. Verify the threat is ignored & the Implicit Allow policy name shows in the event for the traffic in the Context Aware Events tab.
27 Verify disabling of Threat Protection, standalone CX Procedure: 5. 1. Create Deny all threat profile. 2. Configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 3. Select the Deny all Profile. 4. Play a PCAP with wireplay 5. Configure Intrustion Protection to Off. 6. Play a PCAP with wireplay. Expected Results: 1, 2, 3 & 4. Verify threat is denied. 5 & 6. Verify threat is ignored.
27 Verify access policy when set to Follow Global 6. (Device-Level) threat profile, managed CX, nonshared policies
Procedure: 1. Discover two CX's with PRSM 2. Create Deny all, Alert all and Ignore all threat profiles. 3. For both CXes, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On. 4. For CX #1, select the Deny all Profile (as the global (Device-Level) profile). For CX #2, select the Alert all profile (as the global (Device-Level) profile) 5. For both CXes, play a PCAP with wireplay. 6. Create an any/any access policy for CX #1. Leave the default profile which follows Global Profile. Create an any/any access policy for CX #2. Leave the default which follows Global Profile. 7. On both CXes, play a PCAP with wireplay. 8. Change Global (Device-Level) Profile for CX #1 to Ignore only. Change Global (Device-Level) Profile for CX #2 to Deny only. 9. On both CXes, play a PCAP with wireplay. Expected Results: 1. Verify CX's can be discovered. 2. Verify Profiles can be created. 3. Verify Intrusion Protection defaulted to Off but can be turned on for both CX #1 and CX #2. 4 & 5. Verify threat is denied for CX #1 and is alerted for CX #2. Verify Events indicate the Implicit Allow policies for both CXes. 6 & 7. On CX #1, verify threat is denied. Verify Event indicates the Allow Any/Any policy . On CX #2, verify threat is alerted. Verify Event indicates the Allow Any/Any policy. 8 & 9. On CX #1, verify threat is ignored. Verify Event indicates the Allow Any/Any policy . On CX #2, verify threat is denied. Verify Event indicates the Allow Any/Any policy
27 Verify access policy set to Follow Global (Device7. Level) threat profile, managed CX, shared policies
Procedure: 1. Discover two CXes with PRSM 2. Create Deny all, Alert all and Ignore all threat profiles. 3. For both CXes, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On. 4. For CX #1, select the Deny all Profile (as the global (Device-Level) profile). For CX #2, select the Alert Only as the global (device-level) profile. 5. For both CXes, play a PCAP with wireplay. 6. Create an any/any access policy for CX #1. Leave the default profile for the policy to Follow Global Profile. Share CX #1's access policy with CX #2. 7. For both CXes, play a PCAP with wireplay. 8. Change Global (Device-Level) Profile for CX #1 to Ignore only. Change Global (Device-Level) Profile for CX #2 to Deny only. 9. For both CXes, play a PCAP with wireplay Expected Results: 1. Verify CX's can be discovered. 2. Verify Profiles can be created. 3, 4 ,5, 6 & 7. Verify threat is denied for CX #1 and is alerted for CX #2. Verify Events indicate the Implicit Allow policies for both CXes. 6 & 7. On CX #1, verify threat is denied. Verify Event indicates the Allow Any/Any policy . On CX #2, verify threat is alerted. Verify Event indicates the Allow Any/Any policy. 8 & 9. On CX #1, verify threat is ignored. Verify Event indicates the Allow Any/Any policy . On CX #2, verify threat is denied. Verify Event indicates the Allow Any/Any policy.
27 Verify access policy when set to None profile, 8. managed CX, non-shared policies
Procedure: 1. Discover two CX's with PRSM 2. Create Deny all threat profile. 3. On both CXes, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 4. On both CXes, select the Deny all Profile (as the Global (Default-Level) Profile) 5. On both CXes, Play a PCAP with wireplay. 6. On both CXes, create an any/any access policy. For Threat Profile, select none. 7. On both CXes, Play a PCAP with wireplay. Expected Results: 1. Verify CX's can be discovered. 2. Verify Profile can be created. 3,4 & 5. On both CXes, verify threat is denied and the Implicit Allow policy name shows in the event for the traffic in the Threat Protection Events tab. 6& 7. On both CXes, verify threat is ignored & the Access policy name shows in the event for the traffic in the Context Aware Events tab. Procedure: 1. Discover two CX's with PRSM 2. Create Deny all threat profile. 3. On both CX's, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 4. On both CX's, select the Deny all Profile (as the Global (Default-Level) Profile) 5. On both CX's, Play a PCAP with wireplay. 6. On CX #1, create an any/any access policy with a Threat Profile set to None. Share this access policy with CX #2. 7. On both CX's, Play a PCAP with wireplay. Expected Results: 1. Verify CX's can be discovered. 2. Verify Profile can be created. 3,4 & 5. On both CXes, verify threat is denied and the Implicit Allow policy name shows in the event for the traffic in the Threat Protection Events tab. 6& 7. On both CXes, verify threat is ignored & the Access policy name (from CX #1) shows in the event for the traffic in the Context Aware Events tab.
27 Verify access policy set to None profile, managed 9. CX, shared policies
28 Verify setting global threat profile policy to None (as Procedure: 0. the default & when setting is changed to none), 1. Discover two CX's with PRSM managed CX, non-shared policies. 2. On both CXes, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 3. On both CXes, select the None Profile (or just leave it blank) 4. On both CXes, Play a PCAP with wireplay 5. On both CXes ,select the Default Threat profile (for global (Device-Level)) 6. On both CXes, play a PCAP with wireplay 7. On both CXes, select none (or blank) as the global (Device-Level) threat profile 8. On both CXes, Play a PCAP with wireplay Expected Results: 1. Verify CXes can be discovered. 2, 3, and 4. On both CXes, verify the threat is ignored & the Implicit Allow policy name shows in the event for the traffic in the Context Aware Events tab. 5 & 6. On both CXes, verify threat is detected and evented according to the Default Threat Profile (and the particular PCAP that is played). 7 & 8. On both CXes, verify the threat is ignored & the Implicit Allow policy name shows in the event for the traffic in the Context Aware Events tab. 28 Verify setting global threat profile policy to None (as Procedure: 1. the default & when setting is changed to none), 1. Discover two CXes with PRSM managed CX, shared policies. 2. On CX #1, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On, and select the None Profile (or just leave it blank) 3. Share the Instrusion Protection settings of CX #1 with CX #2. 4. On both CXes, Play a PCAP with wireplay 5. On CX #1 ,select the Default Threat profile (for global (Device-Level)) 6. On both CXes, Play a PCAP with wireplay 7. On CX #1, select none (or blank) as the global (Default-Level) threat profile 8. On both CXes, Play a PCAP with wireplay Expected Results: 1. Verify CXes can be discovered. 2, 3, and 4. On both CXes, verify the threat is ignored on both CXes & the Implicit Allow policy name shows in the events for the traffic in the Context Aware Events tab. 5 & 6. On both CXes, verify threat is detected and evented according to the Default Threat Profile (and the particular PCAP that is played). 7 & 8. On both CXes, verify the threat is ignored & the Implicit Allow policy name shows in the event for the traffic in the Context Aware Events tab.
28 Verify disabling of Threat Protection, managed CX, Procedure: 2. non-shared policies 1. Discover two CXes with PRSM 2. Create Deny all threat profile. 3. On both CXes, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 4. On both CXes, select the Deny all Profile (as the Device-Level profile) 5. On both CXes, Play a PCAP with wireplay 6. On both CXes, configure Intrustion Protection to Off. 7. On both CXes, Play a PCAP with wireplay. Expected Results: 1. Verify both CXes can be discovered 2, 3, 4 & 5. On both CXes, verify threat is denied. 6 & 7. On both CXes, verify threat is ignored. 28 Verify disabling of Threat Protection, managed CX, Procedure: 3. shared policies 1. Discover two CXes with PRSM 2. Create Deny all threat profile. 3. On CX #1, configure Intrusion Protection (currently at Configurations->Devices, Basic Device properties, Threat Protection) to On 4. On CX #1, select the Deny all Profile (as the Device-Level profile) 5. Share the Instrusion Protection settings of CX #1 with CX #2. 6. On both CXes, Play a PCAP with wireplay 7. On CX #1, configure Intrustion Protection to Off. 8. On both CXes, Play a PCAP with wireplay. Expected Results: 1. Verify both CXes can be discovered 2, 3, 4 , 5 & 6. On both CXes, verify threat is denied. 7 & 8. On both CXes, verify threat is ignored. 28 US7591: Verify the removal of current telemetry 4. option in the welcome screen. Procedure: 1-Install a new ASA-CX build with the latest telemetry features. 2-Login to ASA-CX. 3-Repat test with PRSM. Expected Result: 1-Verify that the new telemetry options pop-up as soon as the admin logs in. 2-Verify that the old telemetry options in the welcome screen has been removed. 3-Verify that when you navigate to Administration, Network participation you see the new telemetry screen. 3-Verify that this works properly with PRSM as well.
28 US7591: Verify the addition of new pop-up prior to 5. welcome screen that asks customers to configure their telemetry setting
Procedure: 1-Install and configure a new ASA-CX box. 2-Login to ASA-CX. 3-Verify that all the buttons are functional and not broken: Yes, No button, Standard, Limited, View terms of agreement, and save. 4-Verify that the save and commit work properly by logging out and back in and making sure it saved the changes. Expected Result: 1-Verify that immediately after login the pop-up screen appears that asks customers to configure their telemetry settings. 2-All button and features are working properly: Yes, No, Standard, Limited, View terms of agreement, and Save. 3-Verify that settings are saved after logging out and back in. 4-When clicking on View terms of agreement the terms of agreements appear. 5-When selecting No for enable telemetry and saving and committing, it will stay saved and telemetry data will not be sent. 6-when selecting Yes for enable telemetry and save changes and committing, it will send telemetry data as requested.
28 US7591: Verify the addition of a new default Procedure: 6. telemetry level(unconfigured) and backend changes 1-Install and configure a new ASA-CX device and to support it. leave the telemetry level to the default level and it needs to be in that state without any changes. 2-In order to verify telemetry data is sent properly login to the backend FBNP server (i.e. SSH to bastion1.sfo.ironport.com and from there ssh to qafbnp-app002.vega.cloud.ironport.com and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check teh logs in /data/ironport/phonehomelogs/ directory) Expected Result: 1-Verify the addition of the new telemetry levels when unconfigured and verify the back end can support it. 2-Verify that the data is sent correclty to the backend FBNP server.
28 US7591: Verify the Telemetry screen should popProcedure: 7. up every time the UI is opened until a user changes 1-Install and configure a new ASA-CX and navigate their level from unconfigured. to telemetry screen but don't configure the telemetry screen. Save but don't commit changes. 2-login to the ASA-CX. 3-Repeat for PRSM. Expected Result: 1-Verify that telemetry pops-up every time the user logs in without committing changes. 2-Result is the same for PRSM. 28 US7591: Verify that the new UI works properly and Procedure: 8. pops up properly. 1-Install and configure a new ASA-CX and login. 2-Test with PRSM as well. Expected Result: 1-Verify that it pops-up properly and has all components: Standard, Limited, Save, view agreement, and Yes-No button 2-Verify that PRSM works as well. 28 US7591: Verify that the new pop-up stops 9. appearing once telemetry changes have been committed. Procedure: 1-Install and configure a new ASA-CX and configure the telemetry page. 2-Repeat test case for PRSM. 3-Reboot the ASA-CX verify that changes have been saved and the pop-up doesn't appear again. 4-Reboot the PRSM and verify that changes have been saved and pop-up doesn't appear again. Expected Result: 1-Verify that the pop-up doesn't appear again after configuration is complete once. 2-Verify that reboot doesn't erase the saved configuration on ASA-CX and PRSM.
29 US7591: Verify that the telemetry change is applied Procedure: 0. properly. 1-Install and configure an ASA-CX and login. 2-Select Standard and Save and Commit changes. Test in PRSM as well. 3-Navigate to Administration, and then Network Participation and select Limited and save and Commit Changes. Test in PRSM as well. 4-Navigate to Administrator, and then Network Participation and then turn OFF the network participation. 5-In order to verify telemetry data is sent properly login to the backend FBNP server (i.e. SSH to bastion1.sfo.ironport.com and from there ssh to qafbnp-app002.vega.cloud.ironport.com and check the FBNP or phone home logs in :/data/ironportvar/phonehomeserver/phonehome.lo g Check teh logs in /data/ironport/phonehomelogs/ directory) Expected Result: 1-Verify that on the first login the telemetry pop-up screen appears. 2-Verify that standard telemetry is applied and configured properly. 3-Verify that the Limited telemetry is applied and configured properly. 4-Verify that the user can opt out of providing telemetry information. 5-Verify that the pop-up does not appear after initial configuration, save and commit. 6-Verify that the data is sent correclty to the backend FBNP server. 29 US7591: Verify that the new telemetry pop-up 1. behaves properly for an upgrade. Procedure: 1-Install and configure an old version of ASA-CX that doesn't have the new pop-up feature and configure the telemetry page as not enabling telemetry. 2-perform an upgrade. 3-Repeat test case for PRSM. Expected Result: 1-Telemetry pop-up should not appear. 2-Result is the same for PRSM.
29 US7591: Verify that the new telemetry pop-up 2. behaves properly for an upgrade.
Procedure: 1-Install and configure an old version of ASA-CX that doesn't have the new pop-up feature and configure the telemetry page to enable telemetry. Perform an upgrade. Repeat with PRSM. 2-Install and configure an old version of ASA-CX that doesn't have the new pop-up feature and configure the telemetry page to opt-out of telemetry. Perform an upgrade. Repeat with PRSM. 3-Install and configure an old version of ASA-CX that doesn't have the new pop-up feature and leave telemetry unconfigured. Perform an upgrade. Repeat with PRSM. Expected Result: 1-Verify that the telemetry pop-up doesn't appear for test case 1 and 2. 2-Verify that the telemetry pop-up does appear for test case 3.
29 US7591: Verify that the telemetry buttons are 3. grayed out and disabled when No is selected for telemetry.
Procedure: 1-Install and configure an ASA-CX and login to the main page. 2-When the telemetry page appears select No for telemetry. 3-Hover over the telemetry options Standard and Limited. 4-Repeat the test case for PRSM Expected Result: 1-Verify that when No is selected for telemetry the hovering feature for telemetry buttons, Limited, and disabled, are disabled and grayed out. 2-Verify that this is the correct behavior for PRSM as well.
29 US7591: Verify that selected button remain 1-Install and configure a new ASA-CX and login to 4. selected after disabling the No button for telemetry. the ASA-CX. 2-pop-up telemetry should appear. 3-Select Limited and then select No for telemetry. 4-select Yes again for telemetry. 5-Select Standard and then select No for telemetry. 6-Select Yes again for telemetry. Expected Result: 1-Verify that the latest configuration appears after selecting YES
29 US7591: Verify that selected telemetry changes are Procedure: 5. saved properly and appear in the Network 1-Install and configure an ASA-CX. Login and participation page. configure the telemetry settings to accept telemetry and select Standard and Save and commit. Repeat with PRSM. 2-Install and configure an ASA-CX. Login and configure the telemetry settings to accept telemetry and select Limited. Save and commit. Repeat with PRSM. 3-Install and configure an ASA-CX. Login and configure the telemetry settings to opt out of telemetry by selecting No. Save and commit. Repeat with PRSM. Expected Result: 1-Navigate to Administration and then Network participation. Verify that all the changes have been saved properly and appear in the Network participation page. 29 US7591: Verify that Welcome screen appears for 6. new users after configuring telemetry options. Procedure: 1-Install and configure a new ASA-CX. 2-Login for the first time and configure the telemetry, save changes and commit. 3-Create a new admin user. 4-Login as the new admin user. 5-Repeat the same test case with a PRSM. Expected Result: 1-Verify that when logging it as the new user the Welcome screen appears and the telemetry screen doesn't appear since it has already been configured. 2-The result is the same for PRSM.
29 Verify the functionality of the default evaluation 7. license for threat protection feature on an unmanaged ASA-CX device.
Procedure: Perform a fresh installation of the latest software image on an unmanaged ASA-CX. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Verify that a fresh installation of the latest software image on ASA-CX comes with a default evaluation license for threat protection feature. Verify that after the software upgrade the evaluation license for threat protection becomes available for the user. Verify that the user would be able to enable threat protection by navigating to Configurations>>Policies/Settings>>Threat Protection. Verify that the user would be able to create a new threat profile object and associate it with an access policy. Verify that all the threat related traffic passing thru the box, during this period will be detected and is visible in events (in the Threat Protection tab of the event viewer) and in the corresponding Threat Protection reports. Verify that the the blacklist toggles in the UI are enabled and can be changed. Verify that the all the updates related to the threat protection feature (blacklist/engines/sigs) will be downloaded and applied as they become available. Verify that all the non-threat related traffic can still pass thru the device as expected and the user will still be able to see corresponding events and reports. Verify that all the non-threat related updates (sas/avc/wbrs/telemetry) will be downloaded and applied if they are available. Verify that the global/device-level threat profile is editable.
29 Verify the functionality of license expiration for Procedure: 8. threat protection feature on an unmanaged ASA-CX Shutdown cisco services and change the system device. clock (date) such that the evaluation license for threat protection expires. Restart cisco services. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Verify that the user will not be able to edit any access policies that are explicitly associated with threat profiles. Verify that the user will not be able to create any new threat profile objects or edit any existing threat profile objects. Verify that the user will not be able to add any new access policies with attached threat profiles. Verify that all the threat related traffic passing thru the box, during this period will not be detected and visible in either events (in the Threat Protection tab of the event viewer) or in the Threat Protection reports. Verify that the user will still be able to see threat related events and corresponding threat protection reports for the time period before the license expired. Verify that the Threat Protection and the blacklist toggles on the UI are disabled, and cannot be reenabled Verify that all the updates related to the threat protection feature (blacklist/engines/sigs) will be not be downloaded and applied. Verify that all the non-threat related traffic can still pass thru the device as expected and the user will still be able to see corresponding events and reports. Verify that all the non-threat related updates (sas/avc/wbrs/telemetry) will be downloaded and applied if they are available. Verify that the global/device-level threat profile is still editable.
29 Verify the functionality of license renewal for threat 9. protection feature on an unmanaged ASA-CX device.
Procedure: Renew the license for threat protection. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Verify that the user will now be able to edit any access policies that are explicitly associated with threat profiles. Verify that the user will be able to create new threat profile objects Validate that the user will be to edit any existing threat profile objects. Verify that the user will now be able to add any new access policies with attached threat profiles. Verify that the user will be able to see threat related events and corresponding threat protection reports again. Verify that the the Threat Protection and the blacklist toggles on the UI are now re-enabled. Verify that the all the updates related to the threat protection feature (blacklist/engines/sigs) will be now be downloaded and applied. Verify that all the non-threat related traffic can pass thru the device as expected and the user will still be able to see corresponding events and reports. Verify that all the non-threat related updates (sas/avc/wbrs/telemetry) will be downloaded and applied if they are available. Verify that the global/device-level threat profile is editable.
30 Verify the functionality of license revocation and 0. removal for threat protection feature on an unmanaged ASA-CX device.
Procedure: Revoke and remove the license for threat protection. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Verify that the user will not be able to edit any access policies that are explicitly associated with threat profiles. Verify that the user will not be able to create any new threat profile objects or edit any existing threat profile objects. Verify that the user will not be able to add any new access policies with attached threat profiles. Verify that all the threat related traffic passing thru the box, during this period will not be detected and visible in either events (in the Threat Protection tab of the event viewer) or in the Threat Protection reports. Verify that the user will still be able to see threat related events and corresponding threat protection reports for the time period before the license removal. Verify that the the Threat Protection and the blacklist toggles on the UI are disabled, and cannot be re-enabled Verify that the all the updates related to the threat protection feature (blacklist/engines/sigs) will be not be downloaded and applied. Verify that all the non-threat related traffic can still pass thru the device as expected and the user will still be able to see corresponding events and reports. Verify that all the non-threat related updates (sas/avc/wbrs/telemetry) will be downloaded and applied if they are available. Verify that the global/device-level threat profile is still editable.
30 Verify the functionality of addition of a license for Procedure: 1. threat protection feature on an unmanaged ASA-CX Add a license for threat protection. device. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Verify that the user will now be able to edit any existing access policies that are explicitly associated with threat profiles (probably created before the license removal). Verify that the user will be able to create new threat profile objects. Validate that the user will be to edit any existing threat profile objects. Verify that the user will now be able to add any new access policies with attached threat profiles. Verify that the user will be able to see threat related events and corresponding threat protection reports again. Verify that the the Threat Protection and the blacklist toggles on the UI are now re-enabled. Verify that the all the updates related to the threat protection feature (blacklist/engines/sigs) will be now be downloaded and applied. Verify that all the non-threat related traffic can pass thru the device as expected and the user will still be able to see corresponding events and reports. Verify that all the non-threat related updates (sas/avc/wbrs/telemetry) will be downloaded and applied if they are available. Verify that the global/device-level threat profile is editable. 30 Verify the functionality of the default evaluation 2. license for threat protection feature on a managed ASA-CX device in PRSM/SMX. Procedure: Log into PRSM/SMX and import/discover an ASACX. Perform a fresh installation of the latest software image on PRSM and ASA-CX. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Repeat test steps 1-10 as in test case 1. Procedure: Log into PRSM/SMX and import/discover an ASACX. Shutdown cisco services and change the system clock (date) such that the evaluation license for threat protection expires. Restart cisco services. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Repeat test steps 1-10 as in test case 2.
30 Verify the functionality of license expiration for 3. threat protection feature on a managed ASA-CX device in PRSM/SMX.
30 Verify the functionality of license renewal for threat Procedure: 4. protection feature on a managed ASA-CX device in Log into PRSM/SMX and import/discover an ASAPRSM/SMX. CX. Renew the license for threat protection. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Repeat test steps 1-10 as in test case 3. 30 Verify the functionality of license revocation and Procedure: 5. removal for threat protection feature on a managed Log into PRSM/SMX and import/discover an ASAASA-CX device in PRSM/SMX. CX. Upgrade from a previous software release such as Torino/Barbary. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Repeat test steps 1-10 as in test case 4. 30 Verify the functionality of addition of a license for 6. threat protection feature on a managed ASA-CX device in PRSM/SMX. Procedure: Log into PRSM/SMX and import/discover an ASACX. Add a license for threat protection. Pass some threat related traffic thru the ASA-CX. Pass some non-threat related traffic thru the ASACX. Expected Results: Repeat test steps 1-10 as in test case 5.
30 Verify Barbary/K2 to Peregrine upgrade, Intrusion 7. Protection, telemetry features and onbox management
Procedure: 1. Load the current Barbary/K2 image. 2. Configure and exercise a broad set of features. - Enable root login by generating a root patch on CX. - Change the logging levels to DEBUG. - Configure access policies ( One with URL Object, One with Network Object and one with Application/Service). - Enable authentication (create a realm,add a directory) and configure an identity policy. - Enable decryption (Generate a cert and import the cert into clients) and configure a decryption policy. 3. Upgrade from Barbary/K2 to Peregrine using the upgrade GUI. 4. Use the broad set of features again. - Enable telemetry and choose a participation level. - Change the logging levels to DEBUG. - Ensure that the above configured access policies, identity policy and decryption policies are retained. - Enable Intrusion Protection. Create a new threat profile object and associate it with an access policy. - Send some blacklisted traffic. - Enable updater. 5. Revert. 6. Exercise the broad set of features again. - Ensure that the above configured access policies, identity policy and decryption policies are retained.
Expected Result: 1 & 2. Verify the features work on the Barbary/K2 release. Send some traffic and verify the access policies, identity and decryption policies work as expected. 3. Verify upgrade is successful. Verify that a pop-up for enabling and configuring telemetry appears. Ensure that all telemetry data (including platform and merlin telemetry data) is being collected in signup logs and sent to FBNP server. 4. Verify the same set of features works on the Peregrine Release. Send some traffic and verify the access policies, identity and decryption policies work as expected. Send some traffic containing threats and verify that the threats get detected. Verify that the blacklisted traffic gets denied. Ensure that tp (signature and engine) updates get downloaded. Send some traffic containing threats again after the tp update and ensure that threats get Cisco Systems, Inc. Cisco Confidential detected. Page 136 of 144 5. Verify revert is successful. Ensure that pop-up screen for telemetry does not appear and no consequently no telemetry data gets collected in the signup logs. 6. Verify the features work on the Barbary/K2
30 Verify Torino to Peregrine upgrade, Intrusion 8. Prevention,telemetry features and onbox management.
Procedure: 1. Load the current Torino image. 2. Configure and exercise a broad set of features. - Enable root login by generating a root patch on CX. - Change the logging levels to DEBUG. - Configure access policies ( One with URL Object, One with Network Object and one with Application/Service). - Enable authentication (create a realm,add a directory) and configure an identity policy. - Enable decryption (Generate a cert and import the cert into clients) and configure a decryption policy. 3. Upgrade from Torino to Peregrine using the upgrade GUI. 4. Use the broad set of features again. - Enable telemetry and choose a participation level. - Change the logging levels to DEBUG. - Ensure that the above configured access policies, identity policy and decryption policies are retained. - Enable Intrusion Protection. Create a new threat profile object and associate it with an access policy. - Send some blacklisted traffic. - Enable updater. 5. Revert. 6. Exercise the broad set of features again. - Ensure that the above configured access policies, identity policy and decryption policies are retained.
Expected Result: 1 & 2. Verify the features work on the Torino release. Send some traffic and verify the access policies, identity and decryption policies work as expected. 3. Verify upgrade is successful. Verify that a pop-up for enabling and configuring telemetry appears. Ensure that all telemetry data (including platform and merlin telemetry data) is being collected in signup logs and sent to FBNP server. 4. Verify the same set of features works on the Peregrine Release. Send some traffic and verify the access policies, identity and decryption policies work as expected. Send some traffic containing threats and verify that the threats get detected. Verify that the blacklisted traffic gets denied. Ensure that tp (signature and engine) updates get downloaded. Send some traffic containing threats again Cisco Systems, Inc. Cisco Confidential after Page 137 of 144 the tp update and ensure that threats get detected. 5. Verify revert is successful. Ensure that pop-up screen for telemetry does not appear and no consequently no telemetry data gets collected in the signup logs.
30 Verify Peregrine to Peregrine upgrade, Intrusion 9. Prevention,telemetry features and onbox management
Procedure: 1. Load an image from the betazoid/main branch from the Peregrine release 2. Configure and exercise a broad set of features. - Enable telemetry and choose a participation level. - Change the logging levels to DEBUG. - Configure access policies ( One with URL Object, One with Network Object and one with Application/Service). - Enable authentication (create a realm,add a directory) and configure an identity policy. - Enable decryption (Generate a cert and import the cert into clients) and configure a decryption policy. - Enable Intrusion Protection. Create a new threat profile object and associate it with an access policy. - Send some blacklisted traffic. - Enable updater. 3. Upgrade to the latest image from Peregrine using the upgrade GUI. 4. Use the broad set of features again. - Ensure that the above configured access policies(with and without threat profiles), identity policy and decryption policies are retained. 5. Revert 6. Exercise the broad set of features again. - Ensure that the above configured access policies(with and without threat profiles), identity policy and decryption policies are retained. Expected Result: 1 & 2. Verify the features work on the Peregrine release Send some traffic and verify the access policies, identity and decryption policies work as expected. Verify that a pop-up for enabling and configuring telemetry appears. Ensure that all telemetry data (including platform and merlin telemetry data) is being collected in signup logs and sent to FBNP server. Send some traffic containing threats and verify that the threats get detected. Verify that the blacklisted traffic gets denied. Ensure that tp (signature and engine) updates get downloaded. Send some traffic containing threats again after the tp update and ensure that threats get detected. 3. Verify upgrade is successful and verify the same set of features still work with the latest image from the Peregrine Release. Send some traffic and verify the access policies, identity and decryption policies work as expected. Cisco Systems, Inc. Cisco Confidential Page 138 of 144Send some traffic containing threats and verify that the threats get detected. Verify that the blacklisted traffic gets denied. 4. Verify revert is successful and verify the same set of features still work. Send some traffic and verify the access
Hawkeye Pcap Efficacy # Entity Title
contains 108 test cases. Description
1. Verify 1019-0.pcap is Malicious Command-andControl Network Traffic 2. Verify 1021-0.pcap is Malicious Command-andControl Network Traffic 3. Verify 1052-0.pcap is Adobe Acrobat and Reader PRC Remote Code Execution Vulnerability 4. Verify 1138-0.pcap is Microsoft Internet Explorer Vector Markup Language Processing Arbitrary Code Execution Vulnerability 5. Verify 1256-0.pcap is Flame Trojan Toolkit 6. Verify 1258-2.pcap is Microsoft Internet Explorer Property ID Processing Memory Corruption Vulnerability 7. Verify 1263-0.pcap is Microsoft Windows Security Update for Digital Certificates Spoofing Vulnerability 8. Verify 1263-1.pcap is Microsoft Windows Security Update for Digital Certificates Spoofing Vulnerability 9. Verify 1341-0.pcap is Joomla! TinyMCE TinyBrowser Plug-in Arbitrary File Upload Vulnerability 10. Verify 1358-0.pcap is Adobe Shockwave Player Lnam Chunk String Processing dirapi.dll Arbitrary Code Execution Vulnerability 11. Verify 1373-0.pcap is Heap Spraying Buffer Overflow Attacks 12. Verify 1389-0.pcap is HP Database Archiving Software Unspecified Arbitrary Code Execution Vulnerability 13. Verify 1394-0.pcap is Cisco Linksys WVC200 Wireless-G PTZ Device ActiveX Control SetSource() Buffer Overflow Vulnerability 14. Verify 1421-0.pcap is Oracle Java Unspecified Code Execution Vulnerability 15. Verify 1446-0.pcap is BaoFeng Storm mps.dll ActiveX Control Arbitrary Code Execution Vulnerability 16. Verify 1450-0.pcap is IBM Tivoli Directory Server ibmslapd.exe Arbitrary Code Execution Vulnerability 17. Verify 1466-0.pcap is Microsoft Internet Explorer img Tag Processing Arbitrary Code Execution Vulnerability 18. Verify 1545-0.pcap is Adobe Acrobat Reader Unspecified Memory Corruption Vulnerability
19. Verify 1555-0.pcap is Mozilla Firefox, Thunderbird and SeaMonkey SVG Image Processing Arbitrary Code Execution Vulnerability 20. Verify 1563-0.pcap is IBM Lotus Notes URL Handling Remote Arbitrary Code Execution Vulnerability 21. Verify 1565-0.pcap is Novell ZENworks Asset Management Web Console Information Disclosure Vulnerability 22. Verify 1568-0.pcap is Novell ZENworks Configuration Management LaunchHelp.dll ActiveX Control Arbitrary Code Execution Vulnerability 23. Verify 1569-0.pcap is HP StorageWorks P4000 Virtual SAN Appliance Arbitrary Code Execution Vulnerability 24. Verify 1575-0.pcap is Novell iPrint Client ActiveX Control nipplib.dll Buffer Overflow Vulnerability 25. Verify 11203-0.pcap is IRC Channel Join 26. Verify 15001-0.pcap is Remote Control Software Potential Security Risk 27. Verify 15113-0.pcap is Microsoft Internet Explorer HTML Form Value Handling Denial of Service Vulnerability 28. Verify 15175-1.pcap is Microsoft Internet Explorer HTML Form Value Handling Denial of Service Vulnerability 29. Verify 15193-0.pcap is Worm: W32.Waledac 30. Verify 15193-1.pcap is Worm: W32.Waledac 31. Verify 15313-0.pcap is Microsoft SQL Server sp_replwritetovarbin() Buffer Overflow Vulnerability 32. Verify 15634-0.pcap is Cisco Application Control Engine Module and Appliance Processing SSH Packet Denial of Service Vulnerability 33. Verify 15773-0.pcap is Adobe Flash Player Invalid Object Reference Buffer Overflow Vulnerability 34. Verify 16217-0.pcap is Autodesk Design Review LiveUpdate16.DLL ActiveX Control Arbitrary Program Execution Vulnerability 35. Verify 16217-1.pcap is Autodesk Design Review LiveUpdate16.DLL ActiveX Control Arbitrary Program Execution Vulnerability 36. Verify 16217-2.pcap is Autodesk Design Review LiveUpdate16.DLL ActiveX Control Arbitrary Program Execution Vulnerability 37. Verify 16293-0.pcap is Worm: W32/Conficker.worm 38. Verify 16293-1.pcap is Worm: W32/Conficker.worm
39. Verify 1651-0.pcap is HP StorageWorks File Migration Agent HsmCfgSvc.exe Remote Arbitrary Code Execution Vulnerability 40. Verify 1654-0.pcap is Multiple Cisco Ironport Appliances Sophos Threat Engine Vulnerabilities 41. Verify 1787-0.pcap is Binary Planting Vulnerability 42. Verify 1975-0 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 43. Verify 1975-1 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 44. Verify 1975-2 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 45. Verify 1975-3 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 46. Verify 1975-4 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 47. Verify 1975-5 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 48. Verify 1975-6 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 49. Verify 1975-7 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 50. Verify 1975-8 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 51. Verify 1975-9 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 52. Verify 1975-10 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 53. Verify 1975-11 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 54. Verify 1975-12 is Self-Signed SSL Certificates Used in Spear-Phishing Attacks 55. Verify 1646-0 is Oracle Java SE Critical Patch Update October 2012 56. Verify 16473-1 is Microsoft Internet Explorer Uninitialized Memory Access Code Execution Vulnerability 57. Verify 16933-0 is Microsoft Office PowerPoint Data Out of Bounds Memory Corruption Vulnerability 58. Verify 16956-0 is Microsoft Office PowerPoint Data Out of Bounds Memory Corruption Vulnerability 59. Verify 1791-0 is Heap Spraying Buffer Overflow Attacks 60. Verify 1872-0 is IrfanView JPEG2000 Plugin Remote Stack Based Buffer Overflow Vulnerability
61. Verify 18921-0 is Apple Safari and Safari for Windows XML External Entity Information Disclosure Vulnerability 62. Verify 19219-0 is Microsoft Windows DirectShow QuickTime Media Processing Arbitrary Code Execution Vulnerability 63. Verify 19279-0 is Cisco Wireless LAN Controller Unauthorized Configuration Change Vulnerability 64. Verify 19819-1 is Multiple Adobe Products SWF File or PDF File Remote Arbitrary Code Execution Vulnerability 65. Verify 1985-0 is Heap Spraying Buffer Overflow Attacks 66. Verify 1985-1 is Heap Spraying Buffer Overflow Attacks 67. Verify 1985-2 is Heap Spraying Buffer Overflow Attacks 68. Verify 1080-0.pcap is IBM Informix Dynamic Server Long Username Buffer Overflow Vulnerability 69. Verify 1421-0.pcap is Oracle Java Unspecified Code Execution Vulnerability 70. Verify 15175-0.pcap is Microsoft Internet Explorer HTML Form Value Handling Denial of Service Vulnerability 71. Verify 1563-0.pcap is IBM Lotus Notes URL Handling Remote Arbitrary Code Execution Vulnerability 72. Verify 1654-0.pcap is Multiple Cisco Ironport Appliances Sophos Threat Engine Vulnerabilities 73. Verify 17785-0.pcap is Nuclear Rat Remote Access Utility 74. Verify 1787-0.pcap is Binary Planting Vulnerability 75. Verify 1792-0.pcap is Heap Spraying Buffer Overflow Attacks 76. Verify 1813-0.pcap is Oracle Java Applet Rhino Script Engine Arbitrary Code Execution Vulnerability 77. Verify 1837-0.pcap is Heap Spraying Buffer Overflow Attacks 78. Verify 1838-0.pcap is Wibu Systems WibuKey Runtime for Windows ActiveX Control DisplayMessageDialog() Buffer Overflow Vulnerability 79. Verify 18420-1.pcap is Microsoft Office Excel Array Index Parsing Memory Corruption Vulnerability 80. Verify 1853-0.pcap is Ruby on Rails JavaScript Object Notation convert_json_to_yaml() Code Execution Vulnerability
81. Verify 1963-0.pcap is MySQL Heap Based Buffer Overflow Vulnerability 82. Verify 1963-1.pcap is MySQL Heap Based Buffer Overflow Vulnerability 83. Verify 15233-1.pcap is ??????? 84. Verify 15233-2.pcap is ??????? 85. Verify 16957-0.pcap is ?????? 86. Verify 18297-3.pcap is ?????? 87. Verify 1759-0.pcap is [UNAVAILABLE(29475)] 88. Verify 1818-0.pcap is IBM Informix Dynamic Server oninit.exe EXPLAIN Remote Code Execution Vulnerability 89. Verify 18921-0.pcap is Apple Safari and Safari for Windows XML External Entity Information Disclosure Vulnerability 90. Verify 19219-0.pcap Microsoft Windows DirectShow QuickTime Media Processing Arbitrary Code Execution Vulnerability 91. Verify 19339-1.pcap is Microsoft Windows Video msvidctl ActiveX Control Code Execution Vulnerability 92. Verify 19383-1.pcap is Microsoft DirectShow Field Size Validation Arbitrary Code Execution Vulnerability 93. Verify 19600-0.pcap is Mozilla Firefox Just-In-Time JavaScript Parsing Arbitrary Code Execution Vulnerability 94. Verify 19639-0.pcap is Mozilla Firefox 3.5 unicode Remote Buffer Overflow 95. Verify 1985-0.pcap is Heap Spraying Buffer Overflow Attacks 96. Verify 1985-1.pcap is Heap Spraying Buffer Overflow Attacks 97. Verify 1985-2.pcap is Heap Spraying Buffer Overflow Attacks 98. Verify 2083-0.pcap is Oracle Java SE Java Sandbox Remote Security Bypass Vulnerability 99. Verify 1044-0.pcap is Exploit Shell Code Encoding Obfuscation Issue 10 Verify 1044-2.pcap is Exploit Shell Code Encoding 0. Obfuscation Issue 10 Verify 1044-3.pcap is Exploit Shell Code Encoding 1. Obfuscation Issue 10 Verify 1044-4.pcap is Exploit Shell Code Encoding 2. Obfuscation Issue 10 Verify 1044-5.pcap is Exploit Shell Code Encoding 3. Obfuscation Issue
10 Verify 1044-6.pcap is Exploit Shell Code Encoding 4. Obfuscation Issue 10 Verify 1044-7.pcap is Exploit Shell Code Encoding 5. Obfuscation Issue 10 Verify 1044-8.pcap is Exploit Shell Code Encoding 6. Obfuscation Issue 10 Verify 1044-9.pcap is Exploit Shell Code Encoding 7. Obfuscation Issue 10 Verify 1044-10.pcap is Exploit Shell Code Encoding 8. Obfuscation Issue Attacker and Victim Testcases # Entity Title contains 10 test cases. Description
1. Verify 1052-0.pcap is a Server Attacker 2. Verify 15001-0.pcap is a Client Attacker 3. Verify 15175-0.pcap is a Server Attacker 4. Verify 19219-0.pcap is a Server Attacker 5. Verify 16217-0.pcap is a Server Attacker 6. Verify 1019-0.pcap is a Client Attacker 7. Verify 1138-0.pcap is a Server Attacker 8. Verify 1256-0.pcap is a Client Attacker 9. Verify 1258-2.pcap is a Server Attacker 10. Verify 1021-0.pcap is a Client Attacker

CX & PRSM: Contains 309 Test Cases

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CX & PRSM: Contains 309 Test Cases

Uploaded by

Copyright:

Available Formats

Test Plan Report

10/15/2013 03:49:52 UTC

10. Verify Multiple threat profiles attached to access policies

11. Verify Same Profile attached to multiple access policies

Cisco Systems, Inc. Cisco Confidential Page 1 of 144

12. Verify Default Profile attached to access policies

16. Verify Global threat Profile set to User Created Profile

Cisco Systems, Inc. Cisco Confidential Page 2 of 144

Cisco Systems, Inc. Cisco Confidential Page 3 of 144

Cisco Systems, Inc. Cisco Confidential Page 4 of 144

47. Verify the default behavior for threat prevention updates.

Cisco Systems, Inc. Cisco Confidential Page 5 of 144

56. Verify threats in non-http-tcp (tls) traffic, access policy.

Cisco Systems, Inc. Cisco Confidential Page 6 of 144

71. Verify that processes are spawned correctly in a VM system.

Cisco Systems, Inc. Cisco Confidential Page 7 of 144

78. Verify predictive defense process and logging.

Cisco Systems, Inc. Cisco Confidential Page 8 of 144

Cisco Systems, Inc. Cisco Confidential Page 9 of 144

Cisco Systems, Inc. Cisco Confidential Page 10 of 144

85. Verify threats in http traffic using Global threat profiles

Cisco Systems, Inc. Cisco Confidential Page 11 of 144

Cisco Systems, Inc. Cisco Confidential Page 12 of 144

Cisco Systems, Inc. Cisco Confidential Page 13 of 144

88. Verify the modal overlay of Top Attackers report.

Cisco Systems, Inc. Cisco Confidential Page 14 of 144

Cisco Systems, Inc. Cisco Confidential Page 15 of 144

90. Verify the modal overlay of Top Attackers report.

Cisco Systems, Inc. Cisco Confidential Page 16 of 144

Cisco Systems, Inc. Cisco Confidential Page 17 of 144

92. Verify the modal overlay of Top Attackers report.

Cisco Systems, Inc. Cisco Confidential Page 18 of 144

Cisco Systems, Inc. Cisco Confidential Page 19 of 144

Cisco Systems, Inc. Cisco Confidential Page 20 of 144

Cisco Systems, Inc. Cisco Confidential Page 21 of 144

Cisco Systems, Inc. Cisco Confidential Page 22 of 144

Cisco Systems, Inc. Cisco Confidential Page 23 of 144

Cisco Systems, Inc. Cisco Confidential Page 24 of 144

Cisco Systems, Inc. Cisco Confidential Page 25 of 144

Cisco Systems, Inc. Cisco Confidential Page 26 of 144

Cisco Systems, Inc. Cisco Confidential Page 27 of 144

Cisco Systems, Inc. Cisco Confidential Page 28 of 144

Cisco Systems, Inc. Cisco Confidential Page 29 of 144

Cisco Systems, Inc. Cisco Confidential Page 30 of 144

Cisco Systems, Inc. Cisco Confidential Page 31 of 144

Cisco Systems, Inc. Cisco Confidential Page 32 of 144

Cisco Systems, Inc. Cisco Confidential Page 33 of 144

Cisco Systems, Inc. Cisco Confidential Page 34 of 144

Cisco Systems, Inc. Cisco Confidential Page 35 of 144

Cisco Systems, Inc. Cisco Confidential Page 36 of 144

Cisco Systems, Inc. Cisco Confidential Page 37 of 144

Cisco Systems, Inc. Cisco Confidential Page 38 of 144

Cisco Systems, Inc. Cisco Confidential Page 39 of 144

Cisco Systems, Inc. Cisco Confidential Page 40 of 144

14 Verify that http-traffic exception work properly in 3. Access Policy

Cisco Systems, Inc. Cisco Confidential Page 41 of 144

Cisco Systems, Inc. Cisco Confidential Page 42 of 144

Cisco Systems, Inc. Cisco Confidential Page 43 of 144

Cisco Systems, Inc. Cisco Confidential Page 44 of 144

15 The Scroll bar in List of Threat is infinite ie 1. continous to the end

15 List of threats appears in Policies, Threats 2.

15 Filter works properly in the list of Threats 3.