4 Replies Latest reply on Dec 19, 2017 2:19 PM by rschroeder

    Censoring Change Report - Removing SNMP, Passwords, and Pre-Share Keys

    rjrothwell

      Any ideas on how to censor or scrub SNMP, Hashes, Passwords, and Pre-Share Keys from the Change Reports? I know that you can remove the from the compare criteria, but not if it is within the 5 lines u/down from the change. These reports are e-mailed every morning to the Networking Team.

       

      I can not encrypt the SNMP or Pre-Share keys on all of our systems since they are too old and don't support it. Capture.JPG

       

      What are your expert thoughts?

        • Re: Censoring Change Report - Removing SNMP, Passwords, and Pre-Share Keys
          dave@entwistle.cc

          I don't think there is a way to naively do it within the tool.  If the output is text vs PDF you could run it though a script to parse out or replace with XXXX the secure parts.

          • Re: Censoring Change Report - Removing SNMP, Passwords, and Pre-Share Keys
            rschroeder

            It seems the correct solution is to not ask NCM to compensate for old operating systems and old equipment.  Instead, upgrade the systems so you can use the "service password-encryption" command (Cisco-ese) and be done with the problem.  Simultaneously you will also enjoy multiple bug fixes and many feature enhancements, as well as improved security and stability.

             

            However, if you MUST stay with antiquated code, there are a few kluges you can try within NCM:

             

            • Set NCM to report fewer lines before and after a changed line.  This will eliminate some of the context you enjoy seeing presently, which currently gives you an idea about where in the code the lines have been changed.  But if your goal remains to use obsolete code while simultaneously avoiding displaying confidential information that occurs within five lines of the change, this is one way to do it:

             

            • Configure NCM to ignore compared lines that contain sensitive information.

             

             

            • Change NCM Settings to Hide SNMP Community strings and user login information:

            1 of 1 people found this helpful
            • Re: Censoring Change Report - Removing SNMP, Passwords, and Pre-Share Keys
              rjrothwell

              Thanks guys for the input. The problem is that we have 220 HP switches on campus and most are running the original out of box OSes. Mainly from 2007-ish to 2012-ish range. (I kind of inherited this problem) I also discovered that both Cisco and HP does not have the feature of encrypt their SNMP Community Strings. I could use an ACL to limit who has access.

               

              We also had several other thoughts talking with my co-worker. Maybe just save the report locally on the server or save it to a network share.

                • Re: Censoring Change Report - Removing SNMP, Passwords, and Pre-Share Keys
                  rschroeder

                  I've been biting my tongue on this one for a while.  Please take this as a gentle and friendly idea, and not a criticism or attack, or even an unreasonable recommendation.

                   

                  • Work towards not treating the symptoms.  Instead, treat the cause.  Rather than creating ACL's to compensate for limitations on the problem gear, eliminate the problems.
                  • Start identifying obsolete operating systems, then prioritize upgrading their IOS to be compatible. Schedule their upgrades and outages with the clients and through Change Management.
                  • Where OS's cannot be upgraded due to hardware age, identify the problem devices and schedule their replacement.  Schedule these replacements with the clients and through Change Management.
                  • Prepare a well-reasoned statement to justify the additional work and capital outlay to accomplish your goals.
                  • If you can't replace OS or hardware within a reasonable time, explain the issues (budget, time constraints, security needs, etc.) and work with the vendors or outside support contractors to provide:
                    • Temporary work arounds, such as you requested--ACL's, etc. to deal with the symptoms
                    • Contracted support hours for vendors to upgrade OS or replace hardware, as required
                  • Have Management and/or Security present a required date for completion of correction.  It will put pressure on you and your team, but it can also be used to justify requests for professional services from outside experts who can get the job done in the required time frame for you.

                   

                  Don't offer excuses.  Clear and unemotional explanations about why the problem is present will suffice.  Before ending an explanation, include the solutions you have chosen to implement, and their timing.  Your project should have a completion target date, to which you and your team can be held accountable.  This is always better than having people understand the issue is inherited.  They'll know you have the problem and its solutions well in hand.

                   

                  Never complain about "inherited" issues.  Instead, discuss them with a solution ready to implement, and a schedule for that implementation  Complaining, without offering practical solutions or suggestions for corrections, may be perceived as "whining", and no one wants that for themselves.

                   

                  When finished with the upgrades and replacements, you'll be in a much better position.  And you'll have earned the respect of your teams, your Manager, and your peers.  Not to mention you'll probably sleep better at night.  When you're not upgrading OS's or replacing hardware.