Continuing the Top 10 “Other than Satisfied Requirements” for 800-171 assessments by DIBCAC. “๐๐๐๐ง๐ญ๐ข๐๐ฒ, ๐ซ๐๐ฉ๐จ๐ซ๐ญ, ๐๐ง๐ ๐๐จ๐ซ๐ซ๐๐๐ญ ๐ข๐ง๐๐จ๐ซ๐ฆ๐๐ญ๐ข๐จ๐ง ๐๐ง๐ ๐ข๐ง๐๐จ๐ซ๐ฆ๐๐ญ๐ข๐จ๐ง ๐ฌ๐ฒ๐ฌ๐ญ๐๐ฆ ๐๐ฅ๐๐ฐ๐ฌ ๐ข๐ง ๐ ๐ญ๐ข๐ฆ๐๐ฅ๐ฒ ๐ฆ๐๐ง๐ง๐๐ซ.” This is the third most “Other than Satisfied” requirement.
3.14.1 is both misunderstood and very hard to implement. Both problems cause failures.
๐๐ก๐ฒ ๐ข๐ฌ 3.14.1 ๐ฆ๐ข๐ฌ๐ฎ๐ง๐๐๐ซ๐ฌ๐ญ๐จ๐จ๐?
Most people read the requirement as just the last assessment objective: [๐ง] ๐ด๐บ๐ด๐ต๐ฆ๐ฎ ๐ง๐ญ๐ข๐ธ๐ด ๐ข๐ณ๐ฆ ๐ค๐ฐ๐ณ๐ณ๐ฆ๐ค๐ต๐ฆ๐ฅ ๐ธ๐ช๐ต๐ฉ๐ช๐ฏ ๐ต๐ฉ๐ฆ ๐ด๐ฑ๐ฆ๐ค๐ช๐ง๐ช๐ฆ๐ฅ ๐ต๐ช๐ฎ๐ฆ ๐ง๐ณ๐ข๐ฎ๐ฆ.
However, other objectives require you to specify timeframes for identifying flaws and reporting flaws, then show proof of identifying and reporting.
These assessment objectives assume you have separate people doing tasks that most small IT departments assign to a single person. This is why they break out identifying from reporting, reporting from patching. Because when you’ve got millions of dollars of IT budget (Hello U.S. Government), those tasks are done by different departments.
When a single person is in charge from start-to-finish, they may have trouble showing evidence that they “reported” the flaws to themselves. I’m rolling my eyes right now as I write this, but seriously, a common solution is adding a reporting step to your process to document what patches are needed before you start patching. The list of flaws is never reviewed by anyone else, except as evidence you are reporting on schedule. Whoopee.
๐๐ก๐ฒ ๐ข๐ฌ 3.14.1 ๐ก๐๐ซ๐ ๐ญ๐จ ๐ข๐ฆ๐ฉ๐ฅ๐๐ฆ๐๐ง๐ญ?
Patching systems is one of the most costly requirements in 800-171 (in terms of labor).
Patching a core system causes brief downtime and can cause it to crash, causing lots of downtime for lots of people. In most companies, you are paying for an IT person to monitor important systems during the entire patch, reboot, and function check process.
As systems get older, vendors start asking for extra money if you want eligibility for continued patches.
Ironically, our role models, the US Government, often struggle with patching on schedule, even though they have more IT resources. It is common to see them take 3-6 months to deploy after a flaw has been ‘identified’.
What to do if you have a system that cannot be patched because it breaks, and you can’t get an alternate system? This is a good candidate for an enduring exception to policy and/or a multi-year POA&M. (Talk to a cybersecurity professional to plan this out, because it can burn you if done wrong.)
Shameless plug: The Kieri Compliance Documentation includes customizable timeframes for identifying, reporting, and patching. We include steps in our process to document what patches are needed (๐ช๐ฅ๐ฆ๐ฏ๐ต๐ช๐ง๐บ๐ช๐ฏ๐จ and ๐ณ๐ฆ๐ฑ๐ฐ๐ณ๐ต๐ช๐ฏ๐จ) so that you don’t fail because of a silly misunderstanding.