f - 01i_Dental_Solicitation Att 9_ITS01 Manage Secure Config Baselines_20241008.docx

ITS01 Manage Secure Configuration Baselines—Process Background Why do I need a secure configuration baseline?

Control CM-6 a. in the Master Security Control Catalog requires systems to: a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using National Checklist Program (NCP) sources approved for use by Enterprise Architecture (EA) and the Cyber Security Office (CSO). We use the term secure configuration baseline to refer to the document that documents these settings. Therefore, it is this control that requires the development of secure configuration baselines. (NIST version of CM-6) To avoid confusion, please use the exact term secure configuration baseline when talking about secure configuration baselines. Do not use variants like secure baseline, security baseline, etc.

Are baseline configurations and secure configuration baselines the same things?

No, baseline configurations, as referred to in controls CM-2, CM-2-1, CM-2-3, and CM-2-7, and secure configuration baselines are not the same things. Depending on how the documentation for a system is structured, a secure configuration baseline might be one component of a baseline configuration.

Does every system have its own secure configuration baselines?

No, every system does not have its own secure configuration baselines. A secure configuration baseline establishes OCC-wide configuration settings for the component to which it applies. (See the second-to-last sentence in the first paragraph of the discussion section for CM-6.) That is to say, for example, there is one secure configuration baseline for Windows Server 2016, one for Tomcat, one for IIS, etc. If your system uses IIS, you do not create an IIS secure configuration baseline for your system; you use the exiting one.

Now, it may be that you need a secure configuration baseline for some component specific to your system. For example, the OCC's C•CURE system, which is responsible for physical access control, uses Windows 2016 Server servers, IIS, and the commercial software product C•CURE 9000. So, C•CURE uses the Windows Server 2016 secure configuration baseline, the IIS secure configuration baseline, and, in addition to those, there is a secure configuration baseline specific to the C•CURE 9000 product. The C•CURE 9000 secure configuration baseline only documents configuration settings specific to the C•CURE 9000 product—it does not repeat settings for the operating system or IIS.

What if I need time to make my system compliant with a secure configuration baseline?

If you need time to make a system compliant with a secure configuration baseline, you should create a plan of action and milestones (POAM) for the compliance effort, assuming the compliance effort can be completed within the standard time limits for POAMs. If it cannot be completed within the standard time limits for POAMs, you should create a risk in the governance, risk, and compliance (GRC) system. Discuss creating a risk with your Information System Security Officer (ISSO).

What if my system will never comply with some settings in a secure configuration baseline?

If your system will never comply with a secure configuration baseline, you can document the settings for the non-compliant controls in your system-specific secure configuration baseline. Referring back to the example in Does every system have its own secure configuration baselines?, if C•CURE had to use some non-compliant value for an IIS configuration setting, that C•CURE-specific IIS configuration setting could be documented in the C•CURE 9000 secure configuration baseline. Note that this approach may require you to create a system-specific secure configuration baseline.

Alternatively, document non-compliant settings by creating a risk in the governance, risk, and compliance (GRC) system. Check with your ISSO before taking this approach.

What is a benchmark?

Paraphrasing from the second paragraph in the discussion section for CM-6, a benchmark is a common secure configuration for information technology products developed by a variety of organizations, including information technology product developers, manufacturers, vendors, federal agencies, consortia, academia, industry, and other organizations in the public and private sectors. The Microsoft IIS Benchmark developed by the Center for Internet Security is an example of a benchmark. Benchmarks are often available in the NIST National Checklist Program Repository.

How are benchmarks and secure configuration baselines related?

Whenever possible, a benchmark is used as the basis for a secure configuration baseline. If the benchmark is adopted as the secure configuration baseline without deviations or customizations, then the benchmark and the secure configuration baseline are one and the same. If there is a need to deviate from some of the controls in the benchmark, then the secure configuration baseline becomes the benchmark plus documentation of deviations from and customizations to benchmark settings. See What are the components of a secure configuration baseline? to understand what components go into a secure configuration baseline. And remember that the secure configuration baseline is always rendered into a single PDF file that gets digitally signed.

What if there is no benchmark to serve as the basis for a secure configuration baseline?

If there is no benchmark to serve as the basis for a secure configuration baseline for a given component, determine which of its configuration settings relate to making it operate most securely and document them as secure configuration baseline controls using the template for secure configuration controls. Do not document every configuration and setting that needs to be made to install and configure the component. A secure configuration baseline is not an installation guide. Limit the controls in it to those settings related to security.

