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.