Question with NSO and CARE

[xifa4]

Question for anyone who used NSO with CARE to automate STIGs.

So we had call yesterday with a few guys from Cisco to discuss us potentially ordering Cisco NSO. The main reason for purchasing is to use their CARE product which will allow us to automate STIG checking and filling out the STIG checklists for us, among other things.

During this meeting the guy referenced anislble alot and said that NSO using a lot of ansible playbooks to do these checks. Even when he showed us the output of some of the checks, i noticed that it is the same output that I would get from ansible. Everything from what it prints down to even the color it prints in.

So my question. Everything that NSO CARE does for checking STIGS (compliance checks, differences between golden configs and all other configs, filling out STIG checklists, etc.), could it all be done with ansible playbooks? I have some experience with ansible and python, and I have my own playbooks/scripts that do compliance checks, check differences between configs, tell me what STIG findings are open, etc. The only thing I really havn't figured out how to do yet that I really would like to be able to do is automate filling out the checklists. Not sure if thats possible with an ansible playbook or not.

[Jaime Valencia]

This is the collaboration / UC area of CSC, might want to move your post to a relevant area to get assistance.

[hhha7x]

Why did you copy this from Reddit? 

[Eric R. Jones]

I just read this reddit page myself while searching for documentation on NSO.

[jbaumgardner]

I realize I am extremely late to this party, but wanted to leave this nugget here for anyone that reads this in the future.  Professionally, I advise against having the same company providing you network infrastructure and solutions focused on availability be the company involved with your Audit and Compliance requirements. I personally associate this to eating where you sleep...

Check out the Defender platform at Squirrel Compliancy Solutions (https://www.squirrelcompliancysolutions.com/request-a-demo) for those looking for a real network STIG automation solution.

Defender offerings:

• Purpose-built platform of modernized engines for audit, analysis, and remediation of STIG vulnerability findings
• Curated rules in tandem with DISA STIG Release schedule
• Dashboards to assist in providing metrics, measurements and key performance indicators to various stakeholders.
• Natively generates STIG .CKL checklist files with detailed findings autogenerated within the checklists based on the audits.
• Both on-demand and schedule audits
• Setup triggered event audits, that will run when a change occurs on a network device.
• Low Code/No Code Embedded Logic GUI

[rogaglia]

This could be a good advise, just like you have "internal" and "external" audits for finance. However, not everyone have budget to build and maintain templates in more than one tool, so it is a risk/mitigation level decision (btw, what happens if one of your vendors acquires your prefered compliance tool). Additionally, in the case of NSO, there is nothing "special" done for Cisco versus other vendors. Finally, if you want to do "automatic re-mediation", you need to interact with your automation layer, which if you use a single tool it is simplified. All in all, I think it is a good principle but there are more nuances in the decision-making process.

[rogaglia]

There is not Ansible Playbooks in NSO compliance features. NSO has its own compliance engine and template definitions.

[snovello]

I just wanted to add some context for anyone else reading this thread. Cisco Audit and Remediation Engine (CARE) and its STIG automation capabilites is a package built on top of NSO.

https://www.youtube.com/watch?v=s-g9sEzV9eI

Here is a video describing that. The video is 2 years old so would be nice to know how it has evolved since then.

From the Video it is clear that most of the functionality is happening inside NSO. NSO comes with the ability to do 'golden config' verification of what is in device configurations. It has some unique advantages there.

1. The configuration is parsed by NSO, so every value is in it's own location witin a tree based schema described by the Yang language. Even for devices that don't natively support Netconf/Yang. What that means is when writing rules, irrespective of device type I am simply expressing things about what may or may not exist within a Tree DB schema. I no longer have to care about specifc device syntaxes, and for example issue like several parameters being defined on the same line.
2. The configurations are all in the DB in that parsed form, so I can run my checks as frequently as I want and I can run them quickly without touching the devices.
3. Whether the DB is in sync with the devices is then separated from the question from whether the config in the DB corresponds to my rules.
4. The NSO capabilities are generic, and rules can be defined and applied for any type of device. NSO is a multi-vendor tool. The main mechanism is templates of which there are 2 types, templates with variables which once the variables are defined can check exactly and can also be used to deply config, and templates that allow regexes for values which can be more useful for determining something like there must be a banner but we don't or only partially prescribe the banner content.
5. NSO is a tool for orchestrating changes to your devices, so keeping the base rules in line is integrated with the process of making changes to your devices in one place.

CARE is a package built on top of the native NSO functionality. It adds the ability of importing Security Technical Implementation Guides (STIGs) from DISA, checking devices against those, and where it can be done safely, which is a majority of cases, it can also be used to auto-remediate. (NSO itself gives you lots of tools to do remediation at scale for the cases it where it is not fully automated)

You mention that in your more recent demo Ansible was mentioned a lot. There is a plugin to call NSO from Ansible, and it may be that some of the sequencing and report generation turned out to be easier to implement by calling Ansible at some point.

The other thing I notice from the Video is the use of the NSO Web UI. All those actions that get executed, and all those models to represent STIGS and vulnerabilites etc. are all in that same DB and it is actually easy to build automation on top of such a package. That automation can exist withn NSO, so creating higher level actions or augmenting the data stored to work better in your environment, or it can be driven from outside NBIs.

[rickCtr]

Just reading into this. Might be worth looking into if not just for testing. I'm just posting to keep the thread relevant and for my own bookmark.