For example, suppose you are installing a new commercial software application, and as part of the installation you need to specify the name of the database it needs to connect to. That type of setting should not be included in the secure configuration baseline. While it is important to the functioning of the application, it is not related to the security of the application. Now suppose as part of the installation you are asked whether users should be authenticated before they can access the application. That type of setting should go into the secure configuration baseline because it is related to the secure operation of the application.

It is possible that for some components, like simple desktop software applications, there are no security-related settings. If that is the case, document that fact in the Additional Information section of the Secure Configuration Baseline Approval form. The secure configuration baseline reduces to the approval form that documents the fact the component is as secure as possible out of the box.

What are the components of a secure configuration baseline?

A secure configuration baseline that is based on a benchmark consists of:

1. The Secure Configuration Baseline Approval Form (Note that you will need to download the approval form to your local hard drive and open it in Adobe Acrobat to fill it out.)

2. Documentation of deviations from and customizations to benchmark settings, if any

3. The benchmark

4. Other documentation necessary to document the secure configuration baseline, only if necessary A secure configuration baseline that is not based on a benchmark consists of:

1. The Secure Configuration Baseline Approval Form (Note that you will need to download the approval form to your local hard drive and open it in Adobe Acrobat to fill it out.)

2. Secure configuration baseline controls and settings

3. Other documentation necessary to document the secure configuration baseline, only if necessary Note that if there are no settings required to make a component operate more securely, the secure configuration baseline becomes just the approval form. See What if there is no benchmark to serve as the basis for a secure configuration baseline?

In all cases, all components of the secure configuration baseline must be rendered into a single PDF file that is digitally signed.

Why do we render the secure configuration baseline into a single PDF file?

We render the secure configuration baseline into a single PDF file for two reasons:

1. It makes it absolutely clear to everyone—reviews, approvers, users, auditors, etc.—what constitutes the secure configuration baseline

2. It makes it easy to sign with a PIV card

3. Approvers need to electronically sign only one file

1. Create a New Secure Configuration Baseline parent process

1. Initiate Secure Configuration Baseline Development This sub-process consists of activities for initiating the development of a new secure configuration baseline, including getting a Secure Configuration Baseline Owner assigned and assembling the team that will create the secure configuration baseline.

Development of a secure configuration baseline can be initiated by anyone who identifies a need for one. The need for a secure configuration baseline could result from an audit finding, the use of a new product or technology in a system, or the release of a new version of a product or technology. Most of the time, we expect the need will be identified by a technical or IPPT lead. Still, those are not the only possibilities, so the process allows for anyone to initiate development. The person initiating the development is referred to as the Secure Configuration Baseline Requestor.

1. Identify Candidates for the Secure Configuration Baseline Owner Role The Secure Configuration Baseline Requestor identifies individuals who are good candidates for the Secure Configuration Baseline Owner role. In many cases there may be only one candidate, but the process allows for the possibility of more than one. The Secure Configuration Baseline Requestor could be one of the candidates. By making the requestor responsible for this task, there is an underlying assumption that she understands who would make good candidates.

2. Discuss Owner Selection with Candidates and Other Stakeholders The Secure Configuration Baseline Requestor discusses the selection of a Secure Configuration Baseline Owner with candidates for the role and other stakeholders, like the candidates' Managers, technical lead, and other individuals interested in the secure configuration baseline. Ideally, the Secure Configuration Baseline Requestor comes to a consensus agreement with candidates and stakeholders, and a Secure Configuration Baseline Owner is chosen.

3. Discuss with ITS SLT2 to Get Owner Assigned If the Secure Configuration Baseline Requestor cannot achieve a consensus agreement on the Secure Configuration Baseline Owner, the requestor should discuss the assignment of an owner with the ITS SLT2. This could be done by discussing it at a regular ITS SLT2 meeting or more informally through individual discussions with ITS SLT2 members. The ultimate outcome of this sub-process is the assignment of a Secure Configuration Baseline Owner by the ITS SLT2.

4. Notify Stakeholders about Secure Configuration Baseline Owner Selection The Secure Configuration Baseline Requestor notifies the Secure Configuration Baseline Owner, the Secure Configuration Baseline Owner's Manager, and other stakeholders of the selection of the Secure Configuration Baseline Owner.

5. Assemble the Secure Configuration Baseline Team The Secure Configuration Baseline Owner assembles the team that will develop the secure configuration baseline.

