SmartNet - Invalid PSIRT Reporting

[twylyghtcisco]

While reviewing the Alerts, we have found that almost none of our PSIRT alerting is correct.  In reviewing the SNTC guide (pages 30-31), I am showing that the threshold for hitting on an affected OS (IOS, XE, XR, ASA and NX-OS) is "Critical" and "High":

http://www.cisco.com/c/dam/en/us/td/docs/net_mgmt/inventory_and_reporting/User_Guides/SNTC_Portal_User_Guide.pdf

As an example, the inventory we have uploaded has a verified count of 727 chassis running IOS 15.2(3)T1.  When running the comparison of expected PSIRTs found in the corresponding Cisco IOS Software Checker, we are coming up woefully short:

https://tools.cisco.com/security/center/swCheckerShowResults.x?technologySelected=&advisoriesSelected=&versionsSelected=114667&versionNamesSelected=15.2%283%29T1&productSelected=ios&allAdvisoriesSelectedByTree=N&advisoryType=0&iosBundleId=cisco-sa-20170322-bundle&adv_key=0.3189937681500079

I have attached a screenshot of PSIRTs sorted by affected chassis count to illustrate.

[Chris Camplejohn]

Thank you for your detailed input.  There are likely two reasons you are not seeing the same result as is reported by the IOS Software Checker:

1) The Alert analysis in SNTC is taking into consideration more than just SW Version.  It is also matching against feature (based on configuration), imagename (IOS only), and optionally hardware attributes (PID, etc.) where needed.

2) You might be hitting this SNTC bug: CSCve06449.  When SNTC has the wrong imagename for a device, the automation will erroneously declare a device Not Vulnerable to a PSIRT.  

[twylyghtcisco]

Chris,

I appreciate the reply. 

With respect to the imagename, I have verified that the correct information is being reflected.  Hence, the Software EoX portion of the portal's reporting is accurate.  Also, the 727 chassis in question have identical hardware configurations except for switch cards being used.  For most they have the HWIC-4ESW card while later deployments have the HWIC-4ESG installed. 

We are in the process of compiling audits for this portion of the network, but the builds for these devices have been standardized with the use of configuration templates over the past two years.

Lastly, I am getting a message on the Cisco site that CSCve06449 does not exist (screenshots attached).

[Chris Camplejohn]

Apologies for that.  The bug was just filed today it seems and it can take 24h before they are customer visible in the bug search tool.  Should be visible tomorrow.

Software EoX doesn't use imagename.  It just uses SW Type (IOS) and SW Version.

Can you send me the SW Version and Imagename as reported in SNTC portal for one of the 727 chassis and give me the name of a PSIRT you are expecting to see?  I just want to make sure it isn't something else going on.

[twylyghtcisco]

Not a problem, sir.  Below is a quick snap of a device we expected to show up with a hit against cisco-sa-20160916-ikev1 (https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160916-ikev1):

router#sh ver
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(3)T1, RELEASE SOFTWARE (fc1)

                        **************************

ROM: System Bootstrap, Version 15.0(1r)M15, RELEASE SOFTWARE (fc1)

                        **************************

System image file is "flash:c2900-universalk9-mz.SPA.152-3.T1.bin"

                        **************************

Cisco CISCO2901/K9 (revision 1.0) with 479232K/45056K bytes of memory.
Processor board ID <omitted>
4 FastEthernet interfaces
2 Gigabit Ethernet interfaces
1 Serial interface
1 Serial(sync/async) interface
1 terminal line
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity enabled.
255K bytes of non-volatile configuration memory.
250880K bytes of ATA System CompactFlash 0 (Read/Write)

License Info:

License UDI:

-------------------------------------------------
Device#   PID                   SN
-------------------------------------------------
*0        CISCO2901/K9          <omitted>

Technology Package License Information for Module:'c2900'

-----------------------------------------------------------------
Technology    Technology-package           Technology-package
              Current       Type           Next reboot 
------------------------------------------------------------------
ipbase        ipbasek9      Permanent      ipbasek9
security      securityk9    Permanent      securityk9
uc            None          None           None
data          datak9        Permanent      datak9

Configuration register is 0x2102

router#sh udp | i 500|4500|848|4848|Proto
Proto        Remote      Port      Local                Port  In Out  Stat TTY  OutputIF
 17         --listen--                    <omitted>          848   0     0 1001011   0
 17(v6)   --listen--                    --any--               848   0     0 1020011   0
 17         --listen--                    <omitted>        4500   0     0 1001011   0
 17(v6)   --listen--                    --any--             4500   0     0 1020011   0

[Chris Camplejohn · Accepted solution]

I'm pretty sure all 2900s will be affected by the bug mentioned because the real imagename is c2900-universalk9-mz.SPA but the image reported in show version is just c2900-universalk9-m.  This is causing your false negative (PSIRT being reported as Not Vulnerable erroneously).

[twylyghtcisco]

Gotcha.  Am I correct in assuming that this is something that Cisco will have to address?  If so, do I need to report all of these instances piecemeal as we find them?  I only picked this one because it stood out.  We have tons more instances.

[Chris Camplejohn]

Yes.  Cisco is on the hook to address this.  You do not need to report all of them.

[twylyghtcisco]

Wanted to check in again to see if there has been any movement on this issue.  I've seen nothing altered for CSCve06449 since it was acknowledged in April of this year.

[Chris Camplejohn]

It is a priority issue and I know at least some of the development work is just recently completed.  What I don't know is when the changes will be deployed into the production SNTC application.  Stay tuned.  It shouldn't be long now.

[twylyghtcisco]

Wanted to check in again to see if there has been any movement on this issue.  I've seen nothing altered for CSCve06449 since it was acknowledged in April of this year.

[Jarrett Pomeroy]

Hello twylyghtcisco,
Unfortunately this bug ( https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve06449 ) requires several design changes for the SNTC Portal. Although the defect is showing as fixed on BST, it has not been released yet for SNTC. Once the bug gets released, the new values will be represented in the 'Known fixed Releases' fields. On the BST web-page, you can also select the "Notification" icon to set up automate alerts and updates to track the status of the defect.
Thank you,
Jarrett

[twylyghtcisco]

I've yet to see any movement on CSCve06449.  Wanted to check and see if there is a timeline to get this addressed

[Chris Camplejohn]

The imagename fix is part of SNTC 4.0 release coming out shortly.

[twylyghtcisco]

My thanks for the reply sir.  My team will continue to be on the lookout for this resolution.