3.14.1 Identify, report, correct system flaws

3.14.1 identify report and correct information system flaws

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.

Leave a Reply

Your email address will not be published. Required fields are marked *