1 line
No EOL
929 KiB
Text
1 line
No EOL
929 KiB
Text
<!DOCTYPE html><html lang="en"><head><meta charSet="utf-8"/><meta name="viewport" content="width=device-width, initial-scale=1"/><link rel="preload" as="image" href="/_next/static/media/CyberGeek-logo.8e9bbd2b.svg" fetchPriority="high"/><link rel="stylesheet" href="/_next/static/css/ef46db3751d8e999.css" data-precedence="next"/><link rel="stylesheet" href="/_next/static/css/0759e90f4fecfde7.css" data-precedence="next"/><link rel="preload" as="script" fetchPriority="low" href="/_next/static/chunks/webpack-182b67d00f496f9d.js"/><script src="/_next/static/chunks/fd9d1056-ad09c71b7719f2fb.js" async=""></script><script src="/_next/static/chunks/23-260042deb5df7a88.js" async=""></script><script src="/_next/static/chunks/main-app-6de3c3100b91a0a9.js" async=""></script><script src="/_next/static/chunks/30-49b1c1429d73281d.js" async=""></script><script src="/_next/static/chunks/317-0f87feacc1712b2f.js" async=""></script><script src="/_next/static/chunks/223-bc9ed43510898bbb.js" async=""></script><script src="/_next/static/chunks/app/layout-9fc24027bc047aa2.js" async=""></script><script src="/_next/static/chunks/972-6e520d137ef194fb.js" async=""></script><script src="/_next/static/chunks/app/page-cc829e051925e906.js" async=""></script><script src="/_next/static/chunks/app/template-d264bab5e3061841.js" async=""></script><script src="/_next/static/chunks/e37a0b60-b74be3d42787b18d.js" async=""></script><script src="/_next/static/chunks/904-dbddf7494c3e6975.js" async=""></script><script src="/_next/static/chunks/549-c87c1c3bbacc319f.js" async=""></script><script src="/_next/static/chunks/app/learn/%5Bslug%5D/page-5b91cdc45a95ebbe.js" async=""></script><link rel="preload" href="/assets/javascript/uswds-init.min.js" as="script"/><link rel="preload" href="/assets/javascript/uswds.min.js" as="script"/><title>Security Impact Analysis (SIA) | CMS Information Security & Privacy Group</title><meta name="description" content="A process to determine the effect(s) a change can cause to the security posture of a FISMA system"/><link rel="canonical" href="https://security.cms.gov/learn/security-impact-analysis-sia"/><meta name="google-site-verification" content="GMZIwBDJgz_o_JYUB2GpJazkrs7P85BaWDsoCjxF32M"/><meta property="og:title" content="Security Impact Analysis (SIA) | CMS Information Security & Privacy Group"/><meta property="og:description" content="A process to determine the effect(s) a change can cause to the security posture of a FISMA system"/><meta property="og:url" content="https://security.cms.gov/learn/security-impact-analysis-sia"/><meta property="og:image:type" content="image/jpeg"/><meta property="og:image:width" content="1200"/><meta property="og:image:height" content="630"/><meta property="og:image" content="https://security.cms.gov/learn/security-impact-analysis-sia/opengraph-image.jpg?d21225707c5ed280"/><meta property="og:type" content="website"/><meta name="twitter:card" content="summary_large_image"/><meta name="twitter:title" content="Security Impact Analysis (SIA) | CMS Information Security & Privacy Group"/><meta name="twitter:description" content="A process to determine the effect(s) a change can cause to the security posture of a FISMA system"/><meta name="twitter:image:type" content="image/jpeg"/><meta name="twitter:image:width" content="1200"/><meta name="twitter:image:height" content="630"/><meta name="twitter:image" content="https://security.cms.gov/learn/security-impact-analysis-sia/opengraph-image.jpg?d21225707c5ed280"/><link rel="icon" href="/favicon.ico" type="image/x-icon" sizes="48x48"/><script>(self.__next_s=self.__next_s||[]).push(["/assets/javascript/uswds-init.min.js",{}])</script><script src="/_next/static/chunks/polyfills-78c92fac7aa8fdd8.js" noModule=""></script></head><body><a class="usa-skipnav" href="#main">Skip to main content</a><section class="usa-banner" aria-label="Official website of the United States government"><div class="usa-accordion"><header class="usa-banner__header"><div class="usa-banner__inner"><div class="grid-col-auto"><img aria-hidden="true" alt="" loading="lazy" width="16" height="11" decoding="async" data-nimg="1" class="usa-banner__header-flag" style="color:transparent" srcSet="/_next/image?url=%2Fassets%2Fimg%2Fus_flag_small.png&w=16&q=75 1x, /_next/image?url=%2Fassets%2Fimg%2Fus_flag_small.png&w=32&q=75 2x" src="/_next/image?url=%2Fassets%2Fimg%2Fus_flag_small.png&w=32&q=75"/></div><div class="grid-col-fill tablet:grid-col-auto" aria-hidden="true"><p class="usa-banner__header-text">An official website of the United States government</p><p class="usa-banner__header-action">Here's how you know</p></div><button type="button" class="usa-accordion__button usa-banner__button" aria-expanded="false" aria-controls="gov-banner-default-default"><span class="usa-banner__button-text">Here's how you know</span></button></div></header><div class="usa-banner__content usa-accordion__content" id="gov-banner-default-default" hidden=""><div class="grid-row grid-gap-lg"><div class="usa-banner__guidance tablet:grid-col-6"><img role="img" alt="" aria-hidden="true" loading="lazy" width="40" height="40" decoding="async" data-nimg="1" class="usa-banner__icon usa-media-block__img" style="color:transparent" src="/_next/static/media/icon-dot-gov.3e9cb1b5.svg"/><div class="usa-media-block__body"><p><strong>Official websites use .gov</strong><br/>A <strong>.gov</strong> website belongs to an official government organization in the United States.</p></div></div><div class="usa-banner__guidance tablet:grid-col-6"><img role="img" alt="" aria-hidden="true" loading="lazy" width="40" height="40" decoding="async" data-nimg="1" class="usa-banner__icon usa-media-block__img" style="color:transparent" src="/_next/static/media/icon-https.e7f1a222.svg"/><div class="usa-media-block__body"><p><strong>Secure .gov websites use HTTPS</strong><br/>A <strong>lock</strong> (<span class="icon-lock"><svg xmlns="http://www.w3.org/2000/svg" width="52" height="64" viewBox="0 0 52 64" class="usa-banner__lock-image" role="img" aria-labelledby="banner-lock-description-default" focusable="false"><title id="banner-lock-title-default">Lock</title><desc id="banner-lock-description-default">Locked padlock icon</desc><path fill="#000000" fill-rule="evenodd" d="M26 0c10.493 0 19 8.507 19 19v9h3a4 4 0 0 1 4 4v28a4 4 0 0 1-4 4H4a4 4 0 0 1-4-4V32a4 4 0 0 1 4-4h3v-9C7 8.507 15.507 0 26 0zm0 8c-5.979 0-10.843 4.77-10.996 10.712L15 19v9h22v-9c0-6.075-4.925-11-11-11z"></path></svg></span>) or <strong>https://</strong> means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.</p></div></div></div></div></div></section><div class="usa-overlay"></div><header class="usa-header usa-header--extended"><div class="bg-primary-dark"><div class="usa-navbar"><div class="usa-logo padding-y-4 padding-right-3" id="CyberGeek-logo"><a title="CMS CyberGeek Home" href="/"><img alt="CyberGeek logo" fetchPriority="high" width="298" height="35" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/CyberGeek-logo.8e9bbd2b.svg"/></a></div><button aria-label="Open menu" type="button" class="usa-menu-btn" data-cy="menu-button">Menu</button></div></div><nav aria-label="Primary navigation" class="usa-nav padding-0 desktop:width-auto bg-white grid-container float-none"><div class="usa-nav__inner"><button type="button" class="usa-nav__close margin-0"><img alt="Close" loading="lazy" width="24" height="24" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/close.1fafc2aa.svg"/></button><ul class="usa-nav__primary usa-accordion"><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="roles"><span>Roles</span></button><ul id="roles" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Roles</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/information-system-security-officer-isso">Information System Security Officer (ISSO)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-system-security-officer-isso-handbook"><span>ISSO Handbook</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos"><span>Getting started (for new ISSOs)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/isso-mentorship-program"><span>ISSO Mentorship Program</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-system-security-officer-isso-handbook#training"><span>ISSO Training</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/data-guardian">Data Guardian</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/data-guardian-handbook"><span>Data Guardian Handbook</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/cyber-risk-advisor-cra">Cyber Risk Advisor (CRA)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-security-and-privacy-handbooks"><span>CMS Security and Privacy Handbooks</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters"><span>Risk Management Handbook (RMH)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/business-system-owner">Business / System Owner (BO/SO)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cybersecurity-risk-assessment-program-csrap"><span>Cybersecurity and Risk Assessment Program (CSRAP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-information-exchange-agreement-iea"><span>Information Exchange Agreement (IEA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-computer-matching-agreement-cma"><span>Computer Matching Agreement (CMA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/isso-service"><span>ISSO As A Service</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="compliance-authorization"><span>Compliance & Authorization</span></button><ul id="compliance-authorization" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Compliance & Authorization</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/learn/authorization-operate-ato">Authorization to Operate (ATO)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato"><span>About ATO at CMS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato#types-of-authorizations"><span>Types of authorizations</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato#ato-stakeholders"><span>ATO stakeholders</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/authorization-operate-ato#related-documents-and-resources"><span>ATO tools and resources</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-technical-reference-architecture-tra"><span>CMS Technical Reference Architecture (TRA)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/learn/ongoing-authorization-oa">Ongoing Authorization (OA)</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/ongoing-authorization-oa"><span>About OA at CMS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa"><span>OA eligibility requirements</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/continuous-diagnostics-and-mitigation-cdm"><span>Continuous Diagnostics and Mitigation (CDM)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Assessments & Audits</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/penetration-testing-pentesting"><span>Penetration Testing</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cybersecurity-risk-assessment-program-csrap"><span>Cybersecurity Risk Assessment Program (CSRAP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/privacy-impact-assessment-pia"><span>Privacy Impact Assessment (PIA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/security-impact-analysis-sia"><span>Security Impact Analysis (SIA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/system-audits"><span>System Audits</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="policy-guidance"><span>Policy & Guidance</span></button><ul id="policy-guidance" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Policy & Guidance</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/cms-policies-and-guidance">CMS Policies and Guidance</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-acceptable-risk-safeguards-ars"><span>CMS Acceptable Risk Safeguards (ARS)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-information-systems-security-privacy-policy-is2p2"><span>CMS Information Security and Privacy Policy (IS2P2)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-security-and-privacy-handbooks"><span>CMS Security and Privacy Handbooks</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="https://security.cms.gov/learn/cms-risk-management-framework-rmf"><span>CMS Risk Management Framework (RMF)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/email-encryption-requirements-cms"><span>CMS Email Encryption</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/federal-policies-and-guidance">Federal Policies and Guidance</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/national-institute-standards-and-technology-nist"><span>National Institute of Standards and Technology (NIST)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/federal-information-security-modernization-act-fisma"><span>Federal Information Security Modernization Act (FISMA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/fedramp"><span>Federal Risk and Authorization Management Program (FedRAMP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/zero-trust"><span>Zero Trust</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="system-security"><span>System Security</span></button><ul id="system-security" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">System Security</span></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/application-security">Application Security</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/threat-modeling"><span>Threat Modeling</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/zero-trust"><span>Zero Trust</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cloud-services"><span>CMS Cloud Services</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/software-bill-materials-sbom"><span>Software Bill of Materials (SBOM)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/security-operations">Security Operations</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir"><span>Incident Response</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cybersecurity-integration-center-ccic"><span>CMS Cybersecurity Integration Center (CCIC)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/penetration-testing-pentesting"><span>Penetration Testing</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header"><a href="/ispg/risk-management-and-reporting">Risk Management and Reporting</a></h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/continuous-diagnostics-and-mitigation-cdm"><span>Continuous Diagnostics and Mitigation (CDM)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cyber-risk-reports"><span>Cyber Risk Reports</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/plan-action-and-milestones-poam"><span>Plan of Action and Milestones (POA&M)</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="privacy"><span>Privacy</span></button><ul id="privacy" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Privacy</span></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Agreements</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-computer-matching-agreement-cma"><span>Computer Matching Agreement (CMA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-information-exchange-agreement-iea"><span>Information Exchange Agreement (IEA)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Privacy Activities</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/breach-response"><span>Breach Response</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/privacy-impact-assessment-pia"><span>Privacy Impact Assessment (PIA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/system-records-notice-sorn"><span>System of Records Notice (SORN)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Privacy Resources</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/ispg/privacy"><span>Privacy at CMS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-breach-response-handbook"><span>CMS Breach Response Handbook</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/health-insurance-portability-and-accountability-act-1996-hipaa"><span>Health Insurance Portability and Accessibility Act (HIPAA)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/policy-guidance/cms-privacy-impact-assessment-pia-handbook"><span>CMS Privacy Impact Assessment (PIA) Handbook</span></a></li></ul></section></div></li></ul></li><li class="usa-nav__primary-item"><button type="button" class="usa-accordion__button usa-nav__link font-family-serif text-medium tablet:text-no-wrap desktop:text-primary-vivid" aria-expanded="false" aria-controls="tools-services"><span>Tools & Services</span></button><ul id="tools-services" class="usa-nav__submenu usa-megamenu bg-white" hidden=""><li class="grid-row grid-gap-3 padding-bottom-6"><div class="usa-col text-center desktop:text-right text-normal position-relative nav-label"><span class="display-block font-heading-xl padding-top-2">Tools & Services</span></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Reporting & Compliance</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="https://security.cms.gov/learn/isso-service"><span>ISSO As A Service</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-fisma-continuous-tracking-system-cfacts"><span>CFACTS</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cyber-risk-reports"><span>Cyber Risk Reports and Dashboards</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/continuous-diagnostics-and-mitigation-cdm"><span>Continuous Diagnostics and Mitigation (CDM)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">System Security</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/threat-modeling"><span>Threat Modeling</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cloud-services"><span>CMS Cloud Services</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cms-cybersecurity-integration-center-ccic"><span>CMS Cybersecurity Integration Center (CCIC)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="https://security.cms.gov/learn/cms-security-data-lake-sdl"><span>CMS Security Data Lake (SDL)</span></a></li></ul></section></div><div class="usa-col"><section><h3 class="usa-col__list-header list-header-margin">Tests & Assessments</h3><ul class="usa-nav__submenu-list"><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/cybersecurity-risk-assessment-program-csrap"><span>Cybersecurity Risk Assessment Program (CSRAP)</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/penetration-testing-pentesting"><span>Penetration Testing</span></a></li><li class="usa-nav__submenu-item font-sans-2xs"><a class="padding-x-0" href="/learn/privacy-impact-assessment-pia"><span>Privacy Impact Assessment (PIA)</span></a></li></ul></section></div></li></ul></li></ul><div class="usa-nav__secondary padding-left-2"><section aria-label="Header search box"><form class="usa-search usa-search--small" role="search" action="/search"><label class="usa-sr-only" for="header-search-box">Search</label><input class="usa-input search__input" id="header-search-box" type="search" name="ispg[query]"/><button aria-label="header search box button" class="usa-button" id="header-search-box-btn" type="submit"><svg aria-describedby="searchIcon" class="usa-icon" aria-hidden="true" focusable="false" role="img"><title id="searchIcon">Search</title><use href="/assets/img/sprite.svg#search"></use></svg></button></form></section></div></div></nav></header><main id="main"><div id="template"><!--$--><!--/$--><section class="hero hero--theme-explainer undefined"><div class="maxw-widescreen margin-x-auto padding-x-2 desktop:padding-x-0 padding-top-4 padding-bottom-6 desktop:padding-y-7"><div class="tablet:grid-container position-relative "><div class="hero__row grid-row grid-gap"><div class="tablet:grid-col-5 widescreen:position-relative"></div><div class="hero__column tablet:grid-col-7 flow padding-bottom-2"><h1 class="hero__heading margin-0 line-height-sans-3 desktop:line-height-sans-2">Security Impact Analysis (SIA)</h1><p class="hero__description">A process to determine the effect(s) a change can cause to the security posture of a FISMA system</p><div class="hero__meta radius-lg padding-x-2 padding-y-1 bg-white font-sans-2xs line-height-sans-5 display-inline-block text-primary-darker">Contact: <span class="text-bold">ISPG Policy Team</span><span class="hidden-mobile"> | </span><span class="break-mobile"><a href="mailto:CISO@cms.hhs.gov">CISO@cms.hhs.gov</a></span></div></div><div class="tablet:position-absolute tablet:top-0"><div class="[ flow ] bg-primary-light radius-lg padding-2 text-base-darkest maxw-mobile"><div class="display-flex flex-align-center font-sans-lg margin-bottom-2 text-italic desktop:text-no-wrap"><img alt="slack logo" loading="lazy" width="21" height="21" decoding="async" data-nimg="1" class="display-inline margin-right-1" style="color:transparent" src="/_next/static/media/slackLogo.f5836093.svg"/>CMS Slack Channel</div><ul class="add-list-reset"><li class="line-height-sans-5 margin-top-0">#security_community</li></ul></div></div></div></div></div></section><div class="grid-container"><div class="grid-row grid-gap margin-top-5"><div class="tablet:grid-col-4"><nav class="table-of-contents overflow-y-auto overflow-x-hidden position-sticky top-3 padding-1 radius-lg shadow-2 display-none tablet:display-block" aria-label="Table of contents"><div class="text-uppercase text-bold border-bottom border-base-lighter padding-bottom-1">Table of Contents</div><p class="text-italic text-base font-sans-xs">No table of content entries to display.</p></nav></div><div class="tablet:grid-col-8 content"><section><div class="text-block text-block--theme-explainer"><h2>What is a Security Impact Analysis (SIA)</h2><p>A Security Impact Analysis (SIA) is an assessment that reviews how a proposed change can impact the security and privacy posture of a FISMA system. It is a mandatory process that is required for all system changes. The SIA maps directly to the <a href="/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm">CMS Acceptable Risk Safeguards (ARS) 5.0 Configuration Management (CM) Control</a>.</p><h3>Who completes the SIA</h3><p>The SIA is initiated by the Information System Security Officer (ISSO) or a designated team member if an ISSO is not available. The ISSO will work with the System/Business Owner and other relevant CMS staff and contractors to complete the SIA.</p><h2>What changes to a system require an SIA?</h2><p>There are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.</p><ul><li>Changes to existing architecture, system, network, application, security boundary, or environment</li><li>Changes made to environments below the production environment (PROD) that will eventually be implemented in PROD</li><li>New data types, or new connection to data source, system, service, or association</li><li>Software or service solutions that are new to the system; especially those that are new to CMS and have yet to be approved under any <a href="/learn/authorization-operate-ato">CMS ATO</a> or <a href="/learn/federal-risk-and-authorization-management-program-fedramp">FedRAMP</a></li></ul><p>Note: <a href="https://csrc.nist.gov/publications/detail/sp/800-128/final">NIST Special Publication 800-128 “<em>Guide for Security-Focused Configuration Management of Information Systems</em>” </a>indicates that the change management process (and by extension, Security Impact Analysis) is not required for changes that are expressly noted as being excluded in each organization’s <strong>Configuration Management Plan (CMP)</strong>. If an anticipated change has not been noted in your organization’s CMP, you will need to perform an SIA.</p><h3>Events that require a SIA</h3><p><a href="https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final">NIST Special Publication 800-37 Rev 2 “<em>Risk Management Framework for Information Systems and Organizations</em>” </a>defines a significant change as a change that is likely to affect the security or privacy posture of a system substantively. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:</p><ul><li>Installation of a new or upgraded operating system, middleware component, or application</li><li>Modifications to system ports, protocols, or services</li><li>Installation of a new or upgraded hardware platform</li><li>Modifications to how information, including PII, is processed</li><li>Modifications to cryptographic modules or services</li><li>Changes in information types processed, stored, or transmitted by the system</li><li>Modifications to security and privacy controls (e.g. identity and access management)</li><li>Significant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:</li><li>Moving to a new facility</li><li>Adding new core missions or business functions</li><li>Acquiring specific and credible threat information that the organization is being targeted by a threat source</li><li>Establishing new/modified laws, directives, policies, or regulations</li></ul><p><em>Note: The examples of changes listed above are only significant when they represent a change that is likely to affect the security and privacy posture of the system.</em></p><h2>What documentation is required?</h2><p>The depth and intensity of your SIA varies significantly depending on the scope of the proposed change. Consider your SIA as a holistic process that will benefit the security of your system over time rather than a compliance exercise you must complete to move forward.<br><br>Your SIA may require limited documentation or it may be a detailed process that results in security testing, scans, and data reviews. Sometimes, information that surfaces about a system change during the SIA process can result in other documents and tests needing to be updated. This is part of the process required to keep your system secure.<br><br>Regardless of the significance of the change to a system, the analysis and outcomes must be documented. You can choose to utilize the <a href="https://security.cms.gov/learn/security-impact-analysis-sia#security-impact-analysis-sia-template">Security Impact Analysis (SIA) Template</a>for this purpose, or you can use a custom template that has been created for your system's specific needs. If you choose to use the generic CMS SIA Template, you will find it at the end of this page and will need to complete four sections:</p><h3>Change information</h3><p>A brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.</p><h3>Technical representative information</h3><p>The contact information for the ISSO or responsible party managing the system. The ISSO is the individual responsible for the completion of all actions related to the SIA even if a designated representative completes the paperwork on their behalf.</p><h3>Trigger actions and events evaluation</h3><p>An extensive list of “Trigger Events”. This section is the heart of the assessment. You will be prompted to answer a number of “yes or no” questions related to the change. To complete this section, you’ll need to review:</p><ul><li>The scope of the change</li><li>The necessary updates or mitigation efforts</li><li>The ARS controls impacted by the change</li></ul><p>If the change you’re proposing is related to the installation of an application or tool that has been pre-approved by FedRAMP on cloud.cms.gov, much of this information will be provided for you there. You’ll often find much of this information on the website of the company that created the application. For further help in determining system risk for new applications, you can always reach out to your Cyber Risk Advisor (CRA) for guidance.</p><h3>Recommendations for Business Owners</h3><p>This final section provides a detailed list of the results of the SIA and recommendations from the ISSO to the System/Business Owner. SIA documentation may serve as a “to-do” list for ISSOs and System/Business Owners to make sure that documentation is updated appropriately, tests performed for identified controls, etc. It may also help justify further testing and potentially expensive processes to the Business Owner.</p><h2>SIA outcomes</h2><p>The SIA and associated documentation may highlight the need for future actions including:</p><ul><li>Communication with the <strong>Technical Review Board (TRB)</strong></li><li>Updates to security artifacts like the <a href="/learn/system-security-and-privacy-plan-sspp">System Security and PrivacyPlan (SSPP)</a>, <a href="/learn/cms-information-system-risk-assessment-isra">Information Security Risk Assessment (ISRA)</a>, <a href="/learn/contingency-plan">Contingency Plan (CP)</a>, <a href="/learn/privacy-impact-assessment-pia">Privacy Impact Assessment (PIA)</a>, among others</li><li>Determination if third party security testing will be required</li><li>The potential requirement for a new <a href="/learn/authorization-operate-ato">Authority to Operate (ATO)</a></li></ul><p>SIA documentation, if properly tailored, is also particularly useful for a DevSecOps environment where multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing documentation to quickly make any updates necessary.</p><h2>Security Impact Analysis (SIA) Template</h2><h3>SIA Template Instructions</h3><p><em>This template provides a suggested methodology to help ISSOs assess the potential security impact of a change or changes to FISMA systems.Individual ISSOs may find it necessary to alter the template to meet their organizational needs.Workflow associated with this template is also dependent on organizational requirements.</em></p><p>This template consists of four sections.They are:</p><p><strong>Section 1</strong> – An overview of the proposed change.If this document is maintained for record keeping/compliance, the completion of this section will make identification easier in the future.</p><p><strong>Section 2</strong> – Information on who is performing the SIA if a technical representative of the ISSO is performing the assessment on behalf of the ISSO.If a technical representative of the ISSO has performed this assessment, they will forward it to the ISSO for discussion and review.It remains the ISSO’s responsibility to complete all appropriate actions.</p><p><strong>Section 3</strong> – An extensive list of “Trigger Events”, most of which are a decomposition of the boxes checked in Section 2. This section is the heart of the assessment.To complete this section:</p><ol><li>The assessor examines each event under “Scope of Change” (column 2).</li><li>If an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).</li></ol><p>At this point, an elaboration of the events noted is included in the section “Summary of Security Impact/ Technical Overview/ Risks Identified<strong>”.</strong>This includes detailing the technical overview of the item and a description of the potential impact and risk.Where other data associated with the change is available such as scan information, references should also be included in this area.</p><p><strong>Section 4</strong> – The ISSO recommendation to the Business Owner on the overall status of the change and what actions are necessary.This section should function as a high-level summarization of the necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”.</p><p><em>Note that the “Mitigation or Necessary Updates” area within Section 3 provides recommended actions.Actions may individually or as a group indicate the requirement for a new ATO.At this point, the ISSO may choose to consult with their Cyber Risk Advisor or Privacy Advisor prior to providing the recommendation of activities to the Business Owner and System Maintainer.</em></p><p>Though every change requires a SIA, <strong>organizations may utilize their own internal methods or processes that can automate or streamline the security analysis rather than using a formal SIA form</strong>.</p><p>These types of changes may include processes for configuration control such as vendor-provided security patches, updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals, motherboard or hard drives, etc.Processes associated with similar functions, may have built-in security components or controls that may not require a formal SIA form.Any of these processes -- whether automated or manual -- must capture the elements needed to properly analyze the security impacts of the particular change. The ISSO may at any time require a formal SIA for any change.</p><p>The SIA document, when completed and shared with the Business Owner, can be used as a checklist to make sure that any work such as documentation changes are performed.</p><p><strong>To create your SIA document, start with the following for a title:</strong></p><p><strong><FISMA SYSTEM NAME> < PRODUCT/FEATURE NAME> <DATE OF RELEASE TO PROD></strong></p><h4>Section 1: Change Information</h4><table><thead><tr><th> </th><th>Add information in this column</th></tr></thead><tbody><tr><td>CR Number</td><td> </td></tr><tr><td>CR Submitter (Contact Information)</td><td> </td></tr><tr><td>System/Application/Tool</td><td> </td></tr><tr><td>Description of System Change<br>(Detailed description that includes the Drivers for the change)</td><td><p> </p><p> </p><p> </p></td></tr></tbody></table><h4>Section 2: Technical Representative Information</h4><p>If a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information.</p><table><thead><tr><th> </th><th>Add information in this column</th></tr></thead><tbody><tr><td>Representative performing the SIA</td><td> </td></tr><tr><td>Title of Representative performing the SIA</td><td> </td></tr><tr><td>Date</td><td> </td></tr><tr><td>Phone</td><td> </td></tr><tr><td>Email</td><td> </td></tr></tbody></table><h4>Section 3: Trigger Actions and Events Evaluation</h4><p><strong>Directions:</strong> Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-inclusive.Note: this list is not all-inclusive.</p><table><thead><tr><th><strong>Impact? (Y/N)</strong></th><th><strong>Category</strong></th><th><strong>Scope of Change</strong></th><th><strong>Mitigation or Necessary Updates</strong></th><th><strong>ARS Controls Impacted</strong></th><th><strong>Summary of Security Impact/ Technical Overview/ Risks Identified</strong></th></tr></thead><tbody><tr><td> </td><td>Mission/ Business requirements</td><td>New Users or<br>New User Roles Added</td><td><p>ISRA updates, potential PIA update, CFACTS system description updates.</p><p> </p></td><td><strong>AC-2, AC-6</strong></td><td> </td></tr><tr><td> </td><td>Mission/ Business requirements</td><td>Change in data collection, storage, sharing</td><td><p>PIA update.</p><p>Potential SORN updates.</p><p> </p></td><td><strong>AC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1</strong></td><td> </td></tr><tr><td> </td><td><p>Mission/</p><p>Business requirements</p></td><td>Cessation of mission or function.</td><td>Potential update to SSP, CFACTS system description updates.</td><td><strong>Potential impact to multiple controls depending on nature of mission/function.</strong></td><td> </td></tr><tr><td> </td><td><p>Policy/</p><p>Standards</p></td><td><p>New revisions of ARS and CMS policy; or Issue or Update of NIST documents</p><p> </p></td><td>Updates to FISMA artifacts including SSP.</td><td><p><strong>Potential impact to multiple controls depending on nature of the policy/</strong></p><p><strong>standards.</strong></p></td><td> </td></tr><tr><td> </td><td>Laws, Regulations, Directives</td><td>New or Changed</td><td>Updates to FISMA artifacts including SSP.</td><td><strong>Potential impact to multiple controls depending on nature of laws, regulations, directives.</strong></td><td> </td></tr><tr><td> </td><td>System boundary</td><td>Interconnections and New connection to FISMA system or Service</td><td><p>Updates to ISA and MOU must occur. If not standard connection service/inheritance from another accredited FISMA system, SCA will be required.</p><p> </p><p>Updates to FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc</p></td><td><strong>AC-4, CA-3, CA-9, PL-2, AC-3, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4</strong></td><td> </td></tr><tr><td> </td><td>System boundary</td><td>Architecture, Topology, Port/Protocol/Service change</td><td><p>Zone changes</p><p>Implementation or inheritance of new services</p><p>Updates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc</p></td><td><strong>CM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7</strong></td><td> </td></tr><tr><td> </td><td>Security components</td><td><p>Identification, Authentication, Authorization</p><p> </p><p>New methods for authentication and/or identifiers added</p><p> </p><p>Migrations between Single Factor and MFA</p></td><td><p>New and modified control implementations must be tested. SCA required unless inheriting from existing FISMA system.</p><p> </p><p>Updates to all FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc</p></td><td><strong>IA (all)</strong></td><td> </td></tr><tr><td> </td><td>Security Components</td><td>Security Controls – Change in implementation standard or status</td><td>New and modified control implementations must be tested via existing security processes. All changes must be documented within the SSP and the Controls tab within CFACTS. Changes in controls that cause controls to no longer be “Satisfied” must be submitted as a POA&M and documented within the ISRA.</td><td><p><strong>List specific controls changed</strong></p><p> </p><p><strong>PL-2 (SSP)</strong></p></td><td> </td></tr><tr><td> </td><td>User Interface</td><td>Updates to GUI including addition of new pages, new inputs</td><td>New pages must go through 508 testing, Static and Dynamic code analysis to determine no additional threats from XSS or other new vulnerabilities.</td><td><p><strong>CM-2, CM-3, CM-4</strong></p><p> </p><p><strong>SI-10</strong></p></td><td> </td></tr><tr><td> </td><td>New or Updated Hardware</td><td>Servers, Communication Devices</td><td>If the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them.</td><td><p><strong>CM-2, CM-3, CM-4, CM-6, CM-7</strong></p><p> </p><p><strong>PL-2 (SSP)</strong></p><p> </p><p><strong>HW/SW List</strong></p><p> </p><p><strong>AC-19, SI-4</strong></p><p> </p><p><strong>CP-2</strong></p></td><td> </td></tr><tr><td> </td><td>New or Updated Operating System</td><td>Change in Operating System</td><td>If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.</td><td><p><strong>CM-2, CM-3, CM-4, CM-6, CM-7</strong></p><p> </p><p><strong>RA-5 Vulnerability Scanning</strong></p><p> </p><p><strong>CA-9(1) Compliance Checks</strong></p><p> </p><p><strong>PL-2 (SSP)</strong></p><p> </p><p><strong>HW/SW List</strong></p><p> </p><p><strong>CP-2</strong></p></td><td> </td></tr><tr><td> </td><td>New or Updated Security Software</td><td>New Security Software or Perimeter Security Change</td><td>If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.</td><td><p><strong>CM-2, CM-3, CM-4, CM-6, CM-7</strong></p><p> </p><p><strong>RA-5 Vulnerability Scanning</strong></p><p> </p><p><strong>CA-9(1) Compliance Checks</strong></p><p> </p><p><strong>PL-2 (SSP)</strong></p><p> </p><p><strong>HW/SW List</strong></p><p> </p><p> </p><p><strong>Potential impact to multiple controls depending on nature of software</strong></p></td><td> </td></tr><tr><td> </td><td>Support Software</td><td><p>New Support Software</p><p> </p></td><td>If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.</td><td><p><strong>CM-2, CM-3, CM-4, CM-6, CM-7</strong></p><p><strong>RA-5</strong></p><p> </p><p><strong>PL-2 (SSP)</strong></p><p> </p><p><strong>HW/SW List</strong></p><p> </p><p><strong>Potential TRB review/approval</strong></p></td><td> </td></tr><tr><td> </td><td>Vendor Patches</td><td>Software, Servers</td><td>Software patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.</td><td><p><strong>CM-2, CM-3, CM-4</strong></p><p> </p><p><strong>PL-2 (SSP)</strong></p><p> </p><p><strong>HW/SW List</strong></p></td><td><p> </p><p> </p><p> </p></td></tr><tr><td> </td><td>System Boundary</td><td>Change to Logical Access Points</td><td>Vulnerability Scan is required</td><td><p><strong>AC-17, AC-2, AC-3, AC-18, AC-19, AC-20,</strong></p><p> </p><p><strong>CA-3, CA-7,</strong></p><p> </p><p><strong>CM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4</strong></p></td><td> </td></tr><tr><td> </td><td>Vulnerability (New or Existing)</td><td>Attacks Developed</td><td>Risk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.</td><td><strong>RA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11</strong></td><td> </td></tr><tr><td> </td><td>Vulnerability (New or Existing)</td><td>Attacks Succeed Elsewhere</td><td>Risk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.</td><td><strong>RA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11</strong></td><td> </td></tr><tr><td> </td><td>Vulnerability (New or Existing)</td><td>Found (No Attacks Known)</td><td>Add to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.</td><td><strong>RA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11</strong></td><td> </td></tr><tr><td> </td><td>System boundary</td><td>New processing location(s)</td><td>A new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks</td><td><p><strong>PE(family)</strong></p><p> </p><p><strong>CM-2, CM-3, CM-4, CM-6, CM-7</strong></p></td><td> </td></tr><tr><td> </td><td>System boundary (environment)</td><td>Change or Addition of Hosting Infrastructure or Site</td><td>Full authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO.</td><td><p><strong>PE(family)</strong></p><p> </p><p><strong>CM-2, CM-3, CM-4, CM-6, CM-7</strong></p></td><td> </td></tr></tbody></table><h4>Section 3: Validation/Security Testing</h4><p>Please provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.</p><table><thead><tr><th><strong>Tool/Scan Type</strong></th><th>(Y/N)</th><th><strong>Testing Performed by</strong></th><th><strong>Testing /Method</strong></th><th><strong>Testing Frequency</strong></th><th><strong>Test Result Location</strong></th><th><strong>Notes</strong></th></tr></thead><tbody><tr><td>Compliance Scans</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td>Vulnerability Scans</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td>Dynamic WAPT Testing</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td>Static WPT Testing</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td>Optional</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td>Optional</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr></tbody></table><h4>Section 4: Overall Recommendation for Business Owners</h4><p>Using the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on the status of the change.</p><p><strong>ISSO recommendation(s):</strong></p><p><em>ISSO should indicate which of the following are recommended, and provide details using additional pages.</em></p><ul><li>Deploy to Production Environment without additional testing</li><li>Undergo Targeted Third Party Security Testing</li><li>Undergo SCA/CSRAP</li><li>Require Business Owner Risk Acceptance to field to Production</li><li>Apply for a new ATO</li><li>Other (e.g. update documentation. Specify on following page)</li></ul><p> </p><p><strong>Signed by:</strong></p><p> </p><p>_____________________________________________</p><p>System ISSO</p><p> </p><p>_____________________________________________</p><p>Business Owner</p></div></section></div></div></div><div class="cg-cards grid-container"><h2 class="cg-cards__heading" id="related-documents-and-resources">Related documents and resources</h2><ul aria-label="cards" class="usa-card-group"><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/learn/fedramp">Federal Risk and Authorization Management Program (FedRAMP)</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>Provides a federally-recognized and standardized security framework for all cloud products and services</p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/learn/authorization-operate-ato">Authorization to Operate (ATO)</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>Testing and documenting system security and compliance to gain approval to operate the system at CMS</p></div></div></li><li class="usa-card grid-col-12 tablet:grid-col-4"><div class="usa-card__container "><div class="usa-card__header"><h3 class="margin-top-1 line-height-sans-2 text-bold text-base-darkest"><a class="usa-card__link text-no-underline" href="/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm">Risk Management Handbook Chapter 5: Configuration Management (CM)</a></h3></div><div class="usa-card__body font-sans-2xs line-height-sans-4 text-base-darkest"><p>RMH Chapter 5 provides information about the Configuration Management family of controls which determine the risk management requirements for CMS systems</p></div></div></li></ul></div></div></main><footer class="usa-footer usa-footer--slim"><div class="grid-container"><div class="grid-row flex-align-end"><div class="grid-col"><div class="usa-footer__return-to-top"><a class="font-sans-xs" href="#">Return to top</a></div></div><div class="grid-col padding-bottom-2 padding-top-4 display-flex flex-justify-end"><a class="usa-button" href="/feedback">Give feedback</a></div></div></div><div class="usa-footer__primary-section"><div class="usa-footer__primary-container grid-row"><div class="tablet:grid-col-3"><a class="usa-footer__primary-link" href="/"><img alt="CyberGeek logo" loading="lazy" width="142" height="26" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/CyberGeek-logo.8e9bbd2b.svg"/></a><p class="usa-footer__logo-heading display-none tablet-lg:display-block">The official website of the CMS Information Security and Privacy Group (ISPG)</p></div><div class="tablet:grid-col-12 tablet-lg:grid-col-9"><nav class="usa-footer__nav" aria-label="Footer navigation,"><ul class="grid-row grid-gap"><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="/learn/about-ispg-cybergeek">What is CyberGeek?</a></li><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="https://www.cms.gov/privacy">Privacy policy</a></li><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="https://www.cms.gov/about-cms/information-systems/privacy/vulnerability-disclosure-policy">CMS Vulnerability Disclosure Policy</a></li><li class=" tablet:grid-col-3 desktop:grid-col-auto usa-footer__primary-content "><a class="usa-footer__primary-link" href="https://www.cms.gov/About-CMS/Agency-Information/Aboutwebsite/Policiesforaccessibility">Accessibility</a></li></ul></nav></div></div></div><div class="usa-footer__secondary-section"><div class="grid-container"><div class="usa-footer__logo grid-row grid-gap-2"><div class="mobile-lg:grid-col-3"><a href="https://www.cms.gov/"><img alt="CMS homepage" loading="lazy" width="124" height="29" decoding="async" data-nimg="1" style="color:transparent" src="/_next/static/media/cmsLogo.10a64ce4.svg"/></a></div><div class="mobile-lg:grid-col-7"><p class="font-sans-3xs line-height-sans-3">A federal government website managed and paid for by the U.S. Centers for Medicare & Medicaid Services.</p><address class="font-sans-3xs line-height-sans-3">7500 Security Boulevard, Baltimore, MD 21244</address></div></div></div></div></footer><script>(self.__next_s=self.__next_s||[]).push(["/assets/javascript/uswds.min.js",{}])</script><script src="/_next/static/chunks/webpack-182b67d00f496f9d.js" async=""></script><script>(self.__next_f=self.__next_f||[]).push([0]);self.__next_f.push([2,null])</script><script>self.__next_f.push([1,"1:HL[\"/_next/static/css/ef46db3751d8e999.css\",\"style\"]\n2:HL[\"/_next/static/css/0759e90f4fecfde7.css\",\"style\"]\n"])</script><script>self.__next_f.push([1,"3:I[5751,[],\"\"]\n6:I[9275,[],\"\"]\n8:I[1343,[],\"\"]\nb:I[6130,[],\"\"]\n7:[\"slug\",\"security-impact-analysis-sia\",\"d\"]\nc:[]\n0:[\"$\",\"$L3\",null,{\"buildId\":\"m9SaS4P6zugJbBHpXSk5Y\",\"assetPrefix\":\"\",\"urlParts\":[\"\",\"learn\",\"security-impact-analysis-sia\"],\"initialTree\":[\"\",{\"children\":[\"learn\",{\"children\":[[\"slug\",\"security-impact-analysis-sia\",\"d\"],{\"children\":[\"__PAGE__\",{}]}]}]},\"$undefined\",\"$undefined\",true],\"initialSeedData\":[\"\",{\"children\":[\"learn\",{\"children\":[[\"slug\",\"security-impact-analysis-sia\",\"d\"],{\"children\":[\"__PAGE__\",{},[[\"$L4\",\"$L5\",null],null],null]},[null,[\"$\",\"$L6\",null,{\"parallelRouterKey\":\"children\",\"segmentPath\":[\"children\",\"learn\",\"children\",\"$7\",\"children\"],\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L8\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"notFoundStyles\":\"$undefined\"}]],null]},[null,[\"$\",\"$L6\",null,{\"parallelRouterKey\":\"children\",\"segmentPath\":[\"children\",\"learn\",\"children\"],\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L8\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"notFoundStyles\":\"$undefined\"}]],null]},[[[[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/ef46db3751d8e999.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\"}],[\"$\",\"link\",\"1\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/css/0759e90f4fecfde7.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\"}]],\"$L9\"],null],null],\"couldBeIntercepted\":false,\"initialHead\":[null,\"$La\"],\"globalErrorComponent\":\"$b\",\"missingSlots\":\"$Wc\"}]\n"])</script><script>self.__next_f.push([1,"d:I[4080,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"\"]\ne:I[8173,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"931\",\"static/chunks/app/page-cc829e051925e906.js\"],\"Image\"]\nf:I[7529,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"default\"]\n11:I[231,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"931\",\"static/chunks/app/page-cc829e051925e906.js\"],\"\"]\n12:I[7303,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"default\"]\n13:I[8521,[\"489\",\"static/chunks/app/template-d264bab5e3061841.js\"],\"default\"]\n14:I[5922,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"931\",\"static/chunks/app/page-cc829e051925e906.js\"],\"default\"]\n15:I[7182,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"default\"]\n16:I[4180,[\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"223\",\"static/chunks/223-bc9ed43510898bbb.js\",\"185\",\"static/chunks/app/layout-9fc24027bc047aa2.js\"],\"TealiumTagManager\"]\n10:Tdced,"])</script><script>self.__next_f.push([1,"{\"id\":\"mega-menu\",\"linkset\":{\"elements\":[{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Roles\",\"hierarchy\":[\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/information-system-security-officer-isso\",\"attributes\":{\"title\":\"Information System Security Officer (ISSO)\",\"hierarchy\":[\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"attributes\":{\"title\":\"ISSO Handbook\",\"hierarchy\":[\"0\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos\",\"attributes\":{\"title\":\"Getting started (for new ISSOs)\",\"hierarchy\":[\"0\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-mentorship-program\",\"attributes\":{\"title\":\"ISSO Mentorship Program\",\"hierarchy\":[\"0\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#training\",\"attributes\":{\"title\":\"ISSO Training\",\"hierarchy\":[\"0\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/data-guardian\",\"attributes\":{\"title\":\"Data Guardian\",\"hierarchy\":[\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/data-guardian-handbook\",\"attributes\":{\"title\":\"Data Guardian Handbook\",\"hierarchy\":[\"0\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cyber-risk-advisor-cra\",\"attributes\":{\"title\":\"Cyber Risk Advisor (CRA)\",\"hierarchy\":[\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"0\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\",\"attributes\":{\"title\":\"Risk Management Handbook (RMH)\",\"hierarchy\":[\"0\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/business-system-owner\",\"attributes\":{\"title\":\"Business / System Owner (BO/SO)\",\"hierarchy\":[\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"0\",\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"0\",\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"0\",\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"0\",\"3\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Compliance \u0026 Authorization\",\"hierarchy\":[\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"Authorization to Operate (ATO)\",\"hierarchy\":[\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"About ATO at CMS\",\"hierarchy\":[\"1\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#types-of-authorizations\",\"attributes\":{\"title\":\"Types of authorizations\",\"hierarchy\":[\"1\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#ato-stakeholders\",\"attributes\":{\"title\":\"ATO stakeholders\",\"hierarchy\":[\"1\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#related-documents-and-resources\",\"attributes\":{\"title\":\"ATO tools and resources\",\"hierarchy\":[\"1\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-technical-reference-architecture-tra\",\"attributes\":{\"title\":\"CMS Technical Reference Architecture (TRA)\",\"hierarchy\":[\"1\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"Ongoing Authorization (OA)\",\"hierarchy\":[\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"About OA at CMS\",\"hierarchy\":[\"1\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa\",\"attributes\":{\"title\":\"OA eligibility requirements\",\"hierarchy\":[\"1\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"1\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Assessments \u0026 Audits\",\"hierarchy\":[\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"1\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"1\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"1\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/security-impact-analysis-sia\",\"attributes\":{\"title\":\"Security Impact Analysis (SIA)\",\"hierarchy\":[\"1\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-audits\",\"attributes\":{\"title\":\"System Audits\",\"hierarchy\":[\"1\",\"2\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Policy \u0026 Guidance\",\"hierarchy\":[\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cms-policies-and-guidance\",\"attributes\":{\"title\":\"CMS Policies and Guidance\",\"hierarchy\":[\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\",\"attributes\":{\"title\":\"CMS Acceptable Risk Safeguards (ARS)\",\"hierarchy\":[\"2\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\",\"attributes\":{\"title\":\"CMS Information Security and Privacy Policy (IS2P2)\",\"hierarchy\":[\"2\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"2\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-risk-management-framework-rmf\",\"attributes\":{\"title\":\"CMS Risk Management Framework (RMF)\",\"hierarchy\":[\"2\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/email-encryption-requirements-cms\",\"attributes\":{\"title\":\"CMS Email Encryption\",\"hierarchy\":[\"2\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/federal-policies-and-guidance\",\"attributes\":{\"title\":\"Federal Policies and Guidance\",\"hierarchy\":[\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/national-institute-standards-and-technology-nist\",\"attributes\":{\"title\":\"National Institute of Standards and Technology (NIST)\",\"hierarchy\":[\"2\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/federal-information-security-modernization-act-fisma\",\"attributes\":{\"title\":\"Federal Information Security Modernization Act (FISMA)\",\"hierarchy\":[\"2\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/fedramp\",\"attributes\":{\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"hierarchy\":[\"2\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"2\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/application-security\",\"attributes\":{\"title\":\"Application Security\",\"hierarchy\":[\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"3\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"3\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"3\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/software-bill-materials-sbom\",\"attributes\":{\"title\":\"Software Bill of Materials (SBOM)\",\"hierarchy\":[\"3\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/security-operations\",\"attributes\":{\"title\":\"Security Operations\",\"hierarchy\":[\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\",\"attributes\":{\"title\":\"Incident Response\",\"hierarchy\":[\"3\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"3\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"3\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/risk-management-and-reporting\",\"attributes\":{\"title\":\"Risk Management and Reporting\",\"hierarchy\":[\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"3\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports\",\"hierarchy\":[\"3\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/plan-action-and-milestones-poam\",\"attributes\":{\"title\":\"Plan of Action and Milestones (POA\u0026M)\",\"hierarchy\":[\"3\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy\",\"hierarchy\":[\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Agreements\",\"hierarchy\":[\"4\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"4\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"4\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Activities\",\"hierarchy\":[\"4\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/breach-response\",\"attributes\":{\"title\":\"Breach Response\",\"hierarchy\":[\"4\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"4\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-records-notice-sorn\",\"attributes\":{\"title\":\"System of Records Notice (SORN)\",\"hierarchy\":[\"4\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Resources\",\"hierarchy\":[\"4\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/privacy\",\"attributes\":{\"title\":\"Privacy at CMS\",\"hierarchy\":[\"4\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-breach-response-handbook\",\"attributes\":{\"title\":\"CMS Breach Response Handbook\",\"hierarchy\":[\"4\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/health-insurance-portability-and-accountability-act-1996-hipaa\",\"attributes\":{\"title\":\"Health Insurance Portability and Accessibility Act (HIPAA)\",\"hierarchy\":[\"4\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"attributes\":{\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"hierarchy\":[\"4\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tools \u0026 Services\",\"hierarchy\":[\"5\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Reporting \u0026 Compliance\",\"hierarchy\":[\"5\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"5\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-fisma-continuous-tracking-system-cfacts\",\"attributes\":{\"title\":\"CFACTS\",\"hierarchy\":[\"5\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports and Dashboards\",\"hierarchy\":[\"5\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"5\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"5\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"5\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"5\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"5\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-security-data-lake-sdl\",\"attributes\":{\"title\":\"CMS Security Data Lake (SDL)\",\"hierarchy\":[\"5\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tests \u0026 Assessments\",\"hierarchy\":[\"5\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"5\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"5\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"5\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}}],\"size\":87},\"elements\":[{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Roles\",\"hierarchy\":[\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/information-system-security-officer-isso\",\"attributes\":{\"title\":\"Information System Security Officer (ISSO)\",\"hierarchy\":[\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"attributes\":{\"title\":\"ISSO Handbook\",\"hierarchy\":[\"0\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos\",\"attributes\":{\"title\":\"Getting started (for new ISSOs)\",\"hierarchy\":[\"0\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-mentorship-program\",\"attributes\":{\"title\":\"ISSO Mentorship Program\",\"hierarchy\":[\"0\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#training\",\"attributes\":{\"title\":\"ISSO Training\",\"hierarchy\":[\"0\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/data-guardian\",\"attributes\":{\"title\":\"Data Guardian\",\"hierarchy\":[\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/data-guardian-handbook\",\"attributes\":{\"title\":\"Data Guardian Handbook\",\"hierarchy\":[\"0\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cyber-risk-advisor-cra\",\"attributes\":{\"title\":\"Cyber Risk Advisor (CRA)\",\"hierarchy\":[\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"0\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\",\"attributes\":{\"title\":\"Risk Management Handbook (RMH)\",\"hierarchy\":[\"0\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/business-system-owner\",\"attributes\":{\"title\":\"Business / System Owner (BO/SO)\",\"hierarchy\":[\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"0\",\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"0\",\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"0\",\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"0\",\"3\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Compliance \u0026 Authorization\",\"hierarchy\":[\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"Authorization to Operate (ATO)\",\"hierarchy\":[\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"About ATO at CMS\",\"hierarchy\":[\"1\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#types-of-authorizations\",\"attributes\":{\"title\":\"Types of authorizations\",\"hierarchy\":[\"1\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#ato-stakeholders\",\"attributes\":{\"title\":\"ATO stakeholders\",\"hierarchy\":[\"1\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#related-documents-and-resources\",\"attributes\":{\"title\":\"ATO tools and resources\",\"hierarchy\":[\"1\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-technical-reference-architecture-tra\",\"attributes\":{\"title\":\"CMS Technical Reference Architecture (TRA)\",\"hierarchy\":[\"1\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"Ongoing Authorization (OA)\",\"hierarchy\":[\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"About OA at CMS\",\"hierarchy\":[\"1\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa\",\"attributes\":{\"title\":\"OA eligibility requirements\",\"hierarchy\":[\"1\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"1\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Assessments \u0026 Audits\",\"hierarchy\":[\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"1\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"1\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"1\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/security-impact-analysis-sia\",\"attributes\":{\"title\":\"Security Impact Analysis (SIA)\",\"hierarchy\":[\"1\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-audits\",\"attributes\":{\"title\":\"System Audits\",\"hierarchy\":[\"1\",\"2\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Policy \u0026 Guidance\",\"hierarchy\":[\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cms-policies-and-guidance\",\"attributes\":{\"title\":\"CMS Policies and Guidance\",\"hierarchy\":[\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\",\"attributes\":{\"title\":\"CMS Acceptable Risk Safeguards (ARS)\",\"hierarchy\":[\"2\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\",\"attributes\":{\"title\":\"CMS Information Security and Privacy Policy (IS2P2)\",\"hierarchy\":[\"2\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"2\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-risk-management-framework-rmf\",\"attributes\":{\"title\":\"CMS Risk Management Framework (RMF)\",\"hierarchy\":[\"2\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/email-encryption-requirements-cms\",\"attributes\":{\"title\":\"CMS Email Encryption\",\"hierarchy\":[\"2\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/federal-policies-and-guidance\",\"attributes\":{\"title\":\"Federal Policies and Guidance\",\"hierarchy\":[\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/national-institute-standards-and-technology-nist\",\"attributes\":{\"title\":\"National Institute of Standards and Technology (NIST)\",\"hierarchy\":[\"2\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/federal-information-security-modernization-act-fisma\",\"attributes\":{\"title\":\"Federal Information Security Modernization Act (FISMA)\",\"hierarchy\":[\"2\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/fedramp\",\"attributes\":{\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"hierarchy\":[\"2\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"2\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/application-security\",\"attributes\":{\"title\":\"Application Security\",\"hierarchy\":[\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"3\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"3\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"3\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/software-bill-materials-sbom\",\"attributes\":{\"title\":\"Software Bill of Materials (SBOM)\",\"hierarchy\":[\"3\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/security-operations\",\"attributes\":{\"title\":\"Security Operations\",\"hierarchy\":[\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\",\"attributes\":{\"title\":\"Incident Response\",\"hierarchy\":[\"3\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"3\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"3\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/risk-management-and-reporting\",\"attributes\":{\"title\":\"Risk Management and Reporting\",\"hierarchy\":[\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"3\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports\",\"hierarchy\":[\"3\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/plan-action-and-milestones-poam\",\"attributes\":{\"title\":\"Plan of Action and Milestones (POA\u0026M)\",\"hierarchy\":[\"3\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy\",\"hierarchy\":[\"4\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Agreements\",\"hierarchy\":[\"4\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"4\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"4\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Activities\",\"hierarchy\":[\"4\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/breach-response\",\"attributes\":{\"title\":\"Breach Response\",\"hierarchy\":[\"4\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"4\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-records-notice-sorn\",\"attributes\":{\"title\":\"System of Records Notice (SORN)\",\"hierarchy\":[\"4\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Resources\",\"hierarchy\":[\"4\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/privacy\",\"attributes\":{\"title\":\"Privacy at CMS\",\"hierarchy\":[\"4\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-breach-response-handbook\",\"attributes\":{\"title\":\"CMS Breach Response Handbook\",\"hierarchy\":[\"4\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/health-insurance-portability-and-accountability-act-1996-hipaa\",\"attributes\":{\"title\":\"Health Insurance Portability and Accessibility Act (HIPAA)\",\"hierarchy\":[\"4\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"attributes\":{\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"hierarchy\":[\"4\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tools \u0026 Services\",\"hierarchy\":[\"5\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Reporting \u0026 Compliance\",\"hierarchy\":[\"5\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"5\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-fisma-continuous-tracking-system-cfacts\",\"attributes\":{\"title\":\"CFACTS\",\"hierarchy\":[\"5\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports and Dashboards\",\"hierarchy\":[\"5\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"5\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"5\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"5\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"5\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"5\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-security-data-lake-sdl\",\"attributes\":{\"title\":\"CMS Security Data Lake (SDL)\",\"hierarchy\":[\"5\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tests \u0026 Assessments\",\"hierarchy\":[\"5\",\"2\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"5\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"5\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"5\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}}],\"size\":87,\"tree\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Roles\",\"hierarchy\":[\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/information-system-security-officer-isso\",\"attributes\":{\"title\":\"Information System Security Officer (ISSO)\",\"hierarchy\":[\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook\",\"attributes\":{\"title\":\"ISSO Handbook\",\"hierarchy\":[\"0\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#getting-started-for-new-issos\",\"attributes\":{\"title\":\"Getting started (for new ISSOs)\",\"hierarchy\":[\"0\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-mentorship-program\",\"attributes\":{\"title\":\"ISSO Mentorship Program\",\"hierarchy\":[\"0\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-system-security-officer-isso-handbook#training\",\"attributes\":{\"title\":\"ISSO Training\",\"hierarchy\":[\"0\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/data-guardian\",\"attributes\":{\"title\":\"Data Guardian\",\"hierarchy\":[\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/data-guardian-handbook\",\"attributes\":{\"title\":\"Data Guardian Handbook\",\"hierarchy\":[\"0\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cyber-risk-advisor-cra\",\"attributes\":{\"title\":\"Cyber Risk Advisor (CRA)\",\"hierarchy\":[\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"0\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks#risk-management-handbook-rmh-chapters\",\"attributes\":{\"title\":\"Risk Management Handbook (RMH)\",\"hierarchy\":[\"0\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/business-system-owner\",\"attributes\":{\"title\":\"Business / System Owner (BO/SO)\",\"hierarchy\":[\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity and Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"0\",\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"0\",\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"0\",\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"0\",\"3\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Compliance \u0026 Authorization\",\"hierarchy\":[\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"Authorization to Operate (ATO)\",\"hierarchy\":[\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato\",\"attributes\":{\"title\":\"About ATO at CMS\",\"hierarchy\":[\"1\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#types-of-authorizations\",\"attributes\":{\"title\":\"Types of authorizations\",\"hierarchy\":[\"1\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#ato-stakeholders\",\"attributes\":{\"title\":\"ATO stakeholders\",\"hierarchy\":[\"1\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/authorization-operate-ato#related-documents-and-resources\",\"attributes\":{\"title\":\"ATO tools and resources\",\"hierarchy\":[\"1\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-technical-reference-architecture-tra\",\"attributes\":{\"title\":\"CMS Technical Reference Architecture (TRA)\",\"hierarchy\":[\"1\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"Ongoing Authorization (OA)\",\"hierarchy\":[\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa\",\"attributes\":{\"title\":\"About OA at CMS\",\"hierarchy\":[\"1\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/ongoing-authorization-oa#is-my-system-eligible-for-oa\",\"attributes\":{\"title\":\"OA eligibility requirements\",\"hierarchy\":[\"1\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"1\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Assessments \u0026 Audits\",\"hierarchy\":[\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"1\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"1\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"1\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/security-impact-analysis-sia\",\"attributes\":{\"title\":\"Security Impact Analysis (SIA)\",\"hierarchy\":[\"1\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-audits\",\"attributes\":{\"title\":\"System Audits\",\"hierarchy\":[\"1\",\"2\",\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Policy \u0026 Guidance\",\"hierarchy\":[\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/cms-policies-and-guidance\",\"attributes\":{\"title\":\"CMS Policies and Guidance\",\"hierarchy\":[\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\",\"attributes\":{\"title\":\"CMS Acceptable Risk Safeguards (ARS)\",\"hierarchy\":[\"2\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\",\"attributes\":{\"title\":\"CMS Information Security and Privacy Policy (IS2P2)\",\"hierarchy\":[\"2\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-security-and-privacy-handbooks\",\"attributes\":{\"title\":\"CMS Security and Privacy Handbooks\",\"hierarchy\":[\"2\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-risk-management-framework-rmf\",\"attributes\":{\"title\":\"CMS Risk Management Framework (RMF)\",\"hierarchy\":[\"2\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/email-encryption-requirements-cms\",\"attributes\":{\"title\":\"CMS Email Encryption\",\"hierarchy\":[\"2\",\"0\",\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/federal-policies-and-guidance\",\"attributes\":{\"title\":\"Federal Policies and Guidance\",\"hierarchy\":[\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/national-institute-standards-and-technology-nist\",\"attributes\":{\"title\":\"National Institute of Standards and Technology (NIST)\",\"hierarchy\":[\"2\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/federal-information-security-modernization-act-fisma\",\"attributes\":{\"title\":\"Federal Information Security Modernization Act (FISMA)\",\"hierarchy\":[\"2\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/fedramp\",\"attributes\":{\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"hierarchy\":[\"2\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"2\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/application-security\",\"attributes\":{\"title\":\"Application Security\",\"hierarchy\":[\"3\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"3\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/zero-trust\",\"attributes\":{\"title\":\"Zero Trust\",\"hierarchy\":[\"3\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"3\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/software-bill-materials-sbom\",\"attributes\":{\"title\":\"Software Bill of Materials (SBOM)\",\"hierarchy\":[\"3\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/security-operations\",\"attributes\":{\"title\":\"Security Operations\",\"hierarchy\":[\"3\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/risk-management-handbook-chapter-8-incident-response-ir\",\"attributes\":{\"title\":\"Incident Response\",\"hierarchy\":[\"3\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"3\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"3\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/risk-management-and-reporting\",\"attributes\":{\"title\":\"Risk Management and Reporting\",\"hierarchy\":[\"3\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"3\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports\",\"hierarchy\":[\"3\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/plan-action-and-milestones-poam\",\"attributes\":{\"title\":\"Plan of Action and Milestones (POA\u0026M)\",\"hierarchy\":[\"3\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy\",\"hierarchy\":[\"4\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Agreements\",\"hierarchy\":[\"4\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-computer-matching-agreement-cma\",\"attributes\":{\"title\":\"Computer Matching Agreement (CMA)\",\"hierarchy\":[\"4\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-information-exchange-agreement-iea\",\"attributes\":{\"title\":\"Information Exchange Agreement (IEA)\",\"hierarchy\":[\"4\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Activities\",\"hierarchy\":[\"4\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/breach-response\",\"attributes\":{\"title\":\"Breach Response\",\"hierarchy\":[\"4\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"4\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/system-records-notice-sorn\",\"attributes\":{\"title\":\"System of Records Notice (SORN)\",\"hierarchy\":[\"4\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Privacy Resources\",\"hierarchy\":[\"4\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/ispg/privacy\",\"attributes\":{\"title\":\"Privacy at CMS\",\"hierarchy\":[\"4\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-breach-response-handbook\",\"attributes\":{\"title\":\"CMS Breach Response Handbook\",\"hierarchy\":[\"4\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/health-insurance-portability-and-accountability-act-1996-hipaa\",\"attributes\":{\"title\":\"Health Insurance Portability and Accessibility Act (HIPAA)\",\"hierarchy\":[\"4\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/policy-guidance/cms-privacy-impact-assessment-pia-handbook\",\"attributes\":{\"title\":\"CMS Privacy Impact Assessment (PIA) Handbook\",\"hierarchy\":[\"4\",\"2\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tools \u0026 Services\",\"hierarchy\":[\"5\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Reporting \u0026 Compliance\",\"hierarchy\":[\"5\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/isso-service\",\"attributes\":{\"title\":\"ISSO As A Service\",\"hierarchy\":[\"5\",\"0\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-fisma-continuous-tracking-system-cfacts\",\"attributes\":{\"title\":\"CFACTS\",\"hierarchy\":[\"5\",\"0\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cyber-risk-reports\",\"attributes\":{\"title\":\"Cyber Risk Reports and Dashboards\",\"hierarchy\":[\"5\",\"0\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/continuous-diagnostics-and-mitigation-cdm\",\"attributes\":{\"title\":\"Continuous Diagnostics and Mitigation (CDM)\",\"hierarchy\":[\"5\",\"0\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"System Security\",\"hierarchy\":[\"5\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/threat-modeling\",\"attributes\":{\"title\":\"Threat Modeling\",\"hierarchy\":[\"5\",\"1\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cloud-services\",\"attributes\":{\"title\":\"CMS Cloud Services\",\"hierarchy\":[\"5\",\"1\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cms-cybersecurity-integration-center-ccic\",\"attributes\":{\"title\":\"CMS Cybersecurity Integration Center (CCIC)\",\"hierarchy\":[\"5\",\"1\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"https://security.cms.gov/learn/cms-security-data-lake-sdl\",\"attributes\":{\"title\":\"CMS Security Data Lake (SDL)\",\"hierarchy\":[\"5\",\"1\",\"3\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"\",\"attributes\":{\"title\":\"Tests \u0026 Assessments\",\"hierarchy\":[\"5\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/cybersecurity-risk-assessment-program-csrap\",\"attributes\":{\"title\":\"Cybersecurity Risk Assessment Program (CSRAP)\",\"hierarchy\":[\"5\",\"2\",\"0\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/penetration-testing-pentesting\",\"attributes\":{\"title\":\"Penetration Testing\",\"hierarchy\":[\"5\",\"2\",\"1\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]},{\"link\":{\"anchor\":\"/system/menu/mega-menu/linkset\",\"rel\":\"item\",\"href\":\"/learn/privacy-impact-assessment-pia\",\"attributes\":{\"title\":\"Privacy Impact Assessment (PIA)\",\"hierarchy\":[\"5\",\"2\",\"2\"],\"machine-name\":[\"mega-menu\"]}},\"children\":[]}]}]}]}"])</script><script>self.__next_f.push([1,"9:[\"$\",\"html\",null,{\"lang\":\"en\",\"children\":[[\"$\",\"head\",null,{\"children\":[\"$\",\"$Ld\",null,{\"src\":\"/assets/javascript/uswds-init.min.js\",\"strategy\":\"beforeInteractive\"}]}],[\"$\",\"body\",null,{\"children\":[[[\"$\",\"a\",null,{\"className\":\"usa-skipnav\",\"href\":\"#main\",\"children\":\"Skip to main content\"}],[\"$\",\"section\",null,{\"className\":\"usa-banner\",\"aria-label\":\"Official website of the United States government\",\"children\":[\"$\",\"div\",null,{\"className\":\"usa-accordion\",\"children\":[[\"$\",\"header\",null,{\"className\":\"usa-banner__header\",\"children\":[\"$\",\"div\",null,{\"className\":\"usa-banner__inner\",\"children\":[[\"$\",\"div\",null,{\"className\":\"grid-col-auto\",\"children\":[\"$\",\"$Le\",null,{\"aria-hidden\":\"true\",\"className\":\"usa-banner__header-flag\",\"src\":\"/assets/img/us_flag_small.png\",\"alt\":\"\",\"width\":\"16\",\"height\":\"11\"}]}],[\"$\",\"div\",null,{\"className\":\"grid-col-fill tablet:grid-col-auto\",\"aria-hidden\":\"true\",\"children\":[[\"$\",\"p\",null,{\"className\":\"usa-banner__header-text\",\"children\":\"An official website of the United States government\"}],[\"$\",\"p\",null,{\"className\":\"usa-banner__header-action\",\"children\":\"Here's how you know\"}]]}],[\"$\",\"button\",null,{\"type\":\"button\",\"className\":\"usa-accordion__button usa-banner__button\",\"aria-expanded\":\"false\",\"aria-controls\":\"gov-banner-default-default\",\"children\":[\"$\",\"span\",null,{\"className\":\"usa-banner__button-text\",\"children\":\"Here's how you know\"}]}]]}]}],[\"$\",\"div\",null,{\"className\":\"usa-banner__content usa-accordion__content\",\"id\":\"gov-banner-default-default\",\"hidden\":true,\"children\":[\"$\",\"div\",null,{\"className\":\"grid-row grid-gap-lg\",\"children\":[[\"$\",\"div\",null,{\"className\":\"usa-banner__guidance tablet:grid-col-6\",\"children\":[[\"$\",\"$Le\",null,{\"className\":\"usa-banner__icon usa-media-block__img\",\"src\":{\"src\":\"/_next/static/media/icon-dot-gov.3e9cb1b5.svg\",\"height\":64,\"width\":64,\"blurWidth\":0,\"blurHeight\":0},\"role\":\"img\",\"alt\":\"\",\"aria-hidden\":\"true\",\"width\":\"40\",\"height\":\"40\"}],[\"$\",\"div\",null,{\"className\":\"usa-media-block__body\",\"children\":[\"$\",\"p\",null,{\"children\":[[\"$\",\"strong\",null,{\"children\":\"Official websites use .gov\"}],[\"$\",\"br\",null,{}],\"A \",[\"$\",\"strong\",null,{\"children\":\".gov\"}],\" website belongs to an official government organization in the United States.\"]}]}]]}],[\"$\",\"div\",null,{\"className\":\"usa-banner__guidance tablet:grid-col-6\",\"children\":[[\"$\",\"$Le\",null,{\"className\":\"usa-banner__icon usa-media-block__img\",\"src\":{\"src\":\"/_next/static/media/icon-https.e7f1a222.svg\",\"height\":64,\"width\":64,\"blurWidth\":0,\"blurHeight\":0},\"role\":\"img\",\"alt\":\"\",\"aria-hidden\":\"true\",\"width\":\"40\",\"height\":\"40\"}],[\"$\",\"div\",null,{\"className\":\"usa-media-block__body\",\"children\":[\"$\",\"p\",null,{\"children\":[[\"$\",\"strong\",null,{\"children\":\"Secure .gov websites use HTTPS\"}],[\"$\",\"br\",null,{}],\"A \",[\"$\",\"strong\",null,{\"children\":\"lock\"}],\" (\",[\"$\",\"span\",null,{\"className\":\"icon-lock\",\"children\":[\"$\",\"svg\",null,{\"xmlns\":\"http://www.w3.org/2000/svg\",\"width\":\"52\",\"height\":\"64\",\"viewBox\":\"0 0 52 64\",\"className\":\"usa-banner__lock-image\",\"role\":\"img\",\"aria-labelledby\":\"banner-lock-description-default\",\"focusable\":\"false\",\"children\":[[\"$\",\"title\",null,{\"id\":\"banner-lock-title-default\",\"children\":\"Lock\"}],[\"$\",\"desc\",null,{\"id\":\"banner-lock-description-default\",\"children\":\"Locked padlock icon\"}],[\"$\",\"path\",null,{\"fill\":\"#000000\",\"fillRule\":\"evenodd\",\"d\":\"M26 0c10.493 0 19 8.507 19 19v9h3a4 4 0 0 1 4 4v28a4 4 0 0 1-4 4H4a4 4 0 0 1-4-4V32a4 4 0 0 1 4-4h3v-9C7 8.507 15.507 0 26 0zm0 8c-5.979 0-10.843 4.77-10.996 10.712L15 19v9h22v-9c0-6.075-4.925-11-11-11z\"}]]}]}],\") or \",[\"$\",\"strong\",null,{\"children\":\"https://\"}],\" means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.\"]}]}]]}]]}]}]]}]}]],[\"$\",\"$Lf\",null,{\"value\":\"$10\",\"children\":[[\"$\",\"div\",null,{\"className\":\"usa-overlay\"}],[\"$\",\"header\",null,{\"className\":\"usa-header usa-header--extended\",\"children\":[[\"$\",\"div\",null,{\"className\":\"bg-primary-dark\",\"children\":[\"$\",\"div\",null,{\"className\":\"usa-navbar\",\"children\":[[\"$\",\"div\",null,{\"className\":\"usa-logo padding-y-4 padding-right-3\",\"id\":\"CyberGeek-logo\",\"children\":[\"$\",\"$L11\",null,{\"href\":\"/\",\"title\":\"CMS CyberGeek Home\",\"children\":[\"$\",\"$Le\",null,{\"src\":{\"src\":\"/_next/static/media/CyberGeek-logo.8e9bbd2b.svg\",\"height\":50,\"width\":425,\"blurWidth\":0,\"blurHeight\":0},\"alt\":\"CyberGeek logo\",\"width\":\"298\",\"height\":\"35\",\"priority\":true}]}]}],[\"$\",\"button\",null,{\"aria-label\":\"Open menu\",\"type\":\"button\",\"className\":\"usa-menu-btn\",\"data-cy\":\"menu-button\",\"children\":\"Menu\"}]]}]}],[\"$\",\"$L12\",null,{}]]}]]}],[\"$\",\"main\",null,{\"id\":\"main\",\"children\":[\"$\",\"$L6\",null,{\"parallelRouterKey\":\"children\",\"segmentPath\":[\"children\"],\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L13\",null,{\"children\":[\"$\",\"$L8\",null,{}]}],\"templateStyles\":[],\"templateScripts\":[],\"notFound\":[\"$\",\"section\",null,{\"className\":\"hero hero--theme-content-not-found undefined\",\"children\":[[\"$\",\"$Le\",null,{\"alt\":\"404 page not found\",\"className\":\"hero__graphic\",\"priority\":true,\"src\":{\"src\":\"/_next/static/media/content-not-found-graphic.8f104f47.svg\",\"height\":551,\"width\":948,\"blurWidth\":0,\"blurHeight\":0}}],[\"$\",\"div\",null,{\"className\":\"maxw-widescreen margin-x-auto padding-x-2 desktop:padding-x-0 padding-top-4 padding-bottom-6 desktop:padding-y-7\",\"children\":[\"$\",\"div\",null,{\"className\":\"tablet:grid-container position-relative \",\"children\":[\"$\",\"div\",null,{\"className\":\"hero__row grid-row grid-gap\",\"children\":[[\"$\",\"div\",null,{\"className\":\"tablet:grid-col-5 widescreen:position-relative\",\"children\":[false,false]}],[\"$\",\"div\",null,{\"className\":\"hero__column tablet:grid-col-7 flow padding-bottom-2\",\"children\":[\"$undefined\",\"$undefined\",false,[\"$\",\"h1\",null,{\"className\":\"hero__heading margin-0 line-height-sans-3 desktop:line-height-sans-2\",\"children\":\"We can't find that page.\"}],\"$undefined\",\"$undefined\",false,[\"$\",\"div\",null,{\"children\":[[\"$\",\"div\",null,{\"className\":\"hero__description\",\"children\":[[\"The page you're looking for may have been moved or retired. You can\",\" \",[\"$\",\"$L11\",null,{\"href\":\"/\",\"children\":\"visit our home page\"}],\" or use the search box to find helpful resources.\"]]}],[\"$\",\"div\",null,{\"className\":\"margin-top-6 search-container\",\"children\":[\"$\",\"$L14\",null,{\"theme\":\"content-not-found\"}]}]]}],false]}],false,false]}]}]}]]}],\"notFoundStyles\":[]}]}],[\"$\",\"$L15\",null,{}],[\"$\",\"$L16\",null,{}],[\"$\",\"$Ld\",null,{\"src\":\"/assets/javascript/uswds.min.js\",\"strategy\":\"beforeInteractive\"}]]}]]}]\n"])</script><script>self.__next_f.push([1,"17:I[9461,[\"866\",\"static/chunks/e37a0b60-b74be3d42787b18d.js\",\"30\",\"static/chunks/30-49b1c1429d73281d.js\",\"317\",\"static/chunks/317-0f87feacc1712b2f.js\",\"904\",\"static/chunks/904-dbddf7494c3e6975.js\",\"972\",\"static/chunks/972-6e520d137ef194fb.js\",\"549\",\"static/chunks/549-c87c1c3bbacc319f.js\",\"192\",\"static/chunks/app/learn/%5Bslug%5D/page-5b91cdc45a95ebbe.js\"],\"default\"]\n18:T66a5,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Security Impact Analysis (SIA) is an assessment that reviews how a proposed change can impact the security and privacy posture of a FISMA system. It is a mandatory process that is required for all system changes. The SIA maps directly to the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eCMS Acceptable Risk Safeguards (ARS) 5.0 Configuration Management (CM) Control\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho completes the SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe SIA is initiated by the Information System Security Officer (ISSO) or a designated team member if an ISSO is not available. The ISSO will work with the System/Business Owner and other relevant CMS staff and contractors to complete the SIA.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat changes to a system require an SIA?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThere are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.\u003c/p\u003e\u003cul\u003e\u003cli\u003eChanges to existing architecture, system, network, application, security boundary, or environment\u003c/li\u003e\u003cli\u003eChanges made to environments below the production environment (PROD) that will eventually be implemented in PROD\u003c/li\u003e\u003cli\u003eNew data types, or new connection to data source, system, service, or association\u003c/li\u003e\u003cli\u003eSoftware or service solutions that are new to the system; especially those that are new to CMS and have yet to be approved under any \u003ca href=\"/learn/authorization-operate-ato\"\u003eCMS ATO\u003c/a\u003e or \u003ca href=\"/learn/federal-risk-and-authorization-management-program-fedramp\"\u003eFedRAMP\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNote: \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-128/final\"\u003eNIST Special Publication 800-128 “\u003cem\u003eGuide for Security-Focused Configuration Management of Information Systems\u003c/em\u003e” \u003c/a\u003eindicates that the change management process (and by extension, Security Impact Analysis) is not required for changes that are expressly noted as being excluded in each organization’s \u003cstrong\u003eConfiguration Management Plan (CMP)\u003c/strong\u003e. If an anticipated change has not been noted in your organization’s CMP, you will need to perform an SIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eEvents that require a SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final\"\u003eNIST Special Publication 800-37 Rev 2 “\u003cem\u003eRisk Management Framework for Information Systems and Organizations\u003c/em\u003e” \u003c/a\u003edefines a significant change as a change that is likely to affect the security or privacy posture of a system substantively. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInstallation of a new or upgraded operating system, middleware component, or application\u003c/li\u003e\u003cli\u003eModifications to system ports, protocols, or services\u003c/li\u003e\u003cli\u003eInstallation of a new or upgraded hardware platform\u003c/li\u003e\u003cli\u003eModifications to how information, including PII, is processed\u003c/li\u003e\u003cli\u003eModifications to cryptographic modules or services\u003c/li\u003e\u003cli\u003eChanges in information types processed, stored, or transmitted by the system\u003c/li\u003e\u003cli\u003eModifications to security and privacy controls (e.g. identity and access management)\u003c/li\u003e\u003cli\u003eSignificant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:\u003c/li\u003e\u003cli\u003eMoving to a new facility\u003c/li\u003e\u003cli\u003eAdding new core missions or business functions\u003c/li\u003e\u003cli\u003eAcquiring specific and credible threat information that the organization is being targeted by a threat source\u003c/li\u003e\u003cli\u003eEstablishing new/modified laws, directives, policies, or regulations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eNote: The examples of changes listed above are only significant when they represent a change that is likely to affect the security and privacy posture of the system.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat documentation is required?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe depth and intensity of your SIA varies significantly depending on the scope of the proposed change. Consider your SIA as a holistic process that will benefit the security of your system over time rather than a compliance exercise you must complete to move forward.\u003cbr\u003e\u003cbr\u003eYour SIA may require limited documentation or it may be a detailed process that results in security testing, scans, and data reviews. Sometimes, information that surfaces about a system change during the SIA process can result in other documents and tests needing to be updated. This is part of the process required to keep your system secure.\u003cbr\u003e\u003cbr\u003eRegardless of the significance of the change to a system, the analysis and outcomes must be documented. You can choose to utilize the \u003ca href=\"https://security.cms.gov/learn/security-impact-analysis-sia#security-impact-analysis-sia-template\"\u003eSecurity Impact Analysis (SIA) Template\u003c/a\u003efor this purpose, or you can use a custom template that has been created for your system's specific needs. If you choose to use the generic CMS SIA Template, you will find it at the end of this page and will need to complete four sections:\u003c/p\u003e\u003ch3\u003eChange information\u003c/h3\u003e\u003cp\u003eA brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.\u003c/p\u003e\u003ch3\u003eTechnical representative information\u003c/h3\u003e\u003cp\u003eThe contact information for the ISSO or responsible party managing the system. The ISSO is the individual responsible for the completion of all actions related to the SIA even if a designated representative completes the paperwork on their behalf.\u003c/p\u003e\u003ch3\u003eTrigger actions and events evaluation\u003c/h3\u003e\u003cp\u003eAn extensive list of “Trigger Events”. This section is the heart of the assessment. You will be prompted to answer a number of “yes or no” questions related to the change. To complete this section, you’ll need to review:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe scope of the change\u003c/li\u003e\u003cli\u003eThe necessary updates or mitigation efforts\u003c/li\u003e\u003cli\u003eThe ARS controls impacted by the change\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf the change you’re proposing is related to the installation of an application or tool that has been pre-approved by FedRAMP on cloud.cms.gov, much of this information will be provided for you there. You’ll often find much of this information on the website of the company that created the application. For further help in determining system risk for new applications, you can always reach out to your Cyber Risk Advisor (CRA) for guidance.\u003c/p\u003e\u003ch3\u003eRecommendations for Business Owners\u003c/h3\u003e\u003cp\u003eThis final section provides a detailed list of the results of the SIA and recommendations from the ISSO to the System/Business Owner. SIA documentation may serve as a “to-do” list for ISSOs and System/Business Owners to make sure that documentation is updated appropriately, tests performed for identified controls, etc. It may also help justify further testing and potentially expensive processes to the Business Owner.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSIA outcomes\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe SIA and associated documentation may highlight the need for future actions including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunication with the \u003cstrong\u003eTechnical Review Board (TRB)\u003c/strong\u003e\u003c/li\u003e\u003cli\u003eUpdates to security artifacts like the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and PrivacyPlan (SSPP)\u003c/a\u003e, \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation Security Risk Assessment (ISRA)\u003c/a\u003e, \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e, \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e, among others\u003c/li\u003e\u003cli\u003eDetermination if third party security testing will be required\u003c/li\u003e\u003cli\u003eThe potential requirement for a new \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSIA documentation, if properly tailored, is also particularly useful for a DevSecOps environment where multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing documentation to quickly make any updates necessary.\u003c/p\u003e\u003ch2\u003eSecurity Impact Analysis (SIA) Template\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eSIA Template Instructions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cem\u003eThis template provides a suggested methodology to help ISSOs assess the potential security impact of a change or changes to FISMA systems.Individual ISSOs may find it necessary to alter the template to meet their organizational needs.Workflow associated with this template is also dependent on organizational requirements.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThis template consists of four sections.They are:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 1\u003c/strong\u003e – An overview of the proposed change.If this document is maintained for record keeping/compliance, the completion of this section will make identification easier in the future.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 2\u003c/strong\u003e – Information on who is performing the SIA if a technical representative of the ISSO is performing the assessment on behalf of the ISSO.If a technical representative of the ISSO has performed this assessment, they will forward it to the ISSO for discussion and review.It remains the ISSO’s responsibility to complete all appropriate actions.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 3\u003c/strong\u003e – An extensive list of “Trigger Events”, most of which are a decomposition of the boxes checked in Section 2. This section is the heart of the assessment.To complete this section:\u003c/p\u003e\u003col\u003e\u003cli\u003eThe assessor examines each event under “Scope of Change” (column 2).\u003c/li\u003e\u003cli\u003eIf an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAt this point, an elaboration of the events noted is included in the section “Summary of Security Impact/ Technical Overview/ Risks Identified\u003cstrong\u003e”.\u003c/strong\u003eThis includes detailing the technical overview of the item and a description of the potential impact and risk.Where other data associated with the change is available such as scan information, references should also be included in this area.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 4\u003c/strong\u003e – The ISSO recommendation to the Business Owner on the overall status of the change and what actions are necessary.This section should function as a high-level summarization of the necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote that the “Mitigation or Necessary Updates” area within Section 3 provides recommended actions.Actions may individually or as a group indicate the requirement for a new ATO.At this point, the ISSO may choose to consult with their Cyber Risk Advisor or Privacy Advisor prior to providing the recommendation of activities to the Business Owner and System Maintainer.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThough every change requires a SIA, \u003cstrong\u003eorganizations may utilize their own internal methods or processes that can automate or streamline the security analysis rather than using a formal SIA form\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eThese types of changes may include processes for configuration control such as vendor-provided security patches, updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals, motherboard or hard drives, etc.Processes associated with similar functions, may have built-in security components or controls that may not require a formal SIA form.Any of these processes -- whether automated or manual -- must capture the elements needed to properly analyze the security impacts of the particular change. The ISSO may at any time require a formal SIA for any change.\u003c/p\u003e\u003cp\u003eThe SIA document, when completed and shared with the Business Owner, can be used as a checklist to make sure that any work such as documentation changes are performed.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTo create your SIA document, start with the following for a title:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003e\u0026lt;FISMA SYSTEM NAME\u0026gt; \u0026lt; PRODUCT/FEATURE NAME\u0026gt; \u0026lt;DATE OF RELEASE TO PROD\u0026gt;\u003c/strong\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSection 1: Change Information\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCR Number\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCR Submitter (Contact Information)\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSystem/Application/Tool\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDescription of System Change\u003cbr\u003e(Detailed description that includes the Drivers for the change)\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 2: Technical Representative Information\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIf a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eRepresentative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTitle of Representative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDate\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePhone\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEmail\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Trigger Actions and Events Evaluation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003e\u003cstrong\u003eDirections:\u003c/strong\u003e Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-inclusive.Note: this list is not all-inclusive.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eImpact? (Y/N)\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCategory\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eScope of Change\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eMitigation or Necessary Updates\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eARS Controls Impacted\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eSummary of Security Impact/ Technical Overview/ Risks Identified\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eNew Users or\u003cbr\u003eNew User Roles Added\u003c/td\u003e\u003ctd\u003e\u003cp\u003eISRA updates, potential PIA update, CFACTS system description updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-2, AC-6\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eChange in data collection, storage, sharing\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePIA update.\u003c/p\u003e\u003cp\u003ePotential SORN updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003eMission/\u003c/p\u003e\u003cp\u003eBusiness requirements\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eCessation of mission or function.\u003c/td\u003e\u003ctd\u003ePotential update to SSP, CFACTS system description updates.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of mission/function.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePolicy/\u003c/p\u003e\u003cp\u003eStandards\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew revisions of ARS and CMS policy; or Issue or Update of NIST documents\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of the policy/\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003estandards.\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eLaws, Regulations, Directives\u003c/td\u003e\u003ctd\u003eNew or Changed\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of laws, regulations, directives.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eInterconnections and New connection to FISMA system or Service\u003c/td\u003e\u003ctd\u003e\u003cp\u003eUpdates to ISA and MOU must occur. If not standard connection service/inheritance from another accredited FISMA system, SCA will be required.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-4, CA-3, CA-9, PL-2, AC-3, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eArchitecture, Topology, Port/Protocol/Service change\u003c/td\u003e\u003ctd\u003e\u003cp\u003eZone changes\u003c/p\u003e\u003cp\u003eImplementation or inheritance of new services\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eCM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity components\u003c/td\u003e\u003ctd\u003e\u003cp\u003eIdentification, Authentication, Authorization\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eNew methods for authentication and/or identifiers added\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eMigrations between Single Factor and MFA\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew and modified control implementations must be tested. SCA required unless inheriting from existing FISMA system.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to all FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eIA (all)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity Components\u003c/td\u003e\u003ctd\u003eSecurity Controls – Change in implementation standard or status\u003c/td\u003e\u003ctd\u003eNew and modified control implementations must be tested via existing security processes. All changes must be documented within the SSP and the Controls tab within CFACTS. Changes in controls that cause controls to no longer be “Satisfied” must be submitted as a POA\u0026amp;M and documented within the ISRA.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eList specific controls changed\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eUser Interface\u003c/td\u003e\u003ctd\u003eUpdates to GUI including addition of new pages, new inputs\u003c/td\u003e\u003ctd\u003eNew pages must go through 508 testing, Static and Dynamic code analysis to determine no additional threats from XSS or other new vulnerabilities.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSI-10\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Hardware\u003c/td\u003e\u003ctd\u003eServers, Communication Devices\u003c/td\u003e\u003ctd\u003eIf the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAC-19, SI-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Operating System\u003c/td\u003e\u003ctd\u003eChange in Operating System\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Security Software\u003c/td\u003e\u003ctd\u003eNew Security Software or Perimeter Security Change\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of software\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSupport Software\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew Support Software\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential TRB review/approval\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVendor Patches\u003c/td\u003e\u003ctd\u003eSoftware, Servers\u003c/td\u003e\u003ctd\u003eSoftware patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem Boundary\u003c/td\u003e\u003ctd\u003eChange to Logical Access Points\u003c/td\u003e\u003ctd\u003eVulnerability Scan is required\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eAC-17, AC-2, AC-3, AC-18, AC-19, AC-20,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-3, CA-7,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Developed\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Succeed Elsewhere\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eFound (No Attacks Known)\u003c/td\u003e\u003ctd\u003eAdd to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eNew processing location(s)\u003c/td\u003e\u003ctd\u003eA new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary (environment)\u003c/td\u003e\u003ctd\u003eChange or Addition of Hosting Infrastructure or Site\u003c/td\u003e\u003ctd\u003eFull authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Validation/Security Testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePlease provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTool/Scan Type\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e(Y/N)\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Performed by\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting /Method\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Frequency\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTest Result Location\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eNotes\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCompliance Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDynamic WAPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eStatic WPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 4: Overall Recommendation for Business Owners\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eUsing the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on the status of the change.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO recommendation(s):\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cem\u003eISSO should indicate which of the following are recommended, and provide details using additional pages.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eDeploy to Production Environment without additional testing\u003c/li\u003e\u003cli\u003eUndergo Targeted Third Party Security Testing\u003c/li\u003e\u003cli\u003eUndergo SCA/CSRAP\u003c/li\u003e\u003cli\u003eRequire Business Owner Risk Acceptance to field to Production\u003c/li\u003e\u003cli\u003eApply for a new ATO\u003c/li\u003e\u003cli\u003eOther (e.g. update documentation. Specify on following page)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSigned by:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eSystem ISSO\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eBusiness Owner\u003c/p\u003e"])</script><script>self.__next_f.push([1,"19:T66a5,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Security Impact Analysis (SIA) is an assessment that reviews how a proposed change can impact the security and privacy posture of a FISMA system. It is a mandatory process that is required for all system changes. The SIA maps directly to the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eCMS Acceptable Risk Safeguards (ARS) 5.0 Configuration Management (CM) Control\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho completes the SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe SIA is initiated by the Information System Security Officer (ISSO) or a designated team member if an ISSO is not available. The ISSO will work with the System/Business Owner and other relevant CMS staff and contractors to complete the SIA.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat changes to a system require an SIA?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThere are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.\u003c/p\u003e\u003cul\u003e\u003cli\u003eChanges to existing architecture, system, network, application, security boundary, or environment\u003c/li\u003e\u003cli\u003eChanges made to environments below the production environment (PROD) that will eventually be implemented in PROD\u003c/li\u003e\u003cli\u003eNew data types, or new connection to data source, system, service, or association\u003c/li\u003e\u003cli\u003eSoftware or service solutions that are new to the system; especially those that are new to CMS and have yet to be approved under any \u003ca href=\"/learn/authorization-operate-ato\"\u003eCMS ATO\u003c/a\u003e or \u003ca href=\"/learn/federal-risk-and-authorization-management-program-fedramp\"\u003eFedRAMP\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNote: \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-128/final\"\u003eNIST Special Publication 800-128 “\u003cem\u003eGuide for Security-Focused Configuration Management of Information Systems\u003c/em\u003e” \u003c/a\u003eindicates that the change management process (and by extension, Security Impact Analysis) is not required for changes that are expressly noted as being excluded in each organization’s \u003cstrong\u003eConfiguration Management Plan (CMP)\u003c/strong\u003e. If an anticipated change has not been noted in your organization’s CMP, you will need to perform an SIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eEvents that require a SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final\"\u003eNIST Special Publication 800-37 Rev 2 “\u003cem\u003eRisk Management Framework for Information Systems and Organizations\u003c/em\u003e” \u003c/a\u003edefines a significant change as a change that is likely to affect the security or privacy posture of a system substantively. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInstallation of a new or upgraded operating system, middleware component, or application\u003c/li\u003e\u003cli\u003eModifications to system ports, protocols, or services\u003c/li\u003e\u003cli\u003eInstallation of a new or upgraded hardware platform\u003c/li\u003e\u003cli\u003eModifications to how information, including PII, is processed\u003c/li\u003e\u003cli\u003eModifications to cryptographic modules or services\u003c/li\u003e\u003cli\u003eChanges in information types processed, stored, or transmitted by the system\u003c/li\u003e\u003cli\u003eModifications to security and privacy controls (e.g. identity and access management)\u003c/li\u003e\u003cli\u003eSignificant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:\u003c/li\u003e\u003cli\u003eMoving to a new facility\u003c/li\u003e\u003cli\u003eAdding new core missions or business functions\u003c/li\u003e\u003cli\u003eAcquiring specific and credible threat information that the organization is being targeted by a threat source\u003c/li\u003e\u003cli\u003eEstablishing new/modified laws, directives, policies, or regulations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eNote: The examples of changes listed above are only significant when they represent a change that is likely to affect the security and privacy posture of the system.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat documentation is required?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe depth and intensity of your SIA varies significantly depending on the scope of the proposed change. Consider your SIA as a holistic process that will benefit the security of your system over time rather than a compliance exercise you must complete to move forward.\u003cbr\u003e\u003cbr\u003eYour SIA may require limited documentation or it may be a detailed process that results in security testing, scans, and data reviews. Sometimes, information that surfaces about a system change during the SIA process can result in other documents and tests needing to be updated. This is part of the process required to keep your system secure.\u003cbr\u003e\u003cbr\u003eRegardless of the significance of the change to a system, the analysis and outcomes must be documented. You can choose to utilize the \u003ca href=\"https://security.cms.gov/learn/security-impact-analysis-sia#security-impact-analysis-sia-template\"\u003eSecurity Impact Analysis (SIA) Template\u003c/a\u003efor this purpose, or you can use a custom template that has been created for your system's specific needs. If you choose to use the generic CMS SIA Template, you will find it at the end of this page and will need to complete four sections:\u003c/p\u003e\u003ch3\u003eChange information\u003c/h3\u003e\u003cp\u003eA brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.\u003c/p\u003e\u003ch3\u003eTechnical representative information\u003c/h3\u003e\u003cp\u003eThe contact information for the ISSO or responsible party managing the system. The ISSO is the individual responsible for the completion of all actions related to the SIA even if a designated representative completes the paperwork on their behalf.\u003c/p\u003e\u003ch3\u003eTrigger actions and events evaluation\u003c/h3\u003e\u003cp\u003eAn extensive list of “Trigger Events”. This section is the heart of the assessment. You will be prompted to answer a number of “yes or no” questions related to the change. To complete this section, you’ll need to review:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe scope of the change\u003c/li\u003e\u003cli\u003eThe necessary updates or mitigation efforts\u003c/li\u003e\u003cli\u003eThe ARS controls impacted by the change\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf the change you’re proposing is related to the installation of an application or tool that has been pre-approved by FedRAMP on cloud.cms.gov, much of this information will be provided for you there. You’ll often find much of this information on the website of the company that created the application. For further help in determining system risk for new applications, you can always reach out to your Cyber Risk Advisor (CRA) for guidance.\u003c/p\u003e\u003ch3\u003eRecommendations for Business Owners\u003c/h3\u003e\u003cp\u003eThis final section provides a detailed list of the results of the SIA and recommendations from the ISSO to the System/Business Owner. SIA documentation may serve as a “to-do” list for ISSOs and System/Business Owners to make sure that documentation is updated appropriately, tests performed for identified controls, etc. It may also help justify further testing and potentially expensive processes to the Business Owner.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSIA outcomes\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe SIA and associated documentation may highlight the need for future actions including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunication with the \u003cstrong\u003eTechnical Review Board (TRB)\u003c/strong\u003e\u003c/li\u003e\u003cli\u003eUpdates to security artifacts like the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and PrivacyPlan (SSPP)\u003c/a\u003e, \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation Security Risk Assessment (ISRA)\u003c/a\u003e, \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e, \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e, among others\u003c/li\u003e\u003cli\u003eDetermination if third party security testing will be required\u003c/li\u003e\u003cli\u003eThe potential requirement for a new \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSIA documentation, if properly tailored, is also particularly useful for a DevSecOps environment where multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing documentation to quickly make any updates necessary.\u003c/p\u003e\u003ch2\u003eSecurity Impact Analysis (SIA) Template\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eSIA Template Instructions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cem\u003eThis template provides a suggested methodology to help ISSOs assess the potential security impact of a change or changes to FISMA systems.Individual ISSOs may find it necessary to alter the template to meet their organizational needs.Workflow associated with this template is also dependent on organizational requirements.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThis template consists of four sections.They are:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 1\u003c/strong\u003e – An overview of the proposed change.If this document is maintained for record keeping/compliance, the completion of this section will make identification easier in the future.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 2\u003c/strong\u003e – Information on who is performing the SIA if a technical representative of the ISSO is performing the assessment on behalf of the ISSO.If a technical representative of the ISSO has performed this assessment, they will forward it to the ISSO for discussion and review.It remains the ISSO’s responsibility to complete all appropriate actions.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 3\u003c/strong\u003e – An extensive list of “Trigger Events”, most of which are a decomposition of the boxes checked in Section 2. This section is the heart of the assessment.To complete this section:\u003c/p\u003e\u003col\u003e\u003cli\u003eThe assessor examines each event under “Scope of Change” (column 2).\u003c/li\u003e\u003cli\u003eIf an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAt this point, an elaboration of the events noted is included in the section “Summary of Security Impact/ Technical Overview/ Risks Identified\u003cstrong\u003e”.\u003c/strong\u003eThis includes detailing the technical overview of the item and a description of the potential impact and risk.Where other data associated with the change is available such as scan information, references should also be included in this area.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 4\u003c/strong\u003e – The ISSO recommendation to the Business Owner on the overall status of the change and what actions are necessary.This section should function as a high-level summarization of the necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote that the “Mitigation or Necessary Updates” area within Section 3 provides recommended actions.Actions may individually or as a group indicate the requirement for a new ATO.At this point, the ISSO may choose to consult with their Cyber Risk Advisor or Privacy Advisor prior to providing the recommendation of activities to the Business Owner and System Maintainer.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThough every change requires a SIA, \u003cstrong\u003eorganizations may utilize their own internal methods or processes that can automate or streamline the security analysis rather than using a formal SIA form\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eThese types of changes may include processes for configuration control such as vendor-provided security patches, updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals, motherboard or hard drives, etc.Processes associated with similar functions, may have built-in security components or controls that may not require a formal SIA form.Any of these processes -- whether automated or manual -- must capture the elements needed to properly analyze the security impacts of the particular change. The ISSO may at any time require a formal SIA for any change.\u003c/p\u003e\u003cp\u003eThe SIA document, when completed and shared with the Business Owner, can be used as a checklist to make sure that any work such as documentation changes are performed.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTo create your SIA document, start with the following for a title:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003e\u0026lt;FISMA SYSTEM NAME\u0026gt; \u0026lt; PRODUCT/FEATURE NAME\u0026gt; \u0026lt;DATE OF RELEASE TO PROD\u0026gt;\u003c/strong\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSection 1: Change Information\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCR Number\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCR Submitter (Contact Information)\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSystem/Application/Tool\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDescription of System Change\u003cbr\u003e(Detailed description that includes the Drivers for the change)\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 2: Technical Representative Information\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIf a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eRepresentative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTitle of Representative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDate\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePhone\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEmail\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Trigger Actions and Events Evaluation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003e\u003cstrong\u003eDirections:\u003c/strong\u003e Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-inclusive.Note: this list is not all-inclusive.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eImpact? (Y/N)\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCategory\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eScope of Change\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eMitigation or Necessary Updates\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eARS Controls Impacted\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eSummary of Security Impact/ Technical Overview/ Risks Identified\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eNew Users or\u003cbr\u003eNew User Roles Added\u003c/td\u003e\u003ctd\u003e\u003cp\u003eISRA updates, potential PIA update, CFACTS system description updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-2, AC-6\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eChange in data collection, storage, sharing\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePIA update.\u003c/p\u003e\u003cp\u003ePotential SORN updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003eMission/\u003c/p\u003e\u003cp\u003eBusiness requirements\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eCessation of mission or function.\u003c/td\u003e\u003ctd\u003ePotential update to SSP, CFACTS system description updates.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of mission/function.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePolicy/\u003c/p\u003e\u003cp\u003eStandards\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew revisions of ARS and CMS policy; or Issue or Update of NIST documents\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of the policy/\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003estandards.\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eLaws, Regulations, Directives\u003c/td\u003e\u003ctd\u003eNew or Changed\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of laws, regulations, directives.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eInterconnections and New connection to FISMA system or Service\u003c/td\u003e\u003ctd\u003e\u003cp\u003eUpdates to ISA and MOU must occur. If not standard connection service/inheritance from another accredited FISMA system, SCA will be required.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-4, CA-3, CA-9, PL-2, AC-3, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eArchitecture, Topology, Port/Protocol/Service change\u003c/td\u003e\u003ctd\u003e\u003cp\u003eZone changes\u003c/p\u003e\u003cp\u003eImplementation or inheritance of new services\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eCM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity components\u003c/td\u003e\u003ctd\u003e\u003cp\u003eIdentification, Authentication, Authorization\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eNew methods for authentication and/or identifiers added\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eMigrations between Single Factor and MFA\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew and modified control implementations must be tested. SCA required unless inheriting from existing FISMA system.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to all FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eIA (all)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity Components\u003c/td\u003e\u003ctd\u003eSecurity Controls – Change in implementation standard or status\u003c/td\u003e\u003ctd\u003eNew and modified control implementations must be tested via existing security processes. All changes must be documented within the SSP and the Controls tab within CFACTS. Changes in controls that cause controls to no longer be “Satisfied” must be submitted as a POA\u0026amp;M and documented within the ISRA.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eList specific controls changed\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eUser Interface\u003c/td\u003e\u003ctd\u003eUpdates to GUI including addition of new pages, new inputs\u003c/td\u003e\u003ctd\u003eNew pages must go through 508 testing, Static and Dynamic code analysis to determine no additional threats from XSS or other new vulnerabilities.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSI-10\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Hardware\u003c/td\u003e\u003ctd\u003eServers, Communication Devices\u003c/td\u003e\u003ctd\u003eIf the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAC-19, SI-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Operating System\u003c/td\u003e\u003ctd\u003eChange in Operating System\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Security Software\u003c/td\u003e\u003ctd\u003eNew Security Software or Perimeter Security Change\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of software\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSupport Software\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew Support Software\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential TRB review/approval\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVendor Patches\u003c/td\u003e\u003ctd\u003eSoftware, Servers\u003c/td\u003e\u003ctd\u003eSoftware patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem Boundary\u003c/td\u003e\u003ctd\u003eChange to Logical Access Points\u003c/td\u003e\u003ctd\u003eVulnerability Scan is required\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eAC-17, AC-2, AC-3, AC-18, AC-19, AC-20,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-3, CA-7,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Developed\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Succeed Elsewhere\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eFound (No Attacks Known)\u003c/td\u003e\u003ctd\u003eAdd to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eNew processing location(s)\u003c/td\u003e\u003ctd\u003eA new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary (environment)\u003c/td\u003e\u003ctd\u003eChange or Addition of Hosting Infrastructure or Site\u003c/td\u003e\u003ctd\u003eFull authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Validation/Security Testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePlease provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTool/Scan Type\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e(Y/N)\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Performed by\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting /Method\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Frequency\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTest Result Location\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eNotes\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCompliance Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDynamic WAPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eStatic WPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 4: Overall Recommendation for Business Owners\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eUsing the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on the status of the change.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO recommendation(s):\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cem\u003eISSO should indicate which of the following are recommended, and provide details using additional pages.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eDeploy to Production Environment without additional testing\u003c/li\u003e\u003cli\u003eUndergo Targeted Third Party Security Testing\u003c/li\u003e\u003cli\u003eUndergo SCA/CSRAP\u003c/li\u003e\u003cli\u003eRequire Business Owner Risk Acceptance to field to Production\u003c/li\u003e\u003cli\u003eApply for a new ATO\u003c/li\u003e\u003cli\u003eOther (e.g. update documentation. Specify on following page)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSigned by:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eSystem ISSO\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eBusiness Owner\u003c/p\u003e"])</script><script>self.__next_f.push([1,"1a:T1c68f,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eIntroduction\u003c/h2\u003e\u003cp\u003eThis Handbook outlines procedures to help CMS staff and contractors implement the Configuration Management family of controls taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 and tailored to the CMS environment in the CMS Acceptable Risk Safeguards (ARS). For more guidance on how to implement CMS policies and standards across many cybersecurity topics, see the CMS Security and Privacy Handbooks.\u0026nbsp;\u003c/p\u003e\u003cp\u003eConfiguration management has been applied to a broad range of information systems. Some basic terms associated with the configuration management discipline are briefly explained below.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eBaseline Configuration\u003c/em\u003e\u0026nbsp;is a set of specifications for a system that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;(CM Plan) is a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. The basic parts of a CM Plan include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eConfiguration Control Board\u003c/em\u003e\u0026nbsp;(CCB) – establishment of and charter for a group of qualified people with responsibility for the process of controlling and approving changes throughout the development and operation lifecycle of products and systems; may also be referred to as a change control board;\u003c/li\u003e\u003cli\u003eConfiguration Item\u0026nbsp;\u003cem\u003eIdentification\u003c/em\u003e\u0026nbsp;– methodology for selecting and naming configuration items that need to be placed under CM;\u003c/li\u003e\u003cli\u003eConfiguration\u0026nbsp;\u003cem\u003eChange Control\u003c/em\u003e\u0026nbsp;– process for managing updates to the baseline configurations for the configuration items; and\u003c/li\u003e\u003cli\u003eConfiguration\u003cem\u003e\u0026nbsp;Monitoring\u003c/em\u003e\u0026nbsp;– process for assessing or testing the level of compliance with the established baseline configuration and mechanisms for reporting on the configuration status of items places under CM.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis guideline is associated with the application of security-focused configuration management practices as they apply to information systems. The configuration of an information system is a representation of the system’s components, how each component is configured, and how the components are connected or arranged to implement the information system. The possible conditions in which an information system or system component can be arranged affect the security posture of the information system. The activities involved in managing the configuration of an information system include development of a configuration management plan, establishment of a configuration control board, development of a methodology for configuration item identification, establishment of the baseline configuration, development of a configuration change control process, and development of a process for configuration monitoring and reporting.\u003c/p\u003e\u003cp\u003eConfiguration management of information systems involves a set of activities that can be organized into four major phases – Planning, Identifying and Implementing Configurations, Monitoring, and Controlling Configuration Changes. It is through these phases that CM not only supports security for an information system and its components, but also supports the management of organizational risk.\u003c/p\u003e\u003ch2\u003eConfiguration Management controls\u003c/h2\u003e\u003ch3\u003eBaseline Configuration (CM-2)\u003c/h3\u003e\u003cp\u003eThis control requires CMS to develop, document, and maintain under configuration control a current baseline configuration for each information system. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for initializing and maintaining an information system configuration baseline.\u003c/p\u003e\u003cp\u003eTo develop and document initial configurations:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system owner with the support of the Change Control Board (CCB) identifies the configuration settings for their information system, device, appliance, or application using configuration settings standards in section 3.5 as part of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer documents the configuration settings chosen during Step 1 in the CMS Intake Form as part of the CMS-SDLC.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn order to maintain the configuration baseline, the Business Owner ensures the following is completed:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization determines that the system requires a change. (See SA-3 and CM-9).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops a high-level plan for how to accomplish the change (see SA-3, and SA-10).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) reviews the Privacy Impact Assessment (PIA) and conducts a Security Impact Analysis (SIA, see CM-4 Security Impact Analysis) to identify the privacy and security impacts of their plan (see CM-4 and SA-3).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops any applicable design requirements to mitigate the identified security impacts (see SA-3, SA-8, and SA-17).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops testing requirements to ensure that the security impacts are verified as successfully mitigated (see CA-2 and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) builds out the system changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) test, independently as required by CA-2(1) and CA-7(1)), the system changes using the security tests developed in step 5 (see AC-5.Std.5, CA-2, CM-3(2), CM-4(1), and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops and implements any Plans of Action and Milestones (POA\u0026amp;Ms) necessary to correct identified failures from testing (see CA-5).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11:\u0026nbsp; \u003c/strong\u003eThe ISSO applies either for a new Authorization To Operate (ATO), or for an ATO update (see CA-6).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReviews and Updates (CM-2(1))\u003c/h4\u003e\u003cp\u003eThis enhancement requires CMS to review and update the baseline configuration of its information systems at a regularly defined frequency, when special circumstances arise, or when and information system component is installed or upgraded.\u0026nbsp; By defining and maintaining a baseline configuration for its information systems, CMS is supporting the cybersecurity concepts of least privilege and least functionality. In addition, the establishment of configuration baselines helps the organization recognize abnormal behavior as a sign of attack.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for review and update of the baseline configuration for an information system.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003e[Assignment: organization-defined frequency];\u003c/li\u003e\u003cli\u003eWhen required due to [Assignment organization-defined circumstances];and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003eAt least every 180 days for High systems or\u0026nbsp; 365 days for Moderate systems;\u003c/li\u003e\u003cli\u003eWhen configuration settings change due to critical security patches (as defined by the federal government, CMS, or vendor), upgrades and emergency changes (e.g., unscheduled changes, system crashes, replacement of critical hardware components), major system changes/upgrades;\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eTo implement the CMS controls for reviewing and updating configuration baseline, the Information System Security Officer (ISSO) must first assign a security category in accordance with FIPS 199.\u003c/p\u003e\u003cp\u003eThis procedure is outlined in RMH Chapter 12: Security \u0026amp; Privacy Planning, under control PL-2.\u0026nbsp; The category will assist the CCB with identifying adequate security controls and ensuring they are integrated into the configuration baseline of the information system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCB will review information system baseline configurations every 365 days for systems categorized “High” and every 1,095 days for systems categorized as “Moderate”. Other triggers outside of scheduled times for configuration baseline review are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical security patches to the system/component\u003c/li\u003e\u003cli\u003eUpgrades to the system\u003c/li\u003e\u003cli\u003eEmergency changes\u003c/li\u003e\u003cli\u003eMajor system changes or upgrades\u003c/li\u003e\u003cli\u003eInformation system component installations\u003c/li\u003e\u003cli\u003eUpdates to the governing standards\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn addition, system developer and maintainers will have to update the documentation regarding the baseline configuration after an approval of changes. Updates must follow the same process stated above in CM-2.\u003c/p\u003e\u003ch4\u003eAutomation Support for Accuracy / Currency (CM-2(2))\u003c/h4\u003e\u003cp\u003eCMS provides automation support whenever possible to information systems’ configuration baselines. \u0026nbsp;Automation support examples include hardware asset management systems, software asset management systems, and centralized configuration management software. \u0026nbsp;CMS uses automation of information gathering to support the continuous monitoring program and inventory systems. \u0026nbsp;Automation support captures the types of hardware and software on the network and the operating system or firmware on each device.\u003c/p\u003e\u003cp\u003eThe goal is to keep track of what the configuration is on each system and to have the ability to go to an information system and collect configuration information automatically. \u0026nbsp;The automation keeps the data on systems configuration up-to-date, accurate, and available when it is needed.\u0026nbsp; With a current list of configurations, CMS can feed it into other processes that look for deviations from the baseline and configurations that are not up to organizational standards. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HSS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for incorporating automation to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system developer and maintainer configures the system architecture to allow automated hardware and software mechanisms provided by Continuous Diagnostics and Mitigation (CDM) to scan the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer configures the access controls, as needed, to allow automation support to have access to the information that it needs.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Cybersecurity Integration Center (CCIC) runs automated mechanisms to gather hardware and software configurations as part of the Continuous Monitoring Program whose point of contact information is in Appendix G.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRetention of Previous Configurations (CM-2(3))\u003c/h4\u003e\u003cp\u003eRetaining documentation of configuration information is the first step to the restoration in times of need. CMS will maintain at least one backup of the configuration for systems, system components, and information system services. The configuration information needed is used to restore a device, service, or software to a previous state. Related to CM-2(2), section 3.1.2 of this document, the automated gathering of configuration information can be used to collect the data. This backup should also be maintained, given that the configuration will change over time. The approval of changes in the configuration from the CCB should also be added to the configuration documentation to retain as a new version.\u003c/p\u003e\u003cp\u003eThe retention of configuration information is in support of CMS as one of its goals to maintain availability of systems. A previous configuration could be used to replace current settings and processes to a former state. This former state should be an approved configuration that may increase risk, but maintain availability. For example, if there were a system that did not apply a critical security patch correctly causing a system failure, then restoring the previous configuration would restore the system to a functioning state (available) without the security protection of the patch (increased risk).\u003c/p\u003e\u003cp\u003eThe configuration information can also be used when settings change with unintended consequences during system upgrades or replacements. The previous configuration can be restored using what is called a rollback procedure, which would implement the settings for a former state that is known to function properly.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameter (ODP) for CM Retention of Previous Configurations.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(3)\u003c/td\u003e\u003ctd\u003eThe organization retains [Assignment: organization-defined previous versions of baseline configurations of the information system] to support rollback.\u003c/td\u003e\u003ctd\u003eThe organization retains older versions of baseline configurations of the information system as deemed necessary, by the ISSO, to support rollback.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for retaining configuration information of an information system:\u003c/p\u003e\u003cp\u003eThe system developer and maintainer will determine the needs of the system to restore it back to a previous state. The information gathered can be a combination of settings, version numbers of software/firmware/hardware, access controls, connection information, or schematics. The importance of gathering the correct information is to ensure that the system will work using the previous configuration as stored. This previous configuration information must also be available in case of emergencies and must therefore be stored apart from the system itself to remain available if the system is offline. Additionally, configuration changes that are approved by the CCB must be added to the configuration baseline to ensure the up-to-date configurations are used for restoration. A minimum of one previous configuration is required for this control.\u003c/p\u003e\u003cp\u003eBecause the retention process will be slightly different for every information system, the system developer and maintainer must document their process in their Configuration Management Plan (CMP).\u003c/p\u003e\u003ch4\u003eConfigure Systems, Components, or Devices for High-Risk Areas (CM-2(7))\u003c/h4\u003e\u003cp\u003eThis control guides CMS to create configurations and/or procedures for systems (laptops, iPhones, etc.) that are traveling to high-risk areas. \u0026nbsp;This control is for official travel, because unofficial/personal travel should not involve the transportation of Government Furnished Equipment (GFEs).\u0026nbsp; CMS employees traveling to high-risk areas should not travel with their permanently issued GFE but instead use an assigned loaner laptop from the designated laptop team. \u0026nbsp;The designation of high-risk countries can be found on the State Department’s website\u0026nbsp;\u003cem\u003eTravel to High-Risk Areas\u003c/em\u003e\u0026nbsp; Upon returning, CMS employees and contractors return their mobile devices to the SOC for a check of signs of physical tampering.\u0026nbsp; HHS guidance can be found here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\"\u003ehttps://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\u003c/a\u003e. Further guidance can be obtained from the HHS Office of Security and Strategic Information and from the Broadcast on Foreign Travel:\u0026nbsp;\u003cem\u003eUpdated Foreign Travel Security Awareness Guidance\u003c/em\u003e\u0026nbsp;(6/12/2017).\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM-2(7) Configure Systems, Components, or Devices for High-Risk Areas.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(7)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003cli\u003eApplies [Assignment: organization-defined security safeguards] to the devices when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues dedicated information systems, system components, or devices with stringent configurations (e.g., FIPS 140-2 for encryption) to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eApplies security safeguards to the devices (i.e., detailed inspection of the device for physical tampering, purging or reimaging the hard disk drive/removable media) when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for handling systems components or devices for travel to a high-risk area.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; CMS Users traveling to foreign countries for official business notify the Office of Security and Strategic Information (OSSI) at least 30 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u0026nbsp;and follow the HHS\u0026nbsp;\u003cem\u003eForeign Travel Checklist\u0026nbsp;\u003c/em\u003ethat is available here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\"\u003ehttps://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;CMS Users traveling to foreign countries for official business notify the CMS International Team least 10 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Users notifies the Service Desk at least 10 days in advance of their travel in order to arrange for their travel laptop to conduct business on while abroad using the email\u0026nbsp;\u003ca href=\"mailto:Cms_it_service_desk@cms.hhs.gov\"\u003ecms_it_service_desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS International Team checks the country against the Department of State travel advisories to determine the risk to the traveling CMS User here:\u0026nbsp;\u003ca href=\"https://travel.state.gov/content/passports/en/alertswarnings.html\"\u003ehttps://travel.state.gov/content/passports/en/alertswarnings.html\u003c/a\u003e. \u0026nbsp;Then uses that information to decide the security awareness briefing that the User will receive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS International Team notifies the Infrastructure \u0026amp; User Services Group about the connection of the GFE that the user will have while overseas.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Deskside Support protects the travel computer using the FIPS 140-2 compliant encryption using the current full-disk encryption solution. (e.g. Checkpoint Endpoint Encryption)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS International Team debriefs the User when they return.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;CMS User returns the travel computer to CMS Deskside Support within two days of returning from travel before connecting it to the CMS network or system and does not attempt to transfer data when returning.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Change Control (CM-3)\u003c/h3\u003e\u003cp\u003eConfiguration change control implements the change control process for the information system, system component, or information system service. Management will determine which changes to the system need to be part of the change control process. There will also be employees assigned to the CCB to review and approve changes to the system, component or service. The CCB will take security considerations as part of the decision making process. Changes that are approved will need to be documented as a part of the process.\u0026nbsp; The documentation should include the decisions on the changes as well as the changes that are to be made.\u0026nbsp; The CCB should periodically audit and review the activities related to the changes that have been made to the applicable system, component or service. It should also meet often enough to accommodate the changes that are proposed.\u003c/p\u003e\u003cp\u003eThe reason that change control is enacted is to reduce the impact of changes to the CIA of the data processed by the system.\u0026nbsp; The CCB can approve or disapprove of changes for a particular system so that there is no single person making changes to the system.\u0026nbsp; CMS wants to prevent or minimize risks that can occur as a result of unauthorized or uncoordinated changes. \u0026nbsp;This helps to separate the duties involved and adds an extra layer of security. \u0026nbsp;The documentation of changes can help to troubleshoot issues when systems malfunction and to audit the system for compliance to CMS rules and regulations. CMS uses configuration change control to maintain availability through changes that have to be tested and system integrity through audits and approvals for system changes.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Configuration Change Control.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board)] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for a minimum of three (3) years after the change;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through change request forms which must be approved by an organizational and/or CMS change control board that convenes frequently enough to accommodate proposed change requests, and other appropriate organization officials including, but not limited to, the System Developer/Maintainer and information system support staff.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following, which is ensured by the Business Owner, details the CMS specific process for controlling changes to a CMS information system’s configuration.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The Information System Security Officer (ISSO), System Owner (or designee) and the project manager writes a configuration management plan that includes the parts of the system (called configuration items or CIs) which are to be controlled under configuration management procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The project/program manager further describes the process of how decisions are made in the CCB for guidance after members are assigned. This is documented in a Change Management Plan in alignment with the CMS-SDLC\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, System Owner (or designee) and the project manager create a CCB by assigning members and write a charter and operating procedures for the CCB. The CCB must have at least the system developer, Privacy Officer, ISSO (contractor/federal), maintainer, and a member of the information system support staff assigned.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CCB coordinates and oversees configuration control activities. They review change requests (CRs) and should meet often enough to appropriately handle the reviews in a timely manner throughout the life cycle from requirements analysis to disposition. \u0026nbsp;The reviews should produce an approval or disapproval that is recorded via the method in Section 4 of the relevant Change Management Plan.\u0026nbsp; The decision should take into account a \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis (SIA)\u003c/a\u003e, as outlined in CM-4, from the ISSO.\u0026nbsp; They should monitor the status of proposed changes ensuring that only approved changes are applied.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer implements approved changes once passed by the CCB. The CCB must maintain a record of configuration-controlled changes to the information system for a minimum of three (3) years after the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The project/program manager updates the configuration information inside of the System Design Document to reflect the changes approved in the CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB audits implemented changes before the changes are added to the configuration baseline by verifying that the changes fulfill the requirements or requesting the update of documented requirements in response to the CR so it accurately reflect the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB tracks the progress of the implementation of the change by confirming the updates to the configuration documentation in the System Design Document as CRs are approved.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;The CCB checks the configuration of the system periodically for discrepancies against the documented configuration baseline. The configuration audit will determine either whether the configuration of the system is compliant with the approved baseline, at which point they will notify the ISSO to initiate a POA\u0026amp;M.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Document / Notification / Prohibition of Changes (CM-3(1))\u003c/h4\u003e\u003cp\u003eAutomation in the change management process can help to document changes and ensure the proper workflow. CMS uses automated means to document system changes for submission to the CCB. The automated process should cover several things. CMS wants the automated system to notify the authorizing personnel, who were designated to approve changes, whenever changes are proposed. The change request can be automated giving highlight rules to change requests for different statuses such as: awaiting approval, not approved, or overdue (defined in the SSPP). When the approvals come through, this system should alert the stakeholders that the change is approved.\u003c/p\u003e\u003cp\u003eChanging systems are a frequent occurrence. Automating the documentation, along with notification or prohibition of changes, saves CMS resources. Automating these processes can also increase the traceability of changes for many systems at once. This helps to keep accounts of all records linked to each applicable system and to review who approved specific changes and reasons for change.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Automated Document/Notification/Prohibition of Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify [Assignment: organized-defined approval authorities] of proposed changes to the information system and request change approval;\u003c/li\u003e\u003cli\u003eHighlight proposed changes to the information system that have not been approved or disapproved by [Assignment: organization-defined time period];\u003c/li\u003e\u003cli\u003eNotify [Assignment: organization-defined personnel] when approved changes to the information system are completed.\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify designated approval authorities (defined in the SSPP) of proposed changes to the information system;\u003c/li\u003e\u003cli\u003eHighlight proposed changes that have been waiting an approval decision, or have not been approved, for longer than change management procedure (defined in the SSPP) requires;\u003c/li\u003e\u003cli\u003eNotify stakeholders when approved changes are completed. A list of potential stakeholders\u0026nbsp; include, but is not limited to the following:\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair;\u003c/li\u003e\u003cli\u003eChief Risk Officer (CRO);\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA);\u003c/li\u003e\u003cli\u003eISSO;\u003c/li\u003e\u003cli\u003eProgram Manager;\u003c/li\u003e\u003cli\u003eData Guardian;\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO); and\u003c/li\u003e\u003cli\u003eInformation System Administrator.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which are ensured by the Business Owner, outline the process for automating the processes of documenting, notifying, and prohibiting actions during the change control process.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The Information System Security Officer (ISSO), Information System Owner (ISO) and Project Manager develops configuration processes and procedures that include automated mechanisms, documenting them in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;during the proper CMS-SDLC phase. The automated mechanism(s) should be able to prohibit changes to the information system until a change is approved, store all approved Change Requests (CRs), and then notify the stakeholders when approved changes are complete.\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStakeholders to be notified upon implementation of changes (at a minimum):\u003c/strong\u003e\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair\u003c/li\u003e\u003cli\u003eCRO Chief Risk Officer (CRO)\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA)\u003c/li\u003e\u003cli\u003eBusiness Owner(BO)\u003c/li\u003e\u003cli\u003eProgram Manager\u003c/li\u003e\u003cli\u003eData Guardian (DG)\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO)\u003c/li\u003e\u003cli\u003eInformation System Administrator\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e* For the stakeholders mentioned in Table 5 and Step 1 above, the CCB must be notified of system changes. However, each system requires its own group of stakeholders to make up the CCB and there is no expectation for each role listed in Table 5 to receive notifications for every single system change. This is especially true for the Data Guardian who should only receive notification when significant changes are implemented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop, as part of the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e, an automated method of requesting approval from the authorized submitter to the appropriate CCB members to be listed in section 4.2 Roles and Responsibilities.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop the method of automated notification of changes that have requested approval to determine who gets notification at the time of proposal and how they are notified.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe ISSO, ISO, and Project Manager reference the SSPP for handling changes, to determine highlighting rules for CRs that have not been addressed or have not been approved within the designated period.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eTest / Validate / Document Changes (CM-3(2))\u003c/h4\u003e\u003cp\u003eSystems can implement this control by creating an environment to test changes prior to implementation in the operational environment. The testing environment should be separate from the operational environment when possible. The test environment should mirror the operational environment to the \u0026nbsp;maximum extent possible, but CMS realizes deviations will have to be made so long as they are properly documented. Teams performing testing should document the process and procedures associated with the test to include a detailed outcome.\u003c/p\u003e\u003cp\u003eThe purpose of testing changes to the system prior to implementation is to reduce the chance that outages will occur during implementation.\u0026nbsp; The separation of testing from implementation in the operational environment is meant to give network/system administrators an opportunity to see if proposed changes will adversely affect the operational systems. \u0026nbsp;CMS has the goal of reducing the chances that the operational environment will fail as a result of changes to the environment. \u0026nbsp;Implementing this control will reduce breaks in operational environments and enable stakeholders making subsequent changes to reference the documentation created.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for testing, validating, and documenting changes to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer designs and develops the tests for the information system, as required by the CMS-SDLC, to be referenced for testing during changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Change Manager collects CRs and makes sure that they are documented in the automated tool as outlined in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan.\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer with the system/network administrator test the system changes as outlined in the documented CR and approved by the CCB.\u0026nbsp; The test may be conducted on the test environment or operational system while off-line or during a maintenance window using the tests outlined in the test plan.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSecurity Impact Analysis (CM-4)\u003c/h3\u003e\u003cp\u003eOrganizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems.\u003c/p\u003e\u003cp\u003eThe analysis of the security impact of a change occurs when changes are analyzed and evaluated for adverse impact on security, preferably before they are approved and implemented, but also in the case of emergency/unscheduled changes. These analyses are important to CMS because they prevent unnecessary risk to the enterprise.\u003c/p\u003e\u003cp\u003eChanges (in both the change management process and if a significant change will be made that impacts the ATO) should not be accepted without first studying the risks posed by these changes by conducting a security impact analysis. Before the changes are implemented and tested, a security impact analysis (and/or assessment) is performed to ensure that the changes have been sufficiently analyzed and documented, and to determine if there are any unanticipated effects of the change on existing security controls.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eChange Management\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eInformation system changes should not be undertaken prior to assessing the security impact of such changes. If the results of the security impact analysis indicate that the proposed or actual changes can affect, or have affected, the security state of the system; then corrective actions must be initiated and appropriate documents are revised and updated (e.g., the system security plan, security assessment report, and plan of action and milestones, etc.).\u003c/p\u003e\u003cp\u003eThe business owner, or common control provider(s) should consult with their ISSO and/or CRA, and participate in the TRB review process prior to implementing any security-related changes to the information system, or its environment of operation.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSignificant Change\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMany events can trigger change—even events that may not result in an actual system “change”. Significant changes require a formal reauthorization of the system. If a formal reauthorization action is required, the business owner should target only the specific security controls affected by the changes and reuse previous assessment results wherever possible. Most routine changes to an information system or its environment of operation can be handled by the business owner’s continuous monitoring program.\u003c/p\u003e\u003cp\u003eNIST states that a Significant Change to an information system may include (for example): (i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform; (iv) modifications to cryptographic modules or services; or (v) modifications to security controls. Examples of significant changes to the environment of operation may include for example: (i) moving to a new facility; (ii) adding new core missions or business functions; (iii) acquiring specific and credible threat information that the organization is being targeted by a threat source; or (iv) establishing new/modified laws, directives, policies, or regulations.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process to conduct a security impact analysis:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;After receiving the Change Request (CR) submission from the CCB, the ISSO will determine the scope of the change by analyzing the CR form. They will develop a high-level architecture overview that shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), the ISSO will request follow-up documentation/information and review it or use whatever information is available (e.g., audit records, interview staff who made the change, etc.) to gain insight into the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2\u003c/strong\u003e: The ISSO will identify the scope and the categorization of the change.\u0026nbsp; See Appendix D for the SIA Template.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3\u003c/strong\u003e: The ISSO will identify any vulnerabilities (via vulnerability scans, documentation comparison etc.) in the proposed change and analyze the categorizations of change and identify the security controls that are impact by the change (both system specific, hybrid, and inherited controls)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4\u003c/strong\u003e: The ISSO, in consultation with the CRA, conducts a risk assessment of any discovered vulnerabilities (impact and likelihood) and change(s) to security control implementation that has been affected by the change(s). A risk assessment is needed to identify the likelihood of a threat exercising the vulnerability and the impact of such an event.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, assess impact of proposed change on functionality of the system or CI and assess impact of proposed change on existing security controls. For example, the change may involve installation of software that alters the existing baseline configuration, or the change itself may cause or require changes to the existing baseline configuration. The change may also affect other systems or system components that depend on the function or component being changed, temporarily or permanently. For example, if a database that is used to support auditing controls is being upgraded to the latest version, auditing functionality within the system may be halted while the upgrade is being implemented.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, conducts a Privacy Impact Assessment to ensure that a change to the system that affects PII/PHI is accounted for and proper action can be taken if necessary\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7\u003c/strong\u003e: The ISSO, in consultation with the CRA, determine whether the change is part of the change management process or if the change is significant enough that the system authorization is in question. Read the above introduction paragraphs for guidance to help make this determination.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf change management\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit them to the Change Control Board (CCB). If the change is occurring on a contractor system, the contractor’s internal CCB will be responsible for approving changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: If change is occurring on a contractor system, CMS has the ability to request that the contractor conduct an SIA.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf a significant change\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: The ISSO and the CRA will meet with the Business Owner and the Technical Review Board (TRB) to determine if a re-authorization is necessary. If re-authorization is necessary, the ATO package must receive proper approval before implementation.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit to the Change Control Board (CCB).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB or TRB.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSeparate Test Environments (CM-4(1))\u003c/h4\u003e\u003cp\u003eSeparate test environments are used at CMS to host an instance of the operational environment.\u0026nbsp; They should mirror one another in order to create an accurate response to changes as they are made for testing.\u0026nbsp; The environment will be kept separate, physically and/or logically, so that changes in one do not affect the other. \u0026nbsp;Changes will then be analyzed for flaws, weaknesses, incompatibility and intentional/unintentional harm that results from implementation. \u0026nbsp;CCB approved changes should be made in this test environment first, then the production/operational environment. Test environments need to mirror production to the maximum extent possible, but CMS realizes that deviations may have to be made so long as they are properly documented.\u003c/p\u003e\u003cp\u003eSeparating the testing environment from the production environment benefits CMS by allowing a chance to see the changes requested for a system enacted before the changes affect end users. Test environments give a chance to observe possible harm or disrupted functionality without applying the changes to production. It can reduce the risks of change overall, since the production data and operational environment are not harmed when the test environment is adversely affected.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS-specific process to ensure that separate environments have been incorporated into testing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System/Network Administrator creates and maintains a test environment that is similar to the operational environment but either physically or logically separate from it.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator uses the test environment to enact approved changes from the CCB then observe and document the effects of those changes before those approved changes are enacted on the operational system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eAccess Restrictions for Change (CM-5)\u003c/h3\u003e\u003cp\u003eThe changes to a system can be sensitive.\u0026nbsp; CMS calls for restrictions on the access to the system both physically and logically.\u0026nbsp; The access controls to limit change privileges can be implemented through discretionary access controls such as deciding who is on the CCB. Supplemental discretionary access or role-based access controls can be enacted on files using Access Control Lists (ACLs). There can also be physical access restrictions such as those requiring a key to get into datacenter facilities. All together, these access restrictions should be developed, documented, approved and enforced throughout the system life cycle.\u003c/p\u003e\u003cp\u003eRestricting the ability to enact change to a system maintains the overall stability to the system.\u0026nbsp; CMS limits production and operational privileges to make sure that there are controlled inputs to the change control process. Without limitations on change requests for a system, the process may become overwhelmed or inefficient based on unnecessary change requests.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS enacts this control, which is ensured by the Business Owner, by utilizing the following steps:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The Office of Information Technology (OIT) defines and approves access restrictions associated with change to the system during the initial phase of the CMS-SDLC including:\u003cul\u003e\u003cli\u003e\u003cstrong\u003eAdministrative controls –\u0026nbsp;\u003c/strong\u003eSuch as procedures, processes and standards to be used in configuration management\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eRole-based Access Controls\u003c/strong\u003e\u0026nbsp;– Such as those on files and storage related to change documentation\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDiscretionary Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those approving the appropriate personnel to approve changes to the system\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePhysical Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those restricting access to the computer equipment where the change requests and automation systems are kept\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Owner includes the defined access restrictions in the baseline configuration for the information system, to be included as a configuration item for the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO develops physical access controls if there is no description of them available for the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO documents physical and logical access controls in CFACTS under the Controls tab in the Authorization Package. Select Allocated Control CM-5 and list the reference or documented physical controls in the Shared Implementation Details field of the Implementation section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO reviews proposed changes to the physical and logical controls and the BO approves the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;Unapproved physical access changes must be filed as a Risk Acceptance Request documented in CFACTS or returned to the developer for modification of the plans and resubmission to the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Access Enforcement / Auditing (CM-5(1))\u003c/h4\u003e\u003cp\u003eA system under this control will have automation in its access enforcement and auditing. \u0026nbsp;The automation means that the system will check to see if the user or service is authorized to access resources as well as use some form of authentication. \u0026nbsp;During this enforcement of access controls, the system should also log actions for auditing those enforcement actions later.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe access enforcement for a system is important to maintain its security. \u0026nbsp;Automating the enforcement is the most efficient method of maintaining access controls.\u0026nbsp; These controls keep the unauthorized users out.\u0026nbsp; They contribute to the safety of the system through authentication and confidentiality. The confidentiality of the system makes it so that users only see parts of the system they are authorized to see.\u0026nbsp; Authentication ensures that CMS knows the user or service that is attempting to access a resource.\u0026nbsp; Finally, the creation of access control records will allow CMS personnel to evaluate working controls and detect misuse of the system through audits.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for automatically controlling access and auditing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System Developer and Maintainer creates the system with the functionality to audit against access restrictions specifically on changes to the hardware, software, and firmware components of the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer creates the functionality to record and document enforcement actions in relation to the access of data and/or functionality that is restricted in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor cloud-based services, the Cloud Service Provider (CSP) should be enforcing Steps 1 and 2 using automated mechanisms, to be in place before the service is in operation.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReview System Changes (CM-5(2))\u003c/h4\u003e\u003cp\u003eThe review of system changes should be carried out once per week by the CCB. \u0026nbsp;This process should also allow for ad-hoc reviews for checking configurations against the baseline when unauthorized changes have been indicated or there is a dramatic unforeseen shift in performance.\u003c/p\u003e\u003cp\u003eReview is a useful tool utilized by CMS to determine which changes may have been made without permission, or without following the configuration management procedure. \u0026nbsp;Discovering an unauthorized change could mean that there are more unauthorized changes present within the system. Reviewing the system changes is an easy way to check for procedural mistakes or intentionally unauthorized system changes. CMS maintains records of access to ensure that configuration change control is implemented and to support after-the-fact actions should CMS discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3, AU-6 and AU-7.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Review System Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(2)\u003c/td\u003e\u003ctd\u003eThe organization reviews information system changes [Assignment: organization-defined frequency] and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred.\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews information system changes:\u003c/p\u003e\u003cp\u003ea. At least once a week; and\u003c/p\u003e\u003cp\u003eb. When unauthorized changes or unexpected levels of system performance are indicated.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for reviewing system changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The CCB meets to review system changes each week to determine if unauthorized changes were made by checking current configuration baselines against the current configuration of the system to check for CIs that were modified without a corresponding approved CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;When the CCB learns of unauthorized changes taking place or unexpected levels of system performance, they should check the configuration baselines of their systems against the actual configuration of the system to determine whether changes have been made on the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The CCB reports any unauthorized changes to the ISSO within 24 hours of the finding.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSigned Components (CM-5(3))\u003c/h4\u003e\u003cp\u003eSigned components are parts of code that are used to create a digital signature and packaged together, code and signature. The digital signature is created from certificate assigned to the author of the code by a trusted certification authority.\u003c/p\u003e\u003cp\u003eCMS uses signed firmware and software components to know who the authors of the code are. The digital signature scheme and the Public Key Infrastructure together provide a way to institute non-repudiation for firmware and software updates.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Signed Components.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(3)\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of network and server software and firmware components without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for signing components:\u003c/p\u003e\u003cp\u003eCode that is taken from third party providers must have a signature from the author. At CMS, the system administrators apply the correct configuration that automatically stops firmware and software components from being installed without a digital signature.\u0026nbsp; These settings are in use as part of CMS’ configuration baselines for systems.\u0026nbsp; In Windows-based systems, this is performed through Active Directory group policy objects.\u0026nbsp; The group policy is applied to the target computer object and results in the computer being configured to restrict software and firmware installations without digital signatures.\u0026nbsp; The certificate for the software should be from a trusted certificate authority and the certificate should not be trusted if it is self-signed. A trusted certificate authority is designated as such by DHS, HHS, and CMS.\u003c/p\u003e\u003ch3\u003eConfiguration Settings (CM-6)\u003c/h3\u003e\u003cp\u003eHHS has outlined guidance for use when configuring information system components for operation.\u0026nbsp; Configuration standards vary depending upon the technical characteristics of the information system (e.g. operating systems, databases, firmware, etc.)\u0026nbsp; The\u0026nbsp;\u003cem\u003eMinimum Security Configurations Standard Guidance\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u003c/em\u003eissued by the Department of Health and Human Services shall be applied to all applicable systems. If an HHS-defined configuration standard baseline is not available than the\u0026nbsp;\u003cem\u003eU.S. Government Configuration Baseline\u003cstrong\u003e\u0026nbsp;(\u003c/strong\u003eUSGCB)\u003c/em\u003e\u0026nbsp;will be applied to the applicable systems.\u0026nbsp; For those systems not covered under USGCB, the\u0026nbsp;\u003cem\u003eNational Checklist Program\u003c/em\u003e\u0026nbsp;can be followed for configuration guidance.\u003c/p\u003e\u003cp\u003eThe purpose of creating common configuration settings is to streamline management and security implementations.\u0026nbsp; CMS configures systems with standardized settings and automates their implementation to save time and create a baseline of security that applies to all information systems, thereby, minimizing risk across the enterprise.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Configuration Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements];\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using the latest security configuration baselines established by the HHS, U.S. Government Configuration Baselines (USGCB), and the National Checklist Program (NCP) defined by NIST SP 800-70 Rev. 2 (refer to Implementation Standard 1 for specifics) that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for individual components within the information system based on explicit operational requirements (defined in the system security plan [SSPP]);\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for documenting configuration changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The CMS System Developer and Maintainer uses the HHS approved configurations and creates the configuration for the applicable information system using\u0026nbsp;\u003cem\u003eHHS\u0026nbsp;\u003c/em\u003edefined security configurations\u003cem\u003e\u0026nbsp;\u003c/em\u003eas the guidance in their creation. For USGCB (HHS Approved) Configuration, the appropriate operating system and/or applications is Microsoft Windows Supported Versions.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer using other OSes and applications develops configurations from guidelines in the following priority:\u003cul\u003e\u003cli\u003eHHS\u0026nbsp;\u003cem\u003eMinimum Security Configuration Standards Guidance\u003c/em\u003e\u003c/li\u003e\u003cli\u003eUSGCB\u003c/li\u003e\u003cli\u003eNIST NCP – Tier IV, then III, II, I in descending order\u003c/li\u003e\u003cli\u003eTechnical Reference Architecture Volume IV – Development and Application Services\u003c/li\u003e\u003cli\u003eDISA Security Technical Implementation Guide (STIG)\u003c/li\u003e\u003cli\u003eNSA STIG\u003c/li\u003e\u003cli\u003eLacking a Federal government-authored checklist, using an industry group or vendor checklist (Such as Center for Internet Security (CIS) benchmarks)\u003c/li\u003e\u003cli\u003eCollaboration within CMS to i) Establish baselines and communicate industry and vendor best practices; and ii) Ensure deployed configurations are supported for security updates\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer documents secure configuration settings for the information system using the procedures in Section 3.1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The network is scanned regularly for compliance with the established baseline configuration.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The information systems that are out of compliance are re-configured with baseline settings by the System Developer and Maintainer, in collaboration with the Vulnerability Management Team.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following steps are intended for use if the information system is cloud-based from a Cloud Service Provider (CSP).\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The OIT creates a baseline configuration with the CSP for their IT products inside the information system using USGCB as a guide to create the most restrictive mode consistent with operational requirements.\u003cul\u003e\u003cli\u003eIf USGCB does not apply, then they use the CIS benchmarks as guides to create the most restrictive mode consistent with operational requirements.\u003c/li\u003e\u003cli\u003eIf neither USGCB nor CIS applies, then they create their own benchmark of configuration settings.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS ISSO and the System Developer and Maintainer creates Security Content Automation Protocol (SCAP) compatible security configuration checklists if there are no validated ones available. The list should be formatted so that it can be read by a validated SCAP tool and enable that tool to determine if the approved configuration is in place.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDeviations\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe following steps are intended for creating deviations to established configuration settings.\u0026nbsp; If the settings established using a standard for baseline configurations have significant detrimental impacts on a system’s ability to perform CMS duties, then follow the steps below to file for a Risk Acceptance. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HHS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eStarting from the established baseline\u003cem\u003e,\u0026nbsp;\u003c/em\u003ethe System Developer and Maintainer documents all of the deviations from the baseline that either:\u003cul\u003e\u003cli\u003eAre not intended to be implemented since the standard(original baseline) setting would interfere with business operations\u003c/li\u003e\u003cli\u003eAre cost prohibitive\u003c/li\u003e\u003cli\u003eAre technically infeasible\u003c/li\u003e\u003cli\u003eHave an impact to operations\u003c/li\u003e\u003cli\u003eCause a loss of functionality\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the collected deviation(s) documented in the previous step by working with the BO to determine if configurations would restrict the types of information used, adversely affect the boundaries or adversely affect the information shared with other systems.\u0026nbsp; Furthermore, the ISSO reviews the list for completeness to ensure it has all the information needed for the Risk Acceptance form. The ISSO selects deviations to be approved by the CISO and CRA through the Risk Acceptance form or otherwise returned to the System Developer and Maintainer within 90 days of receipt with an explanation as to why the deviation was rejected.\u0026nbsp; Then the System Developer and Maintainer can re-submit in the next review period. These actions \u0026nbsp;must be thoroughly documented in CFACTS. The process for documentation is explained in detail below.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO (or System Maintainer) logs into CFACTS and fills out and signs the Risk Acceptance form including all deviations from the baseline configuration that should be considered for the information system in Section 2\u0026nbsp;\u003cem\u003eWeaknesses\u003c/em\u003e\u0026nbsp;with the following information at a minimum:\u003cul\u003e\u003cli\u003eAllocated Control = CM-6\u003c/li\u003e\u003cli\u003eFinding Description\u003c/li\u003e\u003cli\u003eWeakness Description\u003c/li\u003e\u003cli\u003eEffect on Business\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe ISSO then fills out Section 3\u0026nbsp;\u003cem\u003eProposed Risk Acceptance\u003c/em\u003e\u0026nbsp;with all of the information related to the risk(s) that will be accepted and how/if the risk will be mitigated to include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eOverview of the Risk Acceptance Request\u003c/li\u003e\u003cli\u003eBusiness Justification for the Risk Acceptance\u003c/li\u003e\u003cli\u003eJustification for Request\u003c/li\u003e\u003cli\u003eCompensating Controls (if any)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CISO, BO, and CIO approve deviations from the configuration baseline and authorizes, using the Risk Acceptance form Section 5, the new configuration to be used in the CMS environment.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Every year, the ISSO reviews the deviations and exceptions in place on the system. He or she takes the accepted deviations and considers them collected, documented deviations to start over from Step 11 for re-certifying the configuration of the system.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Central Management / Application / Verification (CM-6(1))\u003c/h4\u003e\u003cp\u003eAutomating the management of operating systems and applications gives CMS more control over the information systems in the CMS infrastructure and those processing CMS data.\u0026nbsp; Automation is implemented to create a point (or points) of central management for administrators to change, apply, verify, and enforce configuration baselines and mandatory configuration settings. CMS uses the HHS defined security configuration standards as the basis for the configurations of information systems, components and applications. \u0026nbsp;CMS Information systems are expected to allow access to automated methods of configuration management, change and verification. \u0026nbsp;\u003c/p\u003e\u003cp\u003eUsing these policies and procedures for the CMS environment assures an even application of approved configurations across the network. \u0026nbsp;These configurations are applying the settings that will secure each system and application according to CMS’s business and regulatory needs, specifically to enforce the baseline and the mandatory configuration settings. \u0026nbsp;CMS is able to implement the settings and verify that they are correct using this control. \u0026nbsp;Verification is used to show compliance.\u0026nbsp; The combination of configuration and verification makes this control necessary for large enterprise environments such as CMS.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for Automated Central Management\\Application\\Verification.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for \u0026nbsp;information system components as defined in the HHS Minimum Security Configuration Standards for Departmental Operating Systems and Applications.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for automation of central management:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer configures the information system with the tools necessary to automate monitoring and configuring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO contacts the CDM program (Appendix G) in order to find out how to connect their system to the central management mechanism.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The system is scanned regularly by the System Developer and Maintainer for compliance with approved configurations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The configuration changes are applied by the System Developer and Maintainer using configuration management tools to information systems after they have been approved by the OIT.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRespond to Unauthorized Changes (CM-6(2))\u003c/h4\u003e\u003cp\u003eIt is the duty of CMS authorized personnel to respond to unauthorized changes to the information system, components or its data.\u0026nbsp; The response should include notifying the business owner and ISSO. Additionally, the configuration should be restored to an approved version and further system processing can be halted as necessary.\u003c/p\u003e\u003cp\u003eCMS prevents or rolls back these changes to ensure that they go through the process of change management and receive the appropriate approvals and security checks before implementation. \u0026nbsp;Unauthorized changes that have not undergone security vetting may introduce new vulnerabilities that have not been mitigated by existing security controls. \u0026nbsp;The potential for increase of risk leads CMS to respond to unauthorized changes as soon as possible.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-6(2) Respond to Unauthorized Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(2)\u003c/td\u003e\u003ctd\u003eThe organization employs [Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings].\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization responds to unauthorized changes to information system and components (e.g., authorization, auditing, processing types, baselines) and data (e.g., system libraries, log files, executables) in the following ways:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u0026nbsp;\u003col\u003e\u003cli\u003eAlert responsible actors (person, organization);\u003c/li\u003e\u003cli\u003eRestore to approved configuration; and\u003c/li\u003e\u003cli\u003eHalt system processing as warranted.\u003c/li\u003e\u003c/ol\u003e\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for responding to unauthorized changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; Unauthorized changes are automatically stopped, when possible, by halting system processing using management tools and permission restrictions. \u0026nbsp;Attempts to make unauthorized changes generate alerts that are documented in centralized audit files.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eCDM informs the Incident Management Team in Information and Security Privacy Group (ISPG) when unauthorized changes occur if an unauthorized individual accesses the system that made the change. If an authorized individual made a valid change but did not follow the CM process, CDM contacts the individual and requests that they roll back the change and follow the appropriate CM procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;Incident Management Team coordinates the incident response and assists stakeholders in deciding whether to retrieve the information system or otherwise restore the settings to the approved baseline.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eLeast Functionality (CM-7)\u003c/h3\u003e\u003cp\u003eThe principle of least functionality must considered when configuring a system. \u0026nbsp;This involves first documenting the essential capabilities of the system.\u0026nbsp; After that, the system can be configured to accommodate these capabilities while turning off non-essential functionality.\u0026nbsp; At CMS, we pay special attention to high-risk system services and additionally turn those off unless they are absolutely needed.\u003c/p\u003e\u003cp\u003eCMS integrates security principles into its system development and design.\u0026nbsp; This control addresses the principle that systems are granted only those functions that are needed in order for them to accomplish their tasks.\u0026nbsp; This includes system services, which traverse network boundaries that are considered high-risk.\u0026nbsp; This aims to reduce the “attack surface” of a system.\u0026nbsp; Attack surface refers to the points that an attacker might target when compromising a system.\u0026nbsp; Reducing functionality that goes beyond a system’s tasks leads to minimizing risk resulting in fewer attack vectors and leaving fewer options for attack.\u0026nbsp; CMS reduces the risk as much as possible for each system to prevent attacks.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM least functionality.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003eb. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eProhibits or restricts the use of high-risk system services, ports, network protocols, and capabilities (e.g., Telnet, FTP, etc.) across network boundaries that are not explicitly required for system or application functionality.\u003c/li\u003e\u003cli\u003e[Added] A list of specifically needed system services, ports, and network protocols must be maintained and documented in the applicable security plan; all others will be disabled.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, which is ensured completed by the Business Owner, details the CMS procedure for least functionality:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eTo capture the functionality, the ISSO and the system developer and maintainer should refer to the Intake Form completed during the initial phase of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer logs into CFACTS to reference the network boundaries as shown in the\u0026nbsp;\u003cem\u003eCFACTS User Manual\u003c/em\u003e\u0026nbsp;in section 4.4\u0026nbsp;\u003cem\u003eBoundary Tab\u003c/em\u003e. They must also consider the system description, purpose, functionality, and architecture. This information can be used to turn off high-risk system services on the system or system components if they are not needed for system or application functionality.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer keeps a record of explicitly required system services, ports and network protocols, maintains it on an ongoing basis throughout the CMS-SDLC and communicates changes to the ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO enters the explicitly required system services, ports and network protocols into the\u0026nbsp;\u003cem\u003eSystem Security Plan\u003c/em\u003e\u0026nbsp;in CFACTS using the Boundaries Details section and in the implementation details for control CM-7.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003e\u0026nbsp;Periodic Review (CM-7(1))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eReview of ports, services, functions and protocols involves checking the system periodically.\u0026nbsp; The system checks will make comparisons of what is used and what is authorized for use.\u0026nbsp; CMS will then use that information to make a determination of which ports, services, functions and protocols should be disabled.\u0026nbsp; The system scans will identify the PPS, and then an analysis will have to be conducted to determine if they can be disabled.\u003c/p\u003e\u003cp\u003ePeriodic review within CMS helps to protect the systems in its infrastructure.\u0026nbsp; The protection comes from reducing the attack surface as stated in “\u003cem\u003eLeast Functionality CM-7\u003c/em\u003e” to reduce the risk to the network.\u0026nbsp; Reviewing on a periodic basis allows CMS to check continually for weaknesses and baseline anomalies.\u0026nbsp; The change management process can introduce weaknesses into the environment, so it is important to evaluate systems on an ongoing basis to determine the consequences of changes, including unintentional or unforeseen consequences that affect the risk to that system.\u0026nbsp; CMS authorizes scanning systems on this basis since change management is also an ongoing process in itself.\u0026nbsp; This helps to keep checks coordinated with changes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM periodic review.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or non-secure functions, ports, protocols, and services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eDisables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure].\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system no less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003ePerforms automated reviews of the information system no less often than once every seventy-two (72) hours to identify changes in functions, ports, protocols, and/or services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eDisables functions, ports, protocols, and services within the information system deemed unnecessary and/or non-secure.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process details the CMS procedure for periodic review:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe Continuous Diagnostics and Mitigation (CDM) team coordinates with the ISSO to monitor functions, ports, protocols, and services. The CDM sends periodic review information to the ISSO regarding their monitoring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The CDM team automatically scans the information system for changes in functions, ports, protocols and/or services at least every 72 hours and more frequently as necessary. \u0026nbsp;The scans should include systems, appliances, devices, services and applications (such as databases). This is performed on an ongoing basis until the system is retired. Changes are documented and sent to the system ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the system every 30 days using the reports taken from the CDM program.\u0026nbsp; The reports are compared against the System Architecture and Architecture Design section inside of the System Design Document\u003cem\u003e\u0026nbsp;\u003c/em\u003ein CFACTS for its listing of necessary functions, ports, protocols and services.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer along with the ISSO work together to disable unnecessary functions, ports, protocols and services with advice from the CRA. This is performed on an ongoing basis as they are discovered.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003ePrevent Program Execution (CM-7(2))\u003c/h3\u003e\u003cp\u003eThis control is implemented to ensure that CMS is using the software it has acquired responsibly and legally. \u0026nbsp;To execute this control there must be methods in place to prevent executing software that is not:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLicensed for use\u003c/li\u003e\u003cli\u003eConfigured for use at CMS\u003c/li\u003e\u003cli\u003eExecuted by an authorized user\u003c/li\u003e\u003c/ul\u003e\u003cp\u003ePreventing these executions should be done automatically, and the users must not be permitted to execute the programs themselves.\u003c/p\u003e\u003cp\u003eThese program preventions are a part of CMS’s security controls to ensure that security is built into the basic elements of systems through software. This is done to apply settings, which CMS knows are protecting the interests of the organization. \u0026nbsp;This is extended to licensing to make sure CMS is not exposed to risk by using software that is unlicensed. \u0026nbsp;Unlicensed software may violate the law or introduce new risks through its operation. \u0026nbsp;\u0026nbsp;Risk from operation is also included in this control by restricting software to those that are authorized to use it. Unauthorized users may not be assigned the responsibility of using certain types of software and CMS uses separation of duties to spread out job responsibilities among groups of people to reduce risk and insider threats.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-7(2) prevent program execution.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(2)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with policies regarding authorized software use which include, but are not limited to the following:\u003c/p\u003e\u003cp\u003e\u0026nbsp;a. Software must be legally licensed;\u003c/p\u003e\u003cp\u003e\u0026nbsp;b. Software must be provisioned in approved configurations; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;c. Users must be authorized for software program use.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThis control is system specific, but the following is a good example of how to implement and document the control:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe administrators of the system create the baseline configuration for software on the computer image.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eSystem administrators configure the domain settings to disallow software installations for all Users without administrative privileges.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eSystem administrators distribute computer images for all government issued computers using authorized and licensed software, and ensures that it is using approved configurations for the software included\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor software that is not included in the computer image for the baseline configuration, use the following steps to allow execution in accordance with policies.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe user checks the website for the Office of Information Technology to find if the software that they are requesting has been tested by CMS for conflicts and/or malicious behavior using the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u003c/em\u003e\u0026nbsp;here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eNote:\u0026nbsp;\u003c/strong\u003eSoftware that is supported under an enterprise license is a subset of the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u0026nbsp;\u003c/em\u003efrom step 4; please refer to the OIT website for Enterprise Software Licensing here for more information:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\u003c/a\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eIf the software is not in the list, then submit the software for testing following the steps in the procedure on the OIT website:\u0026nbsp; \u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u0026nbsp;, if the software is on the list then skip to the next step\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp;\u003c/strong\u003eThe user of the software must acquire the license for the software that they wish to use using the forms of proof provided by CMS Deskside support listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp;\u003c/strong\u003eThe user submits a new installation request following the procedure listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\u003c/a\u003e\u0026nbsp;in which the Deskside support personnel will validate the license, authorize the user to use the software and provision the software in approved configurations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eUsers operate under restricted privileges per CM-7 - least privilege, which will logistically prevent program execution through system policies. For those users who may get software installed surreptitiously or have administrative privileges, the following steps will apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp;\u003c/strong\u003eThe operations team within ISPG monitors the network for software network behavior and/or traffic from unauthorized software, when possible, to discover, and create alerts to notify the CMS Security Operations Center (SOC) if unauthorized software use is logged.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u003c/strong\u003e\u0026nbsp;The SOC reviews alerts daily to determine if unauthorized software is in use as part of their duty. When discovered, the SOC isolates the computer on the network if needed and uninstalls the unauthorized software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp;\u003c/strong\u003eThe SOC utilizes automated methods of managing software and notifies the user when unauthorized software is detected and automatically removes the software before the next 48 hours.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAuthorized Software / Allowlisting (CM-7(5))\u003c/h4\u003e\u003cp\u003eThe authorized software allowlisting control means that CMS would document the software that is allowed to run on CMS systems. The software name and its representation would be used to determine if a specific piece of software is on the list. Software on the list is allowed to execute and all other software is denied by default. As part of the implementation of this control, the list should be updated regularly and automatically from a trusted source.\u003c/p\u003e\u003cp\u003eUsing an allowlist instead of a denylist is an option to consider for environments that are more restrictive. The list itself is known, and the system denies all other software. CMS can use an allowlist to lessen the uncertainty in a system through this prevention of executing the unknown. Decreasing the uncertainty in this case can also lead to decreasing the risk that malware or software outside of that needed for the operation of a system is executed.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Authorized Software/Allowlisting.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(5)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies [Assignment: organization-defined software programs authorized to execute on the information system];\u003c/li\u003e\u003cli\u003eReviews and updates the list of authorized software programs [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies defined software programs (defined in the applicable security plan) authorized to execute on the information system;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eReviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and\u003c/li\u003e\u003cli\u003e[Added] Receives automated updates from a trusted source.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for Authorizing Software or Allowlisting:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u0026nbsp;If no Denylisting solution is in place, then an Allowlisting solution must be used.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO, working with the System/Network Administrator and the System Developer and Maintainer, identifies and defines the software programs that are authorized for use on the information system. Then lists them in the applicable part of CFACTS. The list can be held under the\u0026nbsp;\u003cem\u003e“Controls”\u003c/em\u003e\u0026nbsp;tab, in the\u0026nbsp;\u003cem\u003e“Allocated Controls”\u0026nbsp;\u003c/em\u003esection for control CM-7(5) as part of the “\u003cem\u003eShared Implementation Details”\u003c/em\u003e\u0026nbsp;subsection.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures an automated software Allowlisting tool for their applicable information systems so they only allow execution of software that has previously been approved for install/use listed in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO automatically updates and reviews the list of software from Step 1 no less often than every 72 hours from a trusted source such as, but not limited to:\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eCMS internal processes\u003c/li\u003e\u003cli\u003eOther agencies within the federal government\u003c/li\u003e\u003cli\u003eThe vendor of the Allowlisting product\u003c/li\u003e\u003cli\u003eIndustry specialists\u003c/li\u003e\u003cli\u003eCMS systems, appliances, devices, services and applications (to include databases)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the tool to provide results that are searchable by the CCIC.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for allowlisting information must be provided by the timeframe listed within the request.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor cloud-based\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003esystems that run software\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer configures the cloud-based system or service to only allow authorized software to execute following the steps above with or without an automated Allowlisting tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eInformation System Component Inventory (CM-8)\u003c/h3\u003e\u003cp\u003eInformation system components are parts of the CMS network used to process, store or transmit CMS information.\u0026nbsp; The components must each have an identifier that should be received from the property office in the form of an asset tag, which should be linked in an inventory system with the name of the asset, location, asset identification, owner, and description of use. More information can be added as needed, but those fields are the minimum.\u0026nbsp; Then the component inventory should be linked to the CDM tools so monitoring can be linked to specific components.\u003c/p\u003e\u003cp\u003eCMS takes an inventory of information system’s components as a fundamental part of protecting the infrastructure.\u0026nbsp; Inventories contain items that need to be checked for secure configurations, and they provide a logical baseline so that components found outside of the inventory can be scrutinized and unauthorized components removed, disabled or authorized.\u0026nbsp; Unauthorized components could be indicative of a security risk and should be investigated. This control also adds to the accountability of the system. Each component is a part of the system and the same security protections should apply to all components. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Information System Component Inventory.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eDevelops and documents an inventory of information system components that:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eReviews and updates the information system component inventory [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Develops and documents an inventory of information system components that:\u003c/p\u003e\u003cp\u003e1. Accurately reflects the current information system;\u003c/p\u003e\u003cp\u003e2. Include all components within the authorization boundary of the information system;\u003c/p\u003e\u003cp\u003e3. Are at the level of granularity deemed necessary for tracking and reporting; and\u003c/p\u003e\u003cp\u003e4. Includes:\u003c/p\u003e\u003cp\u003e- Each component’s unique identifier and/or serial number;\u003c/p\u003e\u003cp\u003e- Information system of which the component is a part;\u003c/p\u003e\u003cp\u003e- Type of information system component (e.g., server, desktop, application);\u003c/p\u003e\u003cp\u003e- Manufacturer/model information;\u003c/p\u003e\u003cp\u003e- Operating system type and version/service pack level;\u003c/p\u003e\u003cp\u003e- Presence of virtual machines;\u003c/p\u003e\u003cp\u003e- Application software version/license information;\u003c/p\u003e\u003cp\u003e- Physical location (e.g., building/room number);\u003c/p\u003e\u003cp\u003e- Logical location (e.g., IP address, position with the information system [IS] architecture);\u003c/p\u003e\u003cp\u003e- Media access control (MAC) address;\u003c/p\u003e\u003cp\u003e- Ownership;\u003c/p\u003e\u003cp\u003e- Operational status;\u003c/p\u003e\u003cp\u003e- Primary and secondary administrators; and\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003e- Primary user. Reviews and updates the information system component inventory no less frequently than every 180 days for High systems or 365 days for Moderate and Low systems, or per CM-8(1) and/or CM-8(2), as applicable.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops and documents an inventory of information system components. For this, they or a designee gathers the following information to be checked off and documented from each FISMA information technology item, including all components within the authorization boundary:\u003cul\u003e\u003cli\u003eUnique ID (or serial number) such as the asset tag number\u003c/li\u003e\u003cli\u003eInformation system that the component is a part of\u003c/li\u003e\u003cli\u003eAre controls inherited?\u003c/li\u003e\u003cli\u003eHigh Value Asset?\u003c/li\u003e\u003cli\u003eInformation system component type\u003c/li\u003e\u003cli\u003eManufacturer \u0026amp; model\u003c/li\u003e\u003cli\u003eOperating system type and version number\u003c/li\u003e\u003cli\u003eVirtual machine presence\u003c/li\u003e\u003cli\u003eApplication\\software license \u0026amp; version information (when applicable)\u003c/li\u003e\u003cli\u003ePhysical location\u003c/li\u003e\u003cli\u003eLogical location\u003c/li\u003e\u003cli\u003eMedia access control (MAC) address\u003c/li\u003e\u003cli\u003eResponsible party (Owner)\u003c/li\u003e\u003cli\u003eOperational status\u003c/li\u003e\u003cli\u003ePrimary \u0026amp; secondary administrator(s)\u003c/li\u003e\u003cli\u003ePrimary user(s)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO checks the details listed in the asset management tool and determine if the information gathered is enough to track and report on the component and then add fields as necessary. \u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews for accuracy and missing information and update the information system component inventory every 180 days for systems rated as “High” and every 365 days for systems rated as “Moderate” or “Low” from the system categorization in\u0026nbsp;\u003cem\u003eRMH Chapter 12\u003c/em\u003e\u0026nbsp;Section 3.1.2. T\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;System Developer and Maintainer configures the inventory system(s) to provide updates in a format compliant with CMS and federal standards to the CCIC at least once every 72 hours.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for component information must be provided by the timeframe within the request.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The Network/System Administrator provides timely, as defined by the CISO, responses to informational requests about component status and posture information.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eUpdates During Installations / Removals (CM-8(1))\u003c/h4\u003e\u003cp\u003eThe purpose of this control is to ensure that the component inventory is up-to-date in times of change. The CMS system inventory should be updated in cases of: information system component installs, removals, and updates.\u003c/p\u003e\u003cp\u003eUpdates during installations and removals to the inventory system is necessary to keep current information. The result of an upgrade, installation or removal can involve different components altogether. If the system inventory is not current, then the assumptions based on the inventory will not be accurate. It can have far-reaching impact beyond the current system and should involve updates as part of the procedure. Furthermore, updating the inventory supports accountability controls and breach response efforts.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for Updates During Installations/Removals component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe ISSO inputs new information system components into the inventory when they are installed to include the information input for systems in Section 3.7 Step 1 above.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO updates the inventory when an information system component is removed from the system. The component is taken out of inventory.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO updates the inventory when an information system is updated, changing information that is listed in the inventory such as that in Section 3.7 Step 1.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Maintenance (CM-8(2))\u003c/h4\u003e\u003cp\u003eThe CMS inventory system should be able to gather information and update records automatically.\u0026nbsp; The inventory system makes the database complete, accounting for inventory from purchase to disposition.\u0026nbsp; It is accurate, automated where possible and checked for accuracy. It is also meant to be readily available.\u0026nbsp; The system should be fault tolerant to ensure that the information on inventory is there when needed.\u003c/p\u003e\u003cp\u003eCMS uses automated inventory maintenance to show what information system components are available at any given time.\u0026nbsp; Knowing what inventory is supposed to be in the environment compared to what components are seen on the network, CMS can make determinations about components and their suitability. \u0026nbsp;If the component is in inventory and not detected through CDM for a time specified by CMS, then it may need to be flagged as a potentially compromised component. On the other hand, if a component is not in inventory and detected on the network, then it should be flagged as an unauthorized component until verified. These examples show some issues with risk by using inventory anomalies in CMS’ assessments of risk.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for automated information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to maintain the inventory of the information system including all components. The methods should include automation where possible and it should be available for review.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO compares the inventory system to physical inventory to evaluate accuracy and completeness, every 365 days for low/moderate systems and every 180 days for high systems.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Unauthorized Component Detection (CM-8(3))\u003c/h4\u003e\u003cp\u003eThe detection of components is utilized at CMS to determine whether a component is authorized or not.\u0026nbsp; By using an inventory of components that are authorized to be on the network, CMS can utilize a mechanism to compare a discovered component with the inventory.\u0026nbsp; The scans must be done on a weekly basis, more frequently as needed.\u0026nbsp; The mechanism for discovery should be automatic and detect hardware, software and firmware components within the information system.\u0026nbsp; When a component is found to be unauthorized then the automated mechanism should take measures to do the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrevent access to the component\u003c/li\u003e\u003cli\u003eEffectively disconnect the component from the network\u003c/li\u003e\u003cli\u003eIsolate the component\u003c/li\u003e\u003cli\u003eNotify responsible party as specified by the SSPP\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS intends to automate where possible to stop malicious attacks as they occur.\u0026nbsp; Stopping the communication with an unauthorized component as soon as possible is the goal of this control.\u0026nbsp; The automated responses helps CMS address threats in a timely manner since utilizing technology is consistently faster than a manual process would be able to address.\u0026nbsp; In order to review and take action against unauthorized components quickly, automation is the ideal solution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM automated unauthorized component detection.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(3)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components and/or provisioned configurations are detected:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;1. Disable access to the identified component;\u003c/p\u003e\u003cp\u003e\u0026nbsp;2. Disable the identified component’s network access;\u003c/p\u003e\u003cp\u003e\u0026nbsp;3. Isolate the identified component; and\u003c/p\u003e\u003cp\u003e4. Notify the responsible actor (i.e., person/organization defined in security plan).\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the process for automated unauthorized component detection:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO, working with the Business Owner, monitors the network to determine if unauthorized components are connected. The scan should be done at least weekly then as necessary for components that match the inventory in the automated inventory record.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO forwards unauthorized components to the Incident Management Team (IMT.)\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAccountability Information (CM-8(4))\u003c/h4\u003e\u003cp\u003eInformation system components are accounted for in the CMS inventory.\u0026nbsp; This listing has accountability information attached to it that may be referenced when a component is compromised. The information contains the role(s) or individual(s) responsible and/or accountable for the information system components.\u003c/p\u003e\u003cp\u003eThe information listed about CMS system components is designed as a reference for security personnel.\u0026nbsp; The accountability information is used when, for example, the component needs to be replaced, is the source of a breach or a compromise, or needs to be relocated.\u0026nbsp; A control for accountability information provides CMS with the contact information needed during incident response and times of change. The risk associated with those situations is assigned appropriately to the responsible person who can delegate the associated work.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for accountability information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(4)\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components.\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by the System Developer/Maintainer or the Business Owner, \u0026nbsp;\u0026nbsp;the individuals responsible/accountable for administering those components.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, ensured is completed by the Business Owner, details the CMS procedure for keeping accountability information:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to identify the individual(s), to include position and role, responsible and accountable for administering information system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO documents and maintains the information of individual(s) responsible for administering the information system components.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eNo Duplicate Accounting of Components (CM-8(5))\u003c/h4\u003e\u003cp\u003eThis control is used in CMS to ensure components are not duplicated in inventories.\u0026nbsp; The inventory that lists all components shall not have more than one of the same instance of a component.\u003c/p\u003e\u003cp\u003eCMS avoids duplicate accounting in inventory systems because it creates a source of confusion for responsibility and remediation.\u0026nbsp; Systems can be large and complex, involving many different components that interact with each other as well as other interconnected systems.\u0026nbsp; Assigning a component to a single system inventory streamlines accounting and reduces the time and effort to discern applicable parties responsible for that component. It also leads to straightforward remediation of vulnerabilities when discovered since the component is linked to a single system.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for verifying that the accounting for information system components are not duplicated:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO documents the system components inside of CFACTS using the Authorization Package for the system inside of the\u0026nbsp;\u003cem\u003e“Boundary”\u003c/em\u003e\u0026nbsp;tab under the\u003cem\u003e\u0026nbsp;“Hardware”\u003c/em\u003e\u0026nbsp;and\u0026nbsp;\u003cem\u003e“Software”\u0026nbsp;\u003c/em\u003esections.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO sorts hardware and then software by unique attributes to check if all components have different unique attributes from one another whenever entering in new system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;If there is no duplication of component attributes then no further action is needed. If the ISSO identifies a duplication of unique attributes for a component then proceed to the next step.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO removes the duplicate component attribute from the system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Management Plan (CM-9)\u003c/h3\u003e\u003cp\u003eThe CMS-SDLC incorporates a configuration management plan into the planning process. The plan is designed to document the process and procedures for configuration management.\u0026nbsp; The plan shall cover certain areas in order to fulfill this security control.\u0026nbsp; Listed in the document are roles of stakeholders, their responsibilities, processes and procedures.\u0026nbsp; The document shall also outline current configuration items.\u0026nbsp; Specifically, one of the processes covered shall be how to identify a configuration item.\u0026nbsp; The plan shall be protected, after it is finalized, from modification or unauthorized disclosure as are the configuration baselines.\u003c/p\u003e\u003cp\u003eConfiguration management plans define people, processes and procedures.\u0026nbsp; The plans establish the technical and administrative direction and surveillance for the management of configuration items.\u0026nbsp; CMS uses this plan to separate responsibility and add traceability to protect the integrity of systems.\u0026nbsp; Changes are documented and explicitly approved or rejected, so there is accountability regarding the approver, and changes that were made on the system without approval.\u0026nbsp; Implementing the plan properly helps CMS pinpoint issues related to changes, leading to quicker resolutions and rollbacks to repair them.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for developing, documenting and implementing a configuration management plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The CMS Program/Project Manager completes a configuration management plan.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Program/Project Manager documents roles and responsibilities for the plan in a\u003cem\u003e\u0026nbsp;\u003c/em\u003eRoles \u0026amp; Responsibilities section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager defines the processes and procedures involved with configuration management. Configuration Management Administration and Methods and Tools sections should be included.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager lists CIs for the information system in a System Design Document.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager protects the document from unauthorized disclosure or modification by using access control methods for storage locations to restrict access to authorized personnel only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSoftware Usage Restrictions (CM-10)\u003c/h3\u003e\u003cp\u003eCMS will establish and enforce procedures for identifying and removing inappropriate software.\u0026nbsp; Contractors and Government employees are expected to use software and associated documentation according to applicable law and contractual agreements.\u0026nbsp; CMS is responsible for the prevention, monitoring, and removal of unauthorized software.\u0026nbsp; Installed software and documentation will be monitored as needed to determine if its use is allowed by the license or contract. Additionally, peer-to-peer file sharing technology is not expected to be used except as approved by the CIO, but such traffic will be inspected to determine if sensitive or protected content was being shared.\u003c/p\u003e\u003cp\u003eSoftware usage restriction assists in safeguarding against the sharing of copyrighted material and/or the use of software in a manner that would violate CMS agreements. \u0026nbsp;CMS tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution.\u0026nbsp; CMS also controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.\u0026nbsp; This reduces CMS liability by preventing potential copyright violations. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-10 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;System/Network Administrator ensures that the software has been previously tested according to the CMS testing procedure found here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e. A list of previously tested software is available here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator reviews the installation request for the software proof of purchase, unless it was custom developed in-house, which includes:\u003cul\u003e\u003cli\u003eApproved purchase record\u003c/li\u003e\u003cli\u003eCertified receipt or invoice\u003c/li\u003e\u003cli\u003eValidated HHS Form 393 (Purchase/Service/Stock Requisition Form)\u003c/li\u003e\u003cli\u003eCMS credit card invoice\u003c/li\u003e\u003cli\u003eVendor proof of license purchase certificate\u003c/li\u003e\u003cli\u003eVendor end-user authorization form for volume licensing\u003c/li\u003e\u003cli\u003eVendor-provided notice of software purchase\u003c/li\u003e\u003cli\u003eEnd-user license agreement\u003c/li\u003e\u003cli\u003eEnterprise Software Licensing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator installs the software and documents that the instance of software and license are used for the information system so that the total number of licenses, the proof of license and installations are denoted.\u0026nbsp; The documentation is used by the System/Network Administrator to prevent copying per the\u0026nbsp;\u003cem\u003eCMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resources\u003c/em\u003e\u0026nbsp;section 4.1 and/or violating license agreements.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS ISSO and respective component support staff from ISPG CDM performs routine scans of CMS networks to compare the current approved users and their installed software to the list of approved CMS “Core” and “Above Core” software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS ISSO communicates, via e-mail, a list of approved users to the component support staff Asset Management Team that do not comply with CMS Software Policy.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Asset Management Team notifies, via e-mail, those users and their managers that were identified as having unauthorized software on their information systems, and provide a date to remove the software or their respective access will be revoked.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Users that are notified of unauthorized software on their information system, must remove the inappropriate software within twenty-four (24) hours after completion of a Service Request (SR). In the event an exception is needed based on job role and function, an SR is submitted to the ISSO with appropriate justification for further 508 compliance testing and approval.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eUser-Installed Software (CM-11)\u003c/h3\u003e\u003cp\u003eAllowing CMS personnel to install software on agency information systems and system resources exposes the organization to unnecessary risk. \u0026nbsp;GFEs will be configured to prevent installation of software when unprivileged users attempt it.\u0026nbsp; Privileged users will be allowed to install software by following established procedures.\u0026nbsp; The proper methods should be outlined within the SSPP of the information system under the control allocation for CM-11 – Shared Implementation Details.\u0026nbsp; Users of the information system will have to follow the policy as stated in the SSPP.\u0026nbsp; CMS will take action at least once per month after implementation to monitor adherence to the policy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS wants to mitigate potential problems that may arise when users install programs.\u0026nbsp; Some examples of problems that can be introduced are using two different versions of the same software that can cause system conflicts, introducing malware, and installing unlicensed software that could be discovered during audit or unauthorized programs that could be used to gather information from CMS’s network.\u0026nbsp; This control is designed to protect network resources from unauthorized actions from software by restricting the number of people who have the ability to install it.\u0026nbsp; This will minimize the risk of losing functionality in programs, damaging CMS infrastructure from malicious programs, harming CMS’s reputation through sensitive data loss, or exposing CMS to liability from unlicensed software. \u0026nbsp;Monitoring the system for these installations allows us to adhere to information security continuous monitoring (ISCM) requirements as per the CMS IS2P2 section 4.1.2 Risk Management Framework.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for user-installed software.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-11\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through [Assignment: organization-defined methods]; and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at [Assignment: organization-defined frequency].\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Prohibits the installation of software by users on all GFE;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through organization-defined methods (defined in the SSPP); and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at least monthly.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-11 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep\u0026nbsp;1:\u0026nbsp;\u003c/strong\u003eCMS image management team installs privilege management software on all GFE configuration baselines to prevent the installation of software by users in accordance with software installation rules.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;For GFEs, the Deskside Support Team configures them to restrict the permissions of users and prevent user-initiated installations. For all other CMS equipment, the business owner and the ISSO is responsible for restricting the permissions of users and preventing user-initiated installations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor GFEs, the Deskside Support Team configures it with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevents all other user installations of software. For all other CMS equipment, the business owner and the ISSO is responsible for configuring the equipment with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the system with methods and data gathering mechanisms that collect information at least once per month about the installed software that confirms its authorized use. It must be compliant with CDM.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures the methods and data gathering mechanisms from Step 4 to comply with CDM.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures systems with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1b:T1c68f,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eIntroduction\u003c/h2\u003e\u003cp\u003eThis Handbook outlines procedures to help CMS staff and contractors implement the Configuration Management family of controls taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 and tailored to the CMS environment in the CMS Acceptable Risk Safeguards (ARS). For more guidance on how to implement CMS policies and standards across many cybersecurity topics, see the CMS Security and Privacy Handbooks.\u0026nbsp;\u003c/p\u003e\u003cp\u003eConfiguration management has been applied to a broad range of information systems. Some basic terms associated with the configuration management discipline are briefly explained below.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eBaseline Configuration\u003c/em\u003e\u0026nbsp;is a set of specifications for a system that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;(CM Plan) is a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. The basic parts of a CM Plan include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eConfiguration Control Board\u003c/em\u003e\u0026nbsp;(CCB) – establishment of and charter for a group of qualified people with responsibility for the process of controlling and approving changes throughout the development and operation lifecycle of products and systems; may also be referred to as a change control board;\u003c/li\u003e\u003cli\u003eConfiguration Item\u0026nbsp;\u003cem\u003eIdentification\u003c/em\u003e\u0026nbsp;– methodology for selecting and naming configuration items that need to be placed under CM;\u003c/li\u003e\u003cli\u003eConfiguration\u0026nbsp;\u003cem\u003eChange Control\u003c/em\u003e\u0026nbsp;– process for managing updates to the baseline configurations for the configuration items; and\u003c/li\u003e\u003cli\u003eConfiguration\u003cem\u003e\u0026nbsp;Monitoring\u003c/em\u003e\u0026nbsp;– process for assessing or testing the level of compliance with the established baseline configuration and mechanisms for reporting on the configuration status of items places under CM.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis guideline is associated with the application of security-focused configuration management practices as they apply to information systems. The configuration of an information system is a representation of the system’s components, how each component is configured, and how the components are connected or arranged to implement the information system. The possible conditions in which an information system or system component can be arranged affect the security posture of the information system. The activities involved in managing the configuration of an information system include development of a configuration management plan, establishment of a configuration control board, development of a methodology for configuration item identification, establishment of the baseline configuration, development of a configuration change control process, and development of a process for configuration monitoring and reporting.\u003c/p\u003e\u003cp\u003eConfiguration management of information systems involves a set of activities that can be organized into four major phases – Planning, Identifying and Implementing Configurations, Monitoring, and Controlling Configuration Changes. It is through these phases that CM not only supports security for an information system and its components, but also supports the management of organizational risk.\u003c/p\u003e\u003ch2\u003eConfiguration Management controls\u003c/h2\u003e\u003ch3\u003eBaseline Configuration (CM-2)\u003c/h3\u003e\u003cp\u003eThis control requires CMS to develop, document, and maintain under configuration control a current baseline configuration for each information system. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for initializing and maintaining an information system configuration baseline.\u003c/p\u003e\u003cp\u003eTo develop and document initial configurations:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system owner with the support of the Change Control Board (CCB) identifies the configuration settings for their information system, device, appliance, or application using configuration settings standards in section 3.5 as part of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer documents the configuration settings chosen during Step 1 in the CMS Intake Form as part of the CMS-SDLC.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn order to maintain the configuration baseline, the Business Owner ensures the following is completed:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization determines that the system requires a change. (See SA-3 and CM-9).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops a high-level plan for how to accomplish the change (see SA-3, and SA-10).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) reviews the Privacy Impact Assessment (PIA) and conducts a Security Impact Analysis (SIA, see CM-4 Security Impact Analysis) to identify the privacy and security impacts of their plan (see CM-4 and SA-3).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops any applicable design requirements to mitigate the identified security impacts (see SA-3, SA-8, and SA-17).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops testing requirements to ensure that the security impacts are verified as successfully mitigated (see CA-2 and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) builds out the system changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) test, independently as required by CA-2(1) and CA-7(1)), the system changes using the security tests developed in step 5 (see AC-5.Std.5, CA-2, CM-3(2), CM-4(1), and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops and implements any Plans of Action and Milestones (POA\u0026amp;Ms) necessary to correct identified failures from testing (see CA-5).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11:\u0026nbsp; \u003c/strong\u003eThe ISSO applies either for a new Authorization To Operate (ATO), or for an ATO update (see CA-6).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReviews and Updates (CM-2(1))\u003c/h4\u003e\u003cp\u003eThis enhancement requires CMS to review and update the baseline configuration of its information systems at a regularly defined frequency, when special circumstances arise, or when and information system component is installed or upgraded.\u0026nbsp; By defining and maintaining a baseline configuration for its information systems, CMS is supporting the cybersecurity concepts of least privilege and least functionality. In addition, the establishment of configuration baselines helps the organization recognize abnormal behavior as a sign of attack.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for review and update of the baseline configuration for an information system.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003e[Assignment: organization-defined frequency];\u003c/li\u003e\u003cli\u003eWhen required due to [Assignment organization-defined circumstances];and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003eAt least every 180 days for High systems or\u0026nbsp; 365 days for Moderate systems;\u003c/li\u003e\u003cli\u003eWhen configuration settings change due to critical security patches (as defined by the federal government, CMS, or vendor), upgrades and emergency changes (e.g., unscheduled changes, system crashes, replacement of critical hardware components), major system changes/upgrades;\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eTo implement the CMS controls for reviewing and updating configuration baseline, the Information System Security Officer (ISSO) must first assign a security category in accordance with FIPS 199.\u003c/p\u003e\u003cp\u003eThis procedure is outlined in RMH Chapter 12: Security \u0026amp; Privacy Planning, under control PL-2.\u0026nbsp; The category will assist the CCB with identifying adequate security controls and ensuring they are integrated into the configuration baseline of the information system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCB will review information system baseline configurations every 365 days for systems categorized “High” and every 1,095 days for systems categorized as “Moderate”. Other triggers outside of scheduled times for configuration baseline review are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical security patches to the system/component\u003c/li\u003e\u003cli\u003eUpgrades to the system\u003c/li\u003e\u003cli\u003eEmergency changes\u003c/li\u003e\u003cli\u003eMajor system changes or upgrades\u003c/li\u003e\u003cli\u003eInformation system component installations\u003c/li\u003e\u003cli\u003eUpdates to the governing standards\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn addition, system developer and maintainers will have to update the documentation regarding the baseline configuration after an approval of changes. Updates must follow the same process stated above in CM-2.\u003c/p\u003e\u003ch4\u003eAutomation Support for Accuracy / Currency (CM-2(2))\u003c/h4\u003e\u003cp\u003eCMS provides automation support whenever possible to information systems’ configuration baselines. \u0026nbsp;Automation support examples include hardware asset management systems, software asset management systems, and centralized configuration management software. \u0026nbsp;CMS uses automation of information gathering to support the continuous monitoring program and inventory systems. \u0026nbsp;Automation support captures the types of hardware and software on the network and the operating system or firmware on each device.\u003c/p\u003e\u003cp\u003eThe goal is to keep track of what the configuration is on each system and to have the ability to go to an information system and collect configuration information automatically. \u0026nbsp;The automation keeps the data on systems configuration up-to-date, accurate, and available when it is needed.\u0026nbsp; With a current list of configurations, CMS can feed it into other processes that look for deviations from the baseline and configurations that are not up to organizational standards. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HSS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for incorporating automation to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system developer and maintainer configures the system architecture to allow automated hardware and software mechanisms provided by Continuous Diagnostics and Mitigation (CDM) to scan the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer configures the access controls, as needed, to allow automation support to have access to the information that it needs.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Cybersecurity Integration Center (CCIC) runs automated mechanisms to gather hardware and software configurations as part of the Continuous Monitoring Program whose point of contact information is in Appendix G.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRetention of Previous Configurations (CM-2(3))\u003c/h4\u003e\u003cp\u003eRetaining documentation of configuration information is the first step to the restoration in times of need. CMS will maintain at least one backup of the configuration for systems, system components, and information system services. The configuration information needed is used to restore a device, service, or software to a previous state. Related to CM-2(2), section 3.1.2 of this document, the automated gathering of configuration information can be used to collect the data. This backup should also be maintained, given that the configuration will change over time. The approval of changes in the configuration from the CCB should also be added to the configuration documentation to retain as a new version.\u003c/p\u003e\u003cp\u003eThe retention of configuration information is in support of CMS as one of its goals to maintain availability of systems. A previous configuration could be used to replace current settings and processes to a former state. This former state should be an approved configuration that may increase risk, but maintain availability. For example, if there were a system that did not apply a critical security patch correctly causing a system failure, then restoring the previous configuration would restore the system to a functioning state (available) without the security protection of the patch (increased risk).\u003c/p\u003e\u003cp\u003eThe configuration information can also be used when settings change with unintended consequences during system upgrades or replacements. The previous configuration can be restored using what is called a rollback procedure, which would implement the settings for a former state that is known to function properly.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameter (ODP) for CM Retention of Previous Configurations.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(3)\u003c/td\u003e\u003ctd\u003eThe organization retains [Assignment: organization-defined previous versions of baseline configurations of the information system] to support rollback.\u003c/td\u003e\u003ctd\u003eThe organization retains older versions of baseline configurations of the information system as deemed necessary, by the ISSO, to support rollback.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for retaining configuration information of an information system:\u003c/p\u003e\u003cp\u003eThe system developer and maintainer will determine the needs of the system to restore it back to a previous state. The information gathered can be a combination of settings, version numbers of software/firmware/hardware, access controls, connection information, or schematics. The importance of gathering the correct information is to ensure that the system will work using the previous configuration as stored. This previous configuration information must also be available in case of emergencies and must therefore be stored apart from the system itself to remain available if the system is offline. Additionally, configuration changes that are approved by the CCB must be added to the configuration baseline to ensure the up-to-date configurations are used for restoration. A minimum of one previous configuration is required for this control.\u003c/p\u003e\u003cp\u003eBecause the retention process will be slightly different for every information system, the system developer and maintainer must document their process in their Configuration Management Plan (CMP).\u003c/p\u003e\u003ch4\u003eConfigure Systems, Components, or Devices for High-Risk Areas (CM-2(7))\u003c/h4\u003e\u003cp\u003eThis control guides CMS to create configurations and/or procedures for systems (laptops, iPhones, etc.) that are traveling to high-risk areas. \u0026nbsp;This control is for official travel, because unofficial/personal travel should not involve the transportation of Government Furnished Equipment (GFEs).\u0026nbsp; CMS employees traveling to high-risk areas should not travel with their permanently issued GFE but instead use an assigned loaner laptop from the designated laptop team. \u0026nbsp;The designation of high-risk countries can be found on the State Department’s website\u0026nbsp;\u003cem\u003eTravel to High-Risk Areas\u003c/em\u003e\u0026nbsp; Upon returning, CMS employees and contractors return their mobile devices to the SOC for a check of signs of physical tampering.\u0026nbsp; HHS guidance can be found here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\"\u003ehttps://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\u003c/a\u003e. Further guidance can be obtained from the HHS Office of Security and Strategic Information and from the Broadcast on Foreign Travel:\u0026nbsp;\u003cem\u003eUpdated Foreign Travel Security Awareness Guidance\u003c/em\u003e\u0026nbsp;(6/12/2017).\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM-2(7) Configure Systems, Components, or Devices for High-Risk Areas.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(7)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003cli\u003eApplies [Assignment: organization-defined security safeguards] to the devices when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues dedicated information systems, system components, or devices with stringent configurations (e.g., FIPS 140-2 for encryption) to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eApplies security safeguards to the devices (i.e., detailed inspection of the device for physical tampering, purging or reimaging the hard disk drive/removable media) when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for handling systems components or devices for travel to a high-risk area.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; CMS Users traveling to foreign countries for official business notify the Office of Security and Strategic Information (OSSI) at least 30 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u0026nbsp;and follow the HHS\u0026nbsp;\u003cem\u003eForeign Travel Checklist\u0026nbsp;\u003c/em\u003ethat is available here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\"\u003ehttps://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;CMS Users traveling to foreign countries for official business notify the CMS International Team least 10 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Users notifies the Service Desk at least 10 days in advance of their travel in order to arrange for their travel laptop to conduct business on while abroad using the email\u0026nbsp;\u003ca href=\"mailto:Cms_it_service_desk@cms.hhs.gov\"\u003ecms_it_service_desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS International Team checks the country against the Department of State travel advisories to determine the risk to the traveling CMS User here:\u0026nbsp;\u003ca href=\"https://travel.state.gov/content/passports/en/alertswarnings.html\"\u003ehttps://travel.state.gov/content/passports/en/alertswarnings.html\u003c/a\u003e. \u0026nbsp;Then uses that information to decide the security awareness briefing that the User will receive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS International Team notifies the Infrastructure \u0026amp; User Services Group about the connection of the GFE that the user will have while overseas.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Deskside Support protects the travel computer using the FIPS 140-2 compliant encryption using the current full-disk encryption solution. (e.g. Checkpoint Endpoint Encryption)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS International Team debriefs the User when they return.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;CMS User returns the travel computer to CMS Deskside Support within two days of returning from travel before connecting it to the CMS network or system and does not attempt to transfer data when returning.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Change Control (CM-3)\u003c/h3\u003e\u003cp\u003eConfiguration change control implements the change control process for the information system, system component, or information system service. Management will determine which changes to the system need to be part of the change control process. There will also be employees assigned to the CCB to review and approve changes to the system, component or service. The CCB will take security considerations as part of the decision making process. Changes that are approved will need to be documented as a part of the process.\u0026nbsp; The documentation should include the decisions on the changes as well as the changes that are to be made.\u0026nbsp; The CCB should periodically audit and review the activities related to the changes that have been made to the applicable system, component or service. It should also meet often enough to accommodate the changes that are proposed.\u003c/p\u003e\u003cp\u003eThe reason that change control is enacted is to reduce the impact of changes to the CIA of the data processed by the system.\u0026nbsp; The CCB can approve or disapprove of changes for a particular system so that there is no single person making changes to the system.\u0026nbsp; CMS wants to prevent or minimize risks that can occur as a result of unauthorized or uncoordinated changes. \u0026nbsp;This helps to separate the duties involved and adds an extra layer of security. \u0026nbsp;The documentation of changes can help to troubleshoot issues when systems malfunction and to audit the system for compliance to CMS rules and regulations. CMS uses configuration change control to maintain availability through changes that have to be tested and system integrity through audits and approvals for system changes.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Configuration Change Control.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board)] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for a minimum of three (3) years after the change;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through change request forms which must be approved by an organizational and/or CMS change control board that convenes frequently enough to accommodate proposed change requests, and other appropriate organization officials including, but not limited to, the System Developer/Maintainer and information system support staff.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following, which is ensured by the Business Owner, details the CMS specific process for controlling changes to a CMS information system’s configuration.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The Information System Security Officer (ISSO), System Owner (or designee) and the project manager writes a configuration management plan that includes the parts of the system (called configuration items or CIs) which are to be controlled under configuration management procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The project/program manager further describes the process of how decisions are made in the CCB for guidance after members are assigned. This is documented in a Change Management Plan in alignment with the CMS-SDLC\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, System Owner (or designee) and the project manager create a CCB by assigning members and write a charter and operating procedures for the CCB. The CCB must have at least the system developer, Privacy Officer, ISSO (contractor/federal), maintainer, and a member of the information system support staff assigned.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CCB coordinates and oversees configuration control activities. They review change requests (CRs) and should meet often enough to appropriately handle the reviews in a timely manner throughout the life cycle from requirements analysis to disposition. \u0026nbsp;The reviews should produce an approval or disapproval that is recorded via the method in Section 4 of the relevant Change Management Plan.\u0026nbsp; The decision should take into account a \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis (SIA)\u003c/a\u003e, as outlined in CM-4, from the ISSO.\u0026nbsp; They should monitor the status of proposed changes ensuring that only approved changes are applied.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer implements approved changes once passed by the CCB. The CCB must maintain a record of configuration-controlled changes to the information system for a minimum of three (3) years after the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The project/program manager updates the configuration information inside of the System Design Document to reflect the changes approved in the CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB audits implemented changes before the changes are added to the configuration baseline by verifying that the changes fulfill the requirements or requesting the update of documented requirements in response to the CR so it accurately reflect the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB tracks the progress of the implementation of the change by confirming the updates to the configuration documentation in the System Design Document as CRs are approved.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;The CCB checks the configuration of the system periodically for discrepancies against the documented configuration baseline. The configuration audit will determine either whether the configuration of the system is compliant with the approved baseline, at which point they will notify the ISSO to initiate a POA\u0026amp;M.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Document / Notification / Prohibition of Changes (CM-3(1))\u003c/h4\u003e\u003cp\u003eAutomation in the change management process can help to document changes and ensure the proper workflow. CMS uses automated means to document system changes for submission to the CCB. The automated process should cover several things. CMS wants the automated system to notify the authorizing personnel, who were designated to approve changes, whenever changes are proposed. The change request can be automated giving highlight rules to change requests for different statuses such as: awaiting approval, not approved, or overdue (defined in the SSPP). When the approvals come through, this system should alert the stakeholders that the change is approved.\u003c/p\u003e\u003cp\u003eChanging systems are a frequent occurrence. Automating the documentation, along with notification or prohibition of changes, saves CMS resources. Automating these processes can also increase the traceability of changes for many systems at once. This helps to keep accounts of all records linked to each applicable system and to review who approved specific changes and reasons for change.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Automated Document/Notification/Prohibition of Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify [Assignment: organized-defined approval authorities] of proposed changes to the information system and request change approval;\u003c/li\u003e\u003cli\u003eHighlight proposed changes to the information system that have not been approved or disapproved by [Assignment: organization-defined time period];\u003c/li\u003e\u003cli\u003eNotify [Assignment: organization-defined personnel] when approved changes to the information system are completed.\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify designated approval authorities (defined in the SSPP) of proposed changes to the information system;\u003c/li\u003e\u003cli\u003eHighlight proposed changes that have been waiting an approval decision, or have not been approved, for longer than change management procedure (defined in the SSPP) requires;\u003c/li\u003e\u003cli\u003eNotify stakeholders when approved changes are completed. A list of potential stakeholders\u0026nbsp; include, but is not limited to the following:\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair;\u003c/li\u003e\u003cli\u003eChief Risk Officer (CRO);\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA);\u003c/li\u003e\u003cli\u003eISSO;\u003c/li\u003e\u003cli\u003eProgram Manager;\u003c/li\u003e\u003cli\u003eData Guardian;\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO); and\u003c/li\u003e\u003cli\u003eInformation System Administrator.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which are ensured by the Business Owner, outline the process for automating the processes of documenting, notifying, and prohibiting actions during the change control process.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The Information System Security Officer (ISSO), Information System Owner (ISO) and Project Manager develops configuration processes and procedures that include automated mechanisms, documenting them in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;during the proper CMS-SDLC phase. The automated mechanism(s) should be able to prohibit changes to the information system until a change is approved, store all approved Change Requests (CRs), and then notify the stakeholders when approved changes are complete.\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStakeholders to be notified upon implementation of changes (at a minimum):\u003c/strong\u003e\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair\u003c/li\u003e\u003cli\u003eCRO Chief Risk Officer (CRO)\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA)\u003c/li\u003e\u003cli\u003eBusiness Owner(BO)\u003c/li\u003e\u003cli\u003eProgram Manager\u003c/li\u003e\u003cli\u003eData Guardian (DG)\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO)\u003c/li\u003e\u003cli\u003eInformation System Administrator\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e* For the stakeholders mentioned in Table 5 and Step 1 above, the CCB must be notified of system changes. However, each system requires its own group of stakeholders to make up the CCB and there is no expectation for each role listed in Table 5 to receive notifications for every single system change. This is especially true for the Data Guardian who should only receive notification when significant changes are implemented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop, as part of the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e, an automated method of requesting approval from the authorized submitter to the appropriate CCB members to be listed in section 4.2 Roles and Responsibilities.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop the method of automated notification of changes that have requested approval to determine who gets notification at the time of proposal and how they are notified.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe ISSO, ISO, and Project Manager reference the SSPP for handling changes, to determine highlighting rules for CRs that have not been addressed or have not been approved within the designated period.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eTest / Validate / Document Changes (CM-3(2))\u003c/h4\u003e\u003cp\u003eSystems can implement this control by creating an environment to test changes prior to implementation in the operational environment. The testing environment should be separate from the operational environment when possible. The test environment should mirror the operational environment to the \u0026nbsp;maximum extent possible, but CMS realizes deviations will have to be made so long as they are properly documented. Teams performing testing should document the process and procedures associated with the test to include a detailed outcome.\u003c/p\u003e\u003cp\u003eThe purpose of testing changes to the system prior to implementation is to reduce the chance that outages will occur during implementation.\u0026nbsp; The separation of testing from implementation in the operational environment is meant to give network/system administrators an opportunity to see if proposed changes will adversely affect the operational systems. \u0026nbsp;CMS has the goal of reducing the chances that the operational environment will fail as a result of changes to the environment. \u0026nbsp;Implementing this control will reduce breaks in operational environments and enable stakeholders making subsequent changes to reference the documentation created.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for testing, validating, and documenting changes to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer designs and develops the tests for the information system, as required by the CMS-SDLC, to be referenced for testing during changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Change Manager collects CRs and makes sure that they are documented in the automated tool as outlined in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan.\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer with the system/network administrator test the system changes as outlined in the documented CR and approved by the CCB.\u0026nbsp; The test may be conducted on the test environment or operational system while off-line or during a maintenance window using the tests outlined in the test plan.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSecurity Impact Analysis (CM-4)\u003c/h3\u003e\u003cp\u003eOrganizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems.\u003c/p\u003e\u003cp\u003eThe analysis of the security impact of a change occurs when changes are analyzed and evaluated for adverse impact on security, preferably before they are approved and implemented, but also in the case of emergency/unscheduled changes. These analyses are important to CMS because they prevent unnecessary risk to the enterprise.\u003c/p\u003e\u003cp\u003eChanges (in both the change management process and if a significant change will be made that impacts the ATO) should not be accepted without first studying the risks posed by these changes by conducting a security impact analysis. Before the changes are implemented and tested, a security impact analysis (and/or assessment) is performed to ensure that the changes have been sufficiently analyzed and documented, and to determine if there are any unanticipated effects of the change on existing security controls.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eChange Management\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eInformation system changes should not be undertaken prior to assessing the security impact of such changes. If the results of the security impact analysis indicate that the proposed or actual changes can affect, or have affected, the security state of the system; then corrective actions must be initiated and appropriate documents are revised and updated (e.g., the system security plan, security assessment report, and plan of action and milestones, etc.).\u003c/p\u003e\u003cp\u003eThe business owner, or common control provider(s) should consult with their ISSO and/or CRA, and participate in the TRB review process prior to implementing any security-related changes to the information system, or its environment of operation.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSignificant Change\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMany events can trigger change—even events that may not result in an actual system “change”. Significant changes require a formal reauthorization of the system. If a formal reauthorization action is required, the business owner should target only the specific security controls affected by the changes and reuse previous assessment results wherever possible. Most routine changes to an information system or its environment of operation can be handled by the business owner’s continuous monitoring program.\u003c/p\u003e\u003cp\u003eNIST states that a Significant Change to an information system may include (for example): (i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform; (iv) modifications to cryptographic modules or services; or (v) modifications to security controls. Examples of significant changes to the environment of operation may include for example: (i) moving to a new facility; (ii) adding new core missions or business functions; (iii) acquiring specific and credible threat information that the organization is being targeted by a threat source; or (iv) establishing new/modified laws, directives, policies, or regulations.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process to conduct a security impact analysis:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;After receiving the Change Request (CR) submission from the CCB, the ISSO will determine the scope of the change by analyzing the CR form. They will develop a high-level architecture overview that shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), the ISSO will request follow-up documentation/information and review it or use whatever information is available (e.g., audit records, interview staff who made the change, etc.) to gain insight into the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2\u003c/strong\u003e: The ISSO will identify the scope and the categorization of the change.\u0026nbsp; See Appendix D for the SIA Template.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3\u003c/strong\u003e: The ISSO will identify any vulnerabilities (via vulnerability scans, documentation comparison etc.) in the proposed change and analyze the categorizations of change and identify the security controls that are impact by the change (both system specific, hybrid, and inherited controls)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4\u003c/strong\u003e: The ISSO, in consultation with the CRA, conducts a risk assessment of any discovered vulnerabilities (impact and likelihood) and change(s) to security control implementation that has been affected by the change(s). A risk assessment is needed to identify the likelihood of a threat exercising the vulnerability and the impact of such an event.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, assess impact of proposed change on functionality of the system or CI and assess impact of proposed change on existing security controls. For example, the change may involve installation of software that alters the existing baseline configuration, or the change itself may cause or require changes to the existing baseline configuration. The change may also affect other systems or system components that depend on the function or component being changed, temporarily or permanently. For example, if a database that is used to support auditing controls is being upgraded to the latest version, auditing functionality within the system may be halted while the upgrade is being implemented.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, conducts a Privacy Impact Assessment to ensure that a change to the system that affects PII/PHI is accounted for and proper action can be taken if necessary\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7\u003c/strong\u003e: The ISSO, in consultation with the CRA, determine whether the change is part of the change management process or if the change is significant enough that the system authorization is in question. Read the above introduction paragraphs for guidance to help make this determination.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf change management\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit them to the Change Control Board (CCB). If the change is occurring on a contractor system, the contractor’s internal CCB will be responsible for approving changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: If change is occurring on a contractor system, CMS has the ability to request that the contractor conduct an SIA.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf a significant change\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: The ISSO and the CRA will meet with the Business Owner and the Technical Review Board (TRB) to determine if a re-authorization is necessary. If re-authorization is necessary, the ATO package must receive proper approval before implementation.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit to the Change Control Board (CCB).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB or TRB.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSeparate Test Environments (CM-4(1))\u003c/h4\u003e\u003cp\u003eSeparate test environments are used at CMS to host an instance of the operational environment.\u0026nbsp; They should mirror one another in order to create an accurate response to changes as they are made for testing.\u0026nbsp; The environment will be kept separate, physically and/or logically, so that changes in one do not affect the other. \u0026nbsp;Changes will then be analyzed for flaws, weaknesses, incompatibility and intentional/unintentional harm that results from implementation. \u0026nbsp;CCB approved changes should be made in this test environment first, then the production/operational environment. Test environments need to mirror production to the maximum extent possible, but CMS realizes that deviations may have to be made so long as they are properly documented.\u003c/p\u003e\u003cp\u003eSeparating the testing environment from the production environment benefits CMS by allowing a chance to see the changes requested for a system enacted before the changes affect end users. Test environments give a chance to observe possible harm or disrupted functionality without applying the changes to production. It can reduce the risks of change overall, since the production data and operational environment are not harmed when the test environment is adversely affected.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS-specific process to ensure that separate environments have been incorporated into testing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System/Network Administrator creates and maintains a test environment that is similar to the operational environment but either physically or logically separate from it.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator uses the test environment to enact approved changes from the CCB then observe and document the effects of those changes before those approved changes are enacted on the operational system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eAccess Restrictions for Change (CM-5)\u003c/h3\u003e\u003cp\u003eThe changes to a system can be sensitive.\u0026nbsp; CMS calls for restrictions on the access to the system both physically and logically.\u0026nbsp; The access controls to limit change privileges can be implemented through discretionary access controls such as deciding who is on the CCB. Supplemental discretionary access or role-based access controls can be enacted on files using Access Control Lists (ACLs). There can also be physical access restrictions such as those requiring a key to get into datacenter facilities. All together, these access restrictions should be developed, documented, approved and enforced throughout the system life cycle.\u003c/p\u003e\u003cp\u003eRestricting the ability to enact change to a system maintains the overall stability to the system.\u0026nbsp; CMS limits production and operational privileges to make sure that there are controlled inputs to the change control process. Without limitations on change requests for a system, the process may become overwhelmed or inefficient based on unnecessary change requests.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS enacts this control, which is ensured by the Business Owner, by utilizing the following steps:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The Office of Information Technology (OIT) defines and approves access restrictions associated with change to the system during the initial phase of the CMS-SDLC including:\u003cul\u003e\u003cli\u003e\u003cstrong\u003eAdministrative controls –\u0026nbsp;\u003c/strong\u003eSuch as procedures, processes and standards to be used in configuration management\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eRole-based Access Controls\u003c/strong\u003e\u0026nbsp;– Such as those on files and storage related to change documentation\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDiscretionary Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those approving the appropriate personnel to approve changes to the system\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePhysical Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those restricting access to the computer equipment where the change requests and automation systems are kept\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Owner includes the defined access restrictions in the baseline configuration for the information system, to be included as a configuration item for the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO develops physical access controls if there is no description of them available for the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO documents physical and logical access controls in CFACTS under the Controls tab in the Authorization Package. Select Allocated Control CM-5 and list the reference or documented physical controls in the Shared Implementation Details field of the Implementation section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO reviews proposed changes to the physical and logical controls and the BO approves the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;Unapproved physical access changes must be filed as a Risk Acceptance Request documented in CFACTS or returned to the developer for modification of the plans and resubmission to the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Access Enforcement / Auditing (CM-5(1))\u003c/h4\u003e\u003cp\u003eA system under this control will have automation in its access enforcement and auditing. \u0026nbsp;The automation means that the system will check to see if the user or service is authorized to access resources as well as use some form of authentication. \u0026nbsp;During this enforcement of access controls, the system should also log actions for auditing those enforcement actions later.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe access enforcement for a system is important to maintain its security. \u0026nbsp;Automating the enforcement is the most efficient method of maintaining access controls.\u0026nbsp; These controls keep the unauthorized users out.\u0026nbsp; They contribute to the safety of the system through authentication and confidentiality. The confidentiality of the system makes it so that users only see parts of the system they are authorized to see.\u0026nbsp; Authentication ensures that CMS knows the user or service that is attempting to access a resource.\u0026nbsp; Finally, the creation of access control records will allow CMS personnel to evaluate working controls and detect misuse of the system through audits.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for automatically controlling access and auditing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System Developer and Maintainer creates the system with the functionality to audit against access restrictions specifically on changes to the hardware, software, and firmware components of the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer creates the functionality to record and document enforcement actions in relation to the access of data and/or functionality that is restricted in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor cloud-based services, the Cloud Service Provider (CSP) should be enforcing Steps 1 and 2 using automated mechanisms, to be in place before the service is in operation.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReview System Changes (CM-5(2))\u003c/h4\u003e\u003cp\u003eThe review of system changes should be carried out once per week by the CCB. \u0026nbsp;This process should also allow for ad-hoc reviews for checking configurations against the baseline when unauthorized changes have been indicated or there is a dramatic unforeseen shift in performance.\u003c/p\u003e\u003cp\u003eReview is a useful tool utilized by CMS to determine which changes may have been made without permission, or without following the configuration management procedure. \u0026nbsp;Discovering an unauthorized change could mean that there are more unauthorized changes present within the system. Reviewing the system changes is an easy way to check for procedural mistakes or intentionally unauthorized system changes. CMS maintains records of access to ensure that configuration change control is implemented and to support after-the-fact actions should CMS discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3, AU-6 and AU-7.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Review System Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(2)\u003c/td\u003e\u003ctd\u003eThe organization reviews information system changes [Assignment: organization-defined frequency] and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred.\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews information system changes:\u003c/p\u003e\u003cp\u003ea. At least once a week; and\u003c/p\u003e\u003cp\u003eb. When unauthorized changes or unexpected levels of system performance are indicated.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for reviewing system changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The CCB meets to review system changes each week to determine if unauthorized changes were made by checking current configuration baselines against the current configuration of the system to check for CIs that were modified without a corresponding approved CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;When the CCB learns of unauthorized changes taking place or unexpected levels of system performance, they should check the configuration baselines of their systems against the actual configuration of the system to determine whether changes have been made on the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The CCB reports any unauthorized changes to the ISSO within 24 hours of the finding.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSigned Components (CM-5(3))\u003c/h4\u003e\u003cp\u003eSigned components are parts of code that are used to create a digital signature and packaged together, code and signature. The digital signature is created from certificate assigned to the author of the code by a trusted certification authority.\u003c/p\u003e\u003cp\u003eCMS uses signed firmware and software components to know who the authors of the code are. The digital signature scheme and the Public Key Infrastructure together provide a way to institute non-repudiation for firmware and software updates.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Signed Components.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(3)\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of network and server software and firmware components without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for signing components:\u003c/p\u003e\u003cp\u003eCode that is taken from third party providers must have a signature from the author. At CMS, the system administrators apply the correct configuration that automatically stops firmware and software components from being installed without a digital signature.\u0026nbsp; These settings are in use as part of CMS’ configuration baselines for systems.\u0026nbsp; In Windows-based systems, this is performed through Active Directory group policy objects.\u0026nbsp; The group policy is applied to the target computer object and results in the computer being configured to restrict software and firmware installations without digital signatures.\u0026nbsp; The certificate for the software should be from a trusted certificate authority and the certificate should not be trusted if it is self-signed. A trusted certificate authority is designated as such by DHS, HHS, and CMS.\u003c/p\u003e\u003ch3\u003eConfiguration Settings (CM-6)\u003c/h3\u003e\u003cp\u003eHHS has outlined guidance for use when configuring information system components for operation.\u0026nbsp; Configuration standards vary depending upon the technical characteristics of the information system (e.g. operating systems, databases, firmware, etc.)\u0026nbsp; The\u0026nbsp;\u003cem\u003eMinimum Security Configurations Standard Guidance\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u003c/em\u003eissued by the Department of Health and Human Services shall be applied to all applicable systems. If an HHS-defined configuration standard baseline is not available than the\u0026nbsp;\u003cem\u003eU.S. Government Configuration Baseline\u003cstrong\u003e\u0026nbsp;(\u003c/strong\u003eUSGCB)\u003c/em\u003e\u0026nbsp;will be applied to the applicable systems.\u0026nbsp; For those systems not covered under USGCB, the\u0026nbsp;\u003cem\u003eNational Checklist Program\u003c/em\u003e\u0026nbsp;can be followed for configuration guidance.\u003c/p\u003e\u003cp\u003eThe purpose of creating common configuration settings is to streamline management and security implementations.\u0026nbsp; CMS configures systems with standardized settings and automates their implementation to save time and create a baseline of security that applies to all information systems, thereby, minimizing risk across the enterprise.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Configuration Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements];\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using the latest security configuration baselines established by the HHS, U.S. Government Configuration Baselines (USGCB), and the National Checklist Program (NCP) defined by NIST SP 800-70 Rev. 2 (refer to Implementation Standard 1 for specifics) that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for individual components within the information system based on explicit operational requirements (defined in the system security plan [SSPP]);\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for documenting configuration changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The CMS System Developer and Maintainer uses the HHS approved configurations and creates the configuration for the applicable information system using\u0026nbsp;\u003cem\u003eHHS\u0026nbsp;\u003c/em\u003edefined security configurations\u003cem\u003e\u0026nbsp;\u003c/em\u003eas the guidance in their creation. For USGCB (HHS Approved) Configuration, the appropriate operating system and/or applications is Microsoft Windows Supported Versions.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer using other OSes and applications develops configurations from guidelines in the following priority:\u003cul\u003e\u003cli\u003eHHS\u0026nbsp;\u003cem\u003eMinimum Security Configuration Standards Guidance\u003c/em\u003e\u003c/li\u003e\u003cli\u003eUSGCB\u003c/li\u003e\u003cli\u003eNIST NCP – Tier IV, then III, II, I in descending order\u003c/li\u003e\u003cli\u003eTechnical Reference Architecture Volume IV – Development and Application Services\u003c/li\u003e\u003cli\u003eDISA Security Technical Implementation Guide (STIG)\u003c/li\u003e\u003cli\u003eNSA STIG\u003c/li\u003e\u003cli\u003eLacking a Federal government-authored checklist, using an industry group or vendor checklist (Such as Center for Internet Security (CIS) benchmarks)\u003c/li\u003e\u003cli\u003eCollaboration within CMS to i) Establish baselines and communicate industry and vendor best practices; and ii) Ensure deployed configurations are supported for security updates\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer documents secure configuration settings for the information system using the procedures in Section 3.1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The network is scanned regularly for compliance with the established baseline configuration.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The information systems that are out of compliance are re-configured with baseline settings by the System Developer and Maintainer, in collaboration with the Vulnerability Management Team.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following steps are intended for use if the information system is cloud-based from a Cloud Service Provider (CSP).\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The OIT creates a baseline configuration with the CSP for their IT products inside the information system using USGCB as a guide to create the most restrictive mode consistent with operational requirements.\u003cul\u003e\u003cli\u003eIf USGCB does not apply, then they use the CIS benchmarks as guides to create the most restrictive mode consistent with operational requirements.\u003c/li\u003e\u003cli\u003eIf neither USGCB nor CIS applies, then they create their own benchmark of configuration settings.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS ISSO and the System Developer and Maintainer creates Security Content Automation Protocol (SCAP) compatible security configuration checklists if there are no validated ones available. The list should be formatted so that it can be read by a validated SCAP tool and enable that tool to determine if the approved configuration is in place.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDeviations\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe following steps are intended for creating deviations to established configuration settings.\u0026nbsp; If the settings established using a standard for baseline configurations have significant detrimental impacts on a system’s ability to perform CMS duties, then follow the steps below to file for a Risk Acceptance. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HHS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eStarting from the established baseline\u003cem\u003e,\u0026nbsp;\u003c/em\u003ethe System Developer and Maintainer documents all of the deviations from the baseline that either:\u003cul\u003e\u003cli\u003eAre not intended to be implemented since the standard(original baseline) setting would interfere with business operations\u003c/li\u003e\u003cli\u003eAre cost prohibitive\u003c/li\u003e\u003cli\u003eAre technically infeasible\u003c/li\u003e\u003cli\u003eHave an impact to operations\u003c/li\u003e\u003cli\u003eCause a loss of functionality\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the collected deviation(s) documented in the previous step by working with the BO to determine if configurations would restrict the types of information used, adversely affect the boundaries or adversely affect the information shared with other systems.\u0026nbsp; Furthermore, the ISSO reviews the list for completeness to ensure it has all the information needed for the Risk Acceptance form. The ISSO selects deviations to be approved by the CISO and CRA through the Risk Acceptance form or otherwise returned to the System Developer and Maintainer within 90 days of receipt with an explanation as to why the deviation was rejected.\u0026nbsp; Then the System Developer and Maintainer can re-submit in the next review period. These actions \u0026nbsp;must be thoroughly documented in CFACTS. The process for documentation is explained in detail below.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO (or System Maintainer) logs into CFACTS and fills out and signs the Risk Acceptance form including all deviations from the baseline configuration that should be considered for the information system in Section 2\u0026nbsp;\u003cem\u003eWeaknesses\u003c/em\u003e\u0026nbsp;with the following information at a minimum:\u003cul\u003e\u003cli\u003eAllocated Control = CM-6\u003c/li\u003e\u003cli\u003eFinding Description\u003c/li\u003e\u003cli\u003eWeakness Description\u003c/li\u003e\u003cli\u003eEffect on Business\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe ISSO then fills out Section 3\u0026nbsp;\u003cem\u003eProposed Risk Acceptance\u003c/em\u003e\u0026nbsp;with all of the information related to the risk(s) that will be accepted and how/if the risk will be mitigated to include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eOverview of the Risk Acceptance Request\u003c/li\u003e\u003cli\u003eBusiness Justification for the Risk Acceptance\u003c/li\u003e\u003cli\u003eJustification for Request\u003c/li\u003e\u003cli\u003eCompensating Controls (if any)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CISO, BO, and CIO approve deviations from the configuration baseline and authorizes, using the Risk Acceptance form Section 5, the new configuration to be used in the CMS environment.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Every year, the ISSO reviews the deviations and exceptions in place on the system. He or she takes the accepted deviations and considers them collected, documented deviations to start over from Step 11 for re-certifying the configuration of the system.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Central Management / Application / Verification (CM-6(1))\u003c/h4\u003e\u003cp\u003eAutomating the management of operating systems and applications gives CMS more control over the information systems in the CMS infrastructure and those processing CMS data.\u0026nbsp; Automation is implemented to create a point (or points) of central management for administrators to change, apply, verify, and enforce configuration baselines and mandatory configuration settings. CMS uses the HHS defined security configuration standards as the basis for the configurations of information systems, components and applications. \u0026nbsp;CMS Information systems are expected to allow access to automated methods of configuration management, change and verification. \u0026nbsp;\u003c/p\u003e\u003cp\u003eUsing these policies and procedures for the CMS environment assures an even application of approved configurations across the network. \u0026nbsp;These configurations are applying the settings that will secure each system and application according to CMS’s business and regulatory needs, specifically to enforce the baseline and the mandatory configuration settings. \u0026nbsp;CMS is able to implement the settings and verify that they are correct using this control. \u0026nbsp;Verification is used to show compliance.\u0026nbsp; The combination of configuration and verification makes this control necessary for large enterprise environments such as CMS.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for Automated Central Management\\Application\\Verification.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for \u0026nbsp;information system components as defined in the HHS Minimum Security Configuration Standards for Departmental Operating Systems and Applications.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for automation of central management:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer configures the information system with the tools necessary to automate monitoring and configuring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO contacts the CDM program (Appendix G) in order to find out how to connect their system to the central management mechanism.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The system is scanned regularly by the System Developer and Maintainer for compliance with approved configurations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The configuration changes are applied by the System Developer and Maintainer using configuration management tools to information systems after they have been approved by the OIT.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRespond to Unauthorized Changes (CM-6(2))\u003c/h4\u003e\u003cp\u003eIt is the duty of CMS authorized personnel to respond to unauthorized changes to the information system, components or its data.\u0026nbsp; The response should include notifying the business owner and ISSO. Additionally, the configuration should be restored to an approved version and further system processing can be halted as necessary.\u003c/p\u003e\u003cp\u003eCMS prevents or rolls back these changes to ensure that they go through the process of change management and receive the appropriate approvals and security checks before implementation. \u0026nbsp;Unauthorized changes that have not undergone security vetting may introduce new vulnerabilities that have not been mitigated by existing security controls. \u0026nbsp;The potential for increase of risk leads CMS to respond to unauthorized changes as soon as possible.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-6(2) Respond to Unauthorized Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(2)\u003c/td\u003e\u003ctd\u003eThe organization employs [Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings].\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization responds to unauthorized changes to information system and components (e.g., authorization, auditing, processing types, baselines) and data (e.g., system libraries, log files, executables) in the following ways:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u0026nbsp;\u003col\u003e\u003cli\u003eAlert responsible actors (person, organization);\u003c/li\u003e\u003cli\u003eRestore to approved configuration; and\u003c/li\u003e\u003cli\u003eHalt system processing as warranted.\u003c/li\u003e\u003c/ol\u003e\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for responding to unauthorized changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; Unauthorized changes are automatically stopped, when possible, by halting system processing using management tools and permission restrictions. \u0026nbsp;Attempts to make unauthorized changes generate alerts that are documented in centralized audit files.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eCDM informs the Incident Management Team in Information and Security Privacy Group (ISPG) when unauthorized changes occur if an unauthorized individual accesses the system that made the change. If an authorized individual made a valid change but did not follow the CM process, CDM contacts the individual and requests that they roll back the change and follow the appropriate CM procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;Incident Management Team coordinates the incident response and assists stakeholders in deciding whether to retrieve the information system or otherwise restore the settings to the approved baseline.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eLeast Functionality (CM-7)\u003c/h3\u003e\u003cp\u003eThe principle of least functionality must considered when configuring a system. \u0026nbsp;This involves first documenting the essential capabilities of the system.\u0026nbsp; After that, the system can be configured to accommodate these capabilities while turning off non-essential functionality.\u0026nbsp; At CMS, we pay special attention to high-risk system services and additionally turn those off unless they are absolutely needed.\u003c/p\u003e\u003cp\u003eCMS integrates security principles into its system development and design.\u0026nbsp; This control addresses the principle that systems are granted only those functions that are needed in order for them to accomplish their tasks.\u0026nbsp; This includes system services, which traverse network boundaries that are considered high-risk.\u0026nbsp; This aims to reduce the “attack surface” of a system.\u0026nbsp; Attack surface refers to the points that an attacker might target when compromising a system.\u0026nbsp; Reducing functionality that goes beyond a system’s tasks leads to minimizing risk resulting in fewer attack vectors and leaving fewer options for attack.\u0026nbsp; CMS reduces the risk as much as possible for each system to prevent attacks.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM least functionality.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003eb. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eProhibits or restricts the use of high-risk system services, ports, network protocols, and capabilities (e.g., Telnet, FTP, etc.) across network boundaries that are not explicitly required for system or application functionality.\u003c/li\u003e\u003cli\u003e[Added] A list of specifically needed system services, ports, and network protocols must be maintained and documented in the applicable security plan; all others will be disabled.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, which is ensured completed by the Business Owner, details the CMS procedure for least functionality:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eTo capture the functionality, the ISSO and the system developer and maintainer should refer to the Intake Form completed during the initial phase of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer logs into CFACTS to reference the network boundaries as shown in the\u0026nbsp;\u003cem\u003eCFACTS User Manual\u003c/em\u003e\u0026nbsp;in section 4.4\u0026nbsp;\u003cem\u003eBoundary Tab\u003c/em\u003e. They must also consider the system description, purpose, functionality, and architecture. This information can be used to turn off high-risk system services on the system or system components if they are not needed for system or application functionality.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer keeps a record of explicitly required system services, ports and network protocols, maintains it on an ongoing basis throughout the CMS-SDLC and communicates changes to the ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO enters the explicitly required system services, ports and network protocols into the\u0026nbsp;\u003cem\u003eSystem Security Plan\u003c/em\u003e\u0026nbsp;in CFACTS using the Boundaries Details section and in the implementation details for control CM-7.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003e\u0026nbsp;Periodic Review (CM-7(1))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eReview of ports, services, functions and protocols involves checking the system periodically.\u0026nbsp; The system checks will make comparisons of what is used and what is authorized for use.\u0026nbsp; CMS will then use that information to make a determination of which ports, services, functions and protocols should be disabled.\u0026nbsp; The system scans will identify the PPS, and then an analysis will have to be conducted to determine if they can be disabled.\u003c/p\u003e\u003cp\u003ePeriodic review within CMS helps to protect the systems in its infrastructure.\u0026nbsp; The protection comes from reducing the attack surface as stated in “\u003cem\u003eLeast Functionality CM-7\u003c/em\u003e” to reduce the risk to the network.\u0026nbsp; Reviewing on a periodic basis allows CMS to check continually for weaknesses and baseline anomalies.\u0026nbsp; The change management process can introduce weaknesses into the environment, so it is important to evaluate systems on an ongoing basis to determine the consequences of changes, including unintentional or unforeseen consequences that affect the risk to that system.\u0026nbsp; CMS authorizes scanning systems on this basis since change management is also an ongoing process in itself.\u0026nbsp; This helps to keep checks coordinated with changes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM periodic review.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or non-secure functions, ports, protocols, and services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eDisables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure].\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system no less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003ePerforms automated reviews of the information system no less often than once every seventy-two (72) hours to identify changes in functions, ports, protocols, and/or services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eDisables functions, ports, protocols, and services within the information system deemed unnecessary and/or non-secure.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process details the CMS procedure for periodic review:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe Continuous Diagnostics and Mitigation (CDM) team coordinates with the ISSO to monitor functions, ports, protocols, and services. The CDM sends periodic review information to the ISSO regarding their monitoring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The CDM team automatically scans the information system for changes in functions, ports, protocols and/or services at least every 72 hours and more frequently as necessary. \u0026nbsp;The scans should include systems, appliances, devices, services and applications (such as databases). This is performed on an ongoing basis until the system is retired. Changes are documented and sent to the system ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the system every 30 days using the reports taken from the CDM program.\u0026nbsp; The reports are compared against the System Architecture and Architecture Design section inside of the System Design Document\u003cem\u003e\u0026nbsp;\u003c/em\u003ein CFACTS for its listing of necessary functions, ports, protocols and services.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer along with the ISSO work together to disable unnecessary functions, ports, protocols and services with advice from the CRA. This is performed on an ongoing basis as they are discovered.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003ePrevent Program Execution (CM-7(2))\u003c/h3\u003e\u003cp\u003eThis control is implemented to ensure that CMS is using the software it has acquired responsibly and legally. \u0026nbsp;To execute this control there must be methods in place to prevent executing software that is not:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLicensed for use\u003c/li\u003e\u003cli\u003eConfigured for use at CMS\u003c/li\u003e\u003cli\u003eExecuted by an authorized user\u003c/li\u003e\u003c/ul\u003e\u003cp\u003ePreventing these executions should be done automatically, and the users must not be permitted to execute the programs themselves.\u003c/p\u003e\u003cp\u003eThese program preventions are a part of CMS’s security controls to ensure that security is built into the basic elements of systems through software. This is done to apply settings, which CMS knows are protecting the interests of the organization. \u0026nbsp;This is extended to licensing to make sure CMS is not exposed to risk by using software that is unlicensed. \u0026nbsp;Unlicensed software may violate the law or introduce new risks through its operation. \u0026nbsp;\u0026nbsp;Risk from operation is also included in this control by restricting software to those that are authorized to use it. Unauthorized users may not be assigned the responsibility of using certain types of software and CMS uses separation of duties to spread out job responsibilities among groups of people to reduce risk and insider threats.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-7(2) prevent program execution.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(2)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with policies regarding authorized software use which include, but are not limited to the following:\u003c/p\u003e\u003cp\u003e\u0026nbsp;a. Software must be legally licensed;\u003c/p\u003e\u003cp\u003e\u0026nbsp;b. Software must be provisioned in approved configurations; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;c. Users must be authorized for software program use.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThis control is system specific, but the following is a good example of how to implement and document the control:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe administrators of the system create the baseline configuration for software on the computer image.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eSystem administrators configure the domain settings to disallow software installations for all Users without administrative privileges.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eSystem administrators distribute computer images for all government issued computers using authorized and licensed software, and ensures that it is using approved configurations for the software included\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor software that is not included in the computer image for the baseline configuration, use the following steps to allow execution in accordance with policies.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe user checks the website for the Office of Information Technology to find if the software that they are requesting has been tested by CMS for conflicts and/or malicious behavior using the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u003c/em\u003e\u0026nbsp;here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eNote:\u0026nbsp;\u003c/strong\u003eSoftware that is supported under an enterprise license is a subset of the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u0026nbsp;\u003c/em\u003efrom step 4; please refer to the OIT website for Enterprise Software Licensing here for more information:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\u003c/a\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eIf the software is not in the list, then submit the software for testing following the steps in the procedure on the OIT website:\u0026nbsp; \u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u0026nbsp;, if the software is on the list then skip to the next step\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp;\u003c/strong\u003eThe user of the software must acquire the license for the software that they wish to use using the forms of proof provided by CMS Deskside support listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp;\u003c/strong\u003eThe user submits a new installation request following the procedure listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\u003c/a\u003e\u0026nbsp;in which the Deskside support personnel will validate the license, authorize the user to use the software and provision the software in approved configurations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eUsers operate under restricted privileges per CM-7 - least privilege, which will logistically prevent program execution through system policies. For those users who may get software installed surreptitiously or have administrative privileges, the following steps will apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp;\u003c/strong\u003eThe operations team within ISPG monitors the network for software network behavior and/or traffic from unauthorized software, when possible, to discover, and create alerts to notify the CMS Security Operations Center (SOC) if unauthorized software use is logged.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u003c/strong\u003e\u0026nbsp;The SOC reviews alerts daily to determine if unauthorized software is in use as part of their duty. When discovered, the SOC isolates the computer on the network if needed and uninstalls the unauthorized software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp;\u003c/strong\u003eThe SOC utilizes automated methods of managing software and notifies the user when unauthorized software is detected and automatically removes the software before the next 48 hours.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAuthorized Software / Allowlisting (CM-7(5))\u003c/h4\u003e\u003cp\u003eThe authorized software allowlisting control means that CMS would document the software that is allowed to run on CMS systems. The software name and its representation would be used to determine if a specific piece of software is on the list. Software on the list is allowed to execute and all other software is denied by default. As part of the implementation of this control, the list should be updated regularly and automatically from a trusted source.\u003c/p\u003e\u003cp\u003eUsing an allowlist instead of a denylist is an option to consider for environments that are more restrictive. The list itself is known, and the system denies all other software. CMS can use an allowlist to lessen the uncertainty in a system through this prevention of executing the unknown. Decreasing the uncertainty in this case can also lead to decreasing the risk that malware or software outside of that needed for the operation of a system is executed.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Authorized Software/Allowlisting.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(5)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies [Assignment: organization-defined software programs authorized to execute on the information system];\u003c/li\u003e\u003cli\u003eReviews and updates the list of authorized software programs [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies defined software programs (defined in the applicable security plan) authorized to execute on the information system;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eReviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and\u003c/li\u003e\u003cli\u003e[Added] Receives automated updates from a trusted source.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for Authorizing Software or Allowlisting:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u0026nbsp;If no Denylisting solution is in place, then an Allowlisting solution must be used.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO, working with the System/Network Administrator and the System Developer and Maintainer, identifies and defines the software programs that are authorized for use on the information system. Then lists them in the applicable part of CFACTS. The list can be held under the\u0026nbsp;\u003cem\u003e“Controls”\u003c/em\u003e\u0026nbsp;tab, in the\u0026nbsp;\u003cem\u003e“Allocated Controls”\u0026nbsp;\u003c/em\u003esection for control CM-7(5) as part of the “\u003cem\u003eShared Implementation Details”\u003c/em\u003e\u0026nbsp;subsection.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures an automated software Allowlisting tool for their applicable information systems so they only allow execution of software that has previously been approved for install/use listed in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO automatically updates and reviews the list of software from Step 1 no less often than every 72 hours from a trusted source such as, but not limited to:\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eCMS internal processes\u003c/li\u003e\u003cli\u003eOther agencies within the federal government\u003c/li\u003e\u003cli\u003eThe vendor of the Allowlisting product\u003c/li\u003e\u003cli\u003eIndustry specialists\u003c/li\u003e\u003cli\u003eCMS systems, appliances, devices, services and applications (to include databases)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the tool to provide results that are searchable by the CCIC.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for allowlisting information must be provided by the timeframe listed within the request.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor cloud-based\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003esystems that run software\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer configures the cloud-based system or service to only allow authorized software to execute following the steps above with or without an automated Allowlisting tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eInformation System Component Inventory (CM-8)\u003c/h3\u003e\u003cp\u003eInformation system components are parts of the CMS network used to process, store or transmit CMS information.\u0026nbsp; The components must each have an identifier that should be received from the property office in the form of an asset tag, which should be linked in an inventory system with the name of the asset, location, asset identification, owner, and description of use. More information can be added as needed, but those fields are the minimum.\u0026nbsp; Then the component inventory should be linked to the CDM tools so monitoring can be linked to specific components.\u003c/p\u003e\u003cp\u003eCMS takes an inventory of information system’s components as a fundamental part of protecting the infrastructure.\u0026nbsp; Inventories contain items that need to be checked for secure configurations, and they provide a logical baseline so that components found outside of the inventory can be scrutinized and unauthorized components removed, disabled or authorized.\u0026nbsp; Unauthorized components could be indicative of a security risk and should be investigated. This control also adds to the accountability of the system. Each component is a part of the system and the same security protections should apply to all components. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Information System Component Inventory.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eDevelops and documents an inventory of information system components that:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eReviews and updates the information system component inventory [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Develops and documents an inventory of information system components that:\u003c/p\u003e\u003cp\u003e1. Accurately reflects the current information system;\u003c/p\u003e\u003cp\u003e2. Include all components within the authorization boundary of the information system;\u003c/p\u003e\u003cp\u003e3. Are at the level of granularity deemed necessary for tracking and reporting; and\u003c/p\u003e\u003cp\u003e4. Includes:\u003c/p\u003e\u003cp\u003e- Each component’s unique identifier and/or serial number;\u003c/p\u003e\u003cp\u003e- Information system of which the component is a part;\u003c/p\u003e\u003cp\u003e- Type of information system component (e.g., server, desktop, application);\u003c/p\u003e\u003cp\u003e- Manufacturer/model information;\u003c/p\u003e\u003cp\u003e- Operating system type and version/service pack level;\u003c/p\u003e\u003cp\u003e- Presence of virtual machines;\u003c/p\u003e\u003cp\u003e- Application software version/license information;\u003c/p\u003e\u003cp\u003e- Physical location (e.g., building/room number);\u003c/p\u003e\u003cp\u003e- Logical location (e.g., IP address, position with the information system [IS] architecture);\u003c/p\u003e\u003cp\u003e- Media access control (MAC) address;\u003c/p\u003e\u003cp\u003e- Ownership;\u003c/p\u003e\u003cp\u003e- Operational status;\u003c/p\u003e\u003cp\u003e- Primary and secondary administrators; and\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003e- Primary user. Reviews and updates the information system component inventory no less frequently than every 180 days for High systems or 365 days for Moderate and Low systems, or per CM-8(1) and/or CM-8(2), as applicable.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops and documents an inventory of information system components. For this, they or a designee gathers the following information to be checked off and documented from each FISMA information technology item, including all components within the authorization boundary:\u003cul\u003e\u003cli\u003eUnique ID (or serial number) such as the asset tag number\u003c/li\u003e\u003cli\u003eInformation system that the component is a part of\u003c/li\u003e\u003cli\u003eAre controls inherited?\u003c/li\u003e\u003cli\u003eHigh Value Asset?\u003c/li\u003e\u003cli\u003eInformation system component type\u003c/li\u003e\u003cli\u003eManufacturer \u0026amp; model\u003c/li\u003e\u003cli\u003eOperating system type and version number\u003c/li\u003e\u003cli\u003eVirtual machine presence\u003c/li\u003e\u003cli\u003eApplication\\software license \u0026amp; version information (when applicable)\u003c/li\u003e\u003cli\u003ePhysical location\u003c/li\u003e\u003cli\u003eLogical location\u003c/li\u003e\u003cli\u003eMedia access control (MAC) address\u003c/li\u003e\u003cli\u003eResponsible party (Owner)\u003c/li\u003e\u003cli\u003eOperational status\u003c/li\u003e\u003cli\u003ePrimary \u0026amp; secondary administrator(s)\u003c/li\u003e\u003cli\u003ePrimary user(s)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO checks the details listed in the asset management tool and determine if the information gathered is enough to track and report on the component and then add fields as necessary. \u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews for accuracy and missing information and update the information system component inventory every 180 days for systems rated as “High” and every 365 days for systems rated as “Moderate” or “Low” from the system categorization in\u0026nbsp;\u003cem\u003eRMH Chapter 12\u003c/em\u003e\u0026nbsp;Section 3.1.2. T\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;System Developer and Maintainer configures the inventory system(s) to provide updates in a format compliant with CMS and federal standards to the CCIC at least once every 72 hours.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for component information must be provided by the timeframe within the request.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The Network/System Administrator provides timely, as defined by the CISO, responses to informational requests about component status and posture information.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eUpdates During Installations / Removals (CM-8(1))\u003c/h4\u003e\u003cp\u003eThe purpose of this control is to ensure that the component inventory is up-to-date in times of change. The CMS system inventory should be updated in cases of: information system component installs, removals, and updates.\u003c/p\u003e\u003cp\u003eUpdates during installations and removals to the inventory system is necessary to keep current information. The result of an upgrade, installation or removal can involve different components altogether. If the system inventory is not current, then the assumptions based on the inventory will not be accurate. It can have far-reaching impact beyond the current system and should involve updates as part of the procedure. Furthermore, updating the inventory supports accountability controls and breach response efforts.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for Updates During Installations/Removals component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe ISSO inputs new information system components into the inventory when they are installed to include the information input for systems in Section 3.7 Step 1 above.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO updates the inventory when an information system component is removed from the system. The component is taken out of inventory.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO updates the inventory when an information system is updated, changing information that is listed in the inventory such as that in Section 3.7 Step 1.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Maintenance (CM-8(2))\u003c/h4\u003e\u003cp\u003eThe CMS inventory system should be able to gather information and update records automatically.\u0026nbsp; The inventory system makes the database complete, accounting for inventory from purchase to disposition.\u0026nbsp; It is accurate, automated where possible and checked for accuracy. It is also meant to be readily available.\u0026nbsp; The system should be fault tolerant to ensure that the information on inventory is there when needed.\u003c/p\u003e\u003cp\u003eCMS uses automated inventory maintenance to show what information system components are available at any given time.\u0026nbsp; Knowing what inventory is supposed to be in the environment compared to what components are seen on the network, CMS can make determinations about components and their suitability. \u0026nbsp;If the component is in inventory and not detected through CDM for a time specified by CMS, then it may need to be flagged as a potentially compromised component. On the other hand, if a component is not in inventory and detected on the network, then it should be flagged as an unauthorized component until verified. These examples show some issues with risk by using inventory anomalies in CMS’ assessments of risk.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for automated information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to maintain the inventory of the information system including all components. The methods should include automation where possible and it should be available for review.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO compares the inventory system to physical inventory to evaluate accuracy and completeness, every 365 days for low/moderate systems and every 180 days for high systems.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Unauthorized Component Detection (CM-8(3))\u003c/h4\u003e\u003cp\u003eThe detection of components is utilized at CMS to determine whether a component is authorized or not.\u0026nbsp; By using an inventory of components that are authorized to be on the network, CMS can utilize a mechanism to compare a discovered component with the inventory.\u0026nbsp; The scans must be done on a weekly basis, more frequently as needed.\u0026nbsp; The mechanism for discovery should be automatic and detect hardware, software and firmware components within the information system.\u0026nbsp; When a component is found to be unauthorized then the automated mechanism should take measures to do the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrevent access to the component\u003c/li\u003e\u003cli\u003eEffectively disconnect the component from the network\u003c/li\u003e\u003cli\u003eIsolate the component\u003c/li\u003e\u003cli\u003eNotify responsible party as specified by the SSPP\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS intends to automate where possible to stop malicious attacks as they occur.\u0026nbsp; Stopping the communication with an unauthorized component as soon as possible is the goal of this control.\u0026nbsp; The automated responses helps CMS address threats in a timely manner since utilizing technology is consistently faster than a manual process would be able to address.\u0026nbsp; In order to review and take action against unauthorized components quickly, automation is the ideal solution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM automated unauthorized component detection.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(3)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components and/or provisioned configurations are detected:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;1. Disable access to the identified component;\u003c/p\u003e\u003cp\u003e\u0026nbsp;2. Disable the identified component’s network access;\u003c/p\u003e\u003cp\u003e\u0026nbsp;3. Isolate the identified component; and\u003c/p\u003e\u003cp\u003e4. Notify the responsible actor (i.e., person/organization defined in security plan).\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the process for automated unauthorized component detection:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO, working with the Business Owner, monitors the network to determine if unauthorized components are connected. The scan should be done at least weekly then as necessary for components that match the inventory in the automated inventory record.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO forwards unauthorized components to the Incident Management Team (IMT.)\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAccountability Information (CM-8(4))\u003c/h4\u003e\u003cp\u003eInformation system components are accounted for in the CMS inventory.\u0026nbsp; This listing has accountability information attached to it that may be referenced when a component is compromised. The information contains the role(s) or individual(s) responsible and/or accountable for the information system components.\u003c/p\u003e\u003cp\u003eThe information listed about CMS system components is designed as a reference for security personnel.\u0026nbsp; The accountability information is used when, for example, the component needs to be replaced, is the source of a breach or a compromise, or needs to be relocated.\u0026nbsp; A control for accountability information provides CMS with the contact information needed during incident response and times of change. The risk associated with those situations is assigned appropriately to the responsible person who can delegate the associated work.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for accountability information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(4)\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components.\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by the System Developer/Maintainer or the Business Owner, \u0026nbsp;\u0026nbsp;the individuals responsible/accountable for administering those components.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, ensured is completed by the Business Owner, details the CMS procedure for keeping accountability information:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to identify the individual(s), to include position and role, responsible and accountable for administering information system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO documents and maintains the information of individual(s) responsible for administering the information system components.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eNo Duplicate Accounting of Components (CM-8(5))\u003c/h4\u003e\u003cp\u003eThis control is used in CMS to ensure components are not duplicated in inventories.\u0026nbsp; The inventory that lists all components shall not have more than one of the same instance of a component.\u003c/p\u003e\u003cp\u003eCMS avoids duplicate accounting in inventory systems because it creates a source of confusion for responsibility and remediation.\u0026nbsp; Systems can be large and complex, involving many different components that interact with each other as well as other interconnected systems.\u0026nbsp; Assigning a component to a single system inventory streamlines accounting and reduces the time and effort to discern applicable parties responsible for that component. It also leads to straightforward remediation of vulnerabilities when discovered since the component is linked to a single system.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for verifying that the accounting for information system components are not duplicated:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO documents the system components inside of CFACTS using the Authorization Package for the system inside of the\u0026nbsp;\u003cem\u003e“Boundary”\u003c/em\u003e\u0026nbsp;tab under the\u003cem\u003e\u0026nbsp;“Hardware”\u003c/em\u003e\u0026nbsp;and\u0026nbsp;\u003cem\u003e“Software”\u0026nbsp;\u003c/em\u003esections.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO sorts hardware and then software by unique attributes to check if all components have different unique attributes from one another whenever entering in new system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;If there is no duplication of component attributes then no further action is needed. If the ISSO identifies a duplication of unique attributes for a component then proceed to the next step.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO removes the duplicate component attribute from the system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Management Plan (CM-9)\u003c/h3\u003e\u003cp\u003eThe CMS-SDLC incorporates a configuration management plan into the planning process. The plan is designed to document the process and procedures for configuration management.\u0026nbsp; The plan shall cover certain areas in order to fulfill this security control.\u0026nbsp; Listed in the document are roles of stakeholders, their responsibilities, processes and procedures.\u0026nbsp; The document shall also outline current configuration items.\u0026nbsp; Specifically, one of the processes covered shall be how to identify a configuration item.\u0026nbsp; The plan shall be protected, after it is finalized, from modification or unauthorized disclosure as are the configuration baselines.\u003c/p\u003e\u003cp\u003eConfiguration management plans define people, processes and procedures.\u0026nbsp; The plans establish the technical and administrative direction and surveillance for the management of configuration items.\u0026nbsp; CMS uses this plan to separate responsibility and add traceability to protect the integrity of systems.\u0026nbsp; Changes are documented and explicitly approved or rejected, so there is accountability regarding the approver, and changes that were made on the system without approval.\u0026nbsp; Implementing the plan properly helps CMS pinpoint issues related to changes, leading to quicker resolutions and rollbacks to repair them.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for developing, documenting and implementing a configuration management plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The CMS Program/Project Manager completes a configuration management plan.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Program/Project Manager documents roles and responsibilities for the plan in a\u003cem\u003e\u0026nbsp;\u003c/em\u003eRoles \u0026amp; Responsibilities section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager defines the processes and procedures involved with configuration management. Configuration Management Administration and Methods and Tools sections should be included.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager lists CIs for the information system in a System Design Document.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager protects the document from unauthorized disclosure or modification by using access control methods for storage locations to restrict access to authorized personnel only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSoftware Usage Restrictions (CM-10)\u003c/h3\u003e\u003cp\u003eCMS will establish and enforce procedures for identifying and removing inappropriate software.\u0026nbsp; Contractors and Government employees are expected to use software and associated documentation according to applicable law and contractual agreements.\u0026nbsp; CMS is responsible for the prevention, monitoring, and removal of unauthorized software.\u0026nbsp; Installed software and documentation will be monitored as needed to determine if its use is allowed by the license or contract. Additionally, peer-to-peer file sharing technology is not expected to be used except as approved by the CIO, but such traffic will be inspected to determine if sensitive or protected content was being shared.\u003c/p\u003e\u003cp\u003eSoftware usage restriction assists in safeguarding against the sharing of copyrighted material and/or the use of software in a manner that would violate CMS agreements. \u0026nbsp;CMS tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution.\u0026nbsp; CMS also controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.\u0026nbsp; This reduces CMS liability by preventing potential copyright violations. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-10 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;System/Network Administrator ensures that the software has been previously tested according to the CMS testing procedure found here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e. A list of previously tested software is available here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator reviews the installation request for the software proof of purchase, unless it was custom developed in-house, which includes:\u003cul\u003e\u003cli\u003eApproved purchase record\u003c/li\u003e\u003cli\u003eCertified receipt or invoice\u003c/li\u003e\u003cli\u003eValidated HHS Form 393 (Purchase/Service/Stock Requisition Form)\u003c/li\u003e\u003cli\u003eCMS credit card invoice\u003c/li\u003e\u003cli\u003eVendor proof of license purchase certificate\u003c/li\u003e\u003cli\u003eVendor end-user authorization form for volume licensing\u003c/li\u003e\u003cli\u003eVendor-provided notice of software purchase\u003c/li\u003e\u003cli\u003eEnd-user license agreement\u003c/li\u003e\u003cli\u003eEnterprise Software Licensing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator installs the software and documents that the instance of software and license are used for the information system so that the total number of licenses, the proof of license and installations are denoted.\u0026nbsp; The documentation is used by the System/Network Administrator to prevent copying per the\u0026nbsp;\u003cem\u003eCMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resources\u003c/em\u003e\u0026nbsp;section 4.1 and/or violating license agreements.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS ISSO and respective component support staff from ISPG CDM performs routine scans of CMS networks to compare the current approved users and their installed software to the list of approved CMS “Core” and “Above Core” software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS ISSO communicates, via e-mail, a list of approved users to the component support staff Asset Management Team that do not comply with CMS Software Policy.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Asset Management Team notifies, via e-mail, those users and their managers that were identified as having unauthorized software on their information systems, and provide a date to remove the software or their respective access will be revoked.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Users that are notified of unauthorized software on their information system, must remove the inappropriate software within twenty-four (24) hours after completion of a Service Request (SR). In the event an exception is needed based on job role and function, an SR is submitted to the ISSO with appropriate justification for further 508 compliance testing and approval.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eUser-Installed Software (CM-11)\u003c/h3\u003e\u003cp\u003eAllowing CMS personnel to install software on agency information systems and system resources exposes the organization to unnecessary risk. \u0026nbsp;GFEs will be configured to prevent installation of software when unprivileged users attempt it.\u0026nbsp; Privileged users will be allowed to install software by following established procedures.\u0026nbsp; The proper methods should be outlined within the SSPP of the information system under the control allocation for CM-11 – Shared Implementation Details.\u0026nbsp; Users of the information system will have to follow the policy as stated in the SSPP.\u0026nbsp; CMS will take action at least once per month after implementation to monitor adherence to the policy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS wants to mitigate potential problems that may arise when users install programs.\u0026nbsp; Some examples of problems that can be introduced are using two different versions of the same software that can cause system conflicts, introducing malware, and installing unlicensed software that could be discovered during audit or unauthorized programs that could be used to gather information from CMS’s network.\u0026nbsp; This control is designed to protect network resources from unauthorized actions from software by restricting the number of people who have the ability to install it.\u0026nbsp; This will minimize the risk of losing functionality in programs, damaging CMS infrastructure from malicious programs, harming CMS’s reputation through sensitive data loss, or exposing CMS to liability from unlicensed software. \u0026nbsp;Monitoring the system for these installations allows us to adhere to information security continuous monitoring (ISCM) requirements as per the CMS IS2P2 section 4.1.2 Risk Management Framework.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for user-installed software.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-11\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through [Assignment: organization-defined methods]; and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at [Assignment: organization-defined frequency].\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Prohibits the installation of software by users on all GFE;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through organization-defined methods (defined in the SSPP); and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at least monthly.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-11 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep\u0026nbsp;1:\u0026nbsp;\u003c/strong\u003eCMS image management team installs privilege management software on all GFE configuration baselines to prevent the installation of software by users in accordance with software installation rules.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;For GFEs, the Deskside Support Team configures them to restrict the permissions of users and prevent user-initiated installations. For all other CMS equipment, the business owner and the ISSO is responsible for restricting the permissions of users and preventing user-initiated installations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor GFEs, the Deskside Support Team configures it with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevents all other user installations of software. For all other CMS equipment, the business owner and the ISSO is responsible for configuring the equipment with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the system with methods and data gathering mechanisms that collect information at least once per month about the installed software that confirms its authorized use. It must be compliant with CDM.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures the methods and data gathering mechanisms from Step 4 to comply with CDM.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures systems with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node_type/node_type/d185e460-4998-4d2b-85cb-b04f304dfb1b\"}\n1d:{\"self\":\"$1e\"}\n21:[\"menu_ui\",\"scheduler\"]\n20:{\"module\":\"$21\"}\n24:[]\n23:{\"available_menus\":\"$24\",\"parent\":\"\"}\n25:{\"expand_fieldset\":\"when_required\",\"fields_display_mode\":\"vertical_tab\",\"publish_enable\":false,\"publish_past_date\":\"error\",\"publish_past_date_created\":false,\"publish_required\":false,\"publish_revision\":false,\"publish_touch\":false,\"show_message_after_update\":true,\"unpublish_enable\":false,\"unpublish_required\":false,\"unpublish_revision\":false}\n22:{\"menu_ui\":\"$23\",\"scheduler\":\"$25\"}\n1f:{\"langcode\":\"en\",\"status\":true,\"dependencies\":\"$20\",\"third_party_settings\":\"$22\",\"name\":\"Explainer page\",\"drupal_internal__type\":\"explainer\",\"description\":\"Use \u003ci\u003eExplainer pages\u003c/i\u003e to provide general information in plain language about a policy, program, tool, service, or task related to security and privacy at CMS.\",\"help\":null,\"new_revision\":true,\"preview_mode\":1,\"display_submitted\":true}\n1c:{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"links\":\"$1d\",\"attributes\":\"$1f\"}\n28:{\"href\":\"https://cybergeek.cms.gov/jsonapi/user/user/4420e728-6dc2-4022-bf8d-5bd1329e5e64\"}\n27:{\"self\":\"$28\"}\n29:{\"display_name\":\"jcallan - retired\"}\n26:{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"links\":\"$27\",\"attributes\":\"$29\"}\n2c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/user/user/e352e203-fe9c-47ba-af75-2c7f8302fca8\"}\n2b:{\"self\":\"$2c\"}\n2d:{\"display_name\":\"mburgess\"}\n2a:{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"links\":\"$2b\",\"attributes\":\"$2d\"}\n30:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22?resourceVersion=id%3A131\"}\n2f:{\"self\":\"$30\"}\n32:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n31:{\"drupal_internal__tid\":131,\"drupal_internal__revision_id\":131,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:13:33+00:00\",\"status\":true,\"name\":\"General Information\",\"description\":null,\"weight\":2,\"changed\":\"2023-03-10T19:04:03+0"])</script><script>self.__next_f.push([1,"0:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$32\"}\n36:{\"drupal_internal__target_id\":\"resource_type\"}\n35:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"3a0127c4-ee06-41ed-8239-f796f6d78eb3\",\"meta\":\"$36\"}\n38:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/vid?resourceVersion=id%3A131\"}\n39:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/vid?resourceVersion=id%3A131\"}\n37:{\"related\":\"$38\",\"self\":\"$39\"}\n34:{\"data\":\"$35\",\"links\":\"$37\"}\n3c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/revision_user?resourceVersion=id%3A131\"}\n3d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/revision_user?resourceVersion=id%3A131\"}\n3b:{\"related\":\"$3c\",\"self\":\"$3d\"}\n3a:{\"data\":null,\"links\":\"$3b\"}\n44:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n43:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$44\"}\n42:{\"help\":\"$43\"}\n41:{\"links\":\"$42\"}\n40:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"virtual\",\"meta\":\"$41\"}\n3f:[\"$40\"]\n46:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/parent?resourceVersion=id%3A131\"}\n47:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/parent?resourceVersion=id%3A131\"}\n45:{\"related\":\"$46\",\"self\":\"$47\"}\n3e:{\"data\":\"$3f\",\"links\":\"$45\"}\n33:{\"vid\":\"$34\",\"revision_user\":\"$3a\",\"parent\":\"$3e\"}\n2e:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"links\":\"$2f\",\"attributes\":\"$31\",\"relationships\":\"$33\"}\n4a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab?resourceVersion=id%3A61\"}\n49:{\"self\":\"$4a\"}\n4c:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n4b:{\"drupal_in"])</script><script>self.__next_f.push([1,"ternal__tid\":61,\"drupal_internal__revision_id\":61,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:12+00:00\",\"status\":true,\"name\":\"Information System Security Officer (ISSO)\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:12+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$4c\"}\n50:{\"drupal_internal__target_id\":\"roles\"}\n4f:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$50\"}\n52:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/vid?resourceVersion=id%3A61\"}\n53:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/vid?resourceVersion=id%3A61\"}\n51:{\"related\":\"$52\",\"self\":\"$53\"}\n4e:{\"data\":\"$4f\",\"links\":\"$51\"}\n56:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/revision_user?resourceVersion=id%3A61\"}\n57:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/revision_user?resourceVersion=id%3A61\"}\n55:{\"related\":\"$56\",\"self\":\"$57\"}\n54:{\"data\":null,\"links\":\"$55\"}\n5e:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n5d:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$5e\"}\n5c:{\"help\":\"$5d\"}\n5b:{\"links\":\"$5c\"}\n5a:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$5b\"}\n59:[\"$5a\"]\n60:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/parent?resourceVersion=id%3A61\"}\n61:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/parent?resourceVersion=id%3A61\"}\n5f:{\"related\":\"$60\",\"self\":\"$61\"}\n58:{\"data\":\"$59\",\"links\":\"$5f\"}\n4d:{\"vid\":\"$4e\",\"revision_user\":\"$54\",\"parent\":\"$58\"}\n48:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"links\":\"$49\",\"attributes\":\"$4b\",\"relationships\":\"$4d\"}\n64:{\"href\":\"https://cybergeek.cms.gov/jsona"])</script><script>self.__next_f.push([1,"pi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34?resourceVersion=id%3A76\"}\n63:{\"self\":\"$64\"}\n66:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n65:{\"drupal_internal__tid\":76,\"drupal_internal__revision_id\":76,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:55+00:00\",\"status\":true,\"name\":\"System / Business Owner\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:55+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$66\"}\n6a:{\"drupal_internal__target_id\":\"roles\"}\n69:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$6a\"}\n6c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/vid?resourceVersion=id%3A76\"}\n6d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/vid?resourceVersion=id%3A76\"}\n6b:{\"related\":\"$6c\",\"self\":\"$6d\"}\n68:{\"data\":\"$69\",\"links\":\"$6b\"}\n70:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/revision_user?resourceVersion=id%3A76\"}\n71:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/revision_user?resourceVersion=id%3A76\"}\n6f:{\"related\":\"$70\",\"self\":\"$71\"}\n6e:{\"data\":null,\"links\":\"$6f\"}\n78:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n77:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$78\"}\n76:{\"help\":\"$77\"}\n75:{\"links\":\"$76\"}\n74:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$75\"}\n73:[\"$74\"]\n7a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/parent?resourceVersion=id%3A76\"}\n7b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/parent?resourceVersion=id%3A76\"}\n79:{\"related\":\"$7a\",\"self\":\"$7b\"}\n72:{\"data\":\"$73\",\"links\":\"$79\"}\n67:{\"vid\":\"$68\",\"revision_user\":\"$6e\",\"parent\":\"$72\"}\n62:{\"type\":\"taxonomy_term--roles\""])</script><script>self.__next_f.push([1,",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"links\":\"$63\",\"attributes\":\"$65\",\"relationships\":\"$67\"}\n7e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e?resourceVersion=id%3A71\"}\n7d:{\"self\":\"$7e\"}\n80:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n7f:{\"drupal_internal__tid\":71,\"drupal_internal__revision_id\":71,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:42+00:00\",\"status\":true,\"name\":\"System Teams\",\"description\":null,\"weight\":0,\"changed\":\"2024-08-02T21:29:47+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$80\"}\n84:{\"drupal_internal__target_id\":\"roles\"}\n83:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":\"$84\"}\n86:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/vid?resourceVersion=id%3A71\"}\n87:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/vid?resourceVersion=id%3A71\"}\n85:{\"related\":\"$86\",\"self\":\"$87\"}\n82:{\"data\":\"$83\",\"links\":\"$85\"}\n8a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/revision_user?resourceVersion=id%3A71\"}\n8b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/revision_user?resourceVersion=id%3A71\"}\n89:{\"related\":\"$8a\",\"self\":\"$8b\"}\n88:{\"data\":null,\"links\":\"$89\"}\n92:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\n91:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$92\"}\n90:{\"help\":\"$91\"}\n8f:{\"links\":\"$90\"}\n8e:{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":\"$8f\"}\n8d:[\"$8e\"]\n94:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/parent?resourceVersion=id%3A71\"}\n95:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/parent?resourceVersion=id%3A71\"}\n93:{\"related\":\"$94\","])</script><script>self.__next_f.push([1,"\"self\":\"$95\"}\n8c:{\"data\":\"$8d\",\"links\":\"$93\"}\n81:{\"vid\":\"$82\",\"revision_user\":\"$88\",\"parent\":\"$8c\"}\n7c:{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"links\":\"$7d\",\"attributes\":\"$7f\",\"relationships\":\"$81\"}\n98:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674?resourceVersion=id%3A6\"}\n97:{\"self\":\"$98\"}\n9a:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\n99:{\"drupal_internal__tid\":6,\"drupal_internal__revision_id\":6,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:04:59+00:00\",\"status\":true,\"name\":\"Assessments \u0026 Audits\",\"description\":null,\"weight\":1,\"changed\":\"2023-03-10T19:04:22+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$9a\"}\n9e:{\"drupal_internal__target_id\":\"topics\"}\n9d:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"73f89dec-123f-4c8c-9a97-d025a2b0e5cf\",\"meta\":\"$9e\"}\na0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/vid?resourceVersion=id%3A6\"}\na1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/relationships/vid?resourceVersion=id%3A6\"}\n9f:{\"related\":\"$a0\",\"self\":\"$a1\"}\n9c:{\"data\":\"$9d\",\"links\":\"$9f\"}\na4:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/revision_user?resourceVersion=id%3A6\"}\na5:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/relationships/revision_user?resourceVersion=id%3A6\"}\na3:{\"related\":\"$a4\",\"self\":\"$a5\"}\na2:{\"data\":null,\"links\":\"$a3\"}\nac:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\nab:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$ac\"}\naa:{\"help\":\"$ab\"}\na9:{\"links\":\"$aa\"}\na8:{\"type\":\"taxonomy_term--topics\",\"id\":\"virtual\",\"meta\":\"$a9\"}\na7:[\"$a8\"]\nae:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/parent?resourceVersion=id%3A6\"}\naf:{\"href\":\"https://cybergeek"])</script><script>self.__next_f.push([1,".cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/relationships/parent?resourceVersion=id%3A6\"}\nad:{\"related\":\"$ae\",\"self\":\"$af\"}\na6:{\"data\":\"$a7\",\"links\":\"$ad\"}\n9b:{\"vid\":\"$9c\",\"revision_user\":\"$a2\",\"parent\":\"$a6\"}\n96:{\"type\":\"taxonomy_term--topics\",\"id\":\"7917cea4-02d7-4ebd-93a3-4c39d5f24674\",\"links\":\"$97\",\"attributes\":\"$99\",\"relationships\":\"$9b\"}\nb2:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e?resourceVersion=id%3A11\"}\nb1:{\"self\":\"$b2\"}\nb4:{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}\nb3:{\"drupal_internal__tid\":11,\"drupal_internal__revision_id\":11,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:05:12+00:00\",\"status\":true,\"name\":\"System Authorization\",\"description\":null,\"weight\":7,\"changed\":\"2023-03-10T19:04:22+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":\"$b4\"}\nb8:{\"drupal_internal__target_id\":\"topics\"}\nb7:{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"73f89dec-123f-4c8c-9a97-d025a2b0e5cf\",\"meta\":\"$b8\"}\nba:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/vid?resourceVersion=id%3A11\"}\nbb:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/relationships/vid?resourceVersion=id%3A11\"}\nb9:{\"related\":\"$ba\",\"self\":\"$bb\"}\nb6:{\"data\":\"$b7\",\"links\":\"$b9\"}\nbe:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/revision_user?resourceVersion=id%3A11\"}\nbf:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/relationships/revision_user?resourceVersion=id%3A11\"}\nbd:{\"related\":\"$be\",\"self\":\"$bf\"}\nbc:{\"data\":null,\"links\":\"$bd\"}\nc6:{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}\nc5:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":\"$c6\"}\nc4:{\"help\":\"$c5\"}\nc3:{\"links\":\"$c4\"}\nc2:{\"type\":\"taxonomy_term--topics\",\"id\":\"virtual\",\"meta\":\"$c3\"}\nc1:[\"$c2\"]\nc8:{\"href\":\"http"])</script><script>self.__next_f.push([1,"s://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/parent?resourceVersion=id%3A11\"}\nc9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/relationships/parent?resourceVersion=id%3A11\"}\nc7:{\"related\":\"$c8\",\"self\":\"$c9\"}\nc0:{\"data\":\"$c1\",\"links\":\"$c7\"}\nb5:{\"vid\":\"$b6\",\"revision_user\":\"$bc\",\"parent\":\"$c0\"}\nb0:{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"links\":\"$b1\",\"attributes\":\"$b3\",\"relationships\":\"$b5\"}\ncc:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7?resourceVersion=id%3A19022\"}\ncb:{\"self\":\"$cc\"}\nce:[]\nd0:T66a5,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Security Impact Analysis (SIA) is an assessment that reviews how a proposed change can impact the security and privacy posture of a FISMA system. It is a mandatory process that is required for all system changes. The SIA maps directly to the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eCMS Acceptable Risk Safeguards (ARS) 5.0 Configuration Management (CM) Control\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho completes the SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe SIA is initiated by the Information System Security Officer (ISSO) or a designated team member if an ISSO is not available. The ISSO will work with the System/Business Owner and other relevant CMS staff and contractors to complete the SIA.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat changes to a system require an SIA?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThere are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.\u003c/p\u003e\u003cul\u003e\u003cli\u003eChanges to existing architecture, system, network, application, security boundary, or environment\u003c/li\u003e\u003cli\u003eChanges made to environments below the production environment (PROD) that will eventually be implemented in PROD\u003c/li\u003e\u003cli\u003eNew data types, or new connection to data source, system, service, or association\u003c/li\u003e\u003cli\u003eSoftware or service solutions that are new to the system; especially those that are new to CMS and have yet to be approved under any \u003ca href=\"/learn/authorization-operate-ato\"\u003eCMS ATO\u003c/a\u003e or \u003ca href=\"/learn/federal-risk-and-authorization-management-program-fedramp\"\u003eFedRAMP\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNote: \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-128/final\"\u003eNIST Special Publication 800-128 “\u003cem\u003eGuide for Security-Focused Configuration Management of Information Systems\u003c/em\u003e” \u003c/a\u003eindicates that the change management process (and by extension, Security Impact Analysis) is not required for changes that are expressly noted as being excluded in each organization’s \u003cstrong\u003eConfiguration Management Plan (CMP)\u003c/strong\u003e. If an anticipated change has not been noted in your organization’s CMP, you will need to perform an SIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eEvents that require a SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final\"\u003eNIST Special Publication 800-37 Rev 2 “\u003cem\u003eRisk Management Framework for Information Systems and Organizations\u003c/em\u003e” \u003c/a\u003edefines a significant change as a change that is likely to affect the security or privacy posture of a system substantively. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInstallation of a new or upgraded operating system, middleware component, or application\u003c/li\u003e\u003cli\u003eModifications to system ports, protocols, or services\u003c/li\u003e\u003cli\u003eInstallation of a new or upgraded hardware platform\u003c/li\u003e\u003cli\u003eModifications to how information, including PII, is processed\u003c/li\u003e\u003cli\u003eModifications to cryptographic modules or services\u003c/li\u003e\u003cli\u003eChanges in information types processed, stored, or transmitted by the system\u003c/li\u003e\u003cli\u003eModifications to security and privacy controls (e.g. identity and access management)\u003c/li\u003e\u003cli\u003eSignificant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:\u003c/li\u003e\u003cli\u003eMoving to a new facility\u003c/li\u003e\u003cli\u003eAdding new core missions or business functions\u003c/li\u003e\u003cli\u003eAcquiring specific and credible threat information that the organization is being targeted by a threat source\u003c/li\u003e\u003cli\u003eEstablishing new/modified laws, directives, policies, or regulations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eNote: The examples of changes listed above are only significant when they represent a change that is likely to affect the security and privacy posture of the system.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat documentation is required?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe depth and intensity of your SIA varies significantly depending on the scope of the proposed change. Consider your SIA as a holistic process that will benefit the security of your system over time rather than a compliance exercise you must complete to move forward.\u003cbr\u003e\u003cbr\u003eYour SIA may require limited documentation or it may be a detailed process that results in security testing, scans, and data reviews. Sometimes, information that surfaces about a system change during the SIA process can result in other documents and tests needing to be updated. This is part of the process required to keep your system secure.\u003cbr\u003e\u003cbr\u003eRegardless of the significance of the change to a system, the analysis and outcomes must be documented. You can choose to utilize the \u003ca href=\"https://security.cms.gov/learn/security-impact-analysis-sia#security-impact-analysis-sia-template\"\u003eSecurity Impact Analysis (SIA) Template\u003c/a\u003efor this purpose, or you can use a custom template that has been created for your system's specific needs. If you choose to use the generic CMS SIA Template, you will find it at the end of this page and will need to complete four sections:\u003c/p\u003e\u003ch3\u003eChange information\u003c/h3\u003e\u003cp\u003eA brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.\u003c/p\u003e\u003ch3\u003eTechnical representative information\u003c/h3\u003e\u003cp\u003eThe contact information for the ISSO or responsible party managing the system. The ISSO is the individual responsible for the completion of all actions related to the SIA even if a designated representative completes the paperwork on their behalf.\u003c/p\u003e\u003ch3\u003eTrigger actions and events evaluation\u003c/h3\u003e\u003cp\u003eAn extensive list of “Trigger Events”. This section is the heart of the assessment. You will be prompted to answer a number of “yes or no” questions related to the change. To complete this section, you’ll need to review:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe scope of the change\u003c/li\u003e\u003cli\u003eThe necessary updates or mitigation efforts\u003c/li\u003e\u003cli\u003eThe ARS controls impacted by the change\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf the change you’re proposing is related to the installation of an application or tool that has been pre-approved by FedRAMP on cloud.cms.gov, much of this information will be provided for you there. You’ll often find much of this information on the website of the company that created the application. For further help in determining system risk for new applications, you can always reach out to your Cyber Risk Advisor (CRA) for guidance.\u003c/p\u003e\u003ch3\u003eRecommendations for Business Owners\u003c/h3\u003e\u003cp\u003eThis final section provides a detailed list of the results of the SIA and recommendations from the ISSO to the System/Business Owner. SIA documentation may serve as a “to-do” list for ISSOs and System/Business Owners to make sure that documentation is updated appropriately, tests performed for identified controls, etc. It may also help justify further testing and potentially expensive processes to the Business Owner.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSIA outcomes\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe SIA and associated documentation may highlight the need for future actions including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunication with the \u003cstrong\u003eTechnical Review Board (TRB)\u003c/strong\u003e\u003c/li\u003e\u003cli\u003eUpdates to security artifacts like the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and PrivacyPlan (SSPP)\u003c/a\u003e, \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation Security Risk Assessment (ISRA)\u003c/a\u003e, \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e, \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e, among others\u003c/li\u003e\u003cli\u003eDetermination if third party security testing will be required\u003c/li\u003e\u003cli\u003eThe potential requirement for a new \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSIA documentation, if properly tailored, is also particularly useful for a DevSecOps environment where multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing documentation to quickly make any updates necessary.\u003c/p\u003e\u003ch2\u003eSecurity Impact Analysis (SIA) Template\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eSIA Template Instructions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cem\u003eThis template provides a suggested methodology to help ISSOs assess the potential security impact of a change or changes to FISMA systems.Individual ISSOs may find it necessary to alter the template to meet their organizational needs.Workflow associated with this template is also dependent on organizational requirements.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThis template consists of four sections.They are:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 1\u003c/strong\u003e – An overview of the proposed change.If this document is maintained for record keeping/compliance, the completion of this section will make identification easier in the future.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 2\u003c/strong\u003e – Information on who is performing the SIA if a technical representative of the ISSO is performing the assessment on behalf of the ISSO.If a technical representative of the ISSO has performed this assessment, they will forward it to the ISSO for discussion and review.It remains the ISSO’s responsibility to complete all appropriate actions.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 3\u003c/strong\u003e – An extensive list of “Trigger Events”, most of which are a decomposition of the boxes checked in Section 2. This section is the heart of the assessment.To complete this section:\u003c/p\u003e\u003col\u003e\u003cli\u003eThe assessor examines each event under “Scope of Change” (column 2).\u003c/li\u003e\u003cli\u003eIf an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAt this point, an elaboration of the events noted is included in the section “Summary of Security Impact/ Technical Overview/ Risks Identified\u003cstrong\u003e”.\u003c/strong\u003eThis includes detailing the technical overview of the item and a description of the potential impact and risk.Where other data associated with the change is available such as scan information, references should also be included in this area.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 4\u003c/strong\u003e – The ISSO recommendation to the Business Owner on the overall status of the change and what actions are necessary.This section should function as a high-level summarization of the necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote that the “Mitigation or Necessary Updates” area within Section 3 provides recommended actions.Actions may individually or as a group indicate the requirement for a new ATO.At this point, the ISSO may choose to consult with their Cyber Risk Advisor or Privacy Advisor prior to providing the recommendation of activities to the Business Owner and System Maintainer.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThough every change requires a SIA, \u003cstrong\u003eorganizations may utilize their own internal methods or processes that can automate or streamline the security analysis rather than using a formal SIA form\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eThese types of changes may include processes for configuration control such as vendor-provided security patches, updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals, motherboard or hard drives, etc.Processes associated with similar functions, may have built-in security components or controls that may not require a formal SIA form.Any of these processes -- whether automated or manual -- must capture the elements needed to properly analyze the security impacts of the particular change. The ISSO may at any time require a formal SIA for any change.\u003c/p\u003e\u003cp\u003eThe SIA document, when completed and shared with the Business Owner, can be used as a checklist to make sure that any work such as documentation changes are performed.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTo create your SIA document, start with the following for a title:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003e\u0026lt;FISMA SYSTEM NAME\u0026gt; \u0026lt; PRODUCT/FEATURE NAME\u0026gt; \u0026lt;DATE OF RELEASE TO PROD\u0026gt;\u003c/strong\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSection 1: Change Information\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCR Number\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCR Submitter (Contact Information)\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSystem/Application/Tool\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDescription of System Change\u003cbr\u003e(Detailed description that includes the Drivers for the change)\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 2: Technical Representative Information\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIf a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eRepresentative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTitle of Representative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDate\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePhone\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEmail\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Trigger Actions and Events Evaluation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003e\u003cstrong\u003eDirections:\u003c/strong\u003e Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-inclusive.Note: this list is not all-inclusive.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eImpact? (Y/N)\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCategory\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eScope of Change\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eMitigation or Necessary Updates\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eARS Controls Impacted\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eSummary of Security Impact/ Technical Overview/ Risks Identified\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eNew Users or\u003cbr\u003eNew User Roles Added\u003c/td\u003e\u003ctd\u003e\u003cp\u003eISRA updates, potential PIA update, CFACTS system description updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-2, AC-6\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eChange in data collection, storage, sharing\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePIA update.\u003c/p\u003e\u003cp\u003ePotential SORN updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003eMission/\u003c/p\u003e\u003cp\u003eBusiness requirements\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eCessation of mission or function.\u003c/td\u003e\u003ctd\u003ePotential update to SSP, CFACTS system description updates.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of mission/function.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePolicy/\u003c/p\u003e\u003cp\u003eStandards\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew revisions of ARS and CMS policy; or Issue or Update of NIST documents\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of the policy/\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003estandards.\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eLaws, Regulations, Directives\u003c/td\u003e\u003ctd\u003eNew or Changed\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of laws, regulations, directives.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eInterconnections and New connection to FISMA system or Service\u003c/td\u003e\u003ctd\u003e\u003cp\u003eUpdates to ISA and MOU must occur. If not standard connection service/inheritance from another accredited FISMA system, SCA will be required.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-4, CA-3, CA-9, PL-2, AC-3, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eArchitecture, Topology, Port/Protocol/Service change\u003c/td\u003e\u003ctd\u003e\u003cp\u003eZone changes\u003c/p\u003e\u003cp\u003eImplementation or inheritance of new services\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eCM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity components\u003c/td\u003e\u003ctd\u003e\u003cp\u003eIdentification, Authentication, Authorization\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eNew methods for authentication and/or identifiers added\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eMigrations between Single Factor and MFA\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew and modified control implementations must be tested. SCA required unless inheriting from existing FISMA system.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to all FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eIA (all)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity Components\u003c/td\u003e\u003ctd\u003eSecurity Controls – Change in implementation standard or status\u003c/td\u003e\u003ctd\u003eNew and modified control implementations must be tested via existing security processes. All changes must be documented within the SSP and the Controls tab within CFACTS. Changes in controls that cause controls to no longer be “Satisfied” must be submitted as a POA\u0026amp;M and documented within the ISRA.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eList specific controls changed\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eUser Interface\u003c/td\u003e\u003ctd\u003eUpdates to GUI including addition of new pages, new inputs\u003c/td\u003e\u003ctd\u003eNew pages must go through 508 testing, Static and Dynamic code analysis to determine no additional threats from XSS or other new vulnerabilities.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSI-10\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Hardware\u003c/td\u003e\u003ctd\u003eServers, Communication Devices\u003c/td\u003e\u003ctd\u003eIf the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAC-19, SI-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Operating System\u003c/td\u003e\u003ctd\u003eChange in Operating System\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Security Software\u003c/td\u003e\u003ctd\u003eNew Security Software or Perimeter Security Change\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of software\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSupport Software\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew Support Software\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential TRB review/approval\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVendor Patches\u003c/td\u003e\u003ctd\u003eSoftware, Servers\u003c/td\u003e\u003ctd\u003eSoftware patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem Boundary\u003c/td\u003e\u003ctd\u003eChange to Logical Access Points\u003c/td\u003e\u003ctd\u003eVulnerability Scan is required\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eAC-17, AC-2, AC-3, AC-18, AC-19, AC-20,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-3, CA-7,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Developed\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Succeed Elsewhere\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eFound (No Attacks Known)\u003c/td\u003e\u003ctd\u003eAdd to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eNew processing location(s)\u003c/td\u003e\u003ctd\u003eA new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary (environment)\u003c/td\u003e\u003ctd\u003eChange or Addition of Hosting Infrastructure or Site\u003c/td\u003e\u003ctd\u003eFull authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Validation/Security Testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePlease provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTool/Scan Type\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e(Y/N)\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Performed by\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting /Method\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Frequency\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTest Result Location\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eNotes\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCompliance Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDynamic WAPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eStatic WPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 4: Overall Recommendation for Business Owners\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eUsing the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on the status of the change.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO recommendation(s):\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cem\u003eISSO should indicate which of the following are recommended, and provide details using additional pages.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eDeploy to Production Environment without additional testing\u003c/li\u003e\u003cli\u003eUndergo Targeted Third Party Security Testing\u003c/li\u003e\u003cli\u003eUndergo SCA/CSRAP\u003c/li\u003e\u003cli\u003eRequire Business Owner Risk Acceptance to field to Production\u003c/li\u003e\u003cli\u003eApply for a new ATO\u003c/li\u003e\u003cli\u003eOther (e.g. update documentation. Specify on following page)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSigned by:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eSystem ISSO\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eBusiness Owner\u003c/p\u003e"])</script><script>self.__next_f.push([1,"d1:T66a5,"])</script><script>self.__next_f.push([1,"\u003ch2\u003e\u003cstrong\u003eWhat is a Security Impact Analysis (SIA)\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eA Security Impact Analysis (SIA) is an assessment that reviews how a proposed change can impact the security and privacy posture of a FISMA system. It is a mandatory process that is required for all system changes. The SIA maps directly to the \u003ca href=\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\"\u003eCMS Acceptable Risk Safeguards (ARS) 5.0 Configuration Management (CM) Control\u003c/a\u003e.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eWho completes the SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003eThe SIA is initiated by the Information System Security Officer (ISSO) or a designated team member if an ISSO is not available. The ISSO will work with the System/Business Owner and other relevant CMS staff and contractors to complete the SIA.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat changes to a system require an SIA?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThere are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.\u003c/p\u003e\u003cul\u003e\u003cli\u003eChanges to existing architecture, system, network, application, security boundary, or environment\u003c/li\u003e\u003cli\u003eChanges made to environments below the production environment (PROD) that will eventually be implemented in PROD\u003c/li\u003e\u003cli\u003eNew data types, or new connection to data source, system, service, or association\u003c/li\u003e\u003cli\u003eSoftware or service solutions that are new to the system; especially those that are new to CMS and have yet to be approved under any \u003ca href=\"/learn/authorization-operate-ato\"\u003eCMS ATO\u003c/a\u003e or \u003ca href=\"/learn/federal-risk-and-authorization-management-program-fedramp\"\u003eFedRAMP\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eNote: \u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-128/final\"\u003eNIST Special Publication 800-128 “\u003cem\u003eGuide for Security-Focused Configuration Management of Information Systems\u003c/em\u003e” \u003c/a\u003eindicates that the change management process (and by extension, Security Impact Analysis) is not required for changes that are expressly noted as being excluded in each organization’s \u003cstrong\u003eConfiguration Management Plan (CMP)\u003c/strong\u003e. If an anticipated change has not been noted in your organization’s CMP, you will need to perform an SIA.\u003c/p\u003e\u003ch3\u003e\u003cstrong\u003eEvents that require a SIA\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003ca href=\"https://csrc.nist.gov/publications/detail/sp/800-37/rev-2/final\"\u003eNIST Special Publication 800-37 Rev 2 “\u003cem\u003eRisk Management Framework for Information Systems and Organizations\u003c/em\u003e” \u003c/a\u003edefines a significant change as a change that is likely to affect the security or privacy posture of a system substantively. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eInstallation of a new or upgraded operating system, middleware component, or application\u003c/li\u003e\u003cli\u003eModifications to system ports, protocols, or services\u003c/li\u003e\u003cli\u003eInstallation of a new or upgraded hardware platform\u003c/li\u003e\u003cli\u003eModifications to how information, including PII, is processed\u003c/li\u003e\u003cli\u003eModifications to cryptographic modules or services\u003c/li\u003e\u003cli\u003eChanges in information types processed, stored, or transmitted by the system\u003c/li\u003e\u003cli\u003eModifications to security and privacy controls (e.g. identity and access management)\u003c/li\u003e\u003cli\u003eSignificant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:\u003c/li\u003e\u003cli\u003eMoving to a new facility\u003c/li\u003e\u003cli\u003eAdding new core missions or business functions\u003c/li\u003e\u003cli\u003eAcquiring specific and credible threat information that the organization is being targeted by a threat source\u003c/li\u003e\u003cli\u003eEstablishing new/modified laws, directives, policies, or regulations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cem\u003eNote: The examples of changes listed above are only significant when they represent a change that is likely to affect the security and privacy posture of the system.\u003c/em\u003e\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eWhat documentation is required?\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe depth and intensity of your SIA varies significantly depending on the scope of the proposed change. Consider your SIA as a holistic process that will benefit the security of your system over time rather than a compliance exercise you must complete to move forward.\u003cbr\u003e\u003cbr\u003eYour SIA may require limited documentation or it may be a detailed process that results in security testing, scans, and data reviews. Sometimes, information that surfaces about a system change during the SIA process can result in other documents and tests needing to be updated. This is part of the process required to keep your system secure.\u003cbr\u003e\u003cbr\u003eRegardless of the significance of the change to a system, the analysis and outcomes must be documented. You can choose to utilize the \u003ca href=\"https://security.cms.gov/learn/security-impact-analysis-sia#security-impact-analysis-sia-template\"\u003eSecurity Impact Analysis (SIA) Template\u003c/a\u003efor this purpose, or you can use a custom template that has been created for your system's specific needs. If you choose to use the generic CMS SIA Template, you will find it at the end of this page and will need to complete four sections:\u003c/p\u003e\u003ch3\u003eChange information\u003c/h3\u003e\u003cp\u003eA brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.\u003c/p\u003e\u003ch3\u003eTechnical representative information\u003c/h3\u003e\u003cp\u003eThe contact information for the ISSO or responsible party managing the system. The ISSO is the individual responsible for the completion of all actions related to the SIA even if a designated representative completes the paperwork on their behalf.\u003c/p\u003e\u003ch3\u003eTrigger actions and events evaluation\u003c/h3\u003e\u003cp\u003eAn extensive list of “Trigger Events”. This section is the heart of the assessment. You will be prompted to answer a number of “yes or no” questions related to the change. To complete this section, you’ll need to review:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe scope of the change\u003c/li\u003e\u003cli\u003eThe necessary updates or mitigation efforts\u003c/li\u003e\u003cli\u003eThe ARS controls impacted by the change\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIf the change you’re proposing is related to the installation of an application or tool that has been pre-approved by FedRAMP on cloud.cms.gov, much of this information will be provided for you there. You’ll often find much of this information on the website of the company that created the application. For further help in determining system risk for new applications, you can always reach out to your Cyber Risk Advisor (CRA) for guidance.\u003c/p\u003e\u003ch3\u003eRecommendations for Business Owners\u003c/h3\u003e\u003cp\u003eThis final section provides a detailed list of the results of the SIA and recommendations from the ISSO to the System/Business Owner. SIA documentation may serve as a “to-do” list for ISSOs and System/Business Owners to make sure that documentation is updated appropriately, tests performed for identified controls, etc. It may also help justify further testing and potentially expensive processes to the Business Owner.\u003c/p\u003e\u003ch2\u003e\u003cstrong\u003eSIA outcomes\u003c/strong\u003e\u003c/h2\u003e\u003cp\u003eThe SIA and associated documentation may highlight the need for future actions including:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCommunication with the \u003cstrong\u003eTechnical Review Board (TRB)\u003c/strong\u003e\u003c/li\u003e\u003cli\u003eUpdates to security artifacts like the \u003ca href=\"/learn/system-security-and-privacy-plan-sspp\"\u003eSystem Security and PrivacyPlan (SSPP)\u003c/a\u003e, \u003ca href=\"/learn/cms-information-system-risk-assessment-isra\"\u003eInformation Security Risk Assessment (ISRA)\u003c/a\u003e, \u003ca href=\"/learn/contingency-plan\"\u003eContingency Plan (CP)\u003c/a\u003e, \u003ca href=\"/learn/privacy-impact-assessment-pia\"\u003ePrivacy Impact Assessment (PIA)\u003c/a\u003e, among others\u003c/li\u003e\u003cli\u003eDetermination if third party security testing will be required\u003c/li\u003e\u003cli\u003eThe potential requirement for a new \u003ca href=\"/learn/authorization-operate-ato\"\u003eAuthority to Operate (ATO)\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eSIA documentation, if properly tailored, is also particularly useful for a DevSecOps environment where multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing documentation to quickly make any updates necessary.\u003c/p\u003e\u003ch2\u003eSecurity Impact Analysis (SIA) Template\u003c/h2\u003e\u003ch3\u003e\u003cstrong\u003eSIA Template Instructions\u003c/strong\u003e\u003c/h3\u003e\u003cp\u003e\u003cem\u003eThis template provides a suggested methodology to help ISSOs assess the potential security impact of a change or changes to FISMA systems.Individual ISSOs may find it necessary to alter the template to meet their organizational needs.Workflow associated with this template is also dependent on organizational requirements.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThis template consists of four sections.They are:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 1\u003c/strong\u003e – An overview of the proposed change.If this document is maintained for record keeping/compliance, the completion of this section will make identification easier in the future.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 2\u003c/strong\u003e – Information on who is performing the SIA if a technical representative of the ISSO is performing the assessment on behalf of the ISSO.If a technical representative of the ISSO has performed this assessment, they will forward it to the ISSO for discussion and review.It remains the ISSO’s responsibility to complete all appropriate actions.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 3\u003c/strong\u003e – An extensive list of “Trigger Events”, most of which are a decomposition of the boxes checked in Section 2. This section is the heart of the assessment.To complete this section:\u003c/p\u003e\u003col\u003e\u003cli\u003eThe assessor examines each event under “Scope of Change” (column 2).\u003c/li\u003e\u003cli\u003eIf an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).\u003c/li\u003e\u003c/ol\u003e\u003cp\u003eAt this point, an elaboration of the events noted is included in the section “Summary of Security Impact/ Technical Overview/ Risks Identified\u003cstrong\u003e”.\u003c/strong\u003eThis includes detailing the technical overview of the item and a description of the potential impact and risk.Where other data associated with the change is available such as scan information, references should also be included in this area.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSection 4\u003c/strong\u003e – The ISSO recommendation to the Business Owner on the overall status of the change and what actions are necessary.This section should function as a high-level summarization of the necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”.\u003c/p\u003e\u003cp\u003e\u003cem\u003eNote that the “Mitigation or Necessary Updates” area within Section 3 provides recommended actions.Actions may individually or as a group indicate the requirement for a new ATO.At this point, the ISSO may choose to consult with their Cyber Risk Advisor or Privacy Advisor prior to providing the recommendation of activities to the Business Owner and System Maintainer.\u003c/em\u003e\u003c/p\u003e\u003cp\u003eThough every change requires a SIA, \u003cstrong\u003eorganizations may utilize their own internal methods or processes that can automate or streamline the security analysis rather than using a formal SIA form\u003c/strong\u003e.\u003c/p\u003e\u003cp\u003eThese types of changes may include processes for configuration control such as vendor-provided security patches, updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals, motherboard or hard drives, etc.Processes associated with similar functions, may have built-in security components or controls that may not require a formal SIA form.Any of these processes -- whether automated or manual -- must capture the elements needed to properly analyze the security impacts of the particular change. The ISSO may at any time require a formal SIA for any change.\u003c/p\u003e\u003cp\u003eThe SIA document, when completed and shared with the Business Owner, can be used as a checklist to make sure that any work such as documentation changes are performed.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eTo create your SIA document, start with the following for a title:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003e\u0026lt;FISMA SYSTEM NAME\u0026gt; \u0026lt; PRODUCT/FEATURE NAME\u0026gt; \u0026lt;DATE OF RELEASE TO PROD\u0026gt;\u003c/strong\u003e\u003c/p\u003e\u003ch4\u003e\u003cstrong\u003eSection 1: Change Information\u003c/strong\u003e\u003c/h4\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCR Number\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCR Submitter (Contact Information)\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eSystem/Application/Tool\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDescription of System Change\u003cbr\u003e(Detailed description that includes the Drivers for the change)\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 2: Technical Representative Information\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eIf a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u0026nbsp;\u003c/th\u003e\u003cth\u003eAdd information in this column\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eRepresentative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eTitle of Representative performing the SIA\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDate\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003ePhone\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eEmail\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Trigger Actions and Events Evaluation\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003e\u003cstrong\u003eDirections:\u003c/strong\u003e Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-inclusive.Note: this list is not all-inclusive.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eImpact? (Y/N)\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCategory\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eScope of Change\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eMitigation or Necessary Updates\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eARS Controls Impacted\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eSummary of Security Impact/ Technical Overview/ Risks Identified\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eNew Users or\u003cbr\u003eNew User Roles Added\u003c/td\u003e\u003ctd\u003e\u003cp\u003eISRA updates, potential PIA update, CFACTS system description updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-2, AC-6\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eMission/ Business requirements\u003c/td\u003e\u003ctd\u003eChange in data collection, storage, sharing\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePIA update.\u003c/p\u003e\u003cp\u003ePotential SORN updates.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003eMission/\u003c/p\u003e\u003cp\u003eBusiness requirements\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eCessation of mission or function.\u003c/td\u003e\u003ctd\u003ePotential update to SSP, CFACTS system description updates.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of mission/function.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u003cp\u003ePolicy/\u003c/p\u003e\u003cp\u003eStandards\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew revisions of ARS and CMS policy; or Issue or Update of NIST documents\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of the policy/\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003estandards.\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eLaws, Regulations, Directives\u003c/td\u003e\u003ctd\u003eNew or Changed\u003c/td\u003e\u003ctd\u003eUpdates to FISMA artifacts including SSP.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of laws, regulations, directives.\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eInterconnections and New connection to FISMA system or Service\u003c/td\u003e\u003ctd\u003e\u003cp\u003eUpdates to ISA and MOU must occur. If not standard connection service/inheritance from another accredited FISMA system, SCA will be required.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eAC-4, CA-3, CA-9, PL-2, AC-3, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eArchitecture, Topology, Port/Protocol/Service change\u003c/td\u003e\u003ctd\u003e\u003cp\u003eZone changes\u003c/p\u003e\u003cp\u003eImplementation or inheritance of new services\u003c/p\u003e\u003cp\u003eUpdates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eCM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity components\u003c/td\u003e\u003ctd\u003e\u003cp\u003eIdentification, Authentication, Authorization\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eNew methods for authentication and/or identifiers added\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eMigrations between Single Factor and MFA\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew and modified control implementations must be tested. SCA required unless inheriting from existing FISMA system.\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eUpdates to all FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eIA (all)\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSecurity Components\u003c/td\u003e\u003ctd\u003eSecurity Controls – Change in implementation standard or status\u003c/td\u003e\u003ctd\u003eNew and modified control implementations must be tested via existing security processes. All changes must be documented within the SSP and the Controls tab within CFACTS. Changes in controls that cause controls to no longer be “Satisfied” must be submitted as a POA\u0026amp;M and documented within the ISRA.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eList specific controls changed\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eUser Interface\u003c/td\u003e\u003ctd\u003eUpdates to GUI including addition of new pages, new inputs\u003c/td\u003e\u003ctd\u003eNew pages must go through 508 testing, Static and Dynamic code analysis to determine no additional threats from XSS or other new vulnerabilities.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSI-10\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Hardware\u003c/td\u003e\u003ctd\u003eServers, Communication Devices\u003c/td\u003e\u003ctd\u003eIf the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eAC-19, SI-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Operating System\u003c/td\u003e\u003ctd\u003eChange in Operating System\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCP-2\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eNew or Updated Security Software\u003c/td\u003e\u003ctd\u003eNew Security Software or Perimeter Security Change\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5 Vulnerability Scanning\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-9(1) Compliance Checks\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential impact to multiple controls depending on nature of software\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSupport Software\u003c/td\u003e\u003ctd\u003e\u003cp\u003eNew Support Software\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eIf the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eRA-5\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePotential TRB review/approval\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVendor Patches\u003c/td\u003e\u003ctd\u003eSoftware, Servers\u003c/td\u003e\u003ctd\u003eSoftware patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003ePL-2 (SSP)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eHW/SW List\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem Boundary\u003c/td\u003e\u003ctd\u003eChange to Logical Access Points\u003c/td\u003e\u003ctd\u003eVulnerability Scan is required\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003eAC-17, AC-2, AC-3, AC-18, AC-19, AC-20,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCA-3, CA-7,\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Developed\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eAttacks Succeed Elsewhere\u003c/td\u003e\u003ctd\u003eRisk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eVulnerability (New or Existing)\u003c/td\u003e\u003ctd\u003eFound (No Attacks Known)\u003c/td\u003e\u003ctd\u003eAdd to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes.\u003c/td\u003e\u003ctd\u003e\u003cstrong\u003eRA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11\u003c/strong\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary\u003c/td\u003e\u003ctd\u003eNew processing location(s)\u003c/td\u003e\u003ctd\u003eA new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003eSystem boundary (environment)\u003c/td\u003e\u003ctd\u003eChange or Addition of Hosting Infrastructure or Site\u003c/td\u003e\u003ctd\u003eFull authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO.\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u003cstrong\u003ePE(family)\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eCM-2, CM-3, CM-4, CM-6, CM-7\u003c/strong\u003e\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 3: Validation/Security Testing\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003ePlease provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eTool/Scan Type\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e(Y/N)\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Performed by\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting /Method\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTesting Frequency\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eTest Result Location\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eNotes\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCompliance Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eVulnerability Scans\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eDynamic WAPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eStatic WPT Testing\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOptional\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003ctd\u003e\u0026nbsp;\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003ch4\u003e\u003cstrong\u003eSection 4: Overall Recommendation for Business Owners\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eUsing the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on the status of the change.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eISSO recommendation(s):\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u003cem\u003eISSO should indicate which of the following are recommended, and provide details using additional pages.\u003c/em\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003eDeploy to Production Environment without additional testing\u003c/li\u003e\u003cli\u003eUndergo Targeted Third Party Security Testing\u003c/li\u003e\u003cli\u003eUndergo SCA/CSRAP\u003c/li\u003e\u003cli\u003eRequire Business Owner Risk Acceptance to field to Production\u003c/li\u003e\u003cli\u003eApply for a new ATO\u003c/li\u003e\u003cli\u003eOther (e.g. update documentation. Specify on following page)\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSigned by:\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eSystem ISSO\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e_____________________________________________\u003c/p\u003e\u003cp\u003eBusiness Owner\u003c/p\u003e"])</script><script>self.__next_f.push([1,"cf:{\"value\":\"$d0\",\"format\":\"body_text\",\"processed\":\"$d1\"}\ncd:{\"drupal_internal__id\":1351,\"drupal_internal__revision_id\":19022,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-13T18:18:53+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_page_section\",\"behavior_settings\":\"$ce\",\"default_langcode\":true,\"revision_translation_affected\":true,\"field_text_block\":\"$cf\"}\nd5:{\"drupal_internal__target_id\":\"page_section\"}\nd4:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"57f3f40a-8120-4393-b881-a5758f9fb30d\",\"meta\":\"$d5\"}\nd7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/paragraph_type?resourceVersion=id%3A19022\"}\nd8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/relationships/paragraph_type?resourceVersion=id%3A19022\"}\nd6:{\"related\":\"$d7\",\"self\":\"$d8\"}\nd3:{\"data\":\"$d4\",\"links\":\"$d6\"}\ndb:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/field_specialty_item?resourceVersion=id%3A19022\"}\ndc:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/relationships/field_specialty_item?resourceVersion=id%3A19022\"}\nda:{\"related\":\"$db\",\"self\":\"$dc\"}\nd9:{\"data\":null,\"links\":\"$da\"}\nd2:{\"paragraph_type\":\"$d3\",\"field_specialty_item\":\"$d9\"}\nca:{\"type\":\"paragraph--page_section\",\"id\":\"21c13746-6570-4f61-8745-b5520d53b5d7\",\"links\":\"$cb\",\"attributes\":\"$cd\",\"relationships\":\"$d2\"}\ndf:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a?resourceVersion=id%3A19023\"}\nde:{\"self\":\"$df\"}\ne1:[]\ne0:{\"drupal_internal__id\":1686,\"drupal_internal__revision_id\":19023,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-14T16:38:17+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$e1\",\"default_langcode\":true,\"revision_translation_affected\":true}\ne5:{\"drupal_internal__target_id\":\"internal_link\"}\ne4:{\"type\":\"paragraphs_"])</script><script>self.__next_f.push([1,"type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$e5\"}\ne7:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/paragraph_type?resourceVersion=id%3A19023\"}\ne8:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/relationships/paragraph_type?resourceVersion=id%3A19023\"}\ne6:{\"related\":\"$e7\",\"self\":\"$e8\"}\ne3:{\"data\":\"$e4\",\"links\":\"$e6\"}\neb:{\"drupal_internal__target_id\":326}\nea:{\"type\":\"node--explainer\",\"id\":\"a279358b-5b24-49bc-a98e-11681bd7e65c\",\"meta\":\"$eb\"}\ned:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/field_link?resourceVersion=id%3A19023\"}\nee:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/relationships/field_link?resourceVersion=id%3A19023\"}\nec:{\"related\":\"$ed\",\"self\":\"$ee\"}\ne9:{\"data\":\"$ea\",\"links\":\"$ec\"}\ne2:{\"paragraph_type\":\"$e3\",\"field_link\":\"$e9\"}\ndd:{\"type\":\"paragraph--internal_link\",\"id\":\"319e7227-1f2a-4cdd-92a1-c4ef2593477a\",\"links\":\"$de\",\"attributes\":\"$e0\",\"relationships\":\"$e2\"}\nf1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004?resourceVersion=id%3A19024\"}\nf0:{\"self\":\"$f1\"}\nf3:[]\nf2:{\"drupal_internal__id\":1691,\"drupal_internal__revision_id\":19024,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-14T16:38:30+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$f3\",\"default_langcode\":true,\"revision_translation_affected\":true}\nf7:{\"drupal_internal__target_id\":\"internal_link\"}\nf6:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$f7\"}\nf9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/paragraph_type?resourceVersion=id%3A19024\"}\nfa:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/relationships/parag"])</script><script>self.__next_f.push([1,"raph_type?resourceVersion=id%3A19024\"}\nf8:{\"related\":\"$f9\",\"self\":\"$fa\"}\nf5:{\"data\":\"$f6\",\"links\":\"$f8\"}\nfd:{\"drupal_internal__target_id\":206}\nfc:{\"type\":\"node--explainer\",\"id\":\"defa7277-790b-4bbd-b6ee-cc539e121df2\",\"meta\":\"$fd\"}\nff:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/field_link?resourceVersion=id%3A19024\"}\n100:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/relationships/field_link?resourceVersion=id%3A19024\"}\nfe:{\"related\":\"$ff\",\"self\":\"$100\"}\nfb:{\"data\":\"$fc\",\"links\":\"$fe\"}\nf4:{\"paragraph_type\":\"$f5\",\"field_link\":\"$fb\"}\nef:{\"type\":\"paragraph--internal_link\",\"id\":\"1d1a8e48-f873-4c95-93aa-6243a892d004\",\"links\":\"$f0\",\"attributes\":\"$f2\",\"relationships\":\"$f4\"}\n103:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23?resourceVersion=id%3A19025\"}\n102:{\"self\":\"$103\"}\n105:[]\n104:{\"drupal_internal__id\":1696,\"drupal_internal__revision_id\":19025,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-14T16:38:36+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$105\",\"default_langcode\":true,\"revision_translation_affected\":true}\n109:{\"drupal_internal__target_id\":\"internal_link\"}\n108:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$109\"}\n10b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/paragraph_type?resourceVersion=id%3A19025\"}\n10c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/relationships/paragraph_type?resourceVersion=id%3A19025\"}\n10a:{\"related\":\"$10b\",\"self\":\"$10c\"}\n107:{\"data\":\"$108\",\"links\":\"$10a\"}\n10f:{\"drupal_internal__target_id\":461}\n10e:{\"type\":\"node--library\",\"id\":\"0dee405f-3bb7-4a8a-b602-b5de9697cfdf\",\"meta\":\"$10f\"}\n111:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/"])</script><script>self.__next_f.push([1,"field_link?resourceVersion=id%3A19025\"}\n112:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/relationships/field_link?resourceVersion=id%3A19025\"}\n110:{\"related\":\"$111\",\"self\":\"$112\"}\n10d:{\"data\":\"$10e\",\"links\":\"$110\"}\n106:{\"paragraph_type\":\"$107\",\"field_link\":\"$10d\"}\n101:{\"type\":\"paragraph--internal_link\",\"id\":\"9770a81c-b300-49e0-b938-d6fa266ffb23\",\"links\":\"$102\",\"attributes\":\"$104\",\"relationships\":\"$106\"}\n115:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427?resourceVersion=id%3A19026\"}\n114:{\"self\":\"$115\"}\n117:[]\n116:{\"drupal_internal__id\":2576,\"drupal_internal__revision_id\":19026,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-03-14T14:54:50+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":\"$117\",\"default_langcode\":true,\"revision_translation_affected\":true}\n11b:{\"drupal_internal__target_id\":\"internal_link\"}\n11a:{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":\"$11b\"}\n11d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/paragraph_type?resourceVersion=id%3A19026\"}\n11e:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/relationships/paragraph_type?resourceVersion=id%3A19026\"}\n11c:{\"related\":\"$11d\",\"self\":\"$11e\"}\n119:{\"data\":\"$11a\",\"links\":\"$11c\"}\n124:{\"about\":\"Usage and meaning of the 'missing' resource identifier.\"}\n123:{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#missing\",\"meta\":\"$124\"}\n122:{\"help\":\"$123\"}\n121:{\"links\":\"$122\"}\n120:{\"type\":\"unknown\",\"id\":\"missing\",\"meta\":\"$121\"}\n126:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/field_link?resourceVersion=id%3A19026\"}\n127:{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/relationships/field_link?resourceVersion"])</script><script>self.__next_f.push([1,"=id%3A19026\"}\n125:{\"related\":\"$126\",\"self\":\"$127\"}\n11f:{\"data\":\"$120\",\"links\":\"$125\"}\n118:{\"paragraph_type\":\"$119\",\"field_link\":\"$11f\"}\n113:{\"type\":\"paragraph--internal_link\",\"id\":\"5cedd0e5-92bf-4900-9591-37f8c9011427\",\"links\":\"$114\",\"attributes\":\"$116\",\"relationships\":\"$118\"}\n12a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c?resourceVersion=id%3A5942\"}\n129:{\"self\":\"$12a\"}\n12c:{\"alias\":\"/learn/fedramp\",\"pid\":316,\"langcode\":\"en\"}\n12d:{\"value\":\"Provides a federally-recognized and standardized security framework for all cloud products and services\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eProvides a federally-recognized and standardized security framework for all cloud products and services\u003c/p\u003e\\n\"}\n12e:[\"#fedramp\"]\n12b:{\"drupal_internal__nid\":326,\"drupal_internal__vid\":5942,\"langcode\":\"en\",\"revision_timestamp\":\"2024-10-17T14:55:23+00:00\",\"status\":true,\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"created\":\"2022-08-29T15:22:00+00:00\",\"changed\":\"2024-10-17T14:55:23+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$12c\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":null,\"field_contact_email\":\"FedRAMP@cms.hhs.gov\",\"field_contact_name\":\"CMS FedRAMP PMO\",\"field_short_description\":\"$12d\",\"field_slack_channel\":\"$12e\"}\n132:{\"drupal_internal__target_id\":\"explainer\"}\n131:{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"meta\":\"$132\"}\n134:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/node_type?resourceVersion=id%3A5942\"}\n135:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/node_type?resourceVersion=id%3A5942\"}\n133:{\"related\":\"$134\",\"self\":\"$135\"}\n130:{\"data\":\"$131\",\"links\":\"$133\"}\n138:{\"drupal_internal__target_id\":114}\n137:{\"type\":\"user--user"])</script><script>self.__next_f.push([1,"\",\"id\":\"d3421e1d-1fda-4bd0-83ab-e404455b0e66\",\"meta\":\"$138\"}\n13a:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/revision_uid?resourceVersion=id%3A5942\"}\n13b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/revision_uid?resourceVersion=id%3A5942\"}\n139:{\"related\":\"$13a\",\"self\":\"$13b\"}\n136:{\"data\":\"$137\",\"links\":\"$139\"}\n13e:{\"drupal_internal__target_id\":26}\n13d:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$13e\"}\n140:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/uid?resourceVersion=id%3A5942\"}\n141:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/uid?resourceVersion=id%3A5942\"}\n13f:{\"related\":\"$140\",\"self\":\"$141\"}\n13c:{\"data\":\"$13d\",\"links\":\"$13f\"}\n145:{\"target_revision_id\":19451,\"drupal_internal__target_id\":1171}\n144:{\"type\":\"paragraph--page_section\",\"id\":\"2ce39e48-81e4-4bea-a0ff-04f25ddd0041\",\"meta\":\"$145\"}\n147:{\"target_revision_id\":19452,\"drupal_internal__target_id\":1211}\n146:{\"type\":\"paragraph--page_section\",\"id\":\"77ea2e89-2433-4815-b869-52b2d900029e\",\"meta\":\"$147\"}\n149:{\"target_revision_id\":19462,\"drupal_internal__target_id\":3431}\n148:{\"type\":\"paragraph--page_section\",\"id\":\"deedf0fe-44e9-4015-90a1-f86ce6cbaf24\",\"meta\":\"$149\"}\n14b:{\"target_revision_id\":19472,\"drupal_internal__target_id\":1261}\n14a:{\"type\":\"paragraph--page_section\",\"id\":\"2b2216d8-24c3-4940-930f-6e79f68a279a\",\"meta\":\"$14b\"}\n14d:{\"target_revision_id\":19474,\"drupal_internal__target_id\":1266}\n14c:{\"type\":\"paragraph--page_section\",\"id\":\"cbda5c42-489d-4480-85f5-db10db44de3e\",\"meta\":\"$14d\"}\n14f:{\"target_revision_id\":19475,\"drupal_internal__target_id\":3433}\n14e:{\"type\":\"paragraph--page_section\",\"id\":\"37970dd4-a515-4370-a09f-f5177c2f98c2\",\"meta\":\"$14f\"}\n151:{\"target_revision_id\":19476,\"drupal_internal__target_id\":3434}\n150:{\"type\":\"paragraph--page_section\",\"id\":\"434b1960-73e8-43fa-9b9e-253ce35fa55a\",\"meta\":\"$151\"}\n143"])</script><script>self.__next_f.push([1,":[\"$144\",\"$146\",\"$148\",\"$14a\",\"$14c\",\"$14e\",\"$150\"]\n153:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_page_section?resourceVersion=id%3A5942\"}\n154:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_page_section?resourceVersion=id%3A5942\"}\n152:{\"related\":\"$153\",\"self\":\"$154\"}\n142:{\"data\":\"$143\",\"links\":\"$152\"}\n158:{\"target_revision_id\":19477,\"drupal_internal__target_id\":1956}\n157:{\"type\":\"paragraph--internal_link\",\"id\":\"7a5f06f0-e0ba-4ed2-aade-79b2233ec125\",\"meta\":\"$158\"}\n15a:{\"target_revision_id\":19478,\"drupal_internal__target_id\":1961}\n159:{\"type\":\"paragraph--internal_link\",\"id\":\"61509c21-9c9e-48d0-8110-b98574cee727\",\"meta\":\"$15a\"}\n15c:{\"target_revision_id\":19479,\"drupal_internal__target_id\":1966}\n15b:{\"type\":\"paragraph--internal_link\",\"id\":\"c2480fc7-b7c3-49d4-8643-cd42bcd3b56b\",\"meta\":\"$15c\"}\n15e:{\"target_revision_id\":19480,\"drupal_internal__target_id\":3435}\n15d:{\"type\":\"paragraph--internal_link\",\"id\":\"63dffb2c-c587-4991-8523-142b2378a5aa\",\"meta\":\"$15e\"}\n156:[\"$157\",\"$159\",\"$15b\",\"$15d\"]\n160:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_related_collection?resourceVersion=id%3A5942\"}\n161:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_related_collection?resourceVersion=id%3A5942\"}\n15f:{\"related\":\"$160\",\"self\":\"$161\"}\n155:{\"data\":\"$156\",\"links\":\"$15f\"}\n164:{\"drupal_internal__target_id\":131}\n163:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"meta\":\"$164\"}\n166:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_resource_type?resourceVersion=id%3A5942\"}\n167:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_resource_type?resourceVersion=id%3A5942\"}\n165:{\"related\":\"$166\",\"self\":\"$167\"}\n162:{\"data\":\"$163\",\"links\":\"$165\"}\n16b:{\"drupal_"])</script><script>self.__next_f.push([1,"internal__target_id\":66}\n16a:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$16b\"}\n16d:{\"drupal_internal__target_id\":61}\n16c:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$16d\"}\n16f:{\"drupal_internal__target_id\":76}\n16e:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$16f\"}\n169:[\"$16a\",\"$16c\",\"$16e\"]\n171:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_roles?resourceVersion=id%3A5942\"}\n172:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_roles?resourceVersion=id%3A5942\"}\n170:{\"related\":\"$171\",\"self\":\"$172\"}\n168:{\"data\":\"$169\",\"links\":\"$170\"}\n176:{\"drupal_internal__target_id\":21}\n175:{\"type\":\"taxonomy_term--topics\",\"id\":\"b61c7b1f-0882-4fac-bf13-02c68b56fd38\",\"meta\":\"$176\"}\n174:[\"$175\"]\n178:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_topics?resourceVersion=id%3A5942\"}\n179:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_topics?resourceVersion=id%3A5942\"}\n177:{\"related\":\"$178\",\"self\":\"$179\"}\n173:{\"data\":\"$174\",\"links\":\"$177\"}\n12f:{\"node_type\":\"$130\",\"revision_uid\":\"$136\",\"uid\":\"$13c\",\"field_page_section\":\"$142\",\"field_related_collection\":\"$155\",\"field_resource_type\":\"$162\",\"field_roles\":\"$168\",\"field_topics\":\"$173\"}\n128:{\"type\":\"node--explainer\",\"id\":\"a279358b-5b24-49bc-a98e-11681bd7e65c\",\"links\":\"$129\",\"attributes\":\"$12b\",\"relationships\":\"$12f\"}\n17c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2?resourceVersion=id%3A5737\"}\n17b:{\"self\":\"$17c\"}\n17e:{\"alias\":\"/learn/authorization-operate-ato\",\"pid\":196,\"langcode\":\"en\"}\n17f:{\"value\":\"Testing and documenting system security and compliance to gain approval to operate the system at CMS\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eTesting and documenting system security and compliance to g"])</script><script>self.__next_f.push([1,"ain approval to operate the system at CMS\u003c/p\u003e\\n\"}\n180:[\"#cra-help\"]\n17d:{\"drupal_internal__nid\":206,\"drupal_internal__vid\":5737,\"langcode\":\"en\",\"revision_timestamp\":\"2024-07-31T17:37:48+00:00\",\"status\":true,\"title\":\"Authorization to Operate (ATO)\",\"created\":\"2022-08-25T19:06:37+00:00\",\"changed\":\"2024-07-31T17:37:48+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$17e\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":null,\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_short_description\":\"$17f\",\"field_slack_channel\":\"$180\"}\n184:{\"drupal_internal__target_id\":\"explainer\"}\n183:{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"meta\":\"$184\"}\n186:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/node_type?resourceVersion=id%3A5737\"}\n187:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/node_type?resourceVersion=id%3A5737\"}\n185:{\"related\":\"$186\",\"self\":\"$187\"}\n182:{\"data\":\"$183\",\"links\":\"$185\"}\n18a:{\"drupal_internal__target_id\":6}\n189:{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":\"$18a\"}\n18c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/revision_uid?resourceVersion=id%3A5737\"}\n18d:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/revision_uid?resourceVersion=id%3A5737\"}\n18b:{\"related\":\"$18c\",\"self\":\"$18d\"}\n188:{\"data\":\"$189\",\"links\":\"$18b\"}\n190:{\"drupal_internal__target_id\":26}\n18f:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$190\"}\n192:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/uid?resourceVersion=id%3A5737\"}\n193:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/e"])</script><script>self.__next_f.push([1,"xplainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/uid?resourceVersion=id%3A5737\"}\n191:{\"related\":\"$192\",\"self\":\"$193\"}\n18e:{\"data\":\"$18f\",\"links\":\"$191\"}\n197:{\"target_revision_id\":18928,\"drupal_internal__target_id\":711}\n196:{\"type\":\"paragraph--page_section\",\"id\":\"d94629f9-9668-41dd-bce7-a4f267239c07\",\"meta\":\"$197\"}\n199:{\"target_revision_id\":18929,\"drupal_internal__target_id\":736}\n198:{\"type\":\"paragraph--page_section\",\"id\":\"243e2d3f-f903-438c-8b1f-aee53390b1df\",\"meta\":\"$199\"}\n195:[\"$196\",\"$198\"]\n19b:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_page_section?resourceVersion=id%3A5737\"}\n19c:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_page_section?resourceVersion=id%3A5737\"}\n19a:{\"related\":\"$19b\",\"self\":\"$19c\"}\n194:{\"data\":\"$195\",\"links\":\"$19a\"}\n1a0:{\"target_revision_id\":18930,\"drupal_internal__target_id\":3376}\n19f:{\"type\":\"paragraph--internal_link\",\"id\":\"6f904ac4-c80e-47d9-b786-ee79256befed\",\"meta\":\"$1a0\"}\n1a2:{\"target_revision_id\":18931,\"drupal_internal__target_id\":1306}\n1a1:{\"type\":\"paragraph--internal_link\",\"id\":\"e20959d7-2a7b-4a01-b985-cfa5363233f5\",\"meta\":\"$1a2\"}\n1a4:{\"target_revision_id\":18932,\"drupal_internal__target_id\":1316}\n1a3:{\"type\":\"paragraph--internal_link\",\"id\":\"dba9b926-f657-43ce-bc94-0a2d803430c6\",\"meta\":\"$1a4\"}\n1a6:{\"target_revision_id\":18933,\"drupal_internal__target_id\":2521}\n1a5:{\"type\":\"paragraph--internal_link\",\"id\":\"44f7083e-9341-42a5-85dc-a9043cdccdce\",\"meta\":\"$1a6\"}\n1a8:{\"target_revision_id\":18934,\"drupal_internal__target_id\":3444}\n1a7:{\"type\":\"paragraph--internal_link\",\"id\":\"bd0366d9-64ce-401f-9453-bf38aa8054a1\",\"meta\":\"$1a8\"}\n19e:[\"$19f\",\"$1a1\",\"$1a3\",\"$1a5\",\"$1a7\"]\n1aa:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_related_collection?resourceVersion=id%3A5737\"}\n1ab:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_related_collection?reso"])</script><script>self.__next_f.push([1,"urceVersion=id%3A5737\"}\n1a9:{\"related\":\"$1aa\",\"self\":\"$1ab\"}\n19d:{\"data\":\"$19e\",\"links\":\"$1a9\"}\n1ae:{\"drupal_internal__target_id\":131}\n1ad:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"meta\":\"$1ae\"}\n1b0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_resource_type?resourceVersion=id%3A5737\"}\n1b1:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_resource_type?resourceVersion=id%3A5737\"}\n1af:{\"related\":\"$1b0\",\"self\":\"$1b1\"}\n1ac:{\"data\":\"$1ad\",\"links\":\"$1af\"}\n1b5:{\"drupal_internal__target_id\":66}\n1b4:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$1b5\"}\n1b7:{\"drupal_internal__target_id\":61}\n1b6:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":\"$1b7\"}\n1b9:{\"drupal_internal__target_id\":76}\n1b8:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$1b9\"}\n1b3:[\"$1b4\",\"$1b6\",\"$1b8\"]\n1bb:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_roles?resourceVersion=id%3A5737\"}\n1bc:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_roles?resourceVersion=id%3A5737\"}\n1ba:{\"related\":\"$1bb\",\"self\":\"$1bc\"}\n1b2:{\"data\":\"$1b3\",\"links\":\"$1ba\"}\n1c0:{\"drupal_internal__target_id\":11}\n1bf:{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"meta\":\"$1c0\"}\n1be:[\"$1bf\"]\n1c2:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_topics?resourceVersion=id%3A5737\"}\n1c3:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_topics?resourceVersion=id%3A5737\"}\n1c1:{\"related\":\"$1c2\",\"self\":\"$1c3\"}\n1bd:{\"data\":\"$1be\",\"links\":\"$1c1\"}\n181:{\"node_type\":\"$182\",\"revision_uid\":\"$188\",\"uid\":\"$18e\",\"field_page_section\":\"$194\",\"field_related_collection\":\"$19d\",\"field_reso"])</script><script>self.__next_f.push([1,"urce_type\":\"$1ac\",\"field_roles\":\"$1b2\",\"field_topics\":\"$1bd\"}\n17a:{\"type\":\"node--explainer\",\"id\":\"defa7277-790b-4bbd-b6ee-cc539e121df2\",\"links\":\"$17b\",\"attributes\":\"$17d\",\"relationships\":\"$181\"}\n1c6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf?resourceVersion=id%3A5778\"}\n1c5:{\"self\":\"$1c6\"}\n1c8:{\"alias\":\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\",\"pid\":451,\"langcode\":\"en\"}\n1ca:T1c68f,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eIntroduction\u003c/h2\u003e\u003cp\u003eThis Handbook outlines procedures to help CMS staff and contractors implement the Configuration Management family of controls taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 and tailored to the CMS environment in the CMS Acceptable Risk Safeguards (ARS). For more guidance on how to implement CMS policies and standards across many cybersecurity topics, see the CMS Security and Privacy Handbooks.\u0026nbsp;\u003c/p\u003e\u003cp\u003eConfiguration management has been applied to a broad range of information systems. Some basic terms associated with the configuration management discipline are briefly explained below.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eBaseline Configuration\u003c/em\u003e\u0026nbsp;is a set of specifications for a system that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;(CM Plan) is a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. The basic parts of a CM Plan include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eConfiguration Control Board\u003c/em\u003e\u0026nbsp;(CCB) – establishment of and charter for a group of qualified people with responsibility for the process of controlling and approving changes throughout the development and operation lifecycle of products and systems; may also be referred to as a change control board;\u003c/li\u003e\u003cli\u003eConfiguration Item\u0026nbsp;\u003cem\u003eIdentification\u003c/em\u003e\u0026nbsp;– methodology for selecting and naming configuration items that need to be placed under CM;\u003c/li\u003e\u003cli\u003eConfiguration\u0026nbsp;\u003cem\u003eChange Control\u003c/em\u003e\u0026nbsp;– process for managing updates to the baseline configurations for the configuration items; and\u003c/li\u003e\u003cli\u003eConfiguration\u003cem\u003e\u0026nbsp;Monitoring\u003c/em\u003e\u0026nbsp;– process for assessing or testing the level of compliance with the established baseline configuration and mechanisms for reporting on the configuration status of items places under CM.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis guideline is associated with the application of security-focused configuration management practices as they apply to information systems. The configuration of an information system is a representation of the system’s components, how each component is configured, and how the components are connected or arranged to implement the information system. The possible conditions in which an information system or system component can be arranged affect the security posture of the information system. The activities involved in managing the configuration of an information system include development of a configuration management plan, establishment of a configuration control board, development of a methodology for configuration item identification, establishment of the baseline configuration, development of a configuration change control process, and development of a process for configuration monitoring and reporting.\u003c/p\u003e\u003cp\u003eConfiguration management of information systems involves a set of activities that can be organized into four major phases – Planning, Identifying and Implementing Configurations, Monitoring, and Controlling Configuration Changes. It is through these phases that CM not only supports security for an information system and its components, but also supports the management of organizational risk.\u003c/p\u003e\u003ch2\u003eConfiguration Management controls\u003c/h2\u003e\u003ch3\u003eBaseline Configuration (CM-2)\u003c/h3\u003e\u003cp\u003eThis control requires CMS to develop, document, and maintain under configuration control a current baseline configuration for each information system. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for initializing and maintaining an information system configuration baseline.\u003c/p\u003e\u003cp\u003eTo develop and document initial configurations:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system owner with the support of the Change Control Board (CCB) identifies the configuration settings for their information system, device, appliance, or application using configuration settings standards in section 3.5 as part of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer documents the configuration settings chosen during Step 1 in the CMS Intake Form as part of the CMS-SDLC.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn order to maintain the configuration baseline, the Business Owner ensures the following is completed:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization determines that the system requires a change. (See SA-3 and CM-9).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops a high-level plan for how to accomplish the change (see SA-3, and SA-10).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) reviews the Privacy Impact Assessment (PIA) and conducts a Security Impact Analysis (SIA, see CM-4 Security Impact Analysis) to identify the privacy and security impacts of their plan (see CM-4 and SA-3).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops any applicable design requirements to mitigate the identified security impacts (see SA-3, SA-8, and SA-17).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops testing requirements to ensure that the security impacts are verified as successfully mitigated (see CA-2 and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) builds out the system changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) test, independently as required by CA-2(1) and CA-7(1)), the system changes using the security tests developed in step 5 (see AC-5.Std.5, CA-2, CM-3(2), CM-4(1), and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops and implements any Plans of Action and Milestones (POA\u0026amp;Ms) necessary to correct identified failures from testing (see CA-5).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11:\u0026nbsp; \u003c/strong\u003eThe ISSO applies either for a new Authorization To Operate (ATO), or for an ATO update (see CA-6).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReviews and Updates (CM-2(1))\u003c/h4\u003e\u003cp\u003eThis enhancement requires CMS to review and update the baseline configuration of its information systems at a regularly defined frequency, when special circumstances arise, or when and information system component is installed or upgraded.\u0026nbsp; By defining and maintaining a baseline configuration for its information systems, CMS is supporting the cybersecurity concepts of least privilege and least functionality. In addition, the establishment of configuration baselines helps the organization recognize abnormal behavior as a sign of attack.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for review and update of the baseline configuration for an information system.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003e[Assignment: organization-defined frequency];\u003c/li\u003e\u003cli\u003eWhen required due to [Assignment organization-defined circumstances];and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003eAt least every 180 days for High systems or\u0026nbsp; 365 days for Moderate systems;\u003c/li\u003e\u003cli\u003eWhen configuration settings change due to critical security patches (as defined by the federal government, CMS, or vendor), upgrades and emergency changes (e.g., unscheduled changes, system crashes, replacement of critical hardware components), major system changes/upgrades;\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eTo implement the CMS controls for reviewing and updating configuration baseline, the Information System Security Officer (ISSO) must first assign a security category in accordance with FIPS 199.\u003c/p\u003e\u003cp\u003eThis procedure is outlined in RMH Chapter 12: Security \u0026amp; Privacy Planning, under control PL-2.\u0026nbsp; The category will assist the CCB with identifying adequate security controls and ensuring they are integrated into the configuration baseline of the information system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCB will review information system baseline configurations every 365 days for systems categorized “High” and every 1,095 days for systems categorized as “Moderate”. Other triggers outside of scheduled times for configuration baseline review are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical security patches to the system/component\u003c/li\u003e\u003cli\u003eUpgrades to the system\u003c/li\u003e\u003cli\u003eEmergency changes\u003c/li\u003e\u003cli\u003eMajor system changes or upgrades\u003c/li\u003e\u003cli\u003eInformation system component installations\u003c/li\u003e\u003cli\u003eUpdates to the governing standards\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn addition, system developer and maintainers will have to update the documentation regarding the baseline configuration after an approval of changes. Updates must follow the same process stated above in CM-2.\u003c/p\u003e\u003ch4\u003eAutomation Support for Accuracy / Currency (CM-2(2))\u003c/h4\u003e\u003cp\u003eCMS provides automation support whenever possible to information systems’ configuration baselines. \u0026nbsp;Automation support examples include hardware asset management systems, software asset management systems, and centralized configuration management software. \u0026nbsp;CMS uses automation of information gathering to support the continuous monitoring program and inventory systems. \u0026nbsp;Automation support captures the types of hardware and software on the network and the operating system or firmware on each device.\u003c/p\u003e\u003cp\u003eThe goal is to keep track of what the configuration is on each system and to have the ability to go to an information system and collect configuration information automatically. \u0026nbsp;The automation keeps the data on systems configuration up-to-date, accurate, and available when it is needed.\u0026nbsp; With a current list of configurations, CMS can feed it into other processes that look for deviations from the baseline and configurations that are not up to organizational standards. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HSS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for incorporating automation to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system developer and maintainer configures the system architecture to allow automated hardware and software mechanisms provided by Continuous Diagnostics and Mitigation (CDM) to scan the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer configures the access controls, as needed, to allow automation support to have access to the information that it needs.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Cybersecurity Integration Center (CCIC) runs automated mechanisms to gather hardware and software configurations as part of the Continuous Monitoring Program whose point of contact information is in Appendix G.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRetention of Previous Configurations (CM-2(3))\u003c/h4\u003e\u003cp\u003eRetaining documentation of configuration information is the first step to the restoration in times of need. CMS will maintain at least one backup of the configuration for systems, system components, and information system services. The configuration information needed is used to restore a device, service, or software to a previous state. Related to CM-2(2), section 3.1.2 of this document, the automated gathering of configuration information can be used to collect the data. This backup should also be maintained, given that the configuration will change over time. The approval of changes in the configuration from the CCB should also be added to the configuration documentation to retain as a new version.\u003c/p\u003e\u003cp\u003eThe retention of configuration information is in support of CMS as one of its goals to maintain availability of systems. A previous configuration could be used to replace current settings and processes to a former state. This former state should be an approved configuration that may increase risk, but maintain availability. For example, if there were a system that did not apply a critical security patch correctly causing a system failure, then restoring the previous configuration would restore the system to a functioning state (available) without the security protection of the patch (increased risk).\u003c/p\u003e\u003cp\u003eThe configuration information can also be used when settings change with unintended consequences during system upgrades or replacements. The previous configuration can be restored using what is called a rollback procedure, which would implement the settings for a former state that is known to function properly.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameter (ODP) for CM Retention of Previous Configurations.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(3)\u003c/td\u003e\u003ctd\u003eThe organization retains [Assignment: organization-defined previous versions of baseline configurations of the information system] to support rollback.\u003c/td\u003e\u003ctd\u003eThe organization retains older versions of baseline configurations of the information system as deemed necessary, by the ISSO, to support rollback.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for retaining configuration information of an information system:\u003c/p\u003e\u003cp\u003eThe system developer and maintainer will determine the needs of the system to restore it back to a previous state. The information gathered can be a combination of settings, version numbers of software/firmware/hardware, access controls, connection information, or schematics. The importance of gathering the correct information is to ensure that the system will work using the previous configuration as stored. This previous configuration information must also be available in case of emergencies and must therefore be stored apart from the system itself to remain available if the system is offline. Additionally, configuration changes that are approved by the CCB must be added to the configuration baseline to ensure the up-to-date configurations are used for restoration. A minimum of one previous configuration is required for this control.\u003c/p\u003e\u003cp\u003eBecause the retention process will be slightly different for every information system, the system developer and maintainer must document their process in their Configuration Management Plan (CMP).\u003c/p\u003e\u003ch4\u003eConfigure Systems, Components, or Devices for High-Risk Areas (CM-2(7))\u003c/h4\u003e\u003cp\u003eThis control guides CMS to create configurations and/or procedures for systems (laptops, iPhones, etc.) that are traveling to high-risk areas. \u0026nbsp;This control is for official travel, because unofficial/personal travel should not involve the transportation of Government Furnished Equipment (GFEs).\u0026nbsp; CMS employees traveling to high-risk areas should not travel with their permanently issued GFE but instead use an assigned loaner laptop from the designated laptop team. \u0026nbsp;The designation of high-risk countries can be found on the State Department’s website\u0026nbsp;\u003cem\u003eTravel to High-Risk Areas\u003c/em\u003e\u0026nbsp; Upon returning, CMS employees and contractors return their mobile devices to the SOC for a check of signs of physical tampering.\u0026nbsp; HHS guidance can be found here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\"\u003ehttps://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\u003c/a\u003e. Further guidance can be obtained from the HHS Office of Security and Strategic Information and from the Broadcast on Foreign Travel:\u0026nbsp;\u003cem\u003eUpdated Foreign Travel Security Awareness Guidance\u003c/em\u003e\u0026nbsp;(6/12/2017).\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM-2(7) Configure Systems, Components, or Devices for High-Risk Areas.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(7)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003cli\u003eApplies [Assignment: organization-defined security safeguards] to the devices when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues dedicated information systems, system components, or devices with stringent configurations (e.g., FIPS 140-2 for encryption) to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eApplies security safeguards to the devices (i.e., detailed inspection of the device for physical tampering, purging or reimaging the hard disk drive/removable media) when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for handling systems components or devices for travel to a high-risk area.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; CMS Users traveling to foreign countries for official business notify the Office of Security and Strategic Information (OSSI) at least 30 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u0026nbsp;and follow the HHS\u0026nbsp;\u003cem\u003eForeign Travel Checklist\u0026nbsp;\u003c/em\u003ethat is available here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\"\u003ehttps://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;CMS Users traveling to foreign countries for official business notify the CMS International Team least 10 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Users notifies the Service Desk at least 10 days in advance of their travel in order to arrange for their travel laptop to conduct business on while abroad using the email\u0026nbsp;\u003ca href=\"mailto:Cms_it_service_desk@cms.hhs.gov\"\u003ecms_it_service_desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS International Team checks the country against the Department of State travel advisories to determine the risk to the traveling CMS User here:\u0026nbsp;\u003ca href=\"https://travel.state.gov/content/passports/en/alertswarnings.html\"\u003ehttps://travel.state.gov/content/passports/en/alertswarnings.html\u003c/a\u003e. \u0026nbsp;Then uses that information to decide the security awareness briefing that the User will receive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS International Team notifies the Infrastructure \u0026amp; User Services Group about the connection of the GFE that the user will have while overseas.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Deskside Support protects the travel computer using the FIPS 140-2 compliant encryption using the current full-disk encryption solution. (e.g. Checkpoint Endpoint Encryption)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS International Team debriefs the User when they return.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;CMS User returns the travel computer to CMS Deskside Support within two days of returning from travel before connecting it to the CMS network or system and does not attempt to transfer data when returning.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Change Control (CM-3)\u003c/h3\u003e\u003cp\u003eConfiguration change control implements the change control process for the information system, system component, or information system service. Management will determine which changes to the system need to be part of the change control process. There will also be employees assigned to the CCB to review and approve changes to the system, component or service. The CCB will take security considerations as part of the decision making process. Changes that are approved will need to be documented as a part of the process.\u0026nbsp; The documentation should include the decisions on the changes as well as the changes that are to be made.\u0026nbsp; The CCB should periodically audit and review the activities related to the changes that have been made to the applicable system, component or service. It should also meet often enough to accommodate the changes that are proposed.\u003c/p\u003e\u003cp\u003eThe reason that change control is enacted is to reduce the impact of changes to the CIA of the data processed by the system.\u0026nbsp; The CCB can approve or disapprove of changes for a particular system so that there is no single person making changes to the system.\u0026nbsp; CMS wants to prevent or minimize risks that can occur as a result of unauthorized or uncoordinated changes. \u0026nbsp;This helps to separate the duties involved and adds an extra layer of security. \u0026nbsp;The documentation of changes can help to troubleshoot issues when systems malfunction and to audit the system for compliance to CMS rules and regulations. CMS uses configuration change control to maintain availability through changes that have to be tested and system integrity through audits and approvals for system changes.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Configuration Change Control.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board)] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for a minimum of three (3) years after the change;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through change request forms which must be approved by an organizational and/or CMS change control board that convenes frequently enough to accommodate proposed change requests, and other appropriate organization officials including, but not limited to, the System Developer/Maintainer and information system support staff.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following, which is ensured by the Business Owner, details the CMS specific process for controlling changes to a CMS information system’s configuration.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The Information System Security Officer (ISSO), System Owner (or designee) and the project manager writes a configuration management plan that includes the parts of the system (called configuration items or CIs) which are to be controlled under configuration management procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The project/program manager further describes the process of how decisions are made in the CCB for guidance after members are assigned. This is documented in a Change Management Plan in alignment with the CMS-SDLC\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, System Owner (or designee) and the project manager create a CCB by assigning members and write a charter and operating procedures for the CCB. The CCB must have at least the system developer, Privacy Officer, ISSO (contractor/federal), maintainer, and a member of the information system support staff assigned.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CCB coordinates and oversees configuration control activities. They review change requests (CRs) and should meet often enough to appropriately handle the reviews in a timely manner throughout the life cycle from requirements analysis to disposition. \u0026nbsp;The reviews should produce an approval or disapproval that is recorded via the method in Section 4 of the relevant Change Management Plan.\u0026nbsp; The decision should take into account a \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis (SIA)\u003c/a\u003e, as outlined in CM-4, from the ISSO.\u0026nbsp; They should monitor the status of proposed changes ensuring that only approved changes are applied.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer implements approved changes once passed by the CCB. The CCB must maintain a record of configuration-controlled changes to the information system for a minimum of three (3) years after the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The project/program manager updates the configuration information inside of the System Design Document to reflect the changes approved in the CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB audits implemented changes before the changes are added to the configuration baseline by verifying that the changes fulfill the requirements or requesting the update of documented requirements in response to the CR so it accurately reflect the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB tracks the progress of the implementation of the change by confirming the updates to the configuration documentation in the System Design Document as CRs are approved.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;The CCB checks the configuration of the system periodically for discrepancies against the documented configuration baseline. The configuration audit will determine either whether the configuration of the system is compliant with the approved baseline, at which point they will notify the ISSO to initiate a POA\u0026amp;M.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Document / Notification / Prohibition of Changes (CM-3(1))\u003c/h4\u003e\u003cp\u003eAutomation in the change management process can help to document changes and ensure the proper workflow. CMS uses automated means to document system changes for submission to the CCB. The automated process should cover several things. CMS wants the automated system to notify the authorizing personnel, who were designated to approve changes, whenever changes are proposed. The change request can be automated giving highlight rules to change requests for different statuses such as: awaiting approval, not approved, or overdue (defined in the SSPP). When the approvals come through, this system should alert the stakeholders that the change is approved.\u003c/p\u003e\u003cp\u003eChanging systems are a frequent occurrence. Automating the documentation, along with notification or prohibition of changes, saves CMS resources. Automating these processes can also increase the traceability of changes for many systems at once. This helps to keep accounts of all records linked to each applicable system and to review who approved specific changes and reasons for change.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Automated Document/Notification/Prohibition of Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify [Assignment: organized-defined approval authorities] of proposed changes to the information system and request change approval;\u003c/li\u003e\u003cli\u003eHighlight proposed changes to the information system that have not been approved or disapproved by [Assignment: organization-defined time period];\u003c/li\u003e\u003cli\u003eNotify [Assignment: organization-defined personnel] when approved changes to the information system are completed.\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify designated approval authorities (defined in the SSPP) of proposed changes to the information system;\u003c/li\u003e\u003cli\u003eHighlight proposed changes that have been waiting an approval decision, or have not been approved, for longer than change management procedure (defined in the SSPP) requires;\u003c/li\u003e\u003cli\u003eNotify stakeholders when approved changes are completed. A list of potential stakeholders\u0026nbsp; include, but is not limited to the following:\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair;\u003c/li\u003e\u003cli\u003eChief Risk Officer (CRO);\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA);\u003c/li\u003e\u003cli\u003eISSO;\u003c/li\u003e\u003cli\u003eProgram Manager;\u003c/li\u003e\u003cli\u003eData Guardian;\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO); and\u003c/li\u003e\u003cli\u003eInformation System Administrator.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which are ensured by the Business Owner, outline the process for automating the processes of documenting, notifying, and prohibiting actions during the change control process.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The Information System Security Officer (ISSO), Information System Owner (ISO) and Project Manager develops configuration processes and procedures that include automated mechanisms, documenting them in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;during the proper CMS-SDLC phase. The automated mechanism(s) should be able to prohibit changes to the information system until a change is approved, store all approved Change Requests (CRs), and then notify the stakeholders when approved changes are complete.\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStakeholders to be notified upon implementation of changes (at a minimum):\u003c/strong\u003e\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair\u003c/li\u003e\u003cli\u003eCRO Chief Risk Officer (CRO)\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA)\u003c/li\u003e\u003cli\u003eBusiness Owner(BO)\u003c/li\u003e\u003cli\u003eProgram Manager\u003c/li\u003e\u003cli\u003eData Guardian (DG)\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO)\u003c/li\u003e\u003cli\u003eInformation System Administrator\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e* For the stakeholders mentioned in Table 5 and Step 1 above, the CCB must be notified of system changes. However, each system requires its own group of stakeholders to make up the CCB and there is no expectation for each role listed in Table 5 to receive notifications for every single system change. This is especially true for the Data Guardian who should only receive notification when significant changes are implemented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop, as part of the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e, an automated method of requesting approval from the authorized submitter to the appropriate CCB members to be listed in section 4.2 Roles and Responsibilities.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop the method of automated notification of changes that have requested approval to determine who gets notification at the time of proposal and how they are notified.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe ISSO, ISO, and Project Manager reference the SSPP for handling changes, to determine highlighting rules for CRs that have not been addressed or have not been approved within the designated period.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eTest / Validate / Document Changes (CM-3(2))\u003c/h4\u003e\u003cp\u003eSystems can implement this control by creating an environment to test changes prior to implementation in the operational environment. The testing environment should be separate from the operational environment when possible. The test environment should mirror the operational environment to the \u0026nbsp;maximum extent possible, but CMS realizes deviations will have to be made so long as they are properly documented. Teams performing testing should document the process and procedures associated with the test to include a detailed outcome.\u003c/p\u003e\u003cp\u003eThe purpose of testing changes to the system prior to implementation is to reduce the chance that outages will occur during implementation.\u0026nbsp; The separation of testing from implementation in the operational environment is meant to give network/system administrators an opportunity to see if proposed changes will adversely affect the operational systems. \u0026nbsp;CMS has the goal of reducing the chances that the operational environment will fail as a result of changes to the environment. \u0026nbsp;Implementing this control will reduce breaks in operational environments and enable stakeholders making subsequent changes to reference the documentation created.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for testing, validating, and documenting changes to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer designs and develops the tests for the information system, as required by the CMS-SDLC, to be referenced for testing during changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Change Manager collects CRs and makes sure that they are documented in the automated tool as outlined in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan.\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer with the system/network administrator test the system changes as outlined in the documented CR and approved by the CCB.\u0026nbsp; The test may be conducted on the test environment or operational system while off-line or during a maintenance window using the tests outlined in the test plan.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSecurity Impact Analysis (CM-4)\u003c/h3\u003e\u003cp\u003eOrganizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems.\u003c/p\u003e\u003cp\u003eThe analysis of the security impact of a change occurs when changes are analyzed and evaluated for adverse impact on security, preferably before they are approved and implemented, but also in the case of emergency/unscheduled changes. These analyses are important to CMS because they prevent unnecessary risk to the enterprise.\u003c/p\u003e\u003cp\u003eChanges (in both the change management process and if a significant change will be made that impacts the ATO) should not be accepted without first studying the risks posed by these changes by conducting a security impact analysis. Before the changes are implemented and tested, a security impact analysis (and/or assessment) is performed to ensure that the changes have been sufficiently analyzed and documented, and to determine if there are any unanticipated effects of the change on existing security controls.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eChange Management\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eInformation system changes should not be undertaken prior to assessing the security impact of such changes. If the results of the security impact analysis indicate that the proposed or actual changes can affect, or have affected, the security state of the system; then corrective actions must be initiated and appropriate documents are revised and updated (e.g., the system security plan, security assessment report, and plan of action and milestones, etc.).\u003c/p\u003e\u003cp\u003eThe business owner, or common control provider(s) should consult with their ISSO and/or CRA, and participate in the TRB review process prior to implementing any security-related changes to the information system, or its environment of operation.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSignificant Change\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMany events can trigger change—even events that may not result in an actual system “change”. Significant changes require a formal reauthorization of the system. If a formal reauthorization action is required, the business owner should target only the specific security controls affected by the changes and reuse previous assessment results wherever possible. Most routine changes to an information system or its environment of operation can be handled by the business owner’s continuous monitoring program.\u003c/p\u003e\u003cp\u003eNIST states that a Significant Change to an information system may include (for example): (i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform; (iv) modifications to cryptographic modules or services; or (v) modifications to security controls. Examples of significant changes to the environment of operation may include for example: (i) moving to a new facility; (ii) adding new core missions or business functions; (iii) acquiring specific and credible threat information that the organization is being targeted by a threat source; or (iv) establishing new/modified laws, directives, policies, or regulations.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process to conduct a security impact analysis:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;After receiving the Change Request (CR) submission from the CCB, the ISSO will determine the scope of the change by analyzing the CR form. They will develop a high-level architecture overview that shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), the ISSO will request follow-up documentation/information and review it or use whatever information is available (e.g., audit records, interview staff who made the change, etc.) to gain insight into the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2\u003c/strong\u003e: The ISSO will identify the scope and the categorization of the change.\u0026nbsp; See Appendix D for the SIA Template.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3\u003c/strong\u003e: The ISSO will identify any vulnerabilities (via vulnerability scans, documentation comparison etc.) in the proposed change and analyze the categorizations of change and identify the security controls that are impact by the change (both system specific, hybrid, and inherited controls)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4\u003c/strong\u003e: The ISSO, in consultation with the CRA, conducts a risk assessment of any discovered vulnerabilities (impact and likelihood) and change(s) to security control implementation that has been affected by the change(s). A risk assessment is needed to identify the likelihood of a threat exercising the vulnerability and the impact of such an event.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, assess impact of proposed change on functionality of the system or CI and assess impact of proposed change on existing security controls. For example, the change may involve installation of software that alters the existing baseline configuration, or the change itself may cause or require changes to the existing baseline configuration. The change may also affect other systems or system components that depend on the function or component being changed, temporarily or permanently. For example, if a database that is used to support auditing controls is being upgraded to the latest version, auditing functionality within the system may be halted while the upgrade is being implemented.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, conducts a Privacy Impact Assessment to ensure that a change to the system that affects PII/PHI is accounted for and proper action can be taken if necessary\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7\u003c/strong\u003e: The ISSO, in consultation with the CRA, determine whether the change is part of the change management process or if the change is significant enough that the system authorization is in question. Read the above introduction paragraphs for guidance to help make this determination.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf change management\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit them to the Change Control Board (CCB). If the change is occurring on a contractor system, the contractor’s internal CCB will be responsible for approving changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: If change is occurring on a contractor system, CMS has the ability to request that the contractor conduct an SIA.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf a significant change\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: The ISSO and the CRA will meet with the Business Owner and the Technical Review Board (TRB) to determine if a re-authorization is necessary. If re-authorization is necessary, the ATO package must receive proper approval before implementation.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit to the Change Control Board (CCB).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB or TRB.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSeparate Test Environments (CM-4(1))\u003c/h4\u003e\u003cp\u003eSeparate test environments are used at CMS to host an instance of the operational environment.\u0026nbsp; They should mirror one another in order to create an accurate response to changes as they are made for testing.\u0026nbsp; The environment will be kept separate, physically and/or logically, so that changes in one do not affect the other. \u0026nbsp;Changes will then be analyzed for flaws, weaknesses, incompatibility and intentional/unintentional harm that results from implementation. \u0026nbsp;CCB approved changes should be made in this test environment first, then the production/operational environment. Test environments need to mirror production to the maximum extent possible, but CMS realizes that deviations may have to be made so long as they are properly documented.\u003c/p\u003e\u003cp\u003eSeparating the testing environment from the production environment benefits CMS by allowing a chance to see the changes requested for a system enacted before the changes affect end users. Test environments give a chance to observe possible harm or disrupted functionality without applying the changes to production. It can reduce the risks of change overall, since the production data and operational environment are not harmed when the test environment is adversely affected.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS-specific process to ensure that separate environments have been incorporated into testing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System/Network Administrator creates and maintains a test environment that is similar to the operational environment but either physically or logically separate from it.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator uses the test environment to enact approved changes from the CCB then observe and document the effects of those changes before those approved changes are enacted on the operational system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eAccess Restrictions for Change (CM-5)\u003c/h3\u003e\u003cp\u003eThe changes to a system can be sensitive.\u0026nbsp; CMS calls for restrictions on the access to the system both physically and logically.\u0026nbsp; The access controls to limit change privileges can be implemented through discretionary access controls such as deciding who is on the CCB. Supplemental discretionary access or role-based access controls can be enacted on files using Access Control Lists (ACLs). There can also be physical access restrictions such as those requiring a key to get into datacenter facilities. All together, these access restrictions should be developed, documented, approved and enforced throughout the system life cycle.\u003c/p\u003e\u003cp\u003eRestricting the ability to enact change to a system maintains the overall stability to the system.\u0026nbsp; CMS limits production and operational privileges to make sure that there are controlled inputs to the change control process. Without limitations on change requests for a system, the process may become overwhelmed or inefficient based on unnecessary change requests.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS enacts this control, which is ensured by the Business Owner, by utilizing the following steps:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The Office of Information Technology (OIT) defines and approves access restrictions associated with change to the system during the initial phase of the CMS-SDLC including:\u003cul\u003e\u003cli\u003e\u003cstrong\u003eAdministrative controls –\u0026nbsp;\u003c/strong\u003eSuch as procedures, processes and standards to be used in configuration management\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eRole-based Access Controls\u003c/strong\u003e\u0026nbsp;– Such as those on files and storage related to change documentation\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDiscretionary Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those approving the appropriate personnel to approve changes to the system\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePhysical Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those restricting access to the computer equipment where the change requests and automation systems are kept\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Owner includes the defined access restrictions in the baseline configuration for the information system, to be included as a configuration item for the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO develops physical access controls if there is no description of them available for the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO documents physical and logical access controls in CFACTS under the Controls tab in the Authorization Package. Select Allocated Control CM-5 and list the reference or documented physical controls in the Shared Implementation Details field of the Implementation section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO reviews proposed changes to the physical and logical controls and the BO approves the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;Unapproved physical access changes must be filed as a Risk Acceptance Request documented in CFACTS or returned to the developer for modification of the plans and resubmission to the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Access Enforcement / Auditing (CM-5(1))\u003c/h4\u003e\u003cp\u003eA system under this control will have automation in its access enforcement and auditing. \u0026nbsp;The automation means that the system will check to see if the user or service is authorized to access resources as well as use some form of authentication. \u0026nbsp;During this enforcement of access controls, the system should also log actions for auditing those enforcement actions later.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe access enforcement for a system is important to maintain its security. \u0026nbsp;Automating the enforcement is the most efficient method of maintaining access controls.\u0026nbsp; These controls keep the unauthorized users out.\u0026nbsp; They contribute to the safety of the system through authentication and confidentiality. The confidentiality of the system makes it so that users only see parts of the system they are authorized to see.\u0026nbsp; Authentication ensures that CMS knows the user or service that is attempting to access a resource.\u0026nbsp; Finally, the creation of access control records will allow CMS personnel to evaluate working controls and detect misuse of the system through audits.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for automatically controlling access and auditing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System Developer and Maintainer creates the system with the functionality to audit against access restrictions specifically on changes to the hardware, software, and firmware components of the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer creates the functionality to record and document enforcement actions in relation to the access of data and/or functionality that is restricted in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor cloud-based services, the Cloud Service Provider (CSP) should be enforcing Steps 1 and 2 using automated mechanisms, to be in place before the service is in operation.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReview System Changes (CM-5(2))\u003c/h4\u003e\u003cp\u003eThe review of system changes should be carried out once per week by the CCB. \u0026nbsp;This process should also allow for ad-hoc reviews for checking configurations against the baseline when unauthorized changes have been indicated or there is a dramatic unforeseen shift in performance.\u003c/p\u003e\u003cp\u003eReview is a useful tool utilized by CMS to determine which changes may have been made without permission, or without following the configuration management procedure. \u0026nbsp;Discovering an unauthorized change could mean that there are more unauthorized changes present within the system. Reviewing the system changes is an easy way to check for procedural mistakes or intentionally unauthorized system changes. CMS maintains records of access to ensure that configuration change control is implemented and to support after-the-fact actions should CMS discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3, AU-6 and AU-7.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Review System Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(2)\u003c/td\u003e\u003ctd\u003eThe organization reviews information system changes [Assignment: organization-defined frequency] and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred.\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews information system changes:\u003c/p\u003e\u003cp\u003ea. At least once a week; and\u003c/p\u003e\u003cp\u003eb. When unauthorized changes or unexpected levels of system performance are indicated.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for reviewing system changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The CCB meets to review system changes each week to determine if unauthorized changes were made by checking current configuration baselines against the current configuration of the system to check for CIs that were modified without a corresponding approved CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;When the CCB learns of unauthorized changes taking place or unexpected levels of system performance, they should check the configuration baselines of their systems against the actual configuration of the system to determine whether changes have been made on the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The CCB reports any unauthorized changes to the ISSO within 24 hours of the finding.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSigned Components (CM-5(3))\u003c/h4\u003e\u003cp\u003eSigned components are parts of code that are used to create a digital signature and packaged together, code and signature. The digital signature is created from certificate assigned to the author of the code by a trusted certification authority.\u003c/p\u003e\u003cp\u003eCMS uses signed firmware and software components to know who the authors of the code are. The digital signature scheme and the Public Key Infrastructure together provide a way to institute non-repudiation for firmware and software updates.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Signed Components.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(3)\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of network and server software and firmware components without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for signing components:\u003c/p\u003e\u003cp\u003eCode that is taken from third party providers must have a signature from the author. At CMS, the system administrators apply the correct configuration that automatically stops firmware and software components from being installed without a digital signature.\u0026nbsp; These settings are in use as part of CMS’ configuration baselines for systems.\u0026nbsp; In Windows-based systems, this is performed through Active Directory group policy objects.\u0026nbsp; The group policy is applied to the target computer object and results in the computer being configured to restrict software and firmware installations without digital signatures.\u0026nbsp; The certificate for the software should be from a trusted certificate authority and the certificate should not be trusted if it is self-signed. A trusted certificate authority is designated as such by DHS, HHS, and CMS.\u003c/p\u003e\u003ch3\u003eConfiguration Settings (CM-6)\u003c/h3\u003e\u003cp\u003eHHS has outlined guidance for use when configuring information system components for operation.\u0026nbsp; Configuration standards vary depending upon the technical characteristics of the information system (e.g. operating systems, databases, firmware, etc.)\u0026nbsp; The\u0026nbsp;\u003cem\u003eMinimum Security Configurations Standard Guidance\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u003c/em\u003eissued by the Department of Health and Human Services shall be applied to all applicable systems. If an HHS-defined configuration standard baseline is not available than the\u0026nbsp;\u003cem\u003eU.S. Government Configuration Baseline\u003cstrong\u003e\u0026nbsp;(\u003c/strong\u003eUSGCB)\u003c/em\u003e\u0026nbsp;will be applied to the applicable systems.\u0026nbsp; For those systems not covered under USGCB, the\u0026nbsp;\u003cem\u003eNational Checklist Program\u003c/em\u003e\u0026nbsp;can be followed for configuration guidance.\u003c/p\u003e\u003cp\u003eThe purpose of creating common configuration settings is to streamline management and security implementations.\u0026nbsp; CMS configures systems with standardized settings and automates their implementation to save time and create a baseline of security that applies to all information systems, thereby, minimizing risk across the enterprise.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Configuration Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements];\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using the latest security configuration baselines established by the HHS, U.S. Government Configuration Baselines (USGCB), and the National Checklist Program (NCP) defined by NIST SP 800-70 Rev. 2 (refer to Implementation Standard 1 for specifics) that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for individual components within the information system based on explicit operational requirements (defined in the system security plan [SSPP]);\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for documenting configuration changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The CMS System Developer and Maintainer uses the HHS approved configurations and creates the configuration for the applicable information system using\u0026nbsp;\u003cem\u003eHHS\u0026nbsp;\u003c/em\u003edefined security configurations\u003cem\u003e\u0026nbsp;\u003c/em\u003eas the guidance in their creation. For USGCB (HHS Approved) Configuration, the appropriate operating system and/or applications is Microsoft Windows Supported Versions.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer using other OSes and applications develops configurations from guidelines in the following priority:\u003cul\u003e\u003cli\u003eHHS\u0026nbsp;\u003cem\u003eMinimum Security Configuration Standards Guidance\u003c/em\u003e\u003c/li\u003e\u003cli\u003eUSGCB\u003c/li\u003e\u003cli\u003eNIST NCP – Tier IV, then III, II, I in descending order\u003c/li\u003e\u003cli\u003eTechnical Reference Architecture Volume IV – Development and Application Services\u003c/li\u003e\u003cli\u003eDISA Security Technical Implementation Guide (STIG)\u003c/li\u003e\u003cli\u003eNSA STIG\u003c/li\u003e\u003cli\u003eLacking a Federal government-authored checklist, using an industry group or vendor checklist (Such as Center for Internet Security (CIS) benchmarks)\u003c/li\u003e\u003cli\u003eCollaboration within CMS to i) Establish baselines and communicate industry and vendor best practices; and ii) Ensure deployed configurations are supported for security updates\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer documents secure configuration settings for the information system using the procedures in Section 3.1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The network is scanned regularly for compliance with the established baseline configuration.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The information systems that are out of compliance are re-configured with baseline settings by the System Developer and Maintainer, in collaboration with the Vulnerability Management Team.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following steps are intended for use if the information system is cloud-based from a Cloud Service Provider (CSP).\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The OIT creates a baseline configuration with the CSP for their IT products inside the information system using USGCB as a guide to create the most restrictive mode consistent with operational requirements.\u003cul\u003e\u003cli\u003eIf USGCB does not apply, then they use the CIS benchmarks as guides to create the most restrictive mode consistent with operational requirements.\u003c/li\u003e\u003cli\u003eIf neither USGCB nor CIS applies, then they create their own benchmark of configuration settings.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS ISSO and the System Developer and Maintainer creates Security Content Automation Protocol (SCAP) compatible security configuration checklists if there are no validated ones available. The list should be formatted so that it can be read by a validated SCAP tool and enable that tool to determine if the approved configuration is in place.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDeviations\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe following steps are intended for creating deviations to established configuration settings.\u0026nbsp; If the settings established using a standard for baseline configurations have significant detrimental impacts on a system’s ability to perform CMS duties, then follow the steps below to file for a Risk Acceptance. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HHS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eStarting from the established baseline\u003cem\u003e,\u0026nbsp;\u003c/em\u003ethe System Developer and Maintainer documents all of the deviations from the baseline that either:\u003cul\u003e\u003cli\u003eAre not intended to be implemented since the standard(original baseline) setting would interfere with business operations\u003c/li\u003e\u003cli\u003eAre cost prohibitive\u003c/li\u003e\u003cli\u003eAre technically infeasible\u003c/li\u003e\u003cli\u003eHave an impact to operations\u003c/li\u003e\u003cli\u003eCause a loss of functionality\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the collected deviation(s) documented in the previous step by working with the BO to determine if configurations would restrict the types of information used, adversely affect the boundaries or adversely affect the information shared with other systems.\u0026nbsp; Furthermore, the ISSO reviews the list for completeness to ensure it has all the information needed for the Risk Acceptance form. The ISSO selects deviations to be approved by the CISO and CRA through the Risk Acceptance form or otherwise returned to the System Developer and Maintainer within 90 days of receipt with an explanation as to why the deviation was rejected.\u0026nbsp; Then the System Developer and Maintainer can re-submit in the next review period. These actions \u0026nbsp;must be thoroughly documented in CFACTS. The process for documentation is explained in detail below.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO (or System Maintainer) logs into CFACTS and fills out and signs the Risk Acceptance form including all deviations from the baseline configuration that should be considered for the information system in Section 2\u0026nbsp;\u003cem\u003eWeaknesses\u003c/em\u003e\u0026nbsp;with the following information at a minimum:\u003cul\u003e\u003cli\u003eAllocated Control = CM-6\u003c/li\u003e\u003cli\u003eFinding Description\u003c/li\u003e\u003cli\u003eWeakness Description\u003c/li\u003e\u003cli\u003eEffect on Business\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe ISSO then fills out Section 3\u0026nbsp;\u003cem\u003eProposed Risk Acceptance\u003c/em\u003e\u0026nbsp;with all of the information related to the risk(s) that will be accepted and how/if the risk will be mitigated to include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eOverview of the Risk Acceptance Request\u003c/li\u003e\u003cli\u003eBusiness Justification for the Risk Acceptance\u003c/li\u003e\u003cli\u003eJustification for Request\u003c/li\u003e\u003cli\u003eCompensating Controls (if any)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CISO, BO, and CIO approve deviations from the configuration baseline and authorizes, using the Risk Acceptance form Section 5, the new configuration to be used in the CMS environment.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Every year, the ISSO reviews the deviations and exceptions in place on the system. He or she takes the accepted deviations and considers them collected, documented deviations to start over from Step 11 for re-certifying the configuration of the system.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Central Management / Application / Verification (CM-6(1))\u003c/h4\u003e\u003cp\u003eAutomating the management of operating systems and applications gives CMS more control over the information systems in the CMS infrastructure and those processing CMS data.\u0026nbsp; Automation is implemented to create a point (or points) of central management for administrators to change, apply, verify, and enforce configuration baselines and mandatory configuration settings. CMS uses the HHS defined security configuration standards as the basis for the configurations of information systems, components and applications. \u0026nbsp;CMS Information systems are expected to allow access to automated methods of configuration management, change and verification. \u0026nbsp;\u003c/p\u003e\u003cp\u003eUsing these policies and procedures for the CMS environment assures an even application of approved configurations across the network. \u0026nbsp;These configurations are applying the settings that will secure each system and application according to CMS’s business and regulatory needs, specifically to enforce the baseline and the mandatory configuration settings. \u0026nbsp;CMS is able to implement the settings and verify that they are correct using this control. \u0026nbsp;Verification is used to show compliance.\u0026nbsp; The combination of configuration and verification makes this control necessary for large enterprise environments such as CMS.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for Automated Central Management\\Application\\Verification.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for \u0026nbsp;information system components as defined in the HHS Minimum Security Configuration Standards for Departmental Operating Systems and Applications.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for automation of central management:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer configures the information system with the tools necessary to automate monitoring and configuring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO contacts the CDM program (Appendix G) in order to find out how to connect their system to the central management mechanism.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The system is scanned regularly by the System Developer and Maintainer for compliance with approved configurations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The configuration changes are applied by the System Developer and Maintainer using configuration management tools to information systems after they have been approved by the OIT.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRespond to Unauthorized Changes (CM-6(2))\u003c/h4\u003e\u003cp\u003eIt is the duty of CMS authorized personnel to respond to unauthorized changes to the information system, components or its data.\u0026nbsp; The response should include notifying the business owner and ISSO. Additionally, the configuration should be restored to an approved version and further system processing can be halted as necessary.\u003c/p\u003e\u003cp\u003eCMS prevents or rolls back these changes to ensure that they go through the process of change management and receive the appropriate approvals and security checks before implementation. \u0026nbsp;Unauthorized changes that have not undergone security vetting may introduce new vulnerabilities that have not been mitigated by existing security controls. \u0026nbsp;The potential for increase of risk leads CMS to respond to unauthorized changes as soon as possible.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-6(2) Respond to Unauthorized Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(2)\u003c/td\u003e\u003ctd\u003eThe organization employs [Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings].\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization responds to unauthorized changes to information system and components (e.g., authorization, auditing, processing types, baselines) and data (e.g., system libraries, log files, executables) in the following ways:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u0026nbsp;\u003col\u003e\u003cli\u003eAlert responsible actors (person, organization);\u003c/li\u003e\u003cli\u003eRestore to approved configuration; and\u003c/li\u003e\u003cli\u003eHalt system processing as warranted.\u003c/li\u003e\u003c/ol\u003e\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for responding to unauthorized changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; Unauthorized changes are automatically stopped, when possible, by halting system processing using management tools and permission restrictions. \u0026nbsp;Attempts to make unauthorized changes generate alerts that are documented in centralized audit files.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eCDM informs the Incident Management Team in Information and Security Privacy Group (ISPG) when unauthorized changes occur if an unauthorized individual accesses the system that made the change. If an authorized individual made a valid change but did not follow the CM process, CDM contacts the individual and requests that they roll back the change and follow the appropriate CM procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;Incident Management Team coordinates the incident response and assists stakeholders in deciding whether to retrieve the information system or otherwise restore the settings to the approved baseline.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eLeast Functionality (CM-7)\u003c/h3\u003e\u003cp\u003eThe principle of least functionality must considered when configuring a system. \u0026nbsp;This involves first documenting the essential capabilities of the system.\u0026nbsp; After that, the system can be configured to accommodate these capabilities while turning off non-essential functionality.\u0026nbsp; At CMS, we pay special attention to high-risk system services and additionally turn those off unless they are absolutely needed.\u003c/p\u003e\u003cp\u003eCMS integrates security principles into its system development and design.\u0026nbsp; This control addresses the principle that systems are granted only those functions that are needed in order for them to accomplish their tasks.\u0026nbsp; This includes system services, which traverse network boundaries that are considered high-risk.\u0026nbsp; This aims to reduce the “attack surface” of a system.\u0026nbsp; Attack surface refers to the points that an attacker might target when compromising a system.\u0026nbsp; Reducing functionality that goes beyond a system’s tasks leads to minimizing risk resulting in fewer attack vectors and leaving fewer options for attack.\u0026nbsp; CMS reduces the risk as much as possible for each system to prevent attacks.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM least functionality.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003eb. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eProhibits or restricts the use of high-risk system services, ports, network protocols, and capabilities (e.g., Telnet, FTP, etc.) across network boundaries that are not explicitly required for system or application functionality.\u003c/li\u003e\u003cli\u003e[Added] A list of specifically needed system services, ports, and network protocols must be maintained and documented in the applicable security plan; all others will be disabled.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, which is ensured completed by the Business Owner, details the CMS procedure for least functionality:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eTo capture the functionality, the ISSO and the system developer and maintainer should refer to the Intake Form completed during the initial phase of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer logs into CFACTS to reference the network boundaries as shown in the\u0026nbsp;\u003cem\u003eCFACTS User Manual\u003c/em\u003e\u0026nbsp;in section 4.4\u0026nbsp;\u003cem\u003eBoundary Tab\u003c/em\u003e. They must also consider the system description, purpose, functionality, and architecture. This information can be used to turn off high-risk system services on the system or system components if they are not needed for system or application functionality.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer keeps a record of explicitly required system services, ports and network protocols, maintains it on an ongoing basis throughout the CMS-SDLC and communicates changes to the ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO enters the explicitly required system services, ports and network protocols into the\u0026nbsp;\u003cem\u003eSystem Security Plan\u003c/em\u003e\u0026nbsp;in CFACTS using the Boundaries Details section and in the implementation details for control CM-7.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003e\u0026nbsp;Periodic Review (CM-7(1))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eReview of ports, services, functions and protocols involves checking the system periodically.\u0026nbsp; The system checks will make comparisons of what is used and what is authorized for use.\u0026nbsp; CMS will then use that information to make a determination of which ports, services, functions and protocols should be disabled.\u0026nbsp; The system scans will identify the PPS, and then an analysis will have to be conducted to determine if they can be disabled.\u003c/p\u003e\u003cp\u003ePeriodic review within CMS helps to protect the systems in its infrastructure.\u0026nbsp; The protection comes from reducing the attack surface as stated in “\u003cem\u003eLeast Functionality CM-7\u003c/em\u003e” to reduce the risk to the network.\u0026nbsp; Reviewing on a periodic basis allows CMS to check continually for weaknesses and baseline anomalies.\u0026nbsp; The change management process can introduce weaknesses into the environment, so it is important to evaluate systems on an ongoing basis to determine the consequences of changes, including unintentional or unforeseen consequences that affect the risk to that system.\u0026nbsp; CMS authorizes scanning systems on this basis since change management is also an ongoing process in itself.\u0026nbsp; This helps to keep checks coordinated with changes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM periodic review.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or non-secure functions, ports, protocols, and services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eDisables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure].\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system no less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003ePerforms automated reviews of the information system no less often than once every seventy-two (72) hours to identify changes in functions, ports, protocols, and/or services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eDisables functions, ports, protocols, and services within the information system deemed unnecessary and/or non-secure.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process details the CMS procedure for periodic review:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe Continuous Diagnostics and Mitigation (CDM) team coordinates with the ISSO to monitor functions, ports, protocols, and services. The CDM sends periodic review information to the ISSO regarding their monitoring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The CDM team automatically scans the information system for changes in functions, ports, protocols and/or services at least every 72 hours and more frequently as necessary. \u0026nbsp;The scans should include systems, appliances, devices, services and applications (such as databases). This is performed on an ongoing basis until the system is retired. Changes are documented and sent to the system ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the system every 30 days using the reports taken from the CDM program.\u0026nbsp; The reports are compared against the System Architecture and Architecture Design section inside of the System Design Document\u003cem\u003e\u0026nbsp;\u003c/em\u003ein CFACTS for its listing of necessary functions, ports, protocols and services.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer along with the ISSO work together to disable unnecessary functions, ports, protocols and services with advice from the CRA. This is performed on an ongoing basis as they are discovered.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003ePrevent Program Execution (CM-7(2))\u003c/h3\u003e\u003cp\u003eThis control is implemented to ensure that CMS is using the software it has acquired responsibly and legally. \u0026nbsp;To execute this control there must be methods in place to prevent executing software that is not:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLicensed for use\u003c/li\u003e\u003cli\u003eConfigured for use at CMS\u003c/li\u003e\u003cli\u003eExecuted by an authorized user\u003c/li\u003e\u003c/ul\u003e\u003cp\u003ePreventing these executions should be done automatically, and the users must not be permitted to execute the programs themselves.\u003c/p\u003e\u003cp\u003eThese program preventions are a part of CMS’s security controls to ensure that security is built into the basic elements of systems through software. This is done to apply settings, which CMS knows are protecting the interests of the organization. \u0026nbsp;This is extended to licensing to make sure CMS is not exposed to risk by using software that is unlicensed. \u0026nbsp;Unlicensed software may violate the law or introduce new risks through its operation. \u0026nbsp;\u0026nbsp;Risk from operation is also included in this control by restricting software to those that are authorized to use it. Unauthorized users may not be assigned the responsibility of using certain types of software and CMS uses separation of duties to spread out job responsibilities among groups of people to reduce risk and insider threats.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-7(2) prevent program execution.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(2)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with policies regarding authorized software use which include, but are not limited to the following:\u003c/p\u003e\u003cp\u003e\u0026nbsp;a. Software must be legally licensed;\u003c/p\u003e\u003cp\u003e\u0026nbsp;b. Software must be provisioned in approved configurations; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;c. Users must be authorized for software program use.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThis control is system specific, but the following is a good example of how to implement and document the control:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe administrators of the system create the baseline configuration for software on the computer image.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eSystem administrators configure the domain settings to disallow software installations for all Users without administrative privileges.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eSystem administrators distribute computer images for all government issued computers using authorized and licensed software, and ensures that it is using approved configurations for the software included\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor software that is not included in the computer image for the baseline configuration, use the following steps to allow execution in accordance with policies.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe user checks the website for the Office of Information Technology to find if the software that they are requesting has been tested by CMS for conflicts and/or malicious behavior using the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u003c/em\u003e\u0026nbsp;here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eNote:\u0026nbsp;\u003c/strong\u003eSoftware that is supported under an enterprise license is a subset of the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u0026nbsp;\u003c/em\u003efrom step 4; please refer to the OIT website for Enterprise Software Licensing here for more information:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\u003c/a\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eIf the software is not in the list, then submit the software for testing following the steps in the procedure on the OIT website:\u0026nbsp; \u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u0026nbsp;, if the software is on the list then skip to the next step\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp;\u003c/strong\u003eThe user of the software must acquire the license for the software that they wish to use using the forms of proof provided by CMS Deskside support listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp;\u003c/strong\u003eThe user submits a new installation request following the procedure listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\u003c/a\u003e\u0026nbsp;in which the Deskside support personnel will validate the license, authorize the user to use the software and provision the software in approved configurations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eUsers operate under restricted privileges per CM-7 - least privilege, which will logistically prevent program execution through system policies. For those users who may get software installed surreptitiously or have administrative privileges, the following steps will apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp;\u003c/strong\u003eThe operations team within ISPG monitors the network for software network behavior and/or traffic from unauthorized software, when possible, to discover, and create alerts to notify the CMS Security Operations Center (SOC) if unauthorized software use is logged.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u003c/strong\u003e\u0026nbsp;The SOC reviews alerts daily to determine if unauthorized software is in use as part of their duty. When discovered, the SOC isolates the computer on the network if needed and uninstalls the unauthorized software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp;\u003c/strong\u003eThe SOC utilizes automated methods of managing software and notifies the user when unauthorized software is detected and automatically removes the software before the next 48 hours.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAuthorized Software / Allowlisting (CM-7(5))\u003c/h4\u003e\u003cp\u003eThe authorized software allowlisting control means that CMS would document the software that is allowed to run on CMS systems. The software name and its representation would be used to determine if a specific piece of software is on the list. Software on the list is allowed to execute and all other software is denied by default. As part of the implementation of this control, the list should be updated regularly and automatically from a trusted source.\u003c/p\u003e\u003cp\u003eUsing an allowlist instead of a denylist is an option to consider for environments that are more restrictive. The list itself is known, and the system denies all other software. CMS can use an allowlist to lessen the uncertainty in a system through this prevention of executing the unknown. Decreasing the uncertainty in this case can also lead to decreasing the risk that malware or software outside of that needed for the operation of a system is executed.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Authorized Software/Allowlisting.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(5)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies [Assignment: organization-defined software programs authorized to execute on the information system];\u003c/li\u003e\u003cli\u003eReviews and updates the list of authorized software programs [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies defined software programs (defined in the applicable security plan) authorized to execute on the information system;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eReviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and\u003c/li\u003e\u003cli\u003e[Added] Receives automated updates from a trusted source.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for Authorizing Software or Allowlisting:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u0026nbsp;If no Denylisting solution is in place, then an Allowlisting solution must be used.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO, working with the System/Network Administrator and the System Developer and Maintainer, identifies and defines the software programs that are authorized for use on the information system. Then lists them in the applicable part of CFACTS. The list can be held under the\u0026nbsp;\u003cem\u003e“Controls”\u003c/em\u003e\u0026nbsp;tab, in the\u0026nbsp;\u003cem\u003e“Allocated Controls”\u0026nbsp;\u003c/em\u003esection for control CM-7(5) as part of the “\u003cem\u003eShared Implementation Details”\u003c/em\u003e\u0026nbsp;subsection.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures an automated software Allowlisting tool for their applicable information systems so they only allow execution of software that has previously been approved for install/use listed in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO automatically updates and reviews the list of software from Step 1 no less often than every 72 hours from a trusted source such as, but not limited to:\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eCMS internal processes\u003c/li\u003e\u003cli\u003eOther agencies within the federal government\u003c/li\u003e\u003cli\u003eThe vendor of the Allowlisting product\u003c/li\u003e\u003cli\u003eIndustry specialists\u003c/li\u003e\u003cli\u003eCMS systems, appliances, devices, services and applications (to include databases)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the tool to provide results that are searchable by the CCIC.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for allowlisting information must be provided by the timeframe listed within the request.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor cloud-based\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003esystems that run software\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer configures the cloud-based system or service to only allow authorized software to execute following the steps above with or without an automated Allowlisting tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eInformation System Component Inventory (CM-8)\u003c/h3\u003e\u003cp\u003eInformation system components are parts of the CMS network used to process, store or transmit CMS information.\u0026nbsp; The components must each have an identifier that should be received from the property office in the form of an asset tag, which should be linked in an inventory system with the name of the asset, location, asset identification, owner, and description of use. More information can be added as needed, but those fields are the minimum.\u0026nbsp; Then the component inventory should be linked to the CDM tools so monitoring can be linked to specific components.\u003c/p\u003e\u003cp\u003eCMS takes an inventory of information system’s components as a fundamental part of protecting the infrastructure.\u0026nbsp; Inventories contain items that need to be checked for secure configurations, and they provide a logical baseline so that components found outside of the inventory can be scrutinized and unauthorized components removed, disabled or authorized.\u0026nbsp; Unauthorized components could be indicative of a security risk and should be investigated. This control also adds to the accountability of the system. Each component is a part of the system and the same security protections should apply to all components. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Information System Component Inventory.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eDevelops and documents an inventory of information system components that:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eReviews and updates the information system component inventory [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Develops and documents an inventory of information system components that:\u003c/p\u003e\u003cp\u003e1. Accurately reflects the current information system;\u003c/p\u003e\u003cp\u003e2. Include all components within the authorization boundary of the information system;\u003c/p\u003e\u003cp\u003e3. Are at the level of granularity deemed necessary for tracking and reporting; and\u003c/p\u003e\u003cp\u003e4. Includes:\u003c/p\u003e\u003cp\u003e- Each component’s unique identifier and/or serial number;\u003c/p\u003e\u003cp\u003e- Information system of which the component is a part;\u003c/p\u003e\u003cp\u003e- Type of information system component (e.g., server, desktop, application);\u003c/p\u003e\u003cp\u003e- Manufacturer/model information;\u003c/p\u003e\u003cp\u003e- Operating system type and version/service pack level;\u003c/p\u003e\u003cp\u003e- Presence of virtual machines;\u003c/p\u003e\u003cp\u003e- Application software version/license information;\u003c/p\u003e\u003cp\u003e- Physical location (e.g., building/room number);\u003c/p\u003e\u003cp\u003e- Logical location (e.g., IP address, position with the information system [IS] architecture);\u003c/p\u003e\u003cp\u003e- Media access control (MAC) address;\u003c/p\u003e\u003cp\u003e- Ownership;\u003c/p\u003e\u003cp\u003e- Operational status;\u003c/p\u003e\u003cp\u003e- Primary and secondary administrators; and\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003e- Primary user. Reviews and updates the information system component inventory no less frequently than every 180 days for High systems or 365 days for Moderate and Low systems, or per CM-8(1) and/or CM-8(2), as applicable.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops and documents an inventory of information system components. For this, they or a designee gathers the following information to be checked off and documented from each FISMA information technology item, including all components within the authorization boundary:\u003cul\u003e\u003cli\u003eUnique ID (or serial number) such as the asset tag number\u003c/li\u003e\u003cli\u003eInformation system that the component is a part of\u003c/li\u003e\u003cli\u003eAre controls inherited?\u003c/li\u003e\u003cli\u003eHigh Value Asset?\u003c/li\u003e\u003cli\u003eInformation system component type\u003c/li\u003e\u003cli\u003eManufacturer \u0026amp; model\u003c/li\u003e\u003cli\u003eOperating system type and version number\u003c/li\u003e\u003cli\u003eVirtual machine presence\u003c/li\u003e\u003cli\u003eApplication\\software license \u0026amp; version information (when applicable)\u003c/li\u003e\u003cli\u003ePhysical location\u003c/li\u003e\u003cli\u003eLogical location\u003c/li\u003e\u003cli\u003eMedia access control (MAC) address\u003c/li\u003e\u003cli\u003eResponsible party (Owner)\u003c/li\u003e\u003cli\u003eOperational status\u003c/li\u003e\u003cli\u003ePrimary \u0026amp; secondary administrator(s)\u003c/li\u003e\u003cli\u003ePrimary user(s)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO checks the details listed in the asset management tool and determine if the information gathered is enough to track and report on the component and then add fields as necessary. \u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews for accuracy and missing information and update the information system component inventory every 180 days for systems rated as “High” and every 365 days for systems rated as “Moderate” or “Low” from the system categorization in\u0026nbsp;\u003cem\u003eRMH Chapter 12\u003c/em\u003e\u0026nbsp;Section 3.1.2. T\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;System Developer and Maintainer configures the inventory system(s) to provide updates in a format compliant with CMS and federal standards to the CCIC at least once every 72 hours.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for component information must be provided by the timeframe within the request.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The Network/System Administrator provides timely, as defined by the CISO, responses to informational requests about component status and posture information.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eUpdates During Installations / Removals (CM-8(1))\u003c/h4\u003e\u003cp\u003eThe purpose of this control is to ensure that the component inventory is up-to-date in times of change. The CMS system inventory should be updated in cases of: information system component installs, removals, and updates.\u003c/p\u003e\u003cp\u003eUpdates during installations and removals to the inventory system is necessary to keep current information. The result of an upgrade, installation or removal can involve different components altogether. If the system inventory is not current, then the assumptions based on the inventory will not be accurate. It can have far-reaching impact beyond the current system and should involve updates as part of the procedure. Furthermore, updating the inventory supports accountability controls and breach response efforts.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for Updates During Installations/Removals component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe ISSO inputs new information system components into the inventory when they are installed to include the information input for systems in Section 3.7 Step 1 above.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO updates the inventory when an information system component is removed from the system. The component is taken out of inventory.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO updates the inventory when an information system is updated, changing information that is listed in the inventory such as that in Section 3.7 Step 1.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Maintenance (CM-8(2))\u003c/h4\u003e\u003cp\u003eThe CMS inventory system should be able to gather information and update records automatically.\u0026nbsp; The inventory system makes the database complete, accounting for inventory from purchase to disposition.\u0026nbsp; It is accurate, automated where possible and checked for accuracy. It is also meant to be readily available.\u0026nbsp; The system should be fault tolerant to ensure that the information on inventory is there when needed.\u003c/p\u003e\u003cp\u003eCMS uses automated inventory maintenance to show what information system components are available at any given time.\u0026nbsp; Knowing what inventory is supposed to be in the environment compared to what components are seen on the network, CMS can make determinations about components and their suitability. \u0026nbsp;If the component is in inventory and not detected through CDM for a time specified by CMS, then it may need to be flagged as a potentially compromised component. On the other hand, if a component is not in inventory and detected on the network, then it should be flagged as an unauthorized component until verified. These examples show some issues with risk by using inventory anomalies in CMS’ assessments of risk.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for automated information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to maintain the inventory of the information system including all components. The methods should include automation where possible and it should be available for review.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO compares the inventory system to physical inventory to evaluate accuracy and completeness, every 365 days for low/moderate systems and every 180 days for high systems.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Unauthorized Component Detection (CM-8(3))\u003c/h4\u003e\u003cp\u003eThe detection of components is utilized at CMS to determine whether a component is authorized or not.\u0026nbsp; By using an inventory of components that are authorized to be on the network, CMS can utilize a mechanism to compare a discovered component with the inventory.\u0026nbsp; The scans must be done on a weekly basis, more frequently as needed.\u0026nbsp; The mechanism for discovery should be automatic and detect hardware, software and firmware components within the information system.\u0026nbsp; When a component is found to be unauthorized then the automated mechanism should take measures to do the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrevent access to the component\u003c/li\u003e\u003cli\u003eEffectively disconnect the component from the network\u003c/li\u003e\u003cli\u003eIsolate the component\u003c/li\u003e\u003cli\u003eNotify responsible party as specified by the SSPP\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS intends to automate where possible to stop malicious attacks as they occur.\u0026nbsp; Stopping the communication with an unauthorized component as soon as possible is the goal of this control.\u0026nbsp; The automated responses helps CMS address threats in a timely manner since utilizing technology is consistently faster than a manual process would be able to address.\u0026nbsp; In order to review and take action against unauthorized components quickly, automation is the ideal solution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM automated unauthorized component detection.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(3)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components and/or provisioned configurations are detected:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;1. Disable access to the identified component;\u003c/p\u003e\u003cp\u003e\u0026nbsp;2. Disable the identified component’s network access;\u003c/p\u003e\u003cp\u003e\u0026nbsp;3. Isolate the identified component; and\u003c/p\u003e\u003cp\u003e4. Notify the responsible actor (i.e., person/organization defined in security plan).\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the process for automated unauthorized component detection:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO, working with the Business Owner, monitors the network to determine if unauthorized components are connected. The scan should be done at least weekly then as necessary for components that match the inventory in the automated inventory record.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO forwards unauthorized components to the Incident Management Team (IMT.)\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAccountability Information (CM-8(4))\u003c/h4\u003e\u003cp\u003eInformation system components are accounted for in the CMS inventory.\u0026nbsp; This listing has accountability information attached to it that may be referenced when a component is compromised. The information contains the role(s) or individual(s) responsible and/or accountable for the information system components.\u003c/p\u003e\u003cp\u003eThe information listed about CMS system components is designed as a reference for security personnel.\u0026nbsp; The accountability information is used when, for example, the component needs to be replaced, is the source of a breach or a compromise, or needs to be relocated.\u0026nbsp; A control for accountability information provides CMS with the contact information needed during incident response and times of change. The risk associated with those situations is assigned appropriately to the responsible person who can delegate the associated work.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for accountability information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(4)\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components.\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by the System Developer/Maintainer or the Business Owner, \u0026nbsp;\u0026nbsp;the individuals responsible/accountable for administering those components.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, ensured is completed by the Business Owner, details the CMS procedure for keeping accountability information:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to identify the individual(s), to include position and role, responsible and accountable for administering information system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO documents and maintains the information of individual(s) responsible for administering the information system components.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eNo Duplicate Accounting of Components (CM-8(5))\u003c/h4\u003e\u003cp\u003eThis control is used in CMS to ensure components are not duplicated in inventories.\u0026nbsp; The inventory that lists all components shall not have more than one of the same instance of a component.\u003c/p\u003e\u003cp\u003eCMS avoids duplicate accounting in inventory systems because it creates a source of confusion for responsibility and remediation.\u0026nbsp; Systems can be large and complex, involving many different components that interact with each other as well as other interconnected systems.\u0026nbsp; Assigning a component to a single system inventory streamlines accounting and reduces the time and effort to discern applicable parties responsible for that component. It also leads to straightforward remediation of vulnerabilities when discovered since the component is linked to a single system.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for verifying that the accounting for information system components are not duplicated:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO documents the system components inside of CFACTS using the Authorization Package for the system inside of the\u0026nbsp;\u003cem\u003e“Boundary”\u003c/em\u003e\u0026nbsp;tab under the\u003cem\u003e\u0026nbsp;“Hardware”\u003c/em\u003e\u0026nbsp;and\u0026nbsp;\u003cem\u003e“Software”\u0026nbsp;\u003c/em\u003esections.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO sorts hardware and then software by unique attributes to check if all components have different unique attributes from one another whenever entering in new system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;If there is no duplication of component attributes then no further action is needed. If the ISSO identifies a duplication of unique attributes for a component then proceed to the next step.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO removes the duplicate component attribute from the system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Management Plan (CM-9)\u003c/h3\u003e\u003cp\u003eThe CMS-SDLC incorporates a configuration management plan into the planning process. The plan is designed to document the process and procedures for configuration management.\u0026nbsp; The plan shall cover certain areas in order to fulfill this security control.\u0026nbsp; Listed in the document are roles of stakeholders, their responsibilities, processes and procedures.\u0026nbsp; The document shall also outline current configuration items.\u0026nbsp; Specifically, one of the processes covered shall be how to identify a configuration item.\u0026nbsp; The plan shall be protected, after it is finalized, from modification or unauthorized disclosure as are the configuration baselines.\u003c/p\u003e\u003cp\u003eConfiguration management plans define people, processes and procedures.\u0026nbsp; The plans establish the technical and administrative direction and surveillance for the management of configuration items.\u0026nbsp; CMS uses this plan to separate responsibility and add traceability to protect the integrity of systems.\u0026nbsp; Changes are documented and explicitly approved or rejected, so there is accountability regarding the approver, and changes that were made on the system without approval.\u0026nbsp; Implementing the plan properly helps CMS pinpoint issues related to changes, leading to quicker resolutions and rollbacks to repair them.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for developing, documenting and implementing a configuration management plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The CMS Program/Project Manager completes a configuration management plan.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Program/Project Manager documents roles and responsibilities for the plan in a\u003cem\u003e\u0026nbsp;\u003c/em\u003eRoles \u0026amp; Responsibilities section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager defines the processes and procedures involved with configuration management. Configuration Management Administration and Methods and Tools sections should be included.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager lists CIs for the information system in a System Design Document.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager protects the document from unauthorized disclosure or modification by using access control methods for storage locations to restrict access to authorized personnel only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSoftware Usage Restrictions (CM-10)\u003c/h3\u003e\u003cp\u003eCMS will establish and enforce procedures for identifying and removing inappropriate software.\u0026nbsp; Contractors and Government employees are expected to use software and associated documentation according to applicable law and contractual agreements.\u0026nbsp; CMS is responsible for the prevention, monitoring, and removal of unauthorized software.\u0026nbsp; Installed software and documentation will be monitored as needed to determine if its use is allowed by the license or contract. Additionally, peer-to-peer file sharing technology is not expected to be used except as approved by the CIO, but such traffic will be inspected to determine if sensitive or protected content was being shared.\u003c/p\u003e\u003cp\u003eSoftware usage restriction assists in safeguarding against the sharing of copyrighted material and/or the use of software in a manner that would violate CMS agreements. \u0026nbsp;CMS tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution.\u0026nbsp; CMS also controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.\u0026nbsp; This reduces CMS liability by preventing potential copyright violations. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-10 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;System/Network Administrator ensures that the software has been previously tested according to the CMS testing procedure found here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e. A list of previously tested software is available here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator reviews the installation request for the software proof of purchase, unless it was custom developed in-house, which includes:\u003cul\u003e\u003cli\u003eApproved purchase record\u003c/li\u003e\u003cli\u003eCertified receipt or invoice\u003c/li\u003e\u003cli\u003eValidated HHS Form 393 (Purchase/Service/Stock Requisition Form)\u003c/li\u003e\u003cli\u003eCMS credit card invoice\u003c/li\u003e\u003cli\u003eVendor proof of license purchase certificate\u003c/li\u003e\u003cli\u003eVendor end-user authorization form for volume licensing\u003c/li\u003e\u003cli\u003eVendor-provided notice of software purchase\u003c/li\u003e\u003cli\u003eEnd-user license agreement\u003c/li\u003e\u003cli\u003eEnterprise Software Licensing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator installs the software and documents that the instance of software and license are used for the information system so that the total number of licenses, the proof of license and installations are denoted.\u0026nbsp; The documentation is used by the System/Network Administrator to prevent copying per the\u0026nbsp;\u003cem\u003eCMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resources\u003c/em\u003e\u0026nbsp;section 4.1 and/or violating license agreements.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS ISSO and respective component support staff from ISPG CDM performs routine scans of CMS networks to compare the current approved users and their installed software to the list of approved CMS “Core” and “Above Core” software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS ISSO communicates, via e-mail, a list of approved users to the component support staff Asset Management Team that do not comply with CMS Software Policy.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Asset Management Team notifies, via e-mail, those users and their managers that were identified as having unauthorized software on their information systems, and provide a date to remove the software or their respective access will be revoked.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Users that are notified of unauthorized software on their information system, must remove the inappropriate software within twenty-four (24) hours after completion of a Service Request (SR). In the event an exception is needed based on job role and function, an SR is submitted to the ISSO with appropriate justification for further 508 compliance testing and approval.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eUser-Installed Software (CM-11)\u003c/h3\u003e\u003cp\u003eAllowing CMS personnel to install software on agency information systems and system resources exposes the organization to unnecessary risk. \u0026nbsp;GFEs will be configured to prevent installation of software when unprivileged users attempt it.\u0026nbsp; Privileged users will be allowed to install software by following established procedures.\u0026nbsp; The proper methods should be outlined within the SSPP of the information system under the control allocation for CM-11 – Shared Implementation Details.\u0026nbsp; Users of the information system will have to follow the policy as stated in the SSPP.\u0026nbsp; CMS will take action at least once per month after implementation to monitor adherence to the policy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS wants to mitigate potential problems that may arise when users install programs.\u0026nbsp; Some examples of problems that can be introduced are using two different versions of the same software that can cause system conflicts, introducing malware, and installing unlicensed software that could be discovered during audit or unauthorized programs that could be used to gather information from CMS’s network.\u0026nbsp; This control is designed to protect network resources from unauthorized actions from software by restricting the number of people who have the ability to install it.\u0026nbsp; This will minimize the risk of losing functionality in programs, damaging CMS infrastructure from malicious programs, harming CMS’s reputation through sensitive data loss, or exposing CMS to liability from unlicensed software. \u0026nbsp;Monitoring the system for these installations allows us to adhere to information security continuous monitoring (ISCM) requirements as per the CMS IS2P2 section 4.1.2 Risk Management Framework.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for user-installed software.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-11\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through [Assignment: organization-defined methods]; and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at [Assignment: organization-defined frequency].\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Prohibits the installation of software by users on all GFE;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through organization-defined methods (defined in the SSPP); and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at least monthly.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-11 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep\u0026nbsp;1:\u0026nbsp;\u003c/strong\u003eCMS image management team installs privilege management software on all GFE configuration baselines to prevent the installation of software by users in accordance with software installation rules.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;For GFEs, the Deskside Support Team configures them to restrict the permissions of users and prevent user-initiated installations. For all other CMS equipment, the business owner and the ISSO is responsible for restricting the permissions of users and preventing user-initiated installations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor GFEs, the Deskside Support Team configures it with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevents all other user installations of software. For all other CMS equipment, the business owner and the ISSO is responsible for configuring the equipment with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the system with methods and data gathering mechanisms that collect information at least once per month about the installed software that confirms its authorized use. It must be compliant with CDM.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures the methods and data gathering mechanisms from Step 4 to comply with CDM.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures systems with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1cb:T1c68f,"])</script><script>self.__next_f.push([1,"\u003ch2\u003eIntroduction\u003c/h2\u003e\u003cp\u003eThis Handbook outlines procedures to help CMS staff and contractors implement the Configuration Management family of controls taken from the National Institute of Standards and Technology (NIST) Special Publication 800-53 and tailored to the CMS environment in the CMS Acceptable Risk Safeguards (ARS). For more guidance on how to implement CMS policies and standards across many cybersecurity topics, see the CMS Security and Privacy Handbooks.\u0026nbsp;\u003c/p\u003e\u003cp\u003eConfiguration management has been applied to a broad range of information systems. Some basic terms associated with the configuration management discipline are briefly explained below.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eBaseline Configuration\u003c/em\u003e\u0026nbsp;is a set of specifications for a system that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.\u003c/p\u003e\u003cp\u003eA\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;(CM Plan) is a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. The basic parts of a CM Plan include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cem\u003eConfiguration Control Board\u003c/em\u003e\u0026nbsp;(CCB) – establishment of and charter for a group of qualified people with responsibility for the process of controlling and approving changes throughout the development and operation lifecycle of products and systems; may also be referred to as a change control board;\u003c/li\u003e\u003cli\u003eConfiguration Item\u0026nbsp;\u003cem\u003eIdentification\u003c/em\u003e\u0026nbsp;– methodology for selecting and naming configuration items that need to be placed under CM;\u003c/li\u003e\u003cli\u003eConfiguration\u0026nbsp;\u003cem\u003eChange Control\u003c/em\u003e\u0026nbsp;– process for managing updates to the baseline configurations for the configuration items; and\u003c/li\u003e\u003cli\u003eConfiguration\u003cem\u003e\u0026nbsp;Monitoring\u003c/em\u003e\u0026nbsp;– process for assessing or testing the level of compliance with the established baseline configuration and mechanisms for reporting on the configuration status of items places under CM.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThis guideline is associated with the application of security-focused configuration management practices as they apply to information systems. The configuration of an information system is a representation of the system’s components, how each component is configured, and how the components are connected or arranged to implement the information system. The possible conditions in which an information system or system component can be arranged affect the security posture of the information system. The activities involved in managing the configuration of an information system include development of a configuration management plan, establishment of a configuration control board, development of a methodology for configuration item identification, establishment of the baseline configuration, development of a configuration change control process, and development of a process for configuration monitoring and reporting.\u003c/p\u003e\u003cp\u003eConfiguration management of information systems involves a set of activities that can be organized into four major phases – Planning, Identifying and Implementing Configurations, Monitoring, and Controlling Configuration Changes. It is through these phases that CM not only supports security for an information system and its components, but also supports the management of organizational risk.\u003c/p\u003e\u003ch2\u003eConfiguration Management controls\u003c/h2\u003e\u003ch3\u003eBaseline Configuration (CM-2)\u003c/h3\u003e\u003cp\u003eThis control requires CMS to develop, document, and maintain under configuration control a current baseline configuration for each information system. Baseline configurations are documented, formally reviewed and agreed-upon sets of specifications for information systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and/or changes to information systems. Baseline configurations include information about information system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and patch information on operating systems and applications; and configuration settings/parameters), network topology, and the logical placement of those components within the system architecture.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for initializing and maintaining an information system configuration baseline.\u003c/p\u003e\u003cp\u003eTo develop and document initial configurations:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system owner with the support of the Change Control Board (CCB) identifies the configuration settings for their information system, device, appliance, or application using configuration settings standards in section 3.5 as part of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer documents the configuration settings chosen during Step 1 in the CMS Intake Form as part of the CMS-SDLC.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn order to maintain the configuration baseline, the Business Owner ensures the following is completed:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization determines that the system requires a change. (See SA-3 and CM-9).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops a high-level plan for how to accomplish the change (see SA-3, and SA-10).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) reviews the Privacy Impact Assessment (PIA) and conducts a Security Impact Analysis (SIA, see CM-4 Security Impact Analysis) to identify the privacy and security impacts of their plan (see CM-4 and SA-3).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops any applicable design requirements to mitigate the identified security impacts (see SA-3, SA-8, and SA-17).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops testing requirements to ensure that the security impacts are verified as successfully mitigated (see CA-2 and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) builds out the system changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) test, independently as required by CA-2(1) and CA-7(1)), the system changes using the security tests developed in step 5 (see AC-5.Std.5, CA-2, CM-3(2), CM-4(1), and SA-11).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp; \u003c/strong\u003eThe ISSO’s organization (or their designated System Maintainer) develops and implements any Plans of Action and Milestones (POA\u0026amp;Ms) necessary to correct identified failures from testing (see CA-5).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11:\u0026nbsp; \u003c/strong\u003eThe ISSO applies either for a new Authorization To Operate (ATO), or for an ATO update (see CA-6).\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReviews and Updates (CM-2(1))\u003c/h4\u003e\u003cp\u003eThis enhancement requires CMS to review and update the baseline configuration of its information systems at a regularly defined frequency, when special circumstances arise, or when and information system component is installed or upgraded.\u0026nbsp; By defining and maintaining a baseline configuration for its information systems, CMS is supporting the cybersecurity concepts of least privilege and least functionality. In addition, the establishment of configuration baselines helps the organization recognize abnormal behavior as a sign of attack.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for review and update of the baseline configuration for an information system.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003e[Assignment: organization-defined frequency];\u003c/li\u003e\u003cli\u003eWhen required due to [Assignment organization-defined circumstances];and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews and updates the baseline configuration of the information system:\u003c/p\u003e\u003col\u003e\u003cli\u003eAt least every 180 days for High systems or\u0026nbsp; 365 days for Moderate systems;\u003c/li\u003e\u003cli\u003eWhen configuration settings change due to critical security patches (as defined by the federal government, CMS, or vendor), upgrades and emergency changes (e.g., unscheduled changes, system crashes, replacement of critical hardware components), major system changes/upgrades;\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eTo implement the CMS controls for reviewing and updating configuration baseline, the Information System Security Officer (ISSO) must first assign a security category in accordance with FIPS 199.\u003c/p\u003e\u003cp\u003eThis procedure is outlined in RMH Chapter 12: Security \u0026amp; Privacy Planning, under control PL-2.\u0026nbsp; The category will assist the CCB with identifying adequate security controls and ensuring they are integrated into the configuration baseline of the information system.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe CCB will review information system baseline configurations every 365 days for systems categorized “High” and every 1,095 days for systems categorized as “Moderate”. Other triggers outside of scheduled times for configuration baseline review are:\u003c/p\u003e\u003cul\u003e\u003cli\u003eCritical security patches to the system/component\u003c/li\u003e\u003cli\u003eUpgrades to the system\u003c/li\u003e\u003cli\u003eEmergency changes\u003c/li\u003e\u003cli\u003eMajor system changes or upgrades\u003c/li\u003e\u003cli\u003eInformation system component installations\u003c/li\u003e\u003cli\u003eUpdates to the governing standards\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eIn addition, system developer and maintainers will have to update the documentation regarding the baseline configuration after an approval of changes. Updates must follow the same process stated above in CM-2.\u003c/p\u003e\u003ch4\u003eAutomation Support for Accuracy / Currency (CM-2(2))\u003c/h4\u003e\u003cp\u003eCMS provides automation support whenever possible to information systems’ configuration baselines. \u0026nbsp;Automation support examples include hardware asset management systems, software asset management systems, and centralized configuration management software. \u0026nbsp;CMS uses automation of information gathering to support the continuous monitoring program and inventory systems. \u0026nbsp;Automation support captures the types of hardware and software on the network and the operating system or firmware on each device.\u003c/p\u003e\u003cp\u003eThe goal is to keep track of what the configuration is on each system and to have the ability to go to an information system and collect configuration information automatically. \u0026nbsp;The automation keeps the data on systems configuration up-to-date, accurate, and available when it is needed.\u0026nbsp; With a current list of configurations, CMS can feed it into other processes that look for deviations from the baseline and configurations that are not up to organizational standards. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HSS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for incorporating automation to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The system developer and maintainer configures the system architecture to allow automated hardware and software mechanisms provided by Continuous Diagnostics and Mitigation (CDM) to scan the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer configures the access controls, as needed, to allow automation support to have access to the information that it needs.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Cybersecurity Integration Center (CCIC) runs automated mechanisms to gather hardware and software configurations as part of the Continuous Monitoring Program whose point of contact information is in Appendix G.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRetention of Previous Configurations (CM-2(3))\u003c/h4\u003e\u003cp\u003eRetaining documentation of configuration information is the first step to the restoration in times of need. CMS will maintain at least one backup of the configuration for systems, system components, and information system services. The configuration information needed is used to restore a device, service, or software to a previous state. Related to CM-2(2), section 3.1.2 of this document, the automated gathering of configuration information can be used to collect the data. This backup should also be maintained, given that the configuration will change over time. The approval of changes in the configuration from the CCB should also be added to the configuration documentation to retain as a new version.\u003c/p\u003e\u003cp\u003eThe retention of configuration information is in support of CMS as one of its goals to maintain availability of systems. A previous configuration could be used to replace current settings and processes to a former state. This former state should be an approved configuration that may increase risk, but maintain availability. For example, if there were a system that did not apply a critical security patch correctly causing a system failure, then restoring the previous configuration would restore the system to a functioning state (available) without the security protection of the patch (increased risk).\u003c/p\u003e\u003cp\u003eThe configuration information can also be used when settings change with unintended consequences during system upgrades or replacements. The previous configuration can be restored using what is called a rollback procedure, which would implement the settings for a former state that is known to function properly.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameter (ODP) for CM Retention of Previous Configurations.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(3)\u003c/td\u003e\u003ctd\u003eThe organization retains [Assignment: organization-defined previous versions of baseline configurations of the information system] to support rollback.\u003c/td\u003e\u003ctd\u003eThe organization retains older versions of baseline configurations of the information system as deemed necessary, by the ISSO, to support rollback.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for retaining configuration information of an information system:\u003c/p\u003e\u003cp\u003eThe system developer and maintainer will determine the needs of the system to restore it back to a previous state. The information gathered can be a combination of settings, version numbers of software/firmware/hardware, access controls, connection information, or schematics. The importance of gathering the correct information is to ensure that the system will work using the previous configuration as stored. This previous configuration information must also be available in case of emergencies and must therefore be stored apart from the system itself to remain available if the system is offline. Additionally, configuration changes that are approved by the CCB must be added to the configuration baseline to ensure the up-to-date configurations are used for restoration. A minimum of one previous configuration is required for this control.\u003c/p\u003e\u003cp\u003eBecause the retention process will be slightly different for every information system, the system developer and maintainer must document their process in their Configuration Management Plan (CMP).\u003c/p\u003e\u003ch4\u003eConfigure Systems, Components, or Devices for High-Risk Areas (CM-2(7))\u003c/h4\u003e\u003cp\u003eThis control guides CMS to create configurations and/or procedures for systems (laptops, iPhones, etc.) that are traveling to high-risk areas. \u0026nbsp;This control is for official travel, because unofficial/personal travel should not involve the transportation of Government Furnished Equipment (GFEs).\u0026nbsp; CMS employees traveling to high-risk areas should not travel with their permanently issued GFE but instead use an assigned loaner laptop from the designated laptop team. \u0026nbsp;The designation of high-risk countries can be found on the State Department’s website\u0026nbsp;\u003cem\u003eTravel to High-Risk Areas\u003c/em\u003e\u0026nbsp; Upon returning, CMS employees and contractors return their mobile devices to the SOC for a check of signs of physical tampering.\u0026nbsp; HHS guidance can be found here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\"\u003ehttps://intranet.hhs.gov/it/cybersecurity/policies/memo-gfe.html\u003c/a\u003e. Further guidance can be obtained from the HHS Office of Security and Strategic Information and from the Broadcast on Foreign Travel:\u0026nbsp;\u003cem\u003eUpdated Foreign Travel Security Awareness Guidance\u003c/em\u003e\u0026nbsp;(6/12/2017).\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM-2(7) Configure Systems, Components, or Devices for High-Risk Areas.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-2(7)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues [Assignment: organization-defined information systems, system components, or devices] with [Assignment: organization-defined configurations] to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003cli\u003eApplies [Assignment: organization-defined security safeguards] to the devices when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIssues dedicated information systems, system components, or devices with stringent configurations (e.g., FIPS 140-2 for encryption) to individuals traveling to locations that the organization deems to be of significant risk; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eApplies security safeguards to the devices (i.e., detailed inspection of the device for physical tampering, purging or reimaging the hard disk drive/removable media) when the individuals return.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for handling systems components or devices for travel to a high-risk area.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; CMS Users traveling to foreign countries for official business notify the Office of Security and Strategic Information (OSSI) at least 30 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u0026nbsp;and follow the HHS\u0026nbsp;\u003cem\u003eForeign Travel Checklist\u0026nbsp;\u003c/em\u003ethat is available here:\u0026nbsp;\u003ca href=\"https://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\"\u003ehttps://intranet.hhs.gov/security/ossi-counterintelligence/foreign-travel-list.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;CMS Users traveling to foreign countries for official business notify the CMS International Team least 10 days in advance of travel to arrange for a security briefing by email at\u0026nbsp;\u003ca href=\"mailto:international@cms.hhs.gov\"\u003einternational@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;CMS Users notifies the Service Desk at least 10 days in advance of their travel in order to arrange for their travel laptop to conduct business on while abroad using the email\u0026nbsp;\u003ca href=\"mailto:Cms_it_service_desk@cms.hhs.gov\"\u003ecms_it_service_desk@cms.hhs.gov\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS International Team checks the country against the Department of State travel advisories to determine the risk to the traveling CMS User here:\u0026nbsp;\u003ca href=\"https://travel.state.gov/content/passports/en/alertswarnings.html\"\u003ehttps://travel.state.gov/content/passports/en/alertswarnings.html\u003c/a\u003e. \u0026nbsp;Then uses that information to decide the security awareness briefing that the User will receive.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS International Team notifies the Infrastructure \u0026amp; User Services Group about the connection of the GFE that the user will have while overseas.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Deskside Support protects the travel computer using the FIPS 140-2 compliant encryption using the current full-disk encryption solution. (e.g. Checkpoint Endpoint Encryption)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS International Team debriefs the User when they return.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;CMS User returns the travel computer to CMS Deskside Support within two days of returning from travel before connecting it to the CMS network or system and does not attempt to transfer data when returning.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Change Control (CM-3)\u003c/h3\u003e\u003cp\u003eConfiguration change control implements the change control process for the information system, system component, or information system service. Management will determine which changes to the system need to be part of the change control process. There will also be employees assigned to the CCB to review and approve changes to the system, component or service. The CCB will take security considerations as part of the decision making process. Changes that are approved will need to be documented as a part of the process.\u0026nbsp; The documentation should include the decisions on the changes as well as the changes that are to be made.\u0026nbsp; The CCB should periodically audit and review the activities related to the changes that have been made to the applicable system, component or service. It should also meet often enough to accommodate the changes that are proposed.\u003c/p\u003e\u003cp\u003eThe reason that change control is enacted is to reduce the impact of changes to the CIA of the data processed by the system.\u0026nbsp; The CCB can approve or disapprove of changes for a particular system so that there is no single person making changes to the system.\u0026nbsp; CMS wants to prevent or minimize risks that can occur as a result of unauthorized or uncoordinated changes. \u0026nbsp;This helps to separate the duties involved and adds an extra layer of security. \u0026nbsp;The documentation of changes can help to troubleshoot issues when systems malfunction and to audit the system for compliance to CMS rules and regulations. CMS uses configuration change control to maintain availability through changes that have to be tested and system integrity through audits and approvals for system changes.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Configuration Change Control.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for [Assignment: organization-defined time period];\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through [Assignment: organization-defined configuration change control element (e.g., committee, board)] that convenes [Selection (one or more): [Assignment: organization-defined frequency]; [Assignment: organization-defined configuration change conditions]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eRetains records of configuration-controlled changes to the information system for a minimum of three (3) years after the change;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"7\"\u003e\u003cli\u003eCoordinates and provides oversight for configuration change control activities through change request forms which must be approved by an organizational and/or CMS change control board that convenes frequently enough to accommodate proposed change requests, and other appropriate organization officials including, but not limited to, the System Developer/Maintainer and information system support staff.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following, which is ensured by the Business Owner, details the CMS specific process for controlling changes to a CMS information system’s configuration.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The Information System Security Officer (ISSO), System Owner (or designee) and the project manager writes a configuration management plan that includes the parts of the system (called configuration items or CIs) which are to be controlled under configuration management procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The project/program manager further describes the process of how decisions are made in the CCB for guidance after members are assigned. This is documented in a Change Management Plan in alignment with the CMS-SDLC\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, System Owner (or designee) and the project manager create a CCB by assigning members and write a charter and operating procedures for the CCB. The CCB must have at least the system developer, Privacy Officer, ISSO (contractor/federal), maintainer, and a member of the information system support staff assigned.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CCB coordinates and oversees configuration control activities. They review change requests (CRs) and should meet often enough to appropriately handle the reviews in a timely manner throughout the life cycle from requirements analysis to disposition. \u0026nbsp;The reviews should produce an approval or disapproval that is recorded via the method in Section 4 of the relevant Change Management Plan.\u0026nbsp; The decision should take into account a \u003ca href=\"/learn/security-impact-analysis-sia\"\u003eSecurity Impact Analysis (SIA)\u003c/a\u003e, as outlined in CM-4, from the ISSO.\u0026nbsp; They should monitor the status of proposed changes ensuring that only approved changes are applied.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer implements approved changes once passed by the CCB. The CCB must maintain a record of configuration-controlled changes to the information system for a minimum of three (3) years after the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The project/program manager updates the configuration information inside of the System Design Document to reflect the changes approved in the CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB audits implemented changes before the changes are added to the configuration baseline by verifying that the changes fulfill the requirements or requesting the update of documented requirements in response to the CR so it accurately reflect the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CCB tracks the progress of the implementation of the change by confirming the updates to the configuration documentation in the System Design Document as CRs are approved.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u003c/strong\u003e\u0026nbsp;The CCB checks the configuration of the system periodically for discrepancies against the documented configuration baseline. The configuration audit will determine either whether the configuration of the system is compliant with the approved baseline, at which point they will notify the ISSO to initiate a POA\u0026amp;M.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Document / Notification / Prohibition of Changes (CM-3(1))\u003c/h4\u003e\u003cp\u003eAutomation in the change management process can help to document changes and ensure the proper workflow. CMS uses automated means to document system changes for submission to the CCB. The automated process should cover several things. CMS wants the automated system to notify the authorizing personnel, who were designated to approve changes, whenever changes are proposed. The change request can be automated giving highlight rules to change requests for different statuses such as: awaiting approval, not approved, or overdue (defined in the SSPP). When the approvals come through, this system should alert the stakeholders that the change is approved.\u003c/p\u003e\u003cp\u003eChanging systems are a frequent occurrence. Automating the documentation, along with notification or prohibition of changes, saves CMS resources. Automating these processes can also increase the traceability of changes for many systems at once. This helps to keep accounts of all records linked to each applicable system and to review who approved specific changes and reasons for change.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters (ODPs) for CM Automated Document/Notification/Prohibition of Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-3(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify [Assignment: organized-defined approval authorities] of proposed changes to the information system and request change approval;\u003c/li\u003e\u003cli\u003eHighlight proposed changes to the information system that have not been approved or disapproved by [Assignment: organization-defined time period];\u003c/li\u003e\u003cli\u003eNotify [Assignment: organization-defined personnel] when approved changes to the information system are completed.\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to:\u003c/p\u003e\u003cul\u003e\u003cli\u003eNotify designated approval authorities (defined in the SSPP) of proposed changes to the information system;\u003c/li\u003e\u003cli\u003eHighlight proposed changes that have been waiting an approval decision, or have not been approved, for longer than change management procedure (defined in the SSPP) requires;\u003c/li\u003e\u003cli\u003eNotify stakeholders when approved changes are completed. A list of potential stakeholders\u0026nbsp; include, but is not limited to the following:\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair;\u003c/li\u003e\u003cli\u003eChief Risk Officer (CRO);\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA);\u003c/li\u003e\u003cli\u003eISSO;\u003c/li\u003e\u003cli\u003eProgram Manager;\u003c/li\u003e\u003cli\u003eData Guardian;\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO); and\u003c/li\u003e\u003cli\u003eInformation System Administrator.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which are ensured by the Business Owner, outline the process for automating the processes of documenting, notifying, and prohibiting actions during the change control process.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The Information System Security Officer (ISSO), Information System Owner (ISO) and Project Manager develops configuration processes and procedures that include automated mechanisms, documenting them in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e\u0026nbsp;during the proper CMS-SDLC phase. The automated mechanism(s) should be able to prohibit changes to the information system until a change is approved, store all approved Change Requests (CRs), and then notify the stakeholders when approved changes are complete.\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStakeholders to be notified upon implementation of changes (at a minimum):\u003c/strong\u003e\u003cul\u003e\u003cli\u003eChange Control Board (CCB) Chair\u003c/li\u003e\u003cli\u003eCRO Chief Risk Officer (CRO)\u003c/li\u003e\u003cli\u003eCyber Risk Advisor (CRA)\u003c/li\u003e\u003cli\u003eBusiness Owner(BO)\u003c/li\u003e\u003cli\u003eProgram Manager\u003c/li\u003e\u003cli\u003eData Guardian (DG)\u003c/li\u003e\u003cli\u003eInformation System Owner (ISO)\u003c/li\u003e\u003cli\u003eInformation System Administrator\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e* For the stakeholders mentioned in Table 5 and Step 1 above, the CCB must be notified of system changes. However, each system requires its own group of stakeholders to make up the CCB and there is no expectation for each role listed in Table 5 to receive notifications for every single system change. This is especially true for the Data Guardian who should only receive notification when significant changes are implemented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop, as part of the\u0026nbsp;\u003cem\u003eConfiguration Management Plan\u003c/em\u003e, an automated method of requesting approval from the authorized submitter to the appropriate CCB members to be listed in section 4.2 Roles and Responsibilities.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO, ISO, and Project Manager develop the method of automated notification of changes that have requested approval to determine who gets notification at the time of proposal and how they are notified.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe ISSO, ISO, and Project Manager reference the SSPP for handling changes, to determine highlighting rules for CRs that have not been addressed or have not been approved within the designated period.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eTest / Validate / Document Changes (CM-3(2))\u003c/h4\u003e\u003cp\u003eSystems can implement this control by creating an environment to test changes prior to implementation in the operational environment. The testing environment should be separate from the operational environment when possible. The test environment should mirror the operational environment to the \u0026nbsp;maximum extent possible, but CMS realizes deviations will have to be made so long as they are properly documented. Teams performing testing should document the process and procedures associated with the test to include a detailed outcome.\u003c/p\u003e\u003cp\u003eThe purpose of testing changes to the system prior to implementation is to reduce the chance that outages will occur during implementation.\u0026nbsp; The separation of testing from implementation in the operational environment is meant to give network/system administrators an opportunity to see if proposed changes will adversely affect the operational systems. \u0026nbsp;CMS has the goal of reducing the chances that the operational environment will fail as a result of changes to the environment. \u0026nbsp;Implementing this control will reduce breaks in operational environments and enable stakeholders making subsequent changes to reference the documentation created.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following details the CMS specific process for testing, validating, and documenting changes to an information system.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer designs and develops the tests for the information system, as required by the CMS-SDLC, to be referenced for testing during changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Change Manager collects CRs and makes sure that they are documented in the automated tool as outlined in the\u0026nbsp;\u003cem\u003eConfiguration Management Plan.\u003c/em\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer with the system/network administrator test the system changes as outlined in the documented CR and approved by the CCB.\u0026nbsp; The test may be conducted on the test environment or operational system while off-line or during a maintenance window using the tests outlined in the test plan.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSecurity Impact Analysis (CM-4)\u003c/h3\u003e\u003cp\u003eOrganizational personnel with information security responsibilities (e.g., Information System Administrators, Information System Security Officers, Information System Security Managers, and Information System Security Engineers) conduct security impact analyses. Security impact analysis may include, for example, reviewing security plans to understand security control requirements and reviewing system design documentation to understand control implementation and how specific changes might affect the controls. Security impact analyses may also include assessments of risk to better understand the impact of the changes and to determine if additional security controls are required. Security impact analyses are scaled in accordance with the security categories of the information systems.\u003c/p\u003e\u003cp\u003eThe analysis of the security impact of a change occurs when changes are analyzed and evaluated for adverse impact on security, preferably before they are approved and implemented, but also in the case of emergency/unscheduled changes. These analyses are important to CMS because they prevent unnecessary risk to the enterprise.\u003c/p\u003e\u003cp\u003eChanges (in both the change management process and if a significant change will be made that impacts the ATO) should not be accepted without first studying the risks posed by these changes by conducting a security impact analysis. Before the changes are implemented and tested, a security impact analysis (and/or assessment) is performed to ensure that the changes have been sufficiently analyzed and documented, and to determine if there are any unanticipated effects of the change on existing security controls.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eChange Management\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eInformation system changes should not be undertaken prior to assessing the security impact of such changes. If the results of the security impact analysis indicate that the proposed or actual changes can affect, or have affected, the security state of the system; then corrective actions must be initiated and appropriate documents are revised and updated (e.g., the system security plan, security assessment report, and plan of action and milestones, etc.).\u003c/p\u003e\u003cp\u003eThe business owner, or common control provider(s) should consult with their ISSO and/or CRA, and participate in the TRB review process prior to implementing any security-related changes to the information system, or its environment of operation.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eSignificant Change\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eMany events can trigger change—even events that may not result in an actual system “change”. Significant changes require a formal reauthorization of the system. If a formal reauthorization action is required, the business owner should target only the specific security controls affected by the changes and reuse previous assessment results wherever possible. Most routine changes to an information system or its environment of operation can be handled by the business owner’s continuous monitoring program.\u003c/p\u003e\u003cp\u003eNIST states that a Significant Change to an information system may include (for example): (i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform; (iv) modifications to cryptographic modules or services; or (v) modifications to security controls. Examples of significant changes to the environment of operation may include for example: (i) moving to a new facility; (ii) adding new core missions or business functions; (iii) acquiring specific and credible threat information that the organization is being targeted by a threat source; or (iv) establishing new/modified laws, directives, policies, or regulations.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process to conduct a security impact analysis:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;After receiving the Change Request (CR) submission from the CCB, the ISSO will determine the scope of the change by analyzing the CR form. They will develop a high-level architecture overview that shows how the change will be implemented. If the change has already occurred (unscheduled/unauthorized), the ISSO will request follow-up documentation/information and review it or use whatever information is available (e.g., audit records, interview staff who made the change, etc.) to gain insight into the change.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2\u003c/strong\u003e: The ISSO will identify the scope and the categorization of the change.\u0026nbsp; See Appendix D for the SIA Template.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3\u003c/strong\u003e: The ISSO will identify any vulnerabilities (via vulnerability scans, documentation comparison etc.) in the proposed change and analyze the categorizations of change and identify the security controls that are impact by the change (both system specific, hybrid, and inherited controls)\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4\u003c/strong\u003e: The ISSO, in consultation with the CRA, conducts a risk assessment of any discovered vulnerabilities (impact and likelihood) and change(s) to security control implementation that has been affected by the change(s). A risk assessment is needed to identify the likelihood of a threat exercising the vulnerability and the impact of such an event.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, assess impact of proposed change on functionality of the system or CI and assess impact of proposed change on existing security controls. For example, the change may involve installation of software that alters the existing baseline configuration, or the change itself may cause or require changes to the existing baseline configuration. The change may also affect other systems or system components that depend on the function or component being changed, temporarily or permanently. For example, if a database that is used to support auditing controls is being upgraded to the latest version, auditing functionality within the system may be halted while the upgrade is being implemented.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The ISSO, in consultation with the CRA, conducts a Privacy Impact Assessment to ensure that a change to the system that affects PII/PHI is accounted for and proper action can be taken if necessary\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7\u003c/strong\u003e: The ISSO, in consultation with the CRA, determine whether the change is part of the change management process or if the change is significant enough that the system authorization is in question. Read the above introduction paragraphs for guidance to help make this determination.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf change management\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit them to the Change Control Board (CCB). If the change is occurring on a contractor system, the contractor’s internal CCB will be responsible for approving changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: If change is occurring on a contractor system, CMS has the ability to request that the contractor conduct an SIA.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eIf a significant change\u003c/strong\u003e:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 9\u003c/strong\u003e: The ISSO and the CRA will meet with the Business Owner and the Technical Review Board (TRB) to determine if a re-authorization is necessary. If re-authorization is necessary, the ATO package must receive proper approval before implementation.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10\u003c/strong\u003e: The ISSO and the CRA will document findings, attach them to the change request, and submit to the Change Control Board (CCB).\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 11\u003c/strong\u003e: Assess whether the changes made to the system impact the PIA and whether the PIA needs to be updated. Include this assessment in the findings submitted to the CCB or TRB.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSeparate Test Environments (CM-4(1))\u003c/h4\u003e\u003cp\u003eSeparate test environments are used at CMS to host an instance of the operational environment.\u0026nbsp; They should mirror one another in order to create an accurate response to changes as they are made for testing.\u0026nbsp; The environment will be kept separate, physically and/or logically, so that changes in one do not affect the other. \u0026nbsp;Changes will then be analyzed for flaws, weaknesses, incompatibility and intentional/unintentional harm that results from implementation. \u0026nbsp;CCB approved changes should be made in this test environment first, then the production/operational environment. Test environments need to mirror production to the maximum extent possible, but CMS realizes that deviations may have to be made so long as they are properly documented.\u003c/p\u003e\u003cp\u003eSeparating the testing environment from the production environment benefits CMS by allowing a chance to see the changes requested for a system enacted before the changes affect end users. Test environments give a chance to observe possible harm or disrupted functionality without applying the changes to production. It can reduce the risks of change overall, since the production data and operational environment are not harmed when the test environment is adversely affected.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS-specific process to ensure that separate environments have been incorporated into testing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System/Network Administrator creates and maintains a test environment that is similar to the operational environment but either physically or logically separate from it.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator uses the test environment to enact approved changes from the CCB then observe and document the effects of those changes before those approved changes are enacted on the operational system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eAccess Restrictions for Change (CM-5)\u003c/h3\u003e\u003cp\u003eThe changes to a system can be sensitive.\u0026nbsp; CMS calls for restrictions on the access to the system both physically and logically.\u0026nbsp; The access controls to limit change privileges can be implemented through discretionary access controls such as deciding who is on the CCB. Supplemental discretionary access or role-based access controls can be enacted on files using Access Control Lists (ACLs). There can also be physical access restrictions such as those requiring a key to get into datacenter facilities. All together, these access restrictions should be developed, documented, approved and enforced throughout the system life cycle.\u003c/p\u003e\u003cp\u003eRestricting the ability to enact change to a system maintains the overall stability to the system.\u0026nbsp; CMS limits production and operational privileges to make sure that there are controlled inputs to the change control process. Without limitations on change requests for a system, the process may become overwhelmed or inefficient based on unnecessary change requests.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS enacts this control, which is ensured by the Business Owner, by utilizing the following steps:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The Office of Information Technology (OIT) defines and approves access restrictions associated with change to the system during the initial phase of the CMS-SDLC including:\u003cul\u003e\u003cli\u003e\u003cstrong\u003eAdministrative controls –\u0026nbsp;\u003c/strong\u003eSuch as procedures, processes and standards to be used in configuration management\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eRole-based Access Controls\u003c/strong\u003e\u0026nbsp;– Such as those on files and storage related to change documentation\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eDiscretionary Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those approving the appropriate personnel to approve changes to the system\u003c/li\u003e\u003cli\u003e\u003cstrong\u003ePhysical Access Controls\u0026nbsp;\u003c/strong\u003e– Such as those restricting access to the computer equipment where the change requests and automation systems are kept\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Owner includes the defined access restrictions in the baseline configuration for the information system, to be included as a configuration item for the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO develops physical access controls if there is no description of them available for the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO documents physical and logical access controls in CFACTS under the Controls tab in the Authorization Package. Select Allocated Control CM-5 and list the reference or documented physical controls in the Shared Implementation Details field of the Implementation section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The ISSO reviews proposed changes to the physical and logical controls and the BO approves the changes.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;Unapproved physical access changes must be filed as a Risk Acceptance Request documented in CFACTS or returned to the developer for modification of the plans and resubmission to the ISSO.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Access Enforcement / Auditing (CM-5(1))\u003c/h4\u003e\u003cp\u003eA system under this control will have automation in its access enforcement and auditing. \u0026nbsp;The automation means that the system will check to see if the user or service is authorized to access resources as well as use some form of authentication. \u0026nbsp;During this enforcement of access controls, the system should also log actions for auditing those enforcement actions later.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe access enforcement for a system is important to maintain its security. \u0026nbsp;Automating the enforcement is the most efficient method of maintaining access controls.\u0026nbsp; These controls keep the unauthorized users out.\u0026nbsp; They contribute to the safety of the system through authentication and confidentiality. The confidentiality of the system makes it so that users only see parts of the system they are authorized to see.\u0026nbsp; Authentication ensures that CMS knows the user or service that is attempting to access a resource.\u0026nbsp; Finally, the creation of access control records will allow CMS personnel to evaluate working controls and detect misuse of the system through audits.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for automatically controlling access and auditing:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The System Developer and Maintainer creates the system with the functionality to audit against access restrictions specifically on changes to the hardware, software, and firmware components of the information system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer creates the functionality to record and document enforcement actions in relation to the access of data and/or functionality that is restricted in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor cloud-based services, the Cloud Service Provider (CSP) should be enforcing Steps 1 and 2 using automated mechanisms, to be in place before the service is in operation.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eReview System Changes (CM-5(2))\u003c/h4\u003e\u003cp\u003eThe review of system changes should be carried out once per week by the CCB. \u0026nbsp;This process should also allow for ad-hoc reviews for checking configurations against the baseline when unauthorized changes have been indicated or there is a dramatic unforeseen shift in performance.\u003c/p\u003e\u003cp\u003eReview is a useful tool utilized by CMS to determine which changes may have been made without permission, or without following the configuration management procedure. \u0026nbsp;Discovering an unauthorized change could mean that there are more unauthorized changes present within the system. Reviewing the system changes is an easy way to check for procedural mistakes or intentionally unauthorized system changes. CMS maintains records of access to ensure that configuration change control is implemented and to support after-the-fact actions should CMS discover any unauthorized changes. Access restrictions for change also include software libraries. Access restrictions include, for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover). Related controls: AC-3, AC-6, PE-3, AU-6 and AU-7.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Review System Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(2)\u003c/td\u003e\u003ctd\u003eThe organization reviews information system changes [Assignment: organization-defined frequency] and [Assignment: organization-defined circumstances] to determine whether unauthorized changes have occurred.\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization reviews information system changes:\u003c/p\u003e\u003cp\u003ea. At least once a week; and\u003c/p\u003e\u003cp\u003eb. When unauthorized changes or unexpected levels of system performance are indicated.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for reviewing system changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;\u0026nbsp;The CCB meets to review system changes each week to determine if unauthorized changes were made by checking current configuration baselines against the current configuration of the system to check for CIs that were modified without a corresponding approved CR.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;When the CCB learns of unauthorized changes taking place or unexpected levels of system performance, they should check the configuration baselines of their systems against the actual configuration of the system to determine whether changes have been made on the system.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The CCB reports any unauthorized changes to the ISSO within 24 hours of the finding.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eSigned Components (CM-5(3))\u003c/h4\u003e\u003cp\u003eSigned components are parts of code that are used to create a digital signature and packaged together, code and signature. The digital signature is created from certificate assigned to the author of the code by a trusted certification authority.\u003c/p\u003e\u003cp\u003eCMS uses signed firmware and software components to know who the authors of the code are. The digital signature scheme and the Public Key Infrastructure together provide a way to institute non-repudiation for firmware and software updates.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Signed Components.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-5(3)\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of [Assignment: organization-defined software and firmware components] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003ctd\u003eThe information system prevents the installation of network and server software and firmware components without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following details the CMS specific process for signing components:\u003c/p\u003e\u003cp\u003eCode that is taken from third party providers must have a signature from the author. At CMS, the system administrators apply the correct configuration that automatically stops firmware and software components from being installed without a digital signature.\u0026nbsp; These settings are in use as part of CMS’ configuration baselines for systems.\u0026nbsp; In Windows-based systems, this is performed through Active Directory group policy objects.\u0026nbsp; The group policy is applied to the target computer object and results in the computer being configured to restrict software and firmware installations without digital signatures.\u0026nbsp; The certificate for the software should be from a trusted certificate authority and the certificate should not be trusted if it is self-signed. A trusted certificate authority is designated as such by DHS, HHS, and CMS.\u003c/p\u003e\u003ch3\u003eConfiguration Settings (CM-6)\u003c/h3\u003e\u003cp\u003eHHS has outlined guidance for use when configuring information system components for operation.\u0026nbsp; Configuration standards vary depending upon the technical characteristics of the information system (e.g. operating systems, databases, firmware, etc.)\u0026nbsp; The\u0026nbsp;\u003cem\u003eMinimum Security Configurations Standard Guidance\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003e\u003c/em\u003eissued by the Department of Health and Human Services shall be applied to all applicable systems. If an HHS-defined configuration standard baseline is not available than the\u0026nbsp;\u003cem\u003eU.S. Government Configuration Baseline\u003cstrong\u003e\u0026nbsp;(\u003c/strong\u003eUSGCB)\u003c/em\u003e\u0026nbsp;will be applied to the applicable systems.\u0026nbsp; For those systems not covered under USGCB, the\u0026nbsp;\u003cem\u003eNational Checklist Program\u003c/em\u003e\u0026nbsp;can be followed for configuration guidance.\u003c/p\u003e\u003cp\u003eThe purpose of creating common configuration settings is to streamline management and security implementations.\u0026nbsp; CMS configures systems with standardized settings and automates their implementation to save time and create a baseline of security that applies to all information systems, thereby, minimizing risk across the enterprise.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Configuration Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements];\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEstablishes and documents configuration settings for information technology products employed within the information system using the latest security configuration baselines established by the HHS, U.S. Government Configuration Baselines (USGCB), and the National Checklist Program (NCP) defined by NIST SP 800-70 Rev. 2 (refer to Implementation Standard 1 for specifics) that reflect the most restrictive mode consistent with operational requirements;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eIdentifies, documents, and approves any deviations from established configuration settings for individual components within the information system based on explicit operational requirements (defined in the system security plan [SSPP]);\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for documenting configuration changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The CMS System Developer and Maintainer uses the HHS approved configurations and creates the configuration for the applicable information system using\u0026nbsp;\u003cem\u003eHHS\u0026nbsp;\u003c/em\u003edefined security configurations\u003cem\u003e\u0026nbsp;\u003c/em\u003eas the guidance in their creation. For USGCB (HHS Approved) Configuration, the appropriate operating system and/or applications is Microsoft Windows Supported Versions.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer using other OSes and applications develops configurations from guidelines in the following priority:\u003cul\u003e\u003cli\u003eHHS\u0026nbsp;\u003cem\u003eMinimum Security Configuration Standards Guidance\u003c/em\u003e\u003c/li\u003e\u003cli\u003eUSGCB\u003c/li\u003e\u003cli\u003eNIST NCP – Tier IV, then III, II, I in descending order\u003c/li\u003e\u003cli\u003eTechnical Reference Architecture Volume IV – Development and Application Services\u003c/li\u003e\u003cli\u003eDISA Security Technical Implementation Guide (STIG)\u003c/li\u003e\u003cli\u003eNSA STIG\u003c/li\u003e\u003cli\u003eLacking a Federal government-authored checklist, using an industry group or vendor checklist (Such as Center for Internet Security (CIS) benchmarks)\u003c/li\u003e\u003cli\u003eCollaboration within CMS to i) Establish baselines and communicate industry and vendor best practices; and ii) Ensure deployed configurations are supported for security updates\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer documents secure configuration settings for the information system using the procedures in Section 3.1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The network is scanned regularly for compliance with the established baseline configuration.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The information systems that are out of compliance are re-configured with baseline settings by the System Developer and Maintainer, in collaboration with the Vulnerability Management Team.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe following steps are intended for use if the information system is cloud-based from a Cloud Service Provider (CSP).\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The OIT creates a baseline configuration with the CSP for their IT products inside the information system using USGCB as a guide to create the most restrictive mode consistent with operational requirements.\u003cul\u003e\u003cli\u003eIf USGCB does not apply, then they use the CIS benchmarks as guides to create the most restrictive mode consistent with operational requirements.\u003c/li\u003e\u003cli\u003eIf neither USGCB nor CIS applies, then they create their own benchmark of configuration settings.\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u003c/strong\u003e\u0026nbsp;The CMS ISSO and the System Developer and Maintainer creates Security Content Automation Protocol (SCAP) compatible security configuration checklists if there are no validated ones available. The list should be formatted so that it can be read by a validated SCAP tool and enable that tool to determine if the approved configuration is in place.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eDeviations\u003c/strong\u003e\u003c/p\u003e\u003cp\u003eThe following steps are intended for creating deviations to established configuration settings.\u0026nbsp; If the settings established using a standard for baseline configurations have significant detrimental impacts on a system’s ability to perform CMS duties, then follow the steps below to file for a Risk Acceptance. It is worth noting the difference between a deviation and a waiver. A waiver is required when there is a departure from CMS or HHS policy and must be approved by the AO. A deviation is when the system will differ from established configuration standards and the reason why the deviation is occurring must be documented.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eStarting from the established baseline\u003cem\u003e,\u0026nbsp;\u003c/em\u003ethe System Developer and Maintainer documents all of the deviations from the baseline that either:\u003cul\u003e\u003cli\u003eAre not intended to be implemented since the standard(original baseline) setting would interfere with business operations\u003c/li\u003e\u003cli\u003eAre cost prohibitive\u003c/li\u003e\u003cli\u003eAre technically infeasible\u003c/li\u003e\u003cli\u003eHave an impact to operations\u003c/li\u003e\u003cli\u003eCause a loss of functionality\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the collected deviation(s) documented in the previous step by working with the BO to determine if configurations would restrict the types of information used, adversely affect the boundaries or adversely affect the information shared with other systems.\u0026nbsp; Furthermore, the ISSO reviews the list for completeness to ensure it has all the information needed for the Risk Acceptance form. The ISSO selects deviations to be approved by the CISO and CRA through the Risk Acceptance form or otherwise returned to the System Developer and Maintainer within 90 days of receipt with an explanation as to why the deviation was rejected.\u0026nbsp; Then the System Developer and Maintainer can re-submit in the next review period. These actions \u0026nbsp;must be thoroughly documented in CFACTS. The process for documentation is explained in detail below.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO (or System Maintainer) logs into CFACTS and fills out and signs the Risk Acceptance form including all deviations from the baseline configuration that should be considered for the information system in Section 2\u0026nbsp;\u003cem\u003eWeaknesses\u003c/em\u003e\u0026nbsp;with the following information at a minimum:\u003cul\u003e\u003cli\u003eAllocated Control = CM-6\u003c/li\u003e\u003cli\u003eFinding Description\u003c/li\u003e\u003cli\u003eWeakness Description\u003c/li\u003e\u003cli\u003eEffect on Business\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eThe ISSO then fills out Section 3\u0026nbsp;\u003cem\u003eProposed Risk Acceptance\u003c/em\u003e\u0026nbsp;with all of the information related to the risk(s) that will be accepted and how/if the risk will be mitigated to include:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eOverview of the Risk Acceptance Request\u003c/li\u003e\u003cli\u003eBusiness Justification for the Risk Acceptance\u003c/li\u003e\u003cli\u003eJustification for Request\u003c/li\u003e\u003cli\u003eCompensating Controls (if any)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The CISO, BO, and CIO approve deviations from the configuration baseline and authorizes, using the Risk Acceptance form Section 5, the new configuration to be used in the CMS environment.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Every year, the ISSO reviews the deviations and exceptions in place on the system. He or she takes the accepted deviations and considers them collected, documented deviations to start over from Step 11 for re-certifying the configuration of the system.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Central Management / Application / Verification (CM-6(1))\u003c/h4\u003e\u003cp\u003eAutomating the management of operating systems and applications gives CMS more control over the information systems in the CMS infrastructure and those processing CMS data.\u0026nbsp; Automation is implemented to create a point (or points) of central management for administrators to change, apply, verify, and enforce configuration baselines and mandatory configuration settings. CMS uses the HHS defined security configuration standards as the basis for the configurations of information systems, components and applications. \u0026nbsp;CMS Information systems are expected to allow access to automated methods of configuration management, change and verification. \u0026nbsp;\u003c/p\u003e\u003cp\u003eUsing these policies and procedures for the CMS environment assures an even application of approved configurations across the network. \u0026nbsp;These configurations are applying the settings that will secure each system and application according to CMS’s business and regulatory needs, specifically to enforce the baseline and the mandatory configuration settings. \u0026nbsp;CMS is able to implement the settings and verify that they are correct using this control. \u0026nbsp;Verification is used to show compliance.\u0026nbsp; The combination of configuration and verification makes this control necessary for large enterprise environments such as CMS.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for Automated Central Management\\Application\\Verification.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for [Assignment: organization-defined information system components].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003eThe organization employs automated mechanisms to centrally manage, apply, and verify configuration settings for \u0026nbsp;information system components as defined in the HHS Minimum Security Configuration Standards for Departmental Operating Systems and Applications.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for automation of central management:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The System Developer and Maintainer configures the information system with the tools necessary to automate monitoring and configuring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO contacts the CDM program (Appendix G) in order to find out how to connect their system to the central management mechanism.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The system is scanned regularly by the System Developer and Maintainer for compliance with approved configurations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The configuration changes are applied by the System Developer and Maintainer using configuration management tools to information systems after they have been approved by the OIT.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eRespond to Unauthorized Changes (CM-6(2))\u003c/h4\u003e\u003cp\u003eIt is the duty of CMS authorized personnel to respond to unauthorized changes to the information system, components or its data.\u0026nbsp; The response should include notifying the business owner and ISSO. Additionally, the configuration should be restored to an approved version and further system processing can be halted as necessary.\u003c/p\u003e\u003cp\u003eCMS prevents or rolls back these changes to ensure that they go through the process of change management and receive the appropriate approvals and security checks before implementation. \u0026nbsp;Unauthorized changes that have not undergone security vetting may introduce new vulnerabilities that have not been mitigated by existing security controls. \u0026nbsp;The potential for increase of risk leads CMS to respond to unauthorized changes as soon as possible.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-6(2) Respond to Unauthorized Changes.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-6(2)\u003c/td\u003e\u003ctd\u003eThe organization employs [Assignment: organization-defined security safeguards] to respond to unauthorized changes to [Assignment: organization-defined configuration settings].\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization responds to unauthorized changes to information system and components (e.g., authorization, auditing, processing types, baselines) and data (e.g., system libraries, log files, executables) in the following ways:\u003c/p\u003e\u003col\u003e\u003cli\u003e\u0026nbsp;\u003col\u003e\u003cli\u003eAlert responsible actors (person, organization);\u003c/li\u003e\u003cli\u003eRestore to approved configuration; and\u003c/li\u003e\u003cli\u003eHalt system processing as warranted.\u003c/li\u003e\u003c/ol\u003e\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for responding to unauthorized changes:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; Unauthorized changes are automatically stopped, when possible, by halting system processing using management tools and permission restrictions. \u0026nbsp;Attempts to make unauthorized changes generate alerts that are documented in centralized audit files.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eCDM informs the Incident Management Team in Information and Security Privacy Group (ISPG) when unauthorized changes occur if an unauthorized individual accesses the system that made the change. If an authorized individual made a valid change but did not follow the CM process, CDM contacts the individual and requests that they roll back the change and follow the appropriate CM procedures.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;Incident Management Team coordinates the incident response and assists stakeholders in deciding whether to retrieve the information system or otherwise restore the settings to the approved baseline.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eLeast Functionality (CM-7)\u003c/h3\u003e\u003cp\u003eThe principle of least functionality must considered when configuring a system. \u0026nbsp;This involves first documenting the essential capabilities of the system.\u0026nbsp; After that, the system can be configured to accommodate these capabilities while turning off non-essential functionality.\u0026nbsp; At CMS, we pay special attention to high-risk system services and additionally turn those off unless they are absolutely needed.\u003c/p\u003e\u003cp\u003eCMS integrates security principles into its system development and design.\u0026nbsp; This control addresses the principle that systems are granted only those functions that are needed in order for them to accomplish their tasks.\u0026nbsp; This includes system services, which traverse network boundaries that are considered high-risk.\u0026nbsp; This aims to reduce the “attack surface” of a system.\u0026nbsp; Attack surface refers to the points that an attacker might target when compromising a system.\u0026nbsp; Reducing functionality that goes beyond a system’s tasks leads to minimizing risk resulting in fewer attack vectors and leaving fewer options for attack.\u0026nbsp; CMS reduces the risk as much as possible for each system to prevent attacks.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM least functionality.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003eb. Prohibits or restricts the use of the following functions, ports, protocols, and/or services: [Assignment: organization-defined prohibited or restricted functions, ports, protocols, and/or services].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eProhibits or restricts the use of high-risk system services, ports, network protocols, and capabilities (e.g., Telnet, FTP, etc.) across network boundaries that are not explicitly required for system or application functionality.\u003c/li\u003e\u003cli\u003e[Added] A list of specifically needed system services, ports, and network protocols must be maintained and documented in the applicable security plan; all others will be disabled.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, which is ensured completed by the Business Owner, details the CMS procedure for least functionality:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eTo capture the functionality, the ISSO and the system developer and maintainer should refer to the Intake Form completed during the initial phase of the CMS-SDLC.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer logs into CFACTS to reference the network boundaries as shown in the\u0026nbsp;\u003cem\u003eCFACTS User Manual\u003c/em\u003e\u0026nbsp;in section 4.4\u0026nbsp;\u003cem\u003eBoundary Tab\u003c/em\u003e. They must also consider the system description, purpose, functionality, and architecture. This information can be used to turn off high-risk system services on the system or system components if they are not needed for system or application functionality.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer keeps a record of explicitly required system services, ports and network protocols, maintains it on an ongoing basis throughout the CMS-SDLC and communicates changes to the ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO enters the explicitly required system services, ports and network protocols into the\u0026nbsp;\u003cem\u003eSystem Security Plan\u003c/em\u003e\u0026nbsp;in CFACTS using the Boundaries Details section and in the implementation details for control CM-7.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003e\u003cstrong\u003e\u0026nbsp;Periodic Review (CM-7(1))\u003c/strong\u003e\u003c/h4\u003e\u003cp\u003eReview of ports, services, functions and protocols involves checking the system periodically.\u0026nbsp; The system checks will make comparisons of what is used and what is authorized for use.\u0026nbsp; CMS will then use that information to make a determination of which ports, services, functions and protocols should be disabled.\u0026nbsp; The system scans will identify the PPS, and then an analysis will have to be conducted to determine if they can be disabled.\u003c/p\u003e\u003cp\u003ePeriodic review within CMS helps to protect the systems in its infrastructure.\u0026nbsp; The protection comes from reducing the attack surface as stated in “\u003cem\u003eLeast Functionality CM-7\u003c/em\u003e” to reduce the risk to the network.\u0026nbsp; Reviewing on a periodic basis allows CMS to check continually for weaknesses and baseline anomalies.\u0026nbsp; The change management process can introduce weaknesses into the environment, so it is important to evaluate systems on an ongoing basis to determine the consequences of changes, including unintentional or unforeseen consequences that affect the risk to that system.\u0026nbsp; CMS authorizes scanning systems on this basis since change management is also an ongoing process in itself.\u0026nbsp; This helps to keep checks coordinated with changes.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM periodic review.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(1)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system [Assignment: organization-defined frequency] to identify unnecessary and/or non-secure functions, ports, protocols, and services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eDisables [Assignment: organization-defined functions, ports, protocols, and services within the information system deemed to be unnecessary and/or non-secure].\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eReviews the information system no less often than once every thirty (30) days to identify and eliminate unnecessary functions, ports, protocols, and/or services;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003ePerforms automated reviews of the information system no less often than once every seventy-two (72) hours to identify changes in functions, ports, protocols, and/or services; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eDisables functions, ports, protocols, and services within the information system deemed unnecessary and/or non-secure.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process details the CMS procedure for periodic review:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe Continuous Diagnostics and Mitigation (CDM) team coordinates with the ISSO to monitor functions, ports, protocols, and services. The CDM sends periodic review information to the ISSO regarding their monitoring.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The CDM team automatically scans the information system for changes in functions, ports, protocols and/or services at least every 72 hours and more frequently as necessary. \u0026nbsp;The scans should include systems, appliances, devices, services and applications (such as databases). This is performed on an ongoing basis until the system is retired. Changes are documented and sent to the system ISSO.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews the system every 30 days using the reports taken from the CDM program.\u0026nbsp; The reports are compared against the System Architecture and Architecture Design section inside of the System Design Document\u003cem\u003e\u0026nbsp;\u003c/em\u003ein CFACTS for its listing of necessary functions, ports, protocols and services.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The system developer and maintainer along with the ISSO work together to disable unnecessary functions, ports, protocols and services with advice from the CRA. This is performed on an ongoing basis as they are discovered.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003ePrevent Program Execution (CM-7(2))\u003c/h3\u003e\u003cp\u003eThis control is implemented to ensure that CMS is using the software it has acquired responsibly and legally. \u0026nbsp;To execute this control there must be methods in place to prevent executing software that is not:\u003c/p\u003e\u003cul\u003e\u003cli\u003eLicensed for use\u003c/li\u003e\u003cli\u003eConfigured for use at CMS\u003c/li\u003e\u003cli\u003eExecuted by an authorized user\u003c/li\u003e\u003c/ul\u003e\u003cp\u003ePreventing these executions should be done automatically, and the users must not be permitted to execute the programs themselves.\u003c/p\u003e\u003cp\u003eThese program preventions are a part of CMS’s security controls to ensure that security is built into the basic elements of systems through software. This is done to apply settings, which CMS knows are protecting the interests of the organization. \u0026nbsp;This is extended to licensing to make sure CMS is not exposed to risk by using software that is unlicensed. \u0026nbsp;Unlicensed software may violate the law or introduce new risks through its operation. \u0026nbsp;\u0026nbsp;Risk from operation is also included in this control by restricting software to those that are authorized to use it. Unauthorized users may not be assigned the responsibility of using certain types of software and CMS uses separation of duties to spread out job responsibilities among groups of people to reduce risk and insider threats.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM-7(2) prevent program execution.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(2)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with [Selection (one or more): [Assignment: organization-defined policies regarding software program usage and restrictions]; rules authorizing the terms and conditions of software program usage].\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe information system prevents program execution in accordance with policies regarding authorized software use which include, but are not limited to the following:\u003c/p\u003e\u003cp\u003e\u0026nbsp;a. Software must be legally licensed;\u003c/p\u003e\u003cp\u003e\u0026nbsp;b. Software must be provisioned in approved configurations; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;c. Users must be authorized for software program use.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThis control is system specific, but the following is a good example of how to implement and document the control:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe administrators of the system create the baseline configuration for software on the computer image.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp; \u003c/strong\u003eSystem administrators configure the domain settings to disallow software installations for all Users without administrative privileges.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eSystem administrators distribute computer images for all government issued computers using authorized and licensed software, and ensures that it is using approved configurations for the software included\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor software that is not included in the computer image for the baseline configuration, use the following steps to allow execution in accordance with policies.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe user checks the website for the Office of Information Technology to find if the software that they are requesting has been tested by CMS for conflicts and/or malicious behavior using the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u003c/em\u003e\u0026nbsp;here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u003cstrong\u003eNote:\u0026nbsp;\u003c/strong\u003eSoftware that is supported under an enterprise license is a subset of the\u0026nbsp;\u003cem\u003e“CMS Tested Software List”\u0026nbsp;\u003c/em\u003efrom step 4; please refer to the OIT website for Enterprise Software Licensing here for more information:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Systems-and-Services/enterprise-software-licensing/index.html\u003c/a\u003e\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eIf the software is not in the list, then submit the software for testing following the steps in the procedure on the OIT website:\u0026nbsp; \u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e\u0026nbsp;, if the software is on the list then skip to the next step\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u0026nbsp;\u003c/strong\u003eThe user of the software must acquire the license for the software that they wish to use using the forms of proof provided by CMS Deskside support listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/requests.html\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 7:\u0026nbsp;\u003c/strong\u003eThe user submits a new installation request following the procedure listed here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/process.html\u003c/a\u003e\u0026nbsp;in which the Deskside support personnel will validate the license, authorize the user to use the software and provision the software in approved configurations\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eUsers operate under restricted privileges per CM-7 - least privilege, which will logistically prevent program execution through system policies. For those users who may get software installed surreptitiously or have administrative privileges, the following steps will apply:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 8:\u0026nbsp;\u003c/strong\u003eThe operations team within ISPG monitors the network for software network behavior and/or traffic from unauthorized software, when possible, to discover, and create alerts to notify the CMS Security Operations Center (SOC) if unauthorized software use is logged.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 9:\u003c/strong\u003e\u0026nbsp;The SOC reviews alerts daily to determine if unauthorized software is in use as part of their duty. When discovered, the SOC isolates the computer on the network if needed and uninstalls the unauthorized software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 10:\u0026nbsp;\u003c/strong\u003eThe SOC utilizes automated methods of managing software and notifies the user when unauthorized software is detected and automatically removes the software before the next 48 hours.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAuthorized Software / Allowlisting (CM-7(5))\u003c/h4\u003e\u003cp\u003eThe authorized software allowlisting control means that CMS would document the software that is allowed to run on CMS systems. The software name and its representation would be used to determine if a specific piece of software is on the list. Software on the list is allowed to execute and all other software is denied by default. As part of the implementation of this control, the list should be updated regularly and automatically from a trusted source.\u003c/p\u003e\u003cp\u003eUsing an allowlist instead of a denylist is an option to consider for environments that are more restrictive. The list itself is known, and the system denies all other software. CMS can use an allowlist to lessen the uncertainty in a system through this prevention of executing the unknown. Decreasing the uncertainty in this case can also lead to decreasing the risk that malware or software outside of that needed for the operation of a system is executed.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Authorized Software/Allowlisting.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-7(5)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies [Assignment: organization-defined software programs authorized to execute on the information system];\u003c/li\u003e\u003cli\u003eReviews and updates the list of authorized software programs [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eIdentifies defined software programs (defined in the applicable security plan) authorized to execute on the information system;\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"3\"\u003e\u003cli\u003eReviews and updates the list of authorized software programs no less often than every seventy-two (72) hours; and\u003c/li\u003e\u003cli\u003e[Added] Receives automated updates from a trusted source.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for Authorizing Software or Allowlisting:\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u0026nbsp;If no Denylisting solution is in place, then an Allowlisting solution must be used.\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO, working with the System/Network Administrator and the System Developer and Maintainer, identifies and defines the software programs that are authorized for use on the information system. Then lists them in the applicable part of CFACTS. The list can be held under the\u0026nbsp;\u003cem\u003e“Controls”\u003c/em\u003e\u0026nbsp;tab, in the\u0026nbsp;\u003cem\u003e“Allocated Controls”\u0026nbsp;\u003c/em\u003esection for control CM-7(5) as part of the “\u003cem\u003eShared Implementation Details”\u003c/em\u003e\u0026nbsp;subsection.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures an automated software Allowlisting tool for their applicable information systems so they only allow execution of software that has previously been approved for install/use listed in Step 1.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO automatically updates and reviews the list of software from Step 1 no less often than every 72 hours from a trusted source such as, but not limited to:\u003cul\u003e\u003cli\u003e\u0026nbsp;\u003cul\u003e\u003cli\u003eCMS internal processes\u003c/li\u003e\u003cli\u003eOther agencies within the federal government\u003c/li\u003e\u003cli\u003eThe vendor of the Allowlisting product\u003c/li\u003e\u003cli\u003eIndustry specialists\u003c/li\u003e\u003cli\u003eCMS systems, appliances, devices, services and applications (to include databases)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the tool to provide results that are searchable by the CCIC.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for allowlisting information must be provided by the timeframe listed within the request.\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eFor cloud-based\u003cstrong\u003e\u0026nbsp;\u003c/strong\u003esystems that run software\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp; \u003c/strong\u003eThe System Developer and Maintainer configures the cloud-based system or service to only allow authorized software to execute following the steps above with or without an automated Allowlisting tool.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eInformation System Component Inventory (CM-8)\u003c/h3\u003e\u003cp\u003eInformation system components are parts of the CMS network used to process, store or transmit CMS information.\u0026nbsp; The components must each have an identifier that should be received from the property office in the form of an asset tag, which should be linked in an inventory system with the name of the asset, location, asset identification, owner, and description of use. More information can be added as needed, but those fields are the minimum.\u0026nbsp; Then the component inventory should be linked to the CDM tools so monitoring can be linked to specific components.\u003c/p\u003e\u003cp\u003eCMS takes an inventory of information system’s components as a fundamental part of protecting the infrastructure.\u0026nbsp; Inventories contain items that need to be checked for secure configurations, and they provide a logical baseline so that components found outside of the inventory can be scrutinized and unauthorized components removed, disabled or authorized.\u0026nbsp; Unauthorized components could be indicative of a security risk and should be investigated. This control also adds to the accountability of the system. Each component is a part of the system and the same security protections should apply to all components. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM Information System Component Inventory.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eDevelops and documents an inventory of information system components that:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e4. Includes [Assignment: organization-defined information deemed necessary to achieve effective information system component accountability]; and\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eReviews and updates the information system component inventory [Assignment: organization-defined frequency].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Develops and documents an inventory of information system components that:\u003c/p\u003e\u003cp\u003e1. Accurately reflects the current information system;\u003c/p\u003e\u003cp\u003e2. Include all components within the authorization boundary of the information system;\u003c/p\u003e\u003cp\u003e3. Are at the level of granularity deemed necessary for tracking and reporting; and\u003c/p\u003e\u003cp\u003e4. Includes:\u003c/p\u003e\u003cp\u003e- Each component’s unique identifier and/or serial number;\u003c/p\u003e\u003cp\u003e- Information system of which the component is a part;\u003c/p\u003e\u003cp\u003e- Type of information system component (e.g., server, desktop, application);\u003c/p\u003e\u003cp\u003e- Manufacturer/model information;\u003c/p\u003e\u003cp\u003e- Operating system type and version/service pack level;\u003c/p\u003e\u003cp\u003e- Presence of virtual machines;\u003c/p\u003e\u003cp\u003e- Application software version/license information;\u003c/p\u003e\u003cp\u003e- Physical location (e.g., building/room number);\u003c/p\u003e\u003cp\u003e- Logical location (e.g., IP address, position with the information system [IS] architecture);\u003c/p\u003e\u003cp\u003e- Media access control (MAC) address;\u003c/p\u003e\u003cp\u003e- Ownership;\u003c/p\u003e\u003cp\u003e- Operational status;\u003c/p\u003e\u003cp\u003e- Primary and secondary administrators; and\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003e- Primary user. Reviews and updates the information system component inventory no less frequently than every 180 days for High systems or 365 days for Moderate and Low systems, or per CM-8(1) and/or CM-8(2), as applicable.\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps, which is ensured completed by the Business Owner, detail the CMS specific process for information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops and documents an inventory of information system components. For this, they or a designee gathers the following information to be checked off and documented from each FISMA information technology item, including all components within the authorization boundary:\u003cul\u003e\u003cli\u003eUnique ID (or serial number) such as the asset tag number\u003c/li\u003e\u003cli\u003eInformation system that the component is a part of\u003c/li\u003e\u003cli\u003eAre controls inherited?\u003c/li\u003e\u003cli\u003eHigh Value Asset?\u003c/li\u003e\u003cli\u003eInformation system component type\u003c/li\u003e\u003cli\u003eManufacturer \u0026amp; model\u003c/li\u003e\u003cli\u003eOperating system type and version number\u003c/li\u003e\u003cli\u003eVirtual machine presence\u003c/li\u003e\u003cli\u003eApplication\\software license \u0026amp; version information (when applicable)\u003c/li\u003e\u003cli\u003ePhysical location\u003c/li\u003e\u003cli\u003eLogical location\u003c/li\u003e\u003cli\u003eMedia access control (MAC) address\u003c/li\u003e\u003cli\u003eResponsible party (Owner)\u003c/li\u003e\u003cli\u003eOperational status\u003c/li\u003e\u003cli\u003ePrimary \u0026amp; secondary administrator(s)\u003c/li\u003e\u003cli\u003ePrimary user(s)\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO checks the details listed in the asset management tool and determine if the information gathered is enough to track and report on the component and then add fields as necessary. \u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe ISSO reviews for accuracy and missing information and update the information system component inventory every 180 days for systems rated as “High” and every 365 days for systems rated as “Moderate” or “Low” from the system categorization in\u0026nbsp;\u003cem\u003eRMH Chapter 12\u003c/em\u003e\u0026nbsp;Section 3.1.2. T\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;System Developer and Maintainer configures the inventory system(s) to provide updates in a format compliant with CMS and federal standards to the CCIC at least once every 72 hours.\u0026nbsp; These results must also be available in a raw, unaltered format by request of the CCIC.\u0026nbsp; Tools that are unable to exchange information with the CCIC must have this lack of ability noted in the applicable risk assessment.\u0026nbsp; CCIC directed requests for component information must be provided by the timeframe within the request.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The Network/System Administrator provides timely, as defined by the CISO, responses to informational requests about component status and posture information.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eUpdates During Installations / Removals (CM-8(1))\u003c/h4\u003e\u003cp\u003eThe purpose of this control is to ensure that the component inventory is up-to-date in times of change. The CMS system inventory should be updated in cases of: information system component installs, removals, and updates.\u003c/p\u003e\u003cp\u003eUpdates during installations and removals to the inventory system is necessary to keep current information. The result of an upgrade, installation or removal can involve different components altogether. If the system inventory is not current, then the assumptions based on the inventory will not be accurate. It can have far-reaching impact beyond the current system and should involve updates as part of the procedure. Furthermore, updating the inventory supports accountability controls and breach response efforts.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for Updates During Installations/Removals component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u0026nbsp;\u003c/strong\u003eThe ISSO inputs new information system components into the inventory when they are installed to include the information input for systems in Section 3.7 Step 1 above.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u0026nbsp;\u003c/strong\u003eThe ISSO updates the inventory when an information system component is removed from the system. The component is taken out of inventory.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The ISSO updates the inventory when an information system is updated, changing information that is listed in the inventory such as that in Section 3.7 Step 1.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Maintenance (CM-8(2))\u003c/h4\u003e\u003cp\u003eThe CMS inventory system should be able to gather information and update records automatically.\u0026nbsp; The inventory system makes the database complete, accounting for inventory from purchase to disposition.\u0026nbsp; It is accurate, automated where possible and checked for accuracy. It is also meant to be readily available.\u0026nbsp; The system should be fault tolerant to ensure that the information on inventory is there when needed.\u003c/p\u003e\u003cp\u003eCMS uses automated inventory maintenance to show what information system components are available at any given time.\u0026nbsp; Knowing what inventory is supposed to be in the environment compared to what components are seen on the network, CMS can make determinations about components and their suitability. \u0026nbsp;If the component is in inventory and not detected through CDM for a time specified by CMS, then it may need to be flagged as a potentially compromised component. On the other hand, if a component is not in inventory and detected on the network, then it should be flagged as an unauthorized component until verified. These examples show some issues with risk by using inventory anomalies in CMS’ assessments of risk.\u003c/p\u003e\u003cp\u003eThe following, which is ensured completed by the Business Owner, lists the security safeguards implemented by CMS for automated information system component inventory:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to maintain the inventory of the information system including all components. The methods should include automation where possible and it should be available for review.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO compares the inventory system to physical inventory to evaluate accuracy and completeness, every 365 days for low/moderate systems and every 180 days for high systems.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAutomated Unauthorized Component Detection (CM-8(3))\u003c/h4\u003e\u003cp\u003eThe detection of components is utilized at CMS to determine whether a component is authorized or not.\u0026nbsp; By using an inventory of components that are authorized to be on the network, CMS can utilize a mechanism to compare a discovered component with the inventory.\u0026nbsp; The scans must be done on a weekly basis, more frequently as needed.\u0026nbsp; The mechanism for discovery should be automatic and detect hardware, software and firmware components within the information system.\u0026nbsp; When a component is found to be unauthorized then the automated mechanism should take measures to do the following:\u003c/p\u003e\u003cul\u003e\u003cli\u003ePrevent access to the component\u003c/li\u003e\u003cli\u003eEffectively disconnect the component from the network\u003c/li\u003e\u003cli\u003eIsolate the component\u003c/li\u003e\u003cli\u003eNotify responsible party as specified by the SSPP\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eCMS intends to automate where possible to stop malicious attacks as they occur.\u0026nbsp; Stopping the communication with an unauthorized component as soon as possible is the goal of this control.\u0026nbsp; The automated responses helps CMS address threats in a timely manner since utilizing technology is consistently faster than a manual process would be able to address.\u0026nbsp; In order to review and take action against unauthorized components quickly, automation is the ideal solution.\u0026nbsp;\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for CM automated unauthorized component detection.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(3)\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms [Assignment: organization-defined frequency] to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components are detected: [Selection (one or more): disables network access by such components; isolates the components; notifies [Assignment: organization-defined personnel or roles]].\u003c/li\u003e\u003c/ol\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003col\u003e\u003cli\u003eEmploys automated mechanisms no less than weekly to detect the presence of unauthorized hardware, software, and firmware components within the information system; and\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003col start=\"2\"\u003e\u003cli\u003eTakes the following actions when unauthorized components and/or provisioned configurations are detected:\u003c/li\u003e\u003c/ol\u003e\u003cp\u003e\u0026nbsp;1. Disable access to the identified component;\u003c/p\u003e\u003cp\u003e\u0026nbsp;2. Disable the identified component’s network access;\u003c/p\u003e\u003cp\u003e\u0026nbsp;3. Isolate the identified component; and\u003c/p\u003e\u003cp\u003e4. Notify the responsible actor (i.e., person/organization defined in security plan).\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the process for automated unauthorized component detection:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO, working with the Business Owner, monitors the network to determine if unauthorized components are connected. The scan should be done at least weekly then as necessary for components that match the inventory in the automated inventory record.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO forwards unauthorized components to the Incident Management Team (IMT.)\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eAccountability Information (CM-8(4))\u003c/h4\u003e\u003cp\u003eInformation system components are accounted for in the CMS inventory.\u0026nbsp; This listing has accountability information attached to it that may be referenced when a component is compromised. The information contains the role(s) or individual(s) responsible and/or accountable for the information system components.\u003c/p\u003e\u003cp\u003eThe information listed about CMS system components is designed as a reference for security personnel.\u0026nbsp; The accountability information is used when, for example, the component needs to be replaced, is the source of a breach or a compromise, or needs to be relocated.\u0026nbsp; A control for accountability information provides CMS with the contact information needed during incident response and times of change. The risk associated with those situations is assigned appropriately to the responsible person who can delegate the associated work.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for accountability information.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-8(4)\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by [Selection (one or more): name; position; role], individuals responsible/accountable for administering those components.\u003c/td\u003e\u003ctd\u003eThe organization includes in the information system component inventory information, a means for identifying by the System Developer/Maintainer or the Business Owner, \u0026nbsp;\u0026nbsp;the individuals responsible/accountable for administering those components.\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following process, ensured is completed by the Business Owner, details the CMS procedure for keeping accountability information:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;The ISSO develops methods to identify the individual(s), to include position and role, responsible and accountable for administering information system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO documents and maintains the information of individual(s) responsible for administering the information system components.\u003c/li\u003e\u003c/ul\u003e\u003ch4\u003eNo Duplicate Accounting of Components (CM-8(5))\u003c/h4\u003e\u003cp\u003eThis control is used in CMS to ensure components are not duplicated in inventories.\u0026nbsp; The inventory that lists all components shall not have more than one of the same instance of a component.\u003c/p\u003e\u003cp\u003eCMS avoids duplicate accounting in inventory systems because it creates a source of confusion for responsibility and remediation.\u0026nbsp; Systems can be large and complex, involving many different components that interact with each other as well as other interconnected systems.\u0026nbsp; Assigning a component to a single system inventory streamlines accounting and reduces the time and effort to discern applicable parties responsible for that component. It also leads to straightforward remediation of vulnerabilities when discovered since the component is linked to a single system.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for verifying that the accounting for information system components are not duplicated:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The ISSO documents the system components inside of CFACTS using the Authorization Package for the system inside of the\u0026nbsp;\u003cem\u003e“Boundary”\u003c/em\u003e\u0026nbsp;tab under the\u003cem\u003e\u0026nbsp;“Hardware”\u003c/em\u003e\u0026nbsp;and\u0026nbsp;\u003cem\u003e“Software”\u0026nbsp;\u003c/em\u003esections.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The ISSO sorts hardware and then software by unique attributes to check if all components have different unique attributes from one another whenever entering in new system components.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;If there is no duplication of component attributes then no further action is needed. If the ISSO identifies a duplication of unique attributes for a component then proceed to the next step.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;The ISSO removes the duplicate component attribute from the system.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eConfiguration Management Plan (CM-9)\u003c/h3\u003e\u003cp\u003eThe CMS-SDLC incorporates a configuration management plan into the planning process. The plan is designed to document the process and procedures for configuration management.\u0026nbsp; The plan shall cover certain areas in order to fulfill this security control.\u0026nbsp; Listed in the document are roles of stakeholders, their responsibilities, processes and procedures.\u0026nbsp; The document shall also outline current configuration items.\u0026nbsp; Specifically, one of the processes covered shall be how to identify a configuration item.\u0026nbsp; The plan shall be protected, after it is finalized, from modification or unauthorized disclosure as are the configuration baselines.\u003c/p\u003e\u003cp\u003eConfiguration management plans define people, processes and procedures.\u0026nbsp; The plans establish the technical and administrative direction and surveillance for the management of configuration items.\u0026nbsp; CMS uses this plan to separate responsibility and add traceability to protect the integrity of systems.\u0026nbsp; Changes are documented and explicitly approved or rejected, so there is accountability regarding the approver, and changes that were made on the system without approval.\u0026nbsp; Implementing the plan properly helps CMS pinpoint issues related to changes, leading to quicker resolutions and rollbacks to repair them.\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for developing, documenting and implementing a configuration management plan:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp; The CMS Program/Project Manager completes a configuration management plan.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The Program/Project Manager documents roles and responsibilities for the plan in a\u003cem\u003e\u0026nbsp;\u003c/em\u003eRoles \u0026amp; Responsibilities section.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager defines the processes and procedures involved with configuration management. Configuration Management Administration and Methods and Tools sections should be included.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager lists CIs for the information system in a System Design Document.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u0026nbsp;\u003c/strong\u003eThe Program/Project Manager protects the document from unauthorized disclosure or modification by using access control methods for storage locations to restrict access to authorized personnel only.\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eSoftware Usage Restrictions (CM-10)\u003c/h3\u003e\u003cp\u003eCMS will establish and enforce procedures for identifying and removing inappropriate software.\u0026nbsp; Contractors and Government employees are expected to use software and associated documentation according to applicable law and contractual agreements.\u0026nbsp; CMS is responsible for the prevention, monitoring, and removal of unauthorized software.\u0026nbsp; Installed software and documentation will be monitored as needed to determine if its use is allowed by the license or contract. Additionally, peer-to-peer file sharing technology is not expected to be used except as approved by the CIO, but such traffic will be inspected to determine if sensitive or protected content was being shared.\u003c/p\u003e\u003cp\u003eSoftware usage restriction assists in safeguarding against the sharing of copyrighted material and/or the use of software in a manner that would violate CMS agreements. \u0026nbsp;CMS tracks the use of software and associated documentation protected by quantity licenses to control copying and distribution.\u0026nbsp; CMS also controls and documents the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.\u0026nbsp; This reduces CMS liability by preventing potential copyright violations. \u0026nbsp;\u003c/p\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-10 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep 1:\u003c/strong\u003e\u0026nbsp;System/Network Administrator ensures that the software has been previously tested according to the CMS testing procedure found here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/software/testing.html\u003c/a\u003e. A list of previously tested software is available here:\u0026nbsp;\u003ca href=\"http://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\"\u003ehttp://intranet.cms.gov/Component/OIS/Desktop-Voice-and-Video/support/Documents/Tested-Software-List.pdf\u003c/a\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator reviews the installation request for the software proof of purchase, unless it was custom developed in-house, which includes:\u003cul\u003e\u003cli\u003eApproved purchase record\u003c/li\u003e\u003cli\u003eCertified receipt or invoice\u003c/li\u003e\u003cli\u003eValidated HHS Form 393 (Purchase/Service/Stock Requisition Form)\u003c/li\u003e\u003cli\u003eCMS credit card invoice\u003c/li\u003e\u003cli\u003eVendor proof of license purchase certificate\u003c/li\u003e\u003cli\u003eVendor end-user authorization form for volume licensing\u003c/li\u003e\u003cli\u003eVendor-provided notice of software purchase\u003c/li\u003e\u003cli\u003eEnd-user license agreement\u003c/li\u003e\u003cli\u003eEnterprise Software Licensing\u003c/li\u003e\u003c/ul\u003e\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u003c/strong\u003e\u0026nbsp;The System/Network Administrator installs the software and documents that the instance of software and license are used for the information system so that the total number of licenses, the proof of license and installations are denoted.\u0026nbsp; The documentation is used by the System/Network Administrator to prevent copying per the\u0026nbsp;\u003cem\u003eCMS Policy for Acceptable Use of CMS Desktop/Laptop and Other IT Resources\u003c/em\u003e\u0026nbsp;section 4.1 and/or violating license agreements.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u003c/strong\u003e\u0026nbsp;CMS ISSO and respective component support staff from ISPG CDM performs routine scans of CMS networks to compare the current approved users and their installed software to the list of approved CMS “Core” and “Above Core” software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;CMS ISSO communicates, via e-mail, a list of approved users to the component support staff Asset Management Team that do not comply with CMS Software Policy.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;CMS Asset Management Team notifies, via e-mail, those users and their managers that were identified as having unauthorized software on their information systems, and provide a date to remove the software or their respective access will be revoked.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;Users that are notified of unauthorized software on their information system, must remove the inappropriate software within twenty-four (24) hours after completion of a Service Request (SR). In the event an exception is needed based on job role and function, an SR is submitted to the ISSO with appropriate justification for further 508 compliance testing and approval.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003ch3\u003eUser-Installed Software (CM-11)\u003c/h3\u003e\u003cp\u003eAllowing CMS personnel to install software on agency information systems and system resources exposes the organization to unnecessary risk. \u0026nbsp;GFEs will be configured to prevent installation of software when unprivileged users attempt it.\u0026nbsp; Privileged users will be allowed to install software by following established procedures.\u0026nbsp; The proper methods should be outlined within the SSPP of the information system under the control allocation for CM-11 – Shared Implementation Details.\u0026nbsp; Users of the information system will have to follow the policy as stated in the SSPP.\u0026nbsp; CMS will take action at least once per month after implementation to monitor adherence to the policy.\u0026nbsp;\u003c/p\u003e\u003cp\u003eCMS wants to mitigate potential problems that may arise when users install programs.\u0026nbsp; Some examples of problems that can be introduced are using two different versions of the same software that can cause system conflicts, introducing malware, and installing unlicensed software that could be discovered during audit or unauthorized programs that could be used to gather information from CMS’s network.\u0026nbsp; This control is designed to protect network resources from unauthorized actions from software by restricting the number of people who have the ability to install it.\u0026nbsp; This will minimize the risk of losing functionality in programs, damaging CMS infrastructure from malicious programs, harming CMS’s reputation through sensitive data loss, or exposing CMS to liability from unlicensed software. \u0026nbsp;Monitoring the system for these installations allows us to adhere to information security continuous monitoring (ISCM) requirements as per the CMS IS2P2 section 4.1.2 Risk Management Framework.\u003c/p\u003e\u003cp\u003eThe table below outlines the CMS organizationally defined parameters for user-installed software.\u003c/p\u003e\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003e\u003cstrong\u003eControl\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eControl Requirement\u003c/strong\u003e\u003c/th\u003e\u003cth\u003e\u003cstrong\u003eCMS Parameter\u003c/strong\u003e\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eCM-11\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Establishes [Assignment: organization-defined policies] governing the installation of software by users;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through [Assignment: organization-defined methods]; and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at [Assignment: organization-defined frequency].\u003c/p\u003e\u003c/td\u003e\u003ctd\u003e\u003cp\u003eThe organization:\u003c/p\u003e\u003cp\u003ea. Prohibits the installation of software by users on all GFE;\u003c/p\u003e\u003cp\u003eb. Enforces software installation policies through organization-defined methods (defined in the SSPP); and\u003c/p\u003e\u003cp\u003ec. Monitors policy compliance at least monthly.\u003c/p\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\u003cp\u003eThe following steps detail the CMS specific process for the implementation of the CM-11 control and/or requirement:\u003c/p\u003e\u003cul\u003e\u003cli\u003e\u003cstrong\u003eStep\u0026nbsp;1:\u0026nbsp;\u003c/strong\u003eCMS image management team installs privilege management software on all GFE configuration baselines to prevent the installation of software by users in accordance with software installation rules.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 2:\u003c/strong\u003e\u0026nbsp;For GFEs, the Deskside Support Team configures them to restrict the permissions of users and prevent user-initiated installations. For all other CMS equipment, the business owner and the ISSO is responsible for restricting the permissions of users and preventing user-initiated installations.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 3:\u0026nbsp;\u003c/strong\u003eFor GFEs, the Deskside Support Team configures it with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevents all other user installations of software. For all other CMS equipment, the business owner and the ISSO is responsible for configuring the equipment with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 4:\u0026nbsp;\u003c/strong\u003eThe System Developer and Maintainer configures the system with methods and data gathering mechanisms that collect information at least once per month about the installed software that confirms its authorized use. It must be compliant with CDM.\u0026nbsp;\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 5:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures the methods and data gathering mechanisms from Step 4 to comply with CDM.\u003c/li\u003e\u003cli\u003e\u003cstrong\u003eStep 6:\u003c/strong\u003e\u0026nbsp;The System Developer and Maintainer configures systems with the security category of High to accept installation of a list of applications (i.e. a Allowlist) and prevent all other user installations of software.\u003c/li\u003e\u003c/ul\u003e"])</script><script>self.__next_f.push([1,"1c9:{\"value\":\"$1ca\",\"format\":\"body_text\",\"processed\":\"$1cb\",\"summary\":\"\"}\n1ce:[]\n1cd:{\"uri\":\"entity:node/631\",\"title\":\"CMS Acceptable Risk Safeguards (ARS) \",\"options\":\"$1ce\",\"url\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"}\n1d0:[]\n1cf:{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":\"$1d0\",\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"}\n1d2:[]\n1d1:{\"uri\":\"entity:node/681\",\"title\":\"CMS Security and Privacy Handbooks (all)\",\"options\":\"$1d2\",\"url\":\"/learn/cms-security-and-privacy-handbooks\"}\n1cc:[\"$1cd\",\"$1cf\",\"$1d1\"]\n1d3:{\"value\":\"RMH Chapter 5 provides information about the Configuration Management family of controls which determine the risk management requirements for CMS systems\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eRMH Chapter 5 provides information about the Configuration Management family of controls which determine the risk management requirements for CMS systems\u003c/p\u003e\\n\"}\n1c7:{\"drupal_internal__nid\":461,\"drupal_internal__vid\":5778,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-05T16:04:35+00:00\",\"status\":true,\"title\":\"Risk Management Handbook Chapter 5: Configuration Management (CM)\",\"created\":\"2022-08-29T17:45:27+00:00\",\"changed\":\"2024-08-05T16:04:35+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":\"$1c8\",\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":\"$1c9\",\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2021-03-23\",\"field_related_resources\":\"$1cc\",\"field_short_description\":\"$1d3\"}\n1d7:{\"drupal_internal__target_id\":\"library\"}\n1d6:{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":\"$1d7\"}\n1d9:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/node_type?resourceVersion=id%3A5778\"}\n1da:{\"href\":\"https://c"])</script><script>self.__next_f.push([1,"ybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/node_type?resourceVersion=id%3A5778\"}\n1d8:{\"related\":\"$1d9\",\"self\":\"$1da\"}\n1d5:{\"data\":\"$1d6\",\"links\":\"$1d8\"}\n1dd:{\"drupal_internal__target_id\":159}\n1dc:{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"meta\":\"$1dd\"}\n1df:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/revision_uid?resourceVersion=id%3A5778\"}\n1e0:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/revision_uid?resourceVersion=id%3A5778\"}\n1de:{\"related\":\"$1df\",\"self\":\"$1e0\"}\n1db:{\"data\":\"$1dc\",\"links\":\"$1de\"}\n1e3:{\"drupal_internal__target_id\":26}\n1e2:{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":\"$1e3\"}\n1e5:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/uid?resourceVersion=id%3A5778\"}\n1e6:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/uid?resourceVersion=id%3A5778\"}\n1e4:{\"related\":\"$1e5\",\"self\":\"$1e6\"}\n1e1:{\"data\":\"$1e2\",\"links\":\"$1e4\"}\n1e9:{\"drupal_internal__target_id\":91}\n1e8:{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":\"$1e9\"}\n1eb:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/field_resource_type?resourceVersion=id%3A5778\"}\n1ec:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/field_resource_type?resourceVersion=id%3A5778\"}\n1ea:{\"related\":\"$1eb\",\"self\":\"$1ec\"}\n1e7:{\"data\":\"$1e8\",\"links\":\"$1ea\"}\n1f0:{\"drupal_internal__target_id\":66}\n1ef:{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":\"$1f0\"}\n1f2:{\"drupal_internal__target_id\":81}\n1f1:{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":\"$1f2\"}\n1f4:{\"drupal_internal__target_id\":61}\n1f3:{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\""])</script><script>self.__next_f.push([1,"meta\":\"$1f4\"}\n1f6:{\"drupal_internal__target_id\":76}\n1f5:{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":\"$1f6\"}\n1f8:{\"drupal_internal__target_id\":71}\n1f7:{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":\"$1f8\"}\n1ee:[\"$1ef\",\"$1f1\",\"$1f3\",\"$1f5\",\"$1f7\"]\n1fa:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/field_roles?resourceVersion=id%3A5778\"}\n1fb:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/field_roles?resourceVersion=id%3A5778\"}\n1f9:{\"related\":\"$1fa\",\"self\":\"$1fb\"}\n1ed:{\"data\":\"$1ee\",\"links\":\"$1f9\"}\n1ff:{\"drupal_internal__target_id\":16}\n1fe:{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":\"$1ff\"}\n201:{\"drupal_internal__target_id\":36}\n200:{\"type\":\"taxonomy_term--topics\",\"id\":\"65ef6410-4066-4db4-be03-c8eb26b63305\",\"meta\":\"$201\"}\n1fd:[\"$1fe\",\"$200\"]\n203:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/field_topics?resourceVersion=id%3A5778\"}\n204:{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/field_topics?resourceVersion=id%3A5778\"}\n202:{\"related\":\"$203\",\"self\":\"$204\"}\n1fc:{\"data\":\"$1fd\",\"links\":\"$202\"}\n1d4:{\"node_type\":\"$1d5\",\"revision_uid\":\"$1db\",\"uid\":\"$1e1\",\"field_resource_type\":\"$1e7\",\"field_roles\":\"$1ed\",\"field_topics\":\"$1fc\"}\n1c4:{\"type\":\"node--library\",\"id\":\"0dee405f-3bb7-4a8a-b602-b5de9697cfdf\",\"links\":\"$1c5\",\"attributes\":\"$1c7\",\"relationships\":\"$1d4\"}\n"])</script><script>self.__next_f.push([1,"5:[\"$\",\"$L17\",null,{\"content\":{\"data\":{\"type\":\"node--explainer\",\"id\":\"d664afd5-7779-4776-ad7a-998fa5a85fe7\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7?resourceVersion=id%3A5749\"}},\"attributes\":{\"drupal_internal__nid\":731,\"drupal_internal__vid\":5749,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-05T15:51:17+00:00\",\"status\":true,\"title\":\"Security Impact Analysis (SIA)\",\"created\":\"2023-02-13T18:15:37+00:00\",\"changed\":\"2024-08-05T15:51:17+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/learn/security-impact-analysis-sia\",\"pid\":721,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":null,\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_short_description\":{\"value\":\"A process to determine the effect(s) a change can cause to the security posture of a FISMA system\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eA process to determine the effect(s) a change can cause to the security posture of a FISMA system\u003c/p\u003e\\n\"},\"field_slack_channel\":[\"#security_community\"]},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"meta\":{\"drupal_internal__target_id\":\"explainer\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/node_type?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/node_type?resourceVersion=id%3A5749\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"meta\":{\"drupal_internal__target_id\":159}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/revision_uid?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/revision_uid?resourceVersion=id%3A5749\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/uid?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/uid?resourceVersion=id%3A5749\"}}},\"field_page_section\":{\"data\":[{\"type\":\"paragraph--page_section\",\"id\":\"21c13746-6570-4f61-8745-b5520d53b5d7\",\"meta\":{\"target_revision_id\":19022,\"drupal_internal__target_id\":1351}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/field_page_section?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/field_page_section?resourceVersion=id%3A5749\"}}},\"field_related_collection\":{\"data\":[{\"type\":\"paragraph--internal_link\",\"id\":\"319e7227-1f2a-4cdd-92a1-c4ef2593477a\",\"meta\":{\"target_revision_id\":19023,\"drupal_internal__target_id\":1686}},{\"type\":\"paragraph--internal_link\",\"id\":\"1d1a8e48-f873-4c95-93aa-6243a892d004\",\"meta\":{\"target_revision_id\":19024,\"drupal_internal__target_id\":1691}},{\"type\":\"paragraph--internal_link\",\"id\":\"9770a81c-b300-49e0-b938-d6fa266ffb23\",\"meta\":{\"target_revision_id\":19025,\"drupal_internal__target_id\":1696}},{\"type\":\"paragraph--internal_link\",\"id\":\"5cedd0e5-92bf-4900-9591-37f8c9011427\",\"meta\":{\"target_revision_id\":19026,\"drupal_internal__target_id\":2576}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/field_related_collection?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/field_related_collection?resourceVersion=id%3A5749\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"meta\":{\"drupal_internal__target_id\":131}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/field_resource_type?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/field_resource_type?resourceVersion=id%3A5749\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":{\"drupal_internal__target_id\":71}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/field_roles?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/field_roles?resourceVersion=id%3A5749\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"7917cea4-02d7-4ebd-93a3-4c39d5f24674\",\"meta\":{\"drupal_internal__target_id\":6}},{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"meta\":{\"drupal_internal__target_id\":11}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/field_topics?resourceVersion=id%3A5749\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/d664afd5-7779-4776-ad7a-998fa5a85fe7/relationships/field_topics?resourceVersion=id%3A5749\"}}}}},\"included\":[{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node_type/node_type/d185e460-4998-4d2b-85cb-b04f304dfb1b\"}},\"attributes\":{\"langcode\":\"en\",\"status\":true,\"dependencies\":{\"module\":[\"menu_ui\",\"scheduler\"]},\"third_party_settings\":{\"menu_ui\":{\"available_menus\":[],\"parent\":\"\"},\"scheduler\":{\"expand_fieldset\":\"when_required\",\"fields_display_mode\":\"vertical_tab\",\"publish_enable\":false,\"publish_past_date\":\"error\",\"publish_past_date_created\":false,\"publish_required\":false,\"publish_revision\":false,\"publish_touch\":false,\"show_message_after_update\":true,\"unpublish_enable\":false,\"unpublish_required\":false,\"unpublish_revision\":false}},\"name\":\"Explainer page\",\"drupal_internal__type\":\"explainer\",\"description\":\"Use \u003ci\u003eExplainer pages\u003c/i\u003e to provide general information in plain language about a policy, program, tool, service, or task related to security and privacy at CMS.\",\"help\":null,\"new_revision\":true,\"preview_mode\":1,\"display_submitted\":true}},{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/user/user/4420e728-6dc2-4022-bf8d-5bd1329e5e64\"}},\"attributes\":{\"display_name\":\"jcallan - retired\"}},{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/user/user/e352e203-fe9c-47ba-af75-2c7f8302fca8\"}},\"attributes\":{\"display_name\":\"mburgess\"}},{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22?resourceVersion=id%3A131\"}},\"attributes\":{\"drupal_internal__tid\":131,\"drupal_internal__revision_id\":131,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:13:33+00:00\",\"status\":true,\"name\":\"General Information\",\"description\":null,\"weight\":2,\"changed\":\"2023-03-10T19:04:03+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"3a0127c4-ee06-41ed-8239-f796f6d78eb3\",\"meta\":{\"drupal_internal__target_id\":\"resource_type\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/vid?resourceVersion=id%3A131\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/vid?resourceVersion=id%3A131\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/revision_user?resourceVersion=id%3A131\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/revision_user?resourceVersion=id%3A131\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--resource_type\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/parent?resourceVersion=id%3A131\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/resource_type/a17f4908-9141-4b1e-82aa-e6bfe0f91a22/relationships/parent?resourceVersion=id%3A131\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab?resourceVersion=id%3A61\"}},\"attributes\":{\"drupal_internal__tid\":61,\"drupal_internal__revision_id\":61,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:12+00:00\",\"status\":true,\"name\":\"Information System Security Officer (ISSO)\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:12+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/vid?resourceVersion=id%3A61\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/vid?resourceVersion=id%3A61\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/revision_user?resourceVersion=id%3A61\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/revision_user?resourceVersion=id%3A61\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/parent?resourceVersion=id%3A61\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/7a18463d-b0fc-474f-8536-ad7db1b2e5ab/relationships/parent?resourceVersion=id%3A61\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34?resourceVersion=id%3A76\"}},\"attributes\":{\"drupal_internal__tid\":76,\"drupal_internal__revision_id\":76,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:55+00:00\",\"status\":true,\"name\":\"System / Business Owner\",\"description\":null,\"weight\":0,\"changed\":\"2022-08-02T23:08:55+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/vid?resourceVersion=id%3A76\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/vid?resourceVersion=id%3A76\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/revision_user?resourceVersion=id%3A76\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/revision_user?resourceVersion=id%3A76\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/parent?resourceVersion=id%3A76\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/f591f442-c0b0-4b8e-af66-7998a3329f34/relationships/parent?resourceVersion=id%3A76\"}}}}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e?resourceVersion=id%3A71\"}},\"attributes\":{\"drupal_internal__tid\":71,\"drupal_internal__revision_id\":71,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:08:42+00:00\",\"status\":true,\"name\":\"System Teams\",\"description\":null,\"weight\":0,\"changed\":\"2024-08-02T21:29:47+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"a89af840-d1f0-4a08-9f15-7b1cb71c3e35\",\"meta\":{\"drupal_internal__target_id\":\"roles\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/vid?resourceVersion=id%3A71\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/vid?resourceVersion=id%3A71\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/revision_user?resourceVersion=id%3A71\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/revision_user?resourceVersion=id%3A71\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/parent?resourceVersion=id%3A71\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/roles/feb4e85d-429e-48b0-92f0-3d2da2c5056e/relationships/parent?resourceVersion=id%3A71\"}}}}},{\"type\":\"taxonomy_term--topics\",\"id\":\"7917cea4-02d7-4ebd-93a3-4c39d5f24674\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674?resourceVersion=id%3A6\"}},\"attributes\":{\"drupal_internal__tid\":6,\"drupal_internal__revision_id\":6,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:04:59+00:00\",\"status\":true,\"name\":\"Assessments \u0026 Audits\",\"description\":null,\"weight\":1,\"changed\":\"2023-03-10T19:04:22+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"73f89dec-123f-4c8c-9a97-d025a2b0e5cf\",\"meta\":{\"drupal_internal__target_id\":\"topics\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/vid?resourceVersion=id%3A6\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/relationships/vid?resourceVersion=id%3A6\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/revision_user?resourceVersion=id%3A6\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/relationships/revision_user?resourceVersion=id%3A6\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/parent?resourceVersion=id%3A6\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/7917cea4-02d7-4ebd-93a3-4c39d5f24674/relationships/parent?resourceVersion=id%3A6\"}}}}},{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e?resourceVersion=id%3A11\"}},\"attributes\":{\"drupal_internal__tid\":11,\"drupal_internal__revision_id\":11,\"langcode\":\"en\",\"revision_created\":\"2022-08-02T23:05:12+00:00\",\"status\":true,\"name\":\"System Authorization\",\"description\":null,\"weight\":7,\"changed\":\"2023-03-10T19:04:22+00:00\",\"default_langcode\":true,\"revision_translation_affected\":true,\"path\":{\"alias\":null,\"pid\":null,\"langcode\":\"en\"}},\"relationships\":{\"vid\":{\"data\":{\"type\":\"taxonomy_vocabulary--taxonomy_vocabulary\",\"id\":\"73f89dec-123f-4c8c-9a97-d025a2b0e5cf\",\"meta\":{\"drupal_internal__target_id\":\"topics\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/vid?resourceVersion=id%3A11\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/relationships/vid?resourceVersion=id%3A11\"}}},\"revision_user\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/revision_user?resourceVersion=id%3A11\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/relationships/revision_user?resourceVersion=id%3A11\"}}},\"parent\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"virtual\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#virtual\",\"meta\":{\"about\":\"Usage and meaning of the 'virtual' resource identifier.\"}}}}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/parent?resourceVersion=id%3A11\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/taxonomy_term/topics/0bc7c1d0-b569-4514-b66c-367457dead7e/relationships/parent?resourceVersion=id%3A11\"}}}}},{\"type\":\"paragraph--page_section\",\"id\":\"21c13746-6570-4f61-8745-b5520d53b5d7\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7?resourceVersion=id%3A19022\"}},\"attributes\":{\"drupal_internal__id\":1351,\"drupal_internal__revision_id\":19022,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-13T18:18:53+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_page_section\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true,\"field_text_block\":{\"value\":\"$18\",\"format\":\"body_text\",\"processed\":\"$19\"}},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"57f3f40a-8120-4393-b881-a5758f9fb30d\",\"meta\":{\"drupal_internal__target_id\":\"page_section\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/paragraph_type?resourceVersion=id%3A19022\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/relationships/paragraph_type?resourceVersion=id%3A19022\"}}},\"field_specialty_item\":{\"data\":null,\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/field_specialty_item?resourceVersion=id%3A19022\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/page_section/21c13746-6570-4f61-8745-b5520d53b5d7/relationships/field_specialty_item?resourceVersion=id%3A19022\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"319e7227-1f2a-4cdd-92a1-c4ef2593477a\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a?resourceVersion=id%3A19023\"}},\"attributes\":{\"drupal_internal__id\":1686,\"drupal_internal__revision_id\":19023,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-14T16:38:17+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/paragraph_type?resourceVersion=id%3A19023\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/relationships/paragraph_type?resourceVersion=id%3A19023\"}}},\"field_link\":{\"data\":{\"type\":\"node--explainer\",\"id\":\"a279358b-5b24-49bc-a98e-11681bd7e65c\",\"meta\":{\"drupal_internal__target_id\":326}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/field_link?resourceVersion=id%3A19023\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/319e7227-1f2a-4cdd-92a1-c4ef2593477a/relationships/field_link?resourceVersion=id%3A19023\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"1d1a8e48-f873-4c95-93aa-6243a892d004\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004?resourceVersion=id%3A19024\"}},\"attributes\":{\"drupal_internal__id\":1691,\"drupal_internal__revision_id\":19024,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-14T16:38:30+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/paragraph_type?resourceVersion=id%3A19024\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/relationships/paragraph_type?resourceVersion=id%3A19024\"}}},\"field_link\":{\"data\":{\"type\":\"node--explainer\",\"id\":\"defa7277-790b-4bbd-b6ee-cc539e121df2\",\"meta\":{\"drupal_internal__target_id\":206}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/field_link?resourceVersion=id%3A19024\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/1d1a8e48-f873-4c95-93aa-6243a892d004/relationships/field_link?resourceVersion=id%3A19024\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"9770a81c-b300-49e0-b938-d6fa266ffb23\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23?resourceVersion=id%3A19025\"}},\"attributes\":{\"drupal_internal__id\":1696,\"drupal_internal__revision_id\":19025,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-02-14T16:38:36+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/paragraph_type?resourceVersion=id%3A19025\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/relationships/paragraph_type?resourceVersion=id%3A19025\"}}},\"field_link\":{\"data\":{\"type\":\"node--library\",\"id\":\"0dee405f-3bb7-4a8a-b602-b5de9697cfdf\",\"meta\":{\"drupal_internal__target_id\":461}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/field_link?resourceVersion=id%3A19025\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/9770a81c-b300-49e0-b938-d6fa266ffb23/relationships/field_link?resourceVersion=id%3A19025\"}}}}},{\"type\":\"paragraph--internal_link\",\"id\":\"5cedd0e5-92bf-4900-9591-37f8c9011427\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427?resourceVersion=id%3A19026\"}},\"attributes\":{\"drupal_internal__id\":2576,\"drupal_internal__revision_id\":19026,\"langcode\":\"en\",\"status\":true,\"created\":\"2023-03-14T14:54:50+00:00\",\"parent_id\":\"731\",\"parent_type\":\"node\",\"parent_field_name\":\"field_related_collection\",\"behavior_settings\":[],\"default_langcode\":true,\"revision_translation_affected\":true},\"relationships\":{\"paragraph_type\":{\"data\":{\"type\":\"paragraphs_type--paragraphs_type\",\"id\":\"81d4313f-807c-40e2-8ffa-700ec8c17167\",\"meta\":{\"drupal_internal__target_id\":\"internal_link\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/paragraph_type?resourceVersion=id%3A19026\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/relationships/paragraph_type?resourceVersion=id%3A19026\"}}},\"field_link\":{\"data\":{\"type\":\"unknown\",\"id\":\"missing\",\"meta\":{\"links\":{\"help\":{\"href\":\"https://www.drupal.org/docs/8/modules/json-api/core-concepts#missing\",\"meta\":{\"about\":\"Usage and meaning of the 'missing' resource identifier.\"}}}}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/field_link?resourceVersion=id%3A19026\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/paragraph/internal_link/5cedd0e5-92bf-4900-9591-37f8c9011427/relationships/field_link?resourceVersion=id%3A19026\"}}}}},{\"type\":\"node--explainer\",\"id\":\"a279358b-5b24-49bc-a98e-11681bd7e65c\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c?resourceVersion=id%3A5942\"}},\"attributes\":{\"drupal_internal__nid\":326,\"drupal_internal__vid\":5942,\"langcode\":\"en\",\"revision_timestamp\":\"2024-10-17T14:55:23+00:00\",\"status\":true,\"title\":\"Federal Risk and Authorization Management Program (FedRAMP)\",\"created\":\"2022-08-29T15:22:00+00:00\",\"changed\":\"2024-10-17T14:55:23+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/learn/fedramp\",\"pid\":316,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":null,\"field_contact_email\":\"FedRAMP@cms.hhs.gov\",\"field_contact_name\":\"CMS FedRAMP PMO\",\"field_short_description\":{\"value\":\"Provides a federally-recognized and standardized security framework for all cloud products and services\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eProvides a federally-recognized and standardized security framework for all cloud products and services\u003c/p\u003e\\n\"},\"field_slack_channel\":[\"#fedramp\"]},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"meta\":{\"drupal_internal__target_id\":\"explainer\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/node_type?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/node_type?resourceVersion=id%3A5942\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"d3421e1d-1fda-4bd0-83ab-e404455b0e66\",\"meta\":{\"drupal_internal__target_id\":114}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/revision_uid?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/revision_uid?resourceVersion=id%3A5942\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/uid?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/uid?resourceVersion=id%3A5942\"}}},\"field_page_section\":{\"data\":[{\"type\":\"paragraph--page_section\",\"id\":\"2ce39e48-81e4-4bea-a0ff-04f25ddd0041\",\"meta\":{\"target_revision_id\":19451,\"drupal_internal__target_id\":1171}},{\"type\":\"paragraph--page_section\",\"id\":\"77ea2e89-2433-4815-b869-52b2d900029e\",\"meta\":{\"target_revision_id\":19452,\"drupal_internal__target_id\":1211}},{\"type\":\"paragraph--page_section\",\"id\":\"deedf0fe-44e9-4015-90a1-f86ce6cbaf24\",\"meta\":{\"target_revision_id\":19462,\"drupal_internal__target_id\":3431}},{\"type\":\"paragraph--page_section\",\"id\":\"2b2216d8-24c3-4940-930f-6e79f68a279a\",\"meta\":{\"target_revision_id\":19472,\"drupal_internal__target_id\":1261}},{\"type\":\"paragraph--page_section\",\"id\":\"cbda5c42-489d-4480-85f5-db10db44de3e\",\"meta\":{\"target_revision_id\":19474,\"drupal_internal__target_id\":1266}},{\"type\":\"paragraph--page_section\",\"id\":\"37970dd4-a515-4370-a09f-f5177c2f98c2\",\"meta\":{\"target_revision_id\":19475,\"drupal_internal__target_id\":3433}},{\"type\":\"paragraph--page_section\",\"id\":\"434b1960-73e8-43fa-9b9e-253ce35fa55a\",\"meta\":{\"target_revision_id\":19476,\"drupal_internal__target_id\":3434}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_page_section?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_page_section?resourceVersion=id%3A5942\"}}},\"field_related_collection\":{\"data\":[{\"type\":\"paragraph--internal_link\",\"id\":\"7a5f06f0-e0ba-4ed2-aade-79b2233ec125\",\"meta\":{\"target_revision_id\":19477,\"drupal_internal__target_id\":1956}},{\"type\":\"paragraph--internal_link\",\"id\":\"61509c21-9c9e-48d0-8110-b98574cee727\",\"meta\":{\"target_revision_id\":19478,\"drupal_internal__target_id\":1961}},{\"type\":\"paragraph--internal_link\",\"id\":\"c2480fc7-b7c3-49d4-8643-cd42bcd3b56b\",\"meta\":{\"target_revision_id\":19479,\"drupal_internal__target_id\":1966}},{\"type\":\"paragraph--internal_link\",\"id\":\"63dffb2c-c587-4991-8523-142b2378a5aa\",\"meta\":{\"target_revision_id\":19480,\"drupal_internal__target_id\":3435}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_related_collection?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_related_collection?resourceVersion=id%3A5942\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"meta\":{\"drupal_internal__target_id\":131}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_resource_type?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_resource_type?resourceVersion=id%3A5942\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_roles?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_roles?resourceVersion=id%3A5942\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"b61c7b1f-0882-4fac-bf13-02c68b56fd38\",\"meta\":{\"drupal_internal__target_id\":21}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/field_topics?resourceVersion=id%3A5942\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/a279358b-5b24-49bc-a98e-11681bd7e65c/relationships/field_topics?resourceVersion=id%3A5942\"}}}}},{\"type\":\"node--explainer\",\"id\":\"defa7277-790b-4bbd-b6ee-cc539e121df2\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2?resourceVersion=id%3A5737\"}},\"attributes\":{\"drupal_internal__nid\":206,\"drupal_internal__vid\":5737,\"langcode\":\"en\",\"revision_timestamp\":\"2024-07-31T17:37:48+00:00\",\"status\":true,\"title\":\"Authorization to Operate (ATO)\",\"created\":\"2022-08-25T19:06:37+00:00\",\"changed\":\"2024-07-31T17:37:48+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/learn/authorization-operate-ato\",\"pid\":196,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":null,\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_short_description\":{\"value\":\"Testing and documenting system security and compliance to gain approval to operate the system at CMS\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eTesting and documenting system security and compliance to gain approval to operate the system at CMS\u003c/p\u003e\\n\"},\"field_slack_channel\":[\"#cra-help\"]},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"d185e460-4998-4d2b-85cb-b04f304dfb1b\",\"meta\":{\"drupal_internal__target_id\":\"explainer\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/node_type?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/node_type?resourceVersion=id%3A5737\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"e352e203-fe9c-47ba-af75-2c7f8302fca8\",\"meta\":{\"drupal_internal__target_id\":6}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/revision_uid?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/revision_uid?resourceVersion=id%3A5737\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/uid?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/uid?resourceVersion=id%3A5737\"}}},\"field_page_section\":{\"data\":[{\"type\":\"paragraph--page_section\",\"id\":\"d94629f9-9668-41dd-bce7-a4f267239c07\",\"meta\":{\"target_revision_id\":18928,\"drupal_internal__target_id\":711}},{\"type\":\"paragraph--page_section\",\"id\":\"243e2d3f-f903-438c-8b1f-aee53390b1df\",\"meta\":{\"target_revision_id\":18929,\"drupal_internal__target_id\":736}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_page_section?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_page_section?resourceVersion=id%3A5737\"}}},\"field_related_collection\":{\"data\":[{\"type\":\"paragraph--internal_link\",\"id\":\"6f904ac4-c80e-47d9-b786-ee79256befed\",\"meta\":{\"target_revision_id\":18930,\"drupal_internal__target_id\":3376}},{\"type\":\"paragraph--internal_link\",\"id\":\"e20959d7-2a7b-4a01-b985-cfa5363233f5\",\"meta\":{\"target_revision_id\":18931,\"drupal_internal__target_id\":1306}},{\"type\":\"paragraph--internal_link\",\"id\":\"dba9b926-f657-43ce-bc94-0a2d803430c6\",\"meta\":{\"target_revision_id\":18932,\"drupal_internal__target_id\":1316}},{\"type\":\"paragraph--internal_link\",\"id\":\"44f7083e-9341-42a5-85dc-a9043cdccdce\",\"meta\":{\"target_revision_id\":18933,\"drupal_internal__target_id\":2521}},{\"type\":\"paragraph--internal_link\",\"id\":\"bd0366d9-64ce-401f-9453-bf38aa8054a1\",\"meta\":{\"target_revision_id\":18934,\"drupal_internal__target_id\":3444}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_related_collection?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_related_collection?resourceVersion=id%3A5737\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\",\"meta\":{\"drupal_internal__target_id\":131}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_resource_type?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_resource_type?resourceVersion=id%3A5737\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_roles?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_roles?resourceVersion=id%3A5737\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"0bc7c1d0-b569-4514-b66c-367457dead7e\",\"meta\":{\"drupal_internal__target_id\":11}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/field_topics?resourceVersion=id%3A5737\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/explainer/defa7277-790b-4bbd-b6ee-cc539e121df2/relationships/field_topics?resourceVersion=id%3A5737\"}}}}},{\"type\":\"node--library\",\"id\":\"0dee405f-3bb7-4a8a-b602-b5de9697cfdf\",\"links\":{\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf?resourceVersion=id%3A5778\"}},\"attributes\":{\"drupal_internal__nid\":461,\"drupal_internal__vid\":5778,\"langcode\":\"en\",\"revision_timestamp\":\"2024-08-05T16:04:35+00:00\",\"status\":true,\"title\":\"Risk Management Handbook Chapter 5: Configuration Management (CM)\",\"created\":\"2022-08-29T17:45:27+00:00\",\"changed\":\"2024-08-05T16:04:35+00:00\",\"promote\":false,\"sticky\":false,\"default_langcode\":true,\"revision_translation_affected\":true,\"moderation_state\":\"published\",\"path\":{\"alias\":\"/policy-guidance/risk-management-handbook-chapter-5-configuration-management-cm\",\"pid\":451,\"langcode\":\"en\"},\"rh_action\":null,\"rh_redirect\":null,\"rh_redirect_response\":null,\"rh_redirect_fallback_action\":null,\"publish_on\":null,\"unpublish_on\":null,\"body\":{\"value\":\"$1a\",\"format\":\"body_text\",\"processed\":\"$1b\",\"summary\":\"\"},\"field_contact_email\":\"CISO@cms.hhs.gov\",\"field_contact_name\":\"ISPG Policy Team\",\"field_last_reviewed\":\"2021-03-23\",\"field_related_resources\":[{\"uri\":\"entity:node/631\",\"title\":\"CMS Acceptable Risk Safeguards (ARS) \",\"options\":[],\"url\":\"/policy-guidance/cms-acceptable-risk-safeguards-ars\"},{\"uri\":\"entity:node/601\",\"title\":\"CMS Information Systems Security and Privacy Policy (IS2P2)\",\"options\":[],\"url\":\"/policy-guidance/cms-information-systems-security-privacy-policy-is2p2\"},{\"uri\":\"entity:node/681\",\"title\":\"CMS Security and Privacy Handbooks (all)\",\"options\":[],\"url\":\"/learn/cms-security-and-privacy-handbooks\"}],\"field_short_description\":{\"value\":\"RMH Chapter 5 provides information about the Configuration Management family of controls which determine the risk management requirements for CMS systems\",\"format\":\"plain_text\",\"processed\":\"\u003cp\u003eRMH Chapter 5 provides information about the Configuration Management family of controls which determine the risk management requirements for CMS systems\u003c/p\u003e\\n\"}},\"relationships\":{\"node_type\":{\"data\":{\"type\":\"node_type--node_type\",\"id\":\"ab4b0312-f678-40b9-ae06-79025f52ff43\",\"meta\":{\"drupal_internal__target_id\":\"library\"}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/node_type?resourceVersion=id%3A5778\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/node_type?resourceVersion=id%3A5778\"}}},\"revision_uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\",\"meta\":{\"drupal_internal__target_id\":159}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/revision_uid?resourceVersion=id%3A5778\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/revision_uid?resourceVersion=id%3A5778\"}}},\"uid\":{\"data\":{\"type\":\"user--user\",\"id\":\"dca2c49b-4a12-4d5f-859d-a759444160a4\",\"meta\":{\"drupal_internal__target_id\":26}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/uid?resourceVersion=id%3A5778\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/uid?resourceVersion=id%3A5778\"}}},\"field_resource_type\":{\"data\":{\"type\":\"taxonomy_term--resource_type\",\"id\":\"e3394b9a-cbff-4bad-b68e-c6fad326132e\",\"meta\":{\"drupal_internal__target_id\":91}},\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/field_resource_type?resourceVersion=id%3A5778\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/field_resource_type?resourceVersion=id%3A5778\"}}},\"field_roles\":{\"data\":[{\"type\":\"taxonomy_term--roles\",\"id\":\"9d999ae3-b43c-45fb-973e-dffe50c27da5\",\"meta\":{\"drupal_internal__target_id\":66}},{\"type\":\"taxonomy_term--roles\",\"id\":\"a2b33f6a-8172-4862-9c0e-6e5076b6cf26\",\"meta\":{\"drupal_internal__target_id\":81}},{\"type\":\"taxonomy_term--roles\",\"id\":\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\",\"meta\":{\"drupal_internal__target_id\":61}},{\"type\":\"taxonomy_term--roles\",\"id\":\"f591f442-c0b0-4b8e-af66-7998a3329f34\",\"meta\":{\"drupal_internal__target_id\":76}},{\"type\":\"taxonomy_term--roles\",\"id\":\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\",\"meta\":{\"drupal_internal__target_id\":71}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/field_roles?resourceVersion=id%3A5778\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/field_roles?resourceVersion=id%3A5778\"}}},\"field_topics\":{\"data\":[{\"type\":\"taxonomy_term--topics\",\"id\":\"c12221c3-2c7e-4eb0-903f-0470aad63bf0\",\"meta\":{\"drupal_internal__target_id\":16}},{\"type\":\"taxonomy_term--topics\",\"id\":\"65ef6410-4066-4db4-be03-c8eb26b63305\",\"meta\":{\"drupal_internal__target_id\":36}}],\"links\":{\"related\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/field_topics?resourceVersion=id%3A5778\"},\"self\":{\"href\":\"https://cybergeek.cms.gov/jsonapi/node/library/0dee405f-3bb7-4a8a-b602-b5de9697cfdf/relationships/field_topics?resourceVersion=id%3A5778\"}}}}}],\"includedMap\":{\"d185e460-4998-4d2b-85cb-b04f304dfb1b\":\"$1c\",\"4420e728-6dc2-4022-bf8d-5bd1329e5e64\":\"$26\",\"e352e203-fe9c-47ba-af75-2c7f8302fca8\":\"$2a\",\"a17f4908-9141-4b1e-82aa-e6bfe0f91a22\":\"$2e\",\"7a18463d-b0fc-474f-8536-ad7db1b2e5ab\":\"$48\",\"f591f442-c0b0-4b8e-af66-7998a3329f34\":\"$62\",\"feb4e85d-429e-48b0-92f0-3d2da2c5056e\":\"$7c\",\"7917cea4-02d7-4ebd-93a3-4c39d5f24674\":\"$96\",\"0bc7c1d0-b569-4514-b66c-367457dead7e\":\"$b0\",\"21c13746-6570-4f61-8745-b5520d53b5d7\":\"$ca\",\"319e7227-1f2a-4cdd-92a1-c4ef2593477a\":\"$dd\",\"1d1a8e48-f873-4c95-93aa-6243a892d004\":\"$ef\",\"9770a81c-b300-49e0-b938-d6fa266ffb23\":\"$101\",\"5cedd0e5-92bf-4900-9591-37f8c9011427\":\"$113\",\"a279358b-5b24-49bc-a98e-11681bd7e65c\":\"$128\",\"defa7277-790b-4bbd-b6ee-cc539e121df2\":\"$17a\",\"0dee405f-3bb7-4a8a-b602-b5de9697cfdf\":\"$1c4\"}}}]\n"])</script><script>self.__next_f.push([1,"a:[[\"$\",\"meta\",\"0\",{\"name\":\"viewport\",\"content\":\"width=device-width, initial-scale=1\"}],[\"$\",\"meta\",\"1\",{\"charSet\":\"utf-8\"}],[\"$\",\"title\",\"2\",{\"children\":\"Security Impact Analysis (SIA) | CMS Information Security \u0026 Privacy Group\"}],[\"$\",\"meta\",\"3\",{\"name\":\"description\",\"content\":\"A process to determine the effect(s) a change can cause to the security posture of a FISMA system\"}],[\"$\",\"link\",\"4\",{\"rel\":\"canonical\",\"href\":\"https://security.cms.gov/learn/security-impact-analysis-sia\"}],[\"$\",\"meta\",\"5\",{\"name\":\"google-site-verification\",\"content\":\"GMZIwBDJgz_o_JYUB2GpJazkrs7P85BaWDsoCjxF32M\"}],[\"$\",\"meta\",\"6\",{\"property\":\"og:title\",\"content\":\"Security Impact Analysis (SIA) | CMS Information Security \u0026 Privacy Group\"}],[\"$\",\"meta\",\"7\",{\"property\":\"og:description\",\"content\":\"A process to determine the effect(s) a change can cause to the security posture of a FISMA system\"}],[\"$\",\"meta\",\"8\",{\"property\":\"og:url\",\"content\":\"https://security.cms.gov/learn/security-impact-analysis-sia\"}],[\"$\",\"meta\",\"9\",{\"property\":\"og:image:type\",\"content\":\"image/jpeg\"}],[\"$\",\"meta\",\"10\",{\"property\":\"og:image:width\",\"content\":\"1200\"}],[\"$\",\"meta\",\"11\",{\"property\":\"og:image:height\",\"content\":\"630\"}],[\"$\",\"meta\",\"12\",{\"property\":\"og:image\",\"content\":\"https://security.cms.gov/learn/security-impact-analysis-sia/opengraph-image.jpg?d21225707c5ed280\"}],[\"$\",\"meta\",\"13\",{\"property\":\"og:type\",\"content\":\"website\"}],[\"$\",\"meta\",\"14\",{\"name\":\"twitter:card\",\"content\":\"summary_large_image\"}],[\"$\",\"meta\",\"15\",{\"name\":\"twitter:title\",\"content\":\"Security Impact Analysis (SIA) | CMS Information Security \u0026 Privacy Group\"}],[\"$\",\"meta\",\"16\",{\"name\":\"twitter:description\",\"content\":\"A process to determine the effect(s) a change can cause to the security posture of a FISMA system\"}],[\"$\",\"meta\",\"17\",{\"name\":\"twitter:image:type\",\"content\":\"image/jpeg\"}],[\"$\",\"meta\",\"18\",{\"name\":\"twitter:image:width\",\"content\":\"1200\"}],[\"$\",\"meta\",\"19\",{\"name\":\"twitter:image:height\",\"content\":\"630\"}],[\"$\",\"meta\",\"20\",{\"name\":\"twitter:image\",\"content\":\"https://security.cms.gov/learn/security-impact-analysis-sia/opengraph-image.jpg?d21225707c5ed280\"}],[\"$\",\"link\",\"21\",{\"rel\":\"icon\",\"href\":\"/favicon.ico\",\"type\":\"image/x-icon\",\"sizes\":\"48x48\"}]]\n"])</script><script>self.__next_f.push([1,"4:null\n"])</script></body></html> |