1. Select Enterprise Architecture Team Member The team developing the secure configuration baseline must include at least one person from EA. The Secure Configuration Baseline Owner should work with the Manager for EA to identify a team member.

2. Select Cyber Security Defense Team Member The team developing the secure configuration baseline must include at least one person from Cyber Security Defense. The Secure Configuration Baseline Owner should work with the Manager for Cyber Security Defense to identify a team member. Note that because Cyber Security Defense and Cyber Security Engineering work closely together, the team member might actually come from Cyber Security Engineering.

3. Select Other Team Members The Secure Configuration Baseline Owner should work with Mangers from other parts of ITS to get any other individuals assigned to the team who are needed for the development process to be a success. That might include having ISSOs as part of the team.

4. Socialize the Secure Configuration Baseline Development Effort The Secure Configuration Baseline Owner informs stakeholders about the effort to create the new secure configuration baseline and, as appropriate, gets them involved as the baseline is developed. As a Secure Configuration Baseline Owner, use your judgement about who to inform and how to get them involved.

Process diagrams in Visio | Process background | Top of page

2. Develop the Secure Configuration Baseline This sub-process consists of activities for the actual development of the secure configuration baseline. The output of this sub-process is a version of the secure configuration baseline that is ready for approval.

1. Research Benchmark Options The team researches benchmarks that might be used as the basis for the secure configuration baseline. In the context of this sub-process, a benchmark is a formal, publicly available document, like those cataloged by the NIST National Checklist Program. See What is a benchmark? in the process background.

2. Identify Alterative Documentation as Input to the Secure Configuration Baseline If there is no formal benchmark, the team should identify other documents that could be used as the basis for the secure configuration baseline. Other documents might be vendor-provided installation manuals, user manuals, or security hardening guides that provide information about security-related settings.

3. Review Appropriate Non-benchmark-based Exemplars The team reviews existing secure configuration baselines that are appropriate examples for the baseline under development. The Secure Configuration Baseline Repository tags some secure configuration baselines as exemplars, indicating they are the better examples, but the team may choose to use any one.

4. Create Secure Configuration Baseline without Benchmark The team creates a secure configuration baseline that is not based on a benchmark. When this sub-process is complete, the team has a secure configuration baseline that is ready for final review and approval. Ideally, the secure configuration baseline is now a finished product and there should be few or no changes after this point.

1. Identify the Controls to Include in the Secure Configuration Baseline and Their Values Because there is no benchmark to start from, the team will need to decide what controls to include in the secure configuration baseline and the settings for each control. Product documentation might be a good source to identify controls to include in the baseline. Limit the controls to security-related controls only. Do not document every configuration and setting that needs to be made to install and configure the component. A secure configuration baseline is not an installation guide. See What if there is no benchmark to serve as the basis for a secure configuration baseline? in the process background. Document the controls using the template for secure configuration baseline controls.

2. Determine Specific Setting Description of this reusable sub-process

3. Draft the Secure Configuration Baseline Description of this reusable sub-process

4. Vet with Secure Configuration Baseline Owner's SLT2 Member Description of this reusable sub-process

5. Vet Secure Configuration Baseline with Parties Outside of the Team Description of this reusable sub-process

6. Revise Secure Configuration Baseline Description of this reusable sub-process Process diagrams in Visio | Process background | Top of page

5. Select Benchmark The team selects the benchmark to use for the secure configuration baseline. Select one, and only one, benchmark to use, unless there is a compelling need to use more than one.

6. Make Final Benchmark Selection If there is disagreement within the team as to which benchmark to use, the team member from EA makes the final decision.

7. Review Appropriate Benchmark-based Exemplars The team reviews existing secure configuration baselines that are appropriate examples for the baseline under development. The Secure Configuration Baseline Repository tags some secure configuration baselines as exemplars, indicating they are the better examples, but the team may choose to use anyone.

8. Create Benchmark-based Secure Configuration Baseline The team creates a secure configuration baseline based on a benchmark. When this sub-process is complete, the team has a secure configuration baseline that is ready for final review and approval. Ideally, the secure configuration baseline is now a finished product and there should be few or no changes after this point.

1. Identify Settings that Need to Deviate from the Benchmark Working from the benchmark for the secure configuration baseline, the team identifies any control settings that need to deviate from the benchmark. Or in the case where the benchmark allows for a choice of settings, they identify the setting or settings that will be allowed by the secure configuration baseline. Document deviations and customizations using Deviations from and Customizations to Benchmark Settings. Include a justification for any setting that deviates.

