What We're Working On

This will come once we embed the Python engine into NCM

IF-THEN-ELSE Statements for NCM

I have noticed that RegEx are either true or false based on how they are written within NCM, which is great for most things.  The problem I face often is, while working with DISA STIGs, is that sometimes if an entry is missing, I want to check for a different entry to see if my device is still compliant.  Perhaps my devices are running different versions of code due to hardware limitations? Who knows what different use cases may arise for others?  I honestly believe IF-THEN-ELSE for NCM is a necessary future for configuration management moving forward!

  • I've seen what they're working towards; it has some valid use.  On the other hand, I saw what Cisco offered for a GUI in the 1990's and early 2000's--it looked nice but was starved of features and ran off a terribly slow Java solution, and all the html files required to present the GUI consumed more flash space than the device could afford--other things had to be sacrificed if you wanted the GUI to show.

    Perhaps worse, those old Cisco GUI's introduced a world of vulnerabilities--and didn't even support https at the start.

    I love a great GUI--Nortel was the king of that interface, IMHO.  Fast, small footprint, reliable, powerfully and fully functional.  I'd hoped Cisco would buy Nortel's GUI when Nortel went out of business; it would have made a wonderful addition to Cisco's arsenal, and reduced the cost of ownership while decreasing the time required to learn a new product.  No one needed to learn Nortel's CLI to manage their switches because their GUI was so fast and complete and powerful.

  • I've heard that said numerous times over the last 20 years, usually right after some upgrade to some Software Device Manager or API for a particular product line. It's clearly the Tower of Babel.

    GUIs are inherently non-auditable. One control could affect or interact with multiple settings. Use of ASDM to configure an ASA, for example, sometimes creates unfriendly variable names that make understanding the entire box difficult, if not impossible. We ban it's use for most configuration changes because of that.

    At some point, people surrender, and accept the futility of secure management forced on us by a generation of semi-computer-literate programmers. The crackers of the world celebrate.

  • I think this is a great idea!  Just to add to the conversation, I was at a Cisco Connect and they were saying that the end of CLI is just a few years away.  I am not saying that I agree or disagree, but a lot of the products we are seeing from Cisco have that idea in mind.

  • Each time I run a Compliance Report, I run into variations of configurations that are acceptable, but for which the Compliance Report seems too rigid to handle.

    Suppose we define a device as "compliant" for a particular purpose if it has ANY of lines x, y, or z?  Or it's compliant if it has lines (x or y), or (a or b), but not both.

    If I don't want to flag a device as out of compliance when the above limitations are in play, then I have to narrow my targeted devices more and more granularly.

    Offering the ability to allow a variety of acceptable solutions, while not requiring all of them, might make life simpler for us when we manage a Cisco Nexus 9xxx in ACI mode, a Cisco Nexus 7009 NOT in ACI mode, a 3925 router, a 4510 L3 switch doing WAN BGP and LAN services, etc.

    It can be helpful if a Compliance, or other detection and filtering solution, can be made more broad to cover more devices.

  • Can you give a use case you've encountered that may relate this better outside of the Federal sector?