The DoD transitioned to Risk Management Framework for Cyber 4 or 5 years ago, sounds like it’s based on the same NIST/CNNSI guidance. My program was in the first block of systems to switch over from DIACAP. They gave us a 12 month timeline and it took almost 2 years to get our ATO. It was and is a nightmare on the DoD side to implement because of the diversity of systems and the gov’ts need to apply templates and standards which doesn’t fit everybody. One of the key parts of the NIST framework is tailoring controls, which of course the DoD wouldn’t allow.
RMF is pretty straight forward on the enterprise side, standard users on standard networks. On the tactical side things get squirrely fast. Our system was a command and control suite that flew around in the back of a Blackhawk, but got on the colored networks through comsat links. Big army decreed anyone touching SIPR was immediately a high, high, med system. That meant we had untailored HHM controls applied to an ad hoc system, in a helicopter, in a tactical environment. Super fun.
Controls are how you fix or mitigate a vulnerability, and they cover everything. Policy, physical security, logistics, auditing, budget, personnel, technical, etc. IIRC our system had 1200ish controls, and within a control there can be up to 15 tasks. Tailoring controls removes any that obviously don’t fit that system. You can’t remove it because it’s hard or you want to speed things up, but if a control says “the building will have a fire suppression system that activates within x seconds” and your system isn’t in a building, obviously you can tailor that out. That’s how it’s supposed to work, but again, DoD didn’t want systems purging controls that were hard and the volume of systems didn’t allow any real visibility from the top to approve/deny tailoring, so they just threw out the tailoring step entirely. So back to the Blackhawk example, yep, I had to mitigate why my system didn’t have a fire suppression in the building that is a Blackhawk in my Plan of Actions & Milestones (POAM), which gets reviewed and updated quarterly.
One of the biggest strengths of RMF is closing all the “someone else is responsible for that control” loopholes that plagued DIACAP, and cybersecurity as a whole. On tactical systems we would say that a higher NOC did a bunch of stuff, and that the owning tactical unit was responsible for all the user level stuff, and wipe our hands of it even though we knew units rarely enforced passwords properly, or patched AV on schedule, etc. Now you have to show your work. If someone inherits a control, it flows up or down to their system and gets rolled into their evaluation as well. So if the unit gets evaluated and isn’t doing X controls, they fail, and that failure flows into your system and can trigger a failure for you as well. That’s the academic version of how it’s supposed to be. In reality the Army has realized it’s just too big and hard on the tactical side so there is a lot of leeway being given to systems and vulnerabilities are being left open because of budget (fix this new vuln now, but your budget was already set for the next 5 years and can’t be changed, good luck), or lack of oversight on the hundreds of potential systems, and thousands of implantations at the unit level. The elephant in the room is also on the logistics side. Supply chain protection is a massive part of RMF, and practically impossible to achieve with foreign manufacturing, JIT logistics, and now Covid impacts to the supply chain.
I took the long way around to get to this question (for the NERC guys, shady just provided a convenient roll up). Is the NERC implementation pretty tight top to bottom, or do you have similar issues? I would think it’s much more standard wrt the network side (all one color network, pretty standard enterprise guidance, etc), but all the local control/access still leaves some big holes (giggity) to be exploited. Sloppy admin rights or password policies leads to elevated rights, which leads to attack vector, which leads to yada yada.