2. Determine Specific Setting Description of this reusable sub-process

3. Draft the Secure Configuration Baseline Description of this reusable sub-process

4. Vet with Secure Configuration Baseline Owner's SLT2 Member Description of this reusable sub-process

5. Vet Secure Configuration Baseline with Parties Outside of the Team Description of this reusable sub-process

6. Revise Secure Configuration Baseline Description of this reusable sub-process Process diagrams in Visio | Process background | Top of page

3. Approve the Secure Configuration Baseline This sub-process includes activities to get the secure configuration baseline formally approved. The output of this sub-process is a version of the secure configuration baseline that is fully approved and ready to be published.

1. Fill in the Secure Configuration Baseline Approval Form Download a fresh copy of the Secure Configuration Baseline Approval Form to your local hard drive. Do not reuse an old filled-out copy or an old local version. That way you are sure to have the most current version of the form.

Open Adobe Acrobat and then open the local copy of the form from Acrobat. Fill out the form. Do not have the form signed at this point. Signatures get applied to the form later in the process.

The next few paragraphs provide guidance for completing some fields on the form.

Applicable Product or Technology Specify the name and version of the product or technology to which the secure configuration baseline applies. Be clear about which versions are covered. For example, Tomcat 8.1 only if it applies only to version 8.1. Tomcat 8.x—all dot version of Tomcat 8 if it applies to all dot versions of version 8. Tomcat 8 and all later versions if it applies to version 8 and all later versions, including 9, 10, 11, etc. Generally speaking, a secure configuration baseline should only be associated with one product or technology.

Benchmark Information List the benchmark used. If a benchmark was not used, explain why (e.g., there is no benchmark for this technology). In cases where a benchmark was not used, if documents like installation manuals or user guides were used to define controls, list those documents. When possible, provide hyperlinks to the benchmark or documents that were used.

Do secure configuration baseline settings differ from benchmark settings? Indicate if any of the settings differ from settings specified in the benchmark. If a benchmark was not used, select Not applicable. If settings do differ from the benchmark, be sure to document those differences using the Deviations from and Customizations to Benchmark Settings template.

Overall Risk Rating Your ISSO and Cyber Security will determine the overall risk rating for the secure configuration baseline. Follow their guidance for this value.

Additional Information Enter any additional information that might be important to approvers. Most of the time, you will not need this field. Resist the temptation to fill it in with information that is really not relevant and important.

2. Render the Form and All Documents into a Single PDF File Render the form and all documents that comprise the secure configuration baseline into a single PDF file. See Why do we render the secure configuration baseline into a single PDF file? in the process background.

For secure configuration baselines based on a benchmark, include the following documents in the PDF in this order:

1. The filled-in Secure Configuration Baseline Approval Form. (Note that at this point the form does not have signatures.)

2. The Deviations from and Customizations to the Benchmark document. If there are no deviations or customizations, omit this document.)

3. The benchmark document. In the rare event when more than one benchmark was used, include them all.

4. Any other documentation the team feels is necessary to properly document the baseline, which might include:

a. If the baseline includes deviations from the benchmark, vendor or other documentation that supports the decision to deviate.

b. If the baseline includes customizations to benchmark settings, vendor or other documentation that supports the customized setting Avoid creating spreadsheets that copy all controls from the benchmark. While it has become the custom to develop such a spreadsheet, it is not required. In fact, it is discouraged. There is little added value to repeating what is already included in the benchmark itself.

For secure configuration baselines not based on a benchmark, include the following documents in the PDF in this order:

1. The filled-in Secure Configuration Baseline Approval Form. (Note that at this point the form does not have signatures.)

2. A document that clearly defines the secure configuration baseline controls and their settings using the Template for Secure Configuration Baseline Controls.

3. Any documents that were used as inputs to the secure configuration baseline, like vendor-provided installation manuals, user manuals, or product hardening guides.

4. Any other documents the team feels are necessary to properly document the baseline.

Files in Word, Excel, or other formats first need to be rendered into PDF format using the Save as Adobe PDF feature in those applications. Once all files are in PDF form, render them into a single PDF in Adobe Acrobat Pro:

1. Start Adobe Acrobat Pro.

2. Select File—>Create—>Combine Files into a Single PDF . . .

3. In the Combine Files window, click Add Files . . . in the top-left corner and then select Add Files . . . form the dropdown menu. A file browser window will appear.

4. Using the file browser, select all of the PDF files you want to combine into one file.

5. Once the files are selected, you can change their order by moving them in the Combine Files window.

6. Once the files are correctly arranged, click the Combine Files button.

Note that the secure configuration baseline is rendered as a single PDF file because reviewers and approvers will sign it with a digital signature using a PIV card.

3. Conduct a Final Review of the Secure Configuration Baseline The Secure Configuration Baseline Owner conducts a final review of the secure configuration baseline, in the form of the single PDF file, with the Enterprise Architecture team member, the Cyber Security Defense (or Engineering) team member, and the responsible ITS SLT2 member. This review serves as a final check to make sure everything is correct before the secure configuration baseline is circulated for signatures. Do not send the secure configuration baseline for approval until this final review is done.

The method by which the review is conducted is left to the Secure Configuration Baseline Owner. The owner could circulate it as an email attachment, or they could post it to SharePoint and send a link to the document. Note that using SharePoint is the preferred method.

4. Coordinate Revisions with the Team and Revise If revisions are needed after the final review, the Secure Configuration Baseline Owner coordinates those revisions with the team and revises the secure configuration baseline. The Secure Configuration Baseline Owner then renders a new PDF file and does another final review. See the Approve Secure Configuration Baseline page of the process diagrams.

5. Route the Secure Configuration Baseline for Approval The Secure Configuration Baseline Owner routes the secure configuration baseline to reviewers and approvers for their digital signatures. Have secure configuration baseline signed in the order signatures appear on the approval form: EA team member, Cyber Security team member, Secure Configuration Baseline Owner, ITS SLT2 member, Chief Information Security Officer. See the Route Secure Configuration Baseline for Approval page of the process diagrams. The subprocesses shown on that page are not described in this article.

The method by which the PDF file is routed is not specified by this sub-process. Secure Configuration Baseline Owners could circulate it as an email attachment, or they could post it to SharePoint and send a link to the document.

Process diagrams in Visio | Process background | Top of page

4. Publish the Secure Configuration Baseline The Secure Configuration Baseline Owner is responsible for ITS01.1.4 and all of its sub-processes.

This sub-process includes activities for uploading the secure configuration baseline to eDocs, adding a link to the eDocs document to the Secure Configuration Baseline Repository, and adding source documents to the Secure Configuration Baseline Repository.

1. Load the Secure Configuration Baseline into eDocs The digitally signed secure configuration baseline is considered an electronic record and must be stored in an OCC-approved electronic recordkeeping system (ERK). See the Policy section of PPM 4110-5 Certifying Electronic Recordkeeping Functionality in OCC Systems. SharePoint is not an OCC-approved ERK, but eDocs is, so the approved version must be loaded into eDocs. To upload the secure configuration baseline into eDocs:

1. Open the secure configuration baseline with Adobe Acrobat Pro.

2. From the menu bar, select DM.

3. From the drop-down menu, select Save As. The eDocs profile form will open, allowing you to index the document.

4. Enter the title. For example IIS 9.5 Secure Configuration Baseline.

5. Enter the name of the Secure Configuration Baseline Owner in the Creator field.

6. If a value for the Category field is required, select the appropriate value.

7. Select Secure Configuration Baseline (SEC_BASELN) as the Document Type.

8. Enter information for any other fields in the profile, as appropriate. Note that your specific profile may have required fields that need a value.

9. Do not click the OK button until security for the document is set. See Set eDocs Security on the Secure Configuration Baseline for details on how to set security on the document.

2. Set eDocs Security on the Secure Configuration Baseline Security on the secure configuration baseline should be set such that the Secure Configuration Baseline Owner has full access to the document and the ITS Users group has read-only access. To set security on the document:

1. Click the Security button in the bottom-right corner of the profile window.

2. Be sure the name of the Secure Configuration Baseline Owner appears in the Current Trustees: box. If it does not, find it in the users list and add it.

3. In the Current Trustees: box, select the name of the Secure Configuration Baseline Owner and then select Full Access in the Rights Template: box.

4. In the Groups: box, find the ITS Users group and add it to the Current Trustees: box.

5. In the Current Trustees: box, select the ITS Users group and then select Read Only in the Rights Template: box.

6. Click the OK button. Then click the OK button in the bottom-right corner of the profile window.

3. In the Secure Configuration Baseline Repository, create a link to the document in eDocs Send an email to ITSConfigMgmtSupport@occ.treas.gov if you do not have proper SharePoint access to complete this sub-process.

In the Secure Configuration Baseline Repository, create a link to the document in eDocs.

1. From the menu bar above the column headers, click the select the + New drop-down menu.

2. From the drop-down menu, select Link to a Document.

3. In the pop-up window, enter the document name (e.g., IIS 9.5 Secure Configuration Baseline) and the document URL. The document URL must have the form: https://su2edocs:2124/lViewDOC.html?id=PROD_Library::OCCDMRM^2519780::ACROBAT

4. Replace 2519780 with the actual eDocs document number of the secure configuration baseline PDF document.

5. Click the OK button. If you are prompted for metadata values, enter them.

4. Upload the Source Documents into the Secure Configuration Baseline Repository Upload copies of all of the source documents used to create the single secure configuration baseline PDF file into the Secure Configuration Baseline Repository. Use the Upload item in the menu bar above the column headings to do this.

5. Notify Stakeholders that the Secure Configuration Baseline Is Available Let stakeholders know that the secure configuration baseline is complete. The group of stakeholders that needs to be notified will differ for each secure configuration baseline. The Secure Configuration Baseline Owner will have to use her judgment to decide who those stakeholders are. It would be helpful to provide stakeholders with a link to the Secure Configuration Baseline Repository.

Process diagrams in Visio | Process background | Top of page Reusable Sub-processes (listed alphabetically) Determine Specific Setting ITS01.1.2.4.2 | ITS01.1.2.8.2 In the case where the team cannot come to consensus on the setting for a particular control, the team member from Cyber Security will make the final determination for the setting. In addition, in cases where the secure configuration baseline is being developed without a benchmark, if the team cannot come to consensus about whether a particular control should be included in the baseline, the team member from Cyber Security will decide whether to include it.

Draft the Secure Configuration Baseline ITS01.1.2.4.3 | ITS01.1.2.8.3 In this sub-process the team completes a draft of the secure configuration baseline. The draft should be complete enough for vetting with the ITS SLT2 member responsible for the baseline and any stakeholders outside of the team.

At the end of this sub-process, the draft version of the secure configuration baseline is probably a number of separate files. That is to be expected. Eventually, the separate files that comprise the secure configuration baseline are rendered into a single PDF file for final review and approval.

Revise Secure Configuration Baseline ITS01.1.2.4.6 | ITS01.1.2.8.6 In the course of vetting the secure configuration baseline with the Responsible ITS SLT2 Member and parties outside of the team creating the new secure configuration baseline, if revisions are needed, the team revises the secure configuration baseline.

Vet Secure Configuration Baseline with Parties Outside of the Team ITS01.1.2.4.5 | ITS01.1.2.8.5 Vet the secure configuration baseline with people outside of the team. The people with which the secure configuration baseline should be vetted will depend on the baseline. The Secure Configuration Baseline Owner and the team will need to decide with whom the baseline should be vetted.

Vet with Secure Configuration Baseline Owner's SLT2 Member ITS01.1.2.4.4 | ITS01.1.2.8.4 Vet the secure configuration baseline with the Responsible ITS SLT2 Member. Schedule a meeting to discuss, ask for feedback via email, or employ some other mechanism to the ITS SLT2 Member's feedback.

Secure Configuration Baseline Owner Article metadata. Revised by Glenn Cadoret

Every secure configuration baseline used by ITS has a Secure Configuration Baseline Owner assigned to it. Secure Configuration Baseline Owners are the primary point of contact for the secure configuration baseline and are responsible for:

1. Leading the development of new secure configuration baselines

2. Periodically reviewing risk acceptance memos approving deviations from the secure configuration baseline

3. Updating the secure configuration baseline when needed

4. Assisting teams configuring systems against the secure configuration baseline

5. Ensuring the fully approved version of the secure configuration baseline is available in eDocs and the Secure Configuration Baseline Repository (formerly know as the Enterprise Baseline Configuration Repository) The documentation for the Manage Secure Configuration Baselines process can provide more information on the role of the Secure Configuration Baseline Owner. Please see ITS01 Manage Secure Configuration Baselines—Process Background, ITS01 Manage Secure Configuration Baselines—Process Description, and ITS01.1 Create New Secure Configuration Baseline—Process Description Secure Configuration Baseline Owner is an operational role.