DeCAM 35-31.01.pdf

th

DECA MANUAL 35-31.01

CYBERSECURITY

Originating Component: Information Technology Directorate

Effective: May 15, 2020 Change #1 Effective September 22, 2022

Releasability: Limited. This manual is not approved for public release and is located on the Defense Commissary Agency’s (DeCA) intranet website known as OneNet.

Reissues and Cancels: DeCA Manual (DeCAM) 35-31.01, “Information Assurance

Vulnerability Management Manual,” December 15, 2009 DeCAM 35-31.3, “System Access,” June, 28, 2010 PC1-DeCAM 35-31.3, “Policy Change – Process to Request Removal of System Access,” August 6, 2010 DeCAM 35-31.01, “Cybersecurity,” November 28, 2017

Incorporates and Cancels: DeCA Directive (DeCAD) 35-37, “Vulnerability Assessment,”

December 11, 2007 DeCAM 35-37.1, “Vulnerability Assessment Manual,” January 29, DeCAD 35-40, “Penetration Testing,” February 25, 2009 DeCAD 35-41, “Antivirus,” March 13, 2008

Approved by: Teena P. Standard, Chief of Staff Change #1 Approved by: Dr. Theon Danet, Chief Information Officer

Purpose: This manual is issued under the authority of DeCAD 35-31, “Cybersecurity.”

DeCAM 35-31.01, May 15, 2020 Change #1, September 22, 2022

• Implements policy and provides procedures for implementing a cybersecurity program in accordance with (IAW) Department of Defense (DoD) guidance. The cybersecurity program will ensure that Information Technology (IT) can be used in a way that allows business owners and system operators to have confidence in the confidentiality, integrity, and availability of IT and DeCA information, and to make choices based on that confidence. This manual documents policy for the implementation of DoD’s Risk Management Framework (RMF) within DeCA’s environment.

TABLE OF CONTENTS 3

TABLE OF CONTENTS

SECTION 1: GENERAL ISSUANCE INFORMATION

1.1. Applicability

1.2. Policy

1.3. Summary of Changes

SECTION 2: RESPONSIBILITIES

2.1. Program Manager (PM)

2.2. Cybersecurity Service Provider (CSSP)

2.3. Cybersecurity Division

2.4. Information System Security Manager (ISSM)

2.5. Information System Security Officer (ISSO)

2.6. Privileged User

2.7. Security Division

2.8. Supervisor

2.9. Authorized User

SECTION 3: RISK MANAGEMENT FRAMEWORK

3.1. Risk Management Framework (RMF)

3.2. Guiding Principles

SECTION 4: VULNERABILITY MANAGEMENT

4.1. Vulnerability Management Program

4.2. Notifications and Reporting

4.3. Vulnerability Assessment

4.4. Penetration Test

4.5. Host based Security

4.6. Removable Media Devices

SECTION 5: IT ACCESS

5.1. IT Access Guidelines

5.2. Eligibility for System Access

5.3. Eligibility for Interim System Access

5.4. Credential

5.5. Temporary Employees

5.6. Requesting System Access

5.7. Account Management

5.8. Account Removal

5.9. Account Suspension

5.10. Usage Requirements

5.11. Visitors

GLOSSARY

G.1. Acronyms G.2. Definitions

REFERENCES

FIGURES

Figure 1. Information Systems Logging Requirements Figure 2. User Agreement and Acceptable Use Policy Figure 3. Standard Mandatory DoD System Notice and Consent Banner

SECTION 1: GENERAL ISSUANCE INFORMATION 4

Section 1: General Issuance Information

1.1. APPLICABILITY. This manual applies to all system components that store, process, or transmit DeCA information, to include cardholder information. The term “system components” includes network devices, servers, computing devices, and applications.

1.2. POLICY. It is DeCA’s policy that all system components adhere to the procedures set forth in this manual and with references listed within this document IAW DoD Directive (DoDD) 5105.55 and DeCAD 70-2.

1.3. SUMMARY OF CHANGES. The change to this issuance:

a. Updates Information System Security Manager responsibilities in Section 2.4 to include the requirement to review and approve user-based accounts on the domain that have been authorized access with a password (i.e., exceptions to smart card logon enforcement) on a quarterly basis and revoke exceptions if not covered by a documented justification.

b. Updates Information System Security Officer (ISSO) responsibility in Section 2.5 for granting system access to require a standard DeCA System Access Request be documented in the Remedy system prior to granting access.

c. Updates Privileged User responsibilities in Section 2.6 to include the requirement to use non-privileged accounts, or roles, when accessing non-security functions.

d. Updates Section 5.6(a) to require a DeCA standard System Access Request (SAR) form in Remedy in order to request access to DeCA systems. A link to this form was also added.

e. Updates Section 5.7(d) to clarify that accounts that are deleted for inactivity do not require an account removal request to be documented.

f. Updates Section 5.8(a) to require that requests to remove DeCA system accounts be initiated by completing the DeCA standard SAR form in Remedy. In addition, Section 5.8(b) was updated to provide system managers/program managers the ability to request the removal of a user’s account and remove the ability to request removal by email.

g. Updates Section 5.8(c) to require that accounts that have been inactive for 90 consecutive days be deleted automatically and/or without a valid account removal request, in accordance with (IAW) the update made to paragraph 5.7(d). This update also removed the requirement to forward requests to ISSOs because notifications are now handled by Remedy.

SECTION 2: RESPONSIBILITIES 5

SECTION 2: RESPONSIBILITIES

2.1. PROGRAM MANAGER (PM). A System Manager (SM) may perform these duties in absence of an assigned PM. The PM shall:

a. Ensure an Information System Security Manager (ISSM) is appointed by the Chief Information Officer (CIO) and assigned to each information system (IS) or platform information technology (PIT) system and provide support to the ISSM in performing their duties.

b. Ensure an IS security engineer, qualified IAW DoD 8570.01-M, is assigned to each program that includes an IS or PIT system and that they are engaged to design, develop, implement, modify, and test and evaluate the system architecture in compliance with the cybersecurity component of the DoD Enterprise Architecture.

c. Plan, budget, resource, and implement RMF for assigned IS and PIT systems. This includes integrating RMF activities, to include security testing and evaluation, into acquisition activities, documentation, program schedules, and test plans early on.

d. Assist the Information System Owner (ISO) in the completion of the system categorization for each IS or PIT system IAW DeCA templates and the National Institute of Standards and Technology (NIST) Special Publication 800-60.

e. Register the IS or PIT system in the Enterprise Mission Assurance Support System (eMASS) once the system categorization is completed by the ISO.

f. Assist the ISO in the creation and maintenance of the system security plan.

g. Create and submit Plan of Action and Milestones (POA&M) for system deficiencies, track the execution of POA&M activities, review and update the POA&M (at least every 90 days), and ensure resolution of each POA&M by the specified milestones.

h. Adhere to Authorizing Official (AO) authorization decisions for hosted or interconnected IS and PIT systems.

i. Ensure IS and PIT systems are reviewed and tested for security compliance at least annually, by the ISSM or an independent representative.

j. Provide the IS or PIT system description to be used in all security-related documentation.

k. Include technical and performance requirements, derived from the assigned security controls, in requests for proposals and subsequent contract documents for design, development, production, and maintenance.

l. Ensure individuals providing system support functions are aware of the requirements in this manual.

SECTION 2: RESPONSIBILITIES 6

m. Maintain written agreements with service providers acknowledging in writing that they will maintain compliance with all applicable cybersecurity requirements.

n. Monitor contracts and service providers for cybersecurity compliance, to include compliance with DeCAD 35-46, and identification of the Cyber Workforce, by verifying compliance status.

o. Ensure application development is based on secure coding guidelines (e.g., Open Web Application Security Project or NIST) and adhere to all applicable secure configuration guides.

p. Conduct a review of all system accounts with the ISO to validate the need for continued access twice a year. Ensure all unnecessary accounts are deleted. Completion of the review(s) will be documented and include a nonrepudiation element to identify the reviewer(s).

q. Conduct a review of all privileged system accounts in order to validate the need for continued access every 90 days. Infrastructure accounts (e.g., operating system accounts managed by the DeCA Data Center team) will be reviewed by the infrastructure PM. Ensure all unnecessary accounts are deleted. Completion of the review will be documented. Include a nonrepudiation element to identify the reviewer(s), and ensure that two-factor credentials are used to the fullest extent.

r. Develop and maintain an inventory of systems, system components to include software/hardware unique identifiers, hardware specification (manufacturer, type, model, serial number, physical location), software license information, ISO, machine name, interconnected devices, and required ports/protocols/services, over the course of their deployment.

s. Document and implement a vulnerability management process, to include a patch cycle, to address patches, updates, and configuration changes within the timeframes specified in Section 4, paragraph 4.2. This process is for remediating (fixing), mitigating (reducing risk), or risk acceptance of vulnerabilities with considerations such as mission criticality and severity.

t. Ensure all IS and PIT systems are reported to the DeCA Assured Compliance Assessment Solution team and included in monthly vulnerability scans. Proper privileged credentials and permissions should be made available to ensure successful scans. Collect and evaluate data to determine if vulnerability management processes are operating as expected (i.e., mean time to proper implementation from time of release, mean time to proper implementation from time of directed mitigation, and number of software/hardware items successfully removed prior to end- of-life).

u. Implement secure configuration guides in the following order: Defense Information Systems Agency Secure Technical Implementation Guides (STIG), Defense Information Systems Agency Security Requirements Guide, NIST security checklist program guides, product vendor recommended security configuration guides, and DeCA developed configuration settings.

v. Document the inability to comply with applicable security setting guidance as a deficiency POA&M and update security settings in the next minor software release.

SECTION 2: RESPONSIBILITIES 7

w. Select the next most secure setting when recommended security settings cannot be implemented, document the rationale for deviating from the recommended setting, and obtain approval based on the severity of the setting from the AO.

x. Document and implement a process to verify and maintain the secure configuration of IS and PIT systems quarterly. The proper implementation and maintenance of that implementation must be documented using the applicable manual STIG file to create an evaluation checklist using DoD’s STIG tool. The DoD’s Secure Compliance Checker tool and Defense Information Systems Agency Secure Content Automation Protocol benchmarks must be used to perform any automated STIG compliance checks, when available. The automated results will be imported into the evaluation checklist using STIG viewer. The documentation and/or evaluation is considered complete once the checklist (manual and automated checks) is complete. These checklists should be labeled by host name and date of evaluation, stored, and made available during compliance assessments.

y. Evaluate secure configuration evaluation results quarterly (e.g., STIG results) and ensure systems are brought back into compliance within the timeframes established in Section 4, paragraph 4.2.

z. Document and implement a process to apply new secure configuration guides (e.g., STIG, etc.) within 90 days of release.

aa. Ensure DoD endpoint protection tools are properly installed, configured, and functioning to protect and defend against vulnerabilities and attack vectors. Endpoint protection tools include antivirus, host intrusion prevention, data loss preventions applications, host firewalls, and others.

ab. Ensure mobile devices are configured to use a file and/or device encryption solution.

ac. Document system specific procedures for implementing Cybersecurity Protection conditions (formally known as Information Operation Conditions) in response to changes to the Cybersecurity Protection level.

ad. Ensure all IT products, services, and PIT have completed the appropriate evaluation and configuration processes, IAW DoD Instruction (DoDI) 8510.01, prior to incorporation into or connection to an existing DeCA IS or PIT system.

2.2. CYBERSECURITY SERVICE PROVIDER (CSSP). The CSSP shall:

a. Provide for 24/7 monitoring and analysis of security alerts affecting the DeCA environment and report suspicious events.

b. Ensure the tools that are used to protect, detect, and monitor the security posture of DeCA’s environment are maintained and updated to provide optimal protection.

c. Conduct monthly vulnerability scans, at a minimum, on all devices on DeCA’s network.

d. Establish, document, and distribute computer security incident response and escalation procedures.

SECTION 2: RESPONSIBILITIES 8

e. Provide 24/7 monitoring, analysis, and reporting for evidence of any unauthorized activity, detection of unauthorized wireless access points, intrusion detection/prevention system alerts, and/or reports of unauthorized critical system or content file changes.

f. Provide 24/7 incident response and recovery support if an incident is identified IAW documented computer security incident response and escalation procedures located at the DeCA Cybersecurity SharePoint site:

https://portal.apps.deca.mil/04/003/0001/2/All_Users_Share/Forms/AllItems.aspx.

g. Facilitate an annual incident response (e.g., security breach) exercise and document lessons learned.

h. Provide information and support to penetration testing activities conducted by third parties.

i. Provide for 24/7 monitoring, analysis, and reporting of antivirus compliance, unauthorized systems, and threat activity generated via antivirus/anti-malware alerts for the enterprise through management of the Host Based Security System and ePolicy Orchestrator.

2.3. CYBERSECURITY DIVISION. The Cybersecurity Division shall:

a. Conduct a security risk assessment on all IS and PIT systems per the RMF program.

b. Assess all IT products, services, and PIT, as required, IAW DoDI 8510.01.

c. Manage DeCA’s Enterprise Mission Assurance Support Service instance used to track the assessment and authorization status of DeCA IS and PIT systems.

d. Distribute DoD’s Information Assurance Vulnerability Management (IAVM) notices and report Agency compliance metrics.

e. Ensure remediation activities and/or documented mitigations can be verified.

f. Conduct a security assessment on all IS and PIT systems annually.

g. Consolidate and report Agency compliance metrics to the DoD CIO, to include but limited to scorecard metrics.

2.4. INFORMATION SYSTEM SECURITY MANAGER (ISSM). The ISSM shall:

a. Implement a system-level cybersecurity plan that follows established cybersecurity policies and includes cybersecurity architecture, requirements, objectives, cybersecurity personnel, and procedures.

b. Monitor compliance with cybersecurity policy, as appropriate, and review the results of such monitoring.

SECTION 2: RESPONSIBILITIES 9

c. Ensure that cybersecurity inspections, tests, and reviews are synchronized and coordinated with affected parties and organizations.

d. Ensure implementation of IS security measures and procedures, including reporting incidents to the AO and appropriate reporting chains.

e. Support the implementation of the RMF and act as the primary cybersecurity technical advisor to the AO for DoD IS and PIT systems under their purview.

f. Assemble the security authorization package, consisting of the updated security plan, the Selective Acquisition Report (SAR), and the POA&M(s). For assessments conducted by a Security Control Assessor, the SAR will be provided by the Security Control Assessor.

g. Review POA&Ms and risk acceptance requests for accuracy and impact to the system security posture. Report concerns or issues to the AO.

h. Review cybersecurity-related events and configuration change requests for impact to DoD IS and PIT systems authorization or security posture and formally report issues to the AO.

Approve/disapprove configuration change requests based on security impact.

i. Perform and document annual system security assessments on a subset of implemented security controls when the Security Control Assessor’s involvement is not required by the AO.

j. May recommend to the Senior Information Security Officer (SISO) or AO a reassessment of any or all security controls at any time.

k. Recommend changes or improvement to the implementation of assigned security controls, the assignment of additional security controls, or changes or improvements to the design of the system itself to the SISO and AO at any time.

l. Verify current system security configuration standards (i.e., STIGs, etc.) are applied when new systems are configured.

m. Maintain and report IS and PIT systems assessment and authorization status to the SISO and

AO.

n. Ensure that ISSOs are appointed in writing and provide oversight to ensure that they are following established cybersecurity policies and procedures.

o. Coordinate with the SISO and the organization’s security manager to ensure issues affecting the organization’s overall security are addressed appropriately.

p. Ensure all products, services, and PIT have completed the appropriate evaluation and configuration processes prior to incorporation into or connection to an IS or PIT system (with the review and approval of the responsible AO). This includes verification of proper application of security configuration guidance (e.g., STIGs).

SECTION 2: RESPONSIBILITIES 10

q. Review and approve, on a quarterly basis, all user-based accounts on the domain that have been authorized access with a password (i.e., exceptions to smart card logon enforcement). Ensure exceptions are revoked if not covered by a justification documented with the AO.

r. Document system-level procedures that define processes for reviewing system audit logs, IAW the guidance in Figure 1.

Figure 1. Information Systems Logging Requirements

DeCA SYSTEM LOGGING REQUIREMENTS

This document provides the minimum audit and accountability requirements for systems that store, process, or transmit DeCA information in order to maintain compliance with applicable standards. These requirements should be considered a supplement to the NIST Special Publication 800-37 and Payment Card Industry (PCI) Data Security Standard security controls.

System-level procedures will be required to define roles, responsibilities, and instructions for meeting this policy. System procedures may also include additional audit and accountability requirements due to the system’s function, mission, or sensitivity. System-level procedures will be captured as a supplement to this document. Any system not capable of implementing audit and accountability requirements according to the NIST, DoD, PCI, or other applicable laws, regulations, or requirements will submit a completed POA&M or risk acceptance to the DeCA CIO that includes mitigations that have been implemented to address the risk resulting from the lack of meeting these requirements.

Audit Events

An event is any observable occurrence in an information system. Audit events are defined as those events which are significant and relevant to the security of information systems and the environments in which those systems operate.

The following events are required to be logged. Automated audit logging will be implemented at system start-up for all system components to include the following events:

• Individual user access to data repositories storing the following information: cardholder, financial, contractual, and Personally Identifiable Information (PII).

• Actions taken by any individual with root or administrative privileges.

• Start and end times for user access to systems.

• Successful and unsuccessful attempts to access, modify, elevate, or delete privileges.

• Use of, and changes to identification and authentication mechanisms, including, but not limited to creation of new accounts, elevation of privileges, and all changes, additions, or deletions to accounts with root or administrative privileges.

• Account creation, modification, and termination.

• Access to all audit logs/trails.

• Initialization, modification, pausing, and stopping of any audit log.

• Creation, modification, and deletion of system-level objects.

• Concurrent logons originating from different systems.

SECTION 2: RESPONSIBILITIES 11

• Invalid logical access attempts.

• Program initiation.

• Kernel module load, unload, and restart.

• System time setting modification.

• Audit logs from all anti-virus mechanisms, to include virus and malware activity and anti-malware reactions.

Event Attributes

The following event attributes are required to provide sufficient information for the intended subsequent monitoring and analysis. It must identify and record the “when, where, who, and what” for each event. Include the following information in each audit log event:

• User identification

• Date and time

• Type of event

• Success or failure indication

• Origination/destination of the event

• Identity or name of affected data, system component, or resource

In addition, devices within the cardholder environment will:

• Write logs for external-facing technologies (i.e., wireless, firewalls, domain name service, and email) onto a log server or media on the internal Local Area Network

(LAN).

• Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts.

• Retain audit logs with a minimum of three months immediately available for analysis online.

• Never log full track data, card verification data, and/or personal identification numbers.

• Render unreadable any and all primary account numbers included in logs.

Time Stamp Requirements

• Configure information systems to use internal system clocks to generate time stamps for audit logs and record time stamps that can be mapped to Universal Time Coordinated (UTC), Greenwich Mean Time (GMT), or local time with an offset from UTC.

• Granularity of time measurement for time stamps generated for audit logs is one second.

Frequency of synchronization of internal information system clocks is every 24 hours for networked systems.

• Authoritative time source must be synchronized with the United States (U.S.) Naval Observatory time servers or Global Positioning System every 24 hours.

Audit Review, Analysis, and Reporting

Audit review, analysis, and reporting covers information security-related auditing, for example, auditing the results from monitoring account usage for inappropriate or unusual activity and reporting findings. Audit reduction is a process that manipulates collected audit information and

SECTION 2: RESPONSIBILITIES 12

organizes it in a summary format that is more meaningful to analysts. This includes advanced data filters used to identify anomalous behavior in audit records.

• ISSM or authorized representative will:

o Develop a system-level procedure for their corresponding area(s) that defines the process for reviewing audit logs.

o Maintain a current list of systems from which audit records are to be compiled.

o Define an authorized subset of privileged users allowed access to the management of audit functionality. To further clarify, define the subset of privileged users authorized to select auditable events and make changes.

o Limit the viewing of audit logs to those with a job-related need.

• Audit events will be reviewed weekly by system administrators (SA) in an effort to detect unusual or anomalous behavior. To clarify, database audit logs should be reviewed by database administrators, network device logs by network administrators, and application audit logs by application administrators. The ISSO should verify that this task is being performed. Log harvesting and parsing tools may be used to assist with reviews but the SA is responsible for proper application of the tool (i.e., queries and dashboards used to assist with reviews).

• Audit events from systems in DeCA’s cardholder data environment, as identified in DeCA’s cardholder environment inventory, will be reviewed daily by SAs to detect unusual or anomalous behavior. The ISSO should verify that this task is being performed.

• Completion of the review(s) will be documented and include a nonrepudiation element (digital signature, etc.) to identify the reviewer(s).

• It is recommended that the following event types be baselined per system by a SA and included in the system-level procedure for weekly reviews to assist in identifying unusual system behavior, where feasible:

o Avg # of user logins to a specific Internet Protocol (IP) per day.

o Avg # of user logins from a specific IP per day.

o Avg # of times a specific IP/port is hit per day.

o Avg # of user logins during off hours per host per day.

o Avg bytes of data transferred per source IP per day.

o Avg bytes of data transferred per destination IP per day.

o Avg # failed logins per user per day.

o Avg # failed logins per user per day per source IP.

o Avg # of times processes stopped/started per day.

o Avg # error messages per system per day.

o Avg # of log messages per day.

o Mismatched ports and protocols (e.g., non-secure shell (SSH) application using port

22).

o Startup of a new process uncommon to those systems (define common processes).

o Other activities that contradict the normal baseline characteristics of a system.

• Any findings (i.e., unusual or anomalous behavior/events) discovered during audit reviews will be reported to the ISSO and ISSM, at a minimum. All suspicious activity/events will also be reported to the DeCA Computer Incident Response Team for further investigation, IAW DeCA Computer Incident Response procedures.

SECTION 2: RESPONSIBILITIES 13

• Review and analyze audit logs from multiple components across different repositories in a central location.

• The ISSO, at a minimum, will be notified in the event of audit log processing failure.

Audit Log Storage

• The Chief Technology Officer, or authorized representative, will:

o Provide and implement the capability to centrally review and analyze records from multiple components across different repositories.

o Provide the capability for retrieval of long-term audit records.

• PM/SM or authorized representative will:

o Determine and implement sufficient audit record storage capacity as required or mandated by directive or policy.

o Ensure audit records are off-loaded onto a centralized log server (separate system or media) that is protected from tampering, difficult to alter; in real-time for interconnected systems, and weekly for standalone systems.

o Ensure the protection of audit log files from unauthorized modifications via access control mechanisms, physical, and/or network segregation.

• The ISSM, ISSO, PM/SM, and SA will be notified immediately when audit record storage volume reaches 75 percent capacity.

• The organization will retain audit records for at least one year to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements.

Periodic Review.

Over time, the events that organizations believe should be audited may change. Reviewing and updating the set of audited events periodically is necessary to ensure the current set is still necessary and sufficient. This review will be conducted annually by the ISSM and SISO. The completion of the review will be documented, include a nonrepudiation element (digital signature, etc.) to identify the reviewer(s), and define any changes.

Optional Logging Capabilities.

The capability for authorized users to select a user session to capture/record or view/hear is an optional logging capability. Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable Federal Laws, Executive Orders, directives, policies, regulations, or standards.

2.5. INFORMATION SYSTEM SECURITY OFFICER (ISSO). The ISSO shall:

a. Assist the ISSMs in meeting their duties and responsibilities.

b. Assist the PM/SM in the creation of POA&Ms for all system vulnerabilities and deficiencies, facilitating remediation activities, and tracking the status of remediation efforts.

SECTION 2: RESPONSIBILITIES 14

c. Ensure compliance with the DoD vulnerability management program by monitoring affected assets within the Assured Compliance Assessment Solution (ACAS), facilitating remediation efforts, and monitoring the remediation status.

d. Assist with vulnerability assessments and security compliance reviews, as required.

e. Ensure audit logs are configured to meet current audit requirements (Figure 1).

f. Ensure anomalies identified during audit log reviews or alert notifications are reported to DeCA’s incident response team, as appropriate, and addressed immediately.

g. Ensure that individuals have a DeCA standard SAR documented in DeCA’s Remedy system that is complete with the following information prior to granting system access: business justification from their supervisor, a background investigation and/or clearance verified by the Security Division for the level of system access requested, and are aware of their cybersecurity responsibilities.

h. Ensure deviations from Security Technical Implementation Guides (STIG) or other hardening guides) are documented in system configuration standards and are updated as new vulnerability issues are identified.

i. In coordination with the ISSM, initiate protective or corrective measures when a cybersecurity incident or vulnerability is discovered.

2.6. PRIVILEGED USER. The privileged user shall:

a. Sign and adhere to the DeCA privileged user agreement.

b. Create, manage, and remove user accounts and system access that are no longer needed.

c. Notify the ISSO of all system configuration changes.

d. Implement DoD system security configuration guides and document configuration standards, to include deviations, for each system type. Ensure the documentation is updated as new vulnerabilities or guides are identified.

e. Maintain compliance with DoD system security configuration guides and provide compliance results (i.e., self-assessment results) via use of STIG Viewer, manual STIGs, and security content automation protocol (SCAP) benchmarks, where applicable and on a quarterly basis (as defined by this policy).

f. Protect the privileged user authenticator at the same security level as the data on the system.

g. Review system audit logs for unusual activity and report findings to the ISSO and ISSM, IAW guidance in Figure 1.

SECTION 2: RESPONSIBILITIES 15

h. Exercise due diligence and cybersecurity practices to ensure cybersecurity program implementation.

i. Ensure ISSO approval is obtained prior to granting an individual with system access.

j. Assess vendor-developed patches and updates for system impact and identify those that will change security configuration settings from secure to unsecure states and determine how to return software and hardware items to secure states after patch application.

k. Ensure that all requests for password resets are authenticated by signed email from a supervisor (i.e., if a user requests a password reset by phone, email, web, or other method, the user’s identity is verified before the password is reset).

l. Use non-privileged accounts, or roles, when accessing non-security functions or in other words, when not performing privileged user functions.

2.7. SECURITY DIVISION. The Security Division shall:

a. Validate that employees and contractors have the proper background investigation level required to obtain access to DeCA IS and PIT resources.

b. Conduct physical security and access control assessments and provide results that may impact the security posture of DeCA IS and PIT resources to the SISO and AO.

2.8. SUPERVISOR. The supervisor shall:

a. Authorize an employee’s need to use devices and systems on the network.

b. Ensure employees operating devices within the DeCA environment have access to and have read and understand this manual.

c. Enforce the guidance in this manual and report violations.

d. Ensure sensitive data is not stored on local hard drives, memory devices, thumb drives, or removable media without a DeCA approved file and/or device encryption solution.

e. Maintain the User Agreement and Acceptable Use Policy (Figure 2) signed by each employee under their purview that is accessing DeCA’s network and ensure employees sign the latest agreement and policy prior to obtaining network access and then annually thereafter:

https://onenet.commissaries.com/decas-acceptable-use-policy.

https://onenet.commissaries.com/decas-acceptable-use-policy

SECTION 2: RESPONSIBILITIES 16

Figure 2. User Agreement and Acceptable Use Policy

DEFENSE COMMISSARY AGENCY

USER AGREEMENT AND ACCEPTABLE USE POLICY

By signing this document, you acknowledge and consent that when you access DoD information systems:

• You are accessing a U.S. Government information system (IS) (which includes any device attached to this IS that is provided for U.S. Government-authorized use only.

• You consent to the following conditions:

• The U.S. Government routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, communications security (COMSEC) monitoring, network operations and defense, PM, law enforcement (LE), and counterintelligence (CI) investigations.

• At any time, the U.S. Government may inspect and seize data stored on this IS.

• Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any U.S. Government-authorized purpose.

• This IS includes security measures (e.g., authentication and access controls) to protect U.S.

Government interests--not for your personal benefit or privacy.

• Notwithstanding the above, using an IS does not constitute consent to personnel misconduct, law enforcement, or counterintelligence investigative searching or monitoring of the content of privileged communications or data (including work product) that are related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Under these circumstances, such communications and work product are private and confidential, as further explained below:

o Nothing in this User Agreement shall be interpreted to limit the user’s consent to, or in any other way restrict or affect, any U.S. Government actions for purposes of network administration, operation, protection, or defense, or for communications security. This includes all communications and data on an information system, regardless of any applicable privilege or confidentiality.

o The user consents to interception/capture and seizure of ALL communications and data for any authorized purpose (including personnel misconduct, law enforcement, or counterintelligence investigation). However, consent to interception/capture or seizure of communications and data is not consent to the use of privileged communications or data for personnel misconduct, law enforcement, or counterintelligence investigation against any party and does not negate any applicable privilege or confidentiality that otherwise applies.

SECTION 2: RESPONSIBILITIES 17

o Whether any particular communication or data qualifies for the protection of a privilege, or is covered by a duty of confidentiality, is determined IAW established legal standards and DoD policy. Users are strongly encouraged to seek personal legal counsel on such matters prior to using an IS if the user intends to rely on the protections of a privilege or confidentiality.

o Users should take reasonable steps to identify such communications or data that the user asserts are protected by any such privilege or confidentiality. However, the user’s identification or assertion of a privilege or confidentiality is not sufficient to create such protection where none exists under established legal standards and DoD policy.

o A user’s failure to take reasonable steps to identify such communications or data as privileged or confidential does not waive the privilege or confidentiality if such protections otherwise exist under established legal standards and DoD policy. However, in such cases the U.S. Government is authorized to take reasonable actions to identify such communication or data as being subject to a privilege or confidentiality, and such actions do not negate any applicable privilege or confidentiality.

o These conditions preserve the confidentiality of the communication or data, and the legal protections regarding the use and disclosure of privileged information, and thus such communications and data are private and confidential. Further, the U.S. Government shall take all reasonable measures to protect the content of captured/seized privileged communications and data to ensure they are appropriately protected.

• In cases when the user has consented to content searching or monitoring of communications or data for personnel misconduct, law enforcement, or counterintelligence investigative searching, (i.e., for all communications and data other than privileged communications or data that are related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants), the U.S. Government may, solely at its discretion and IAW DoD policy, elect to apply a privilege or other restriction on the U.S. Government’s otherwise-authorized use or disclosure of such information.

• All of the above conditions apply regardless of whether the access or use of an information system includes the display of a Notice and Consent Banner (“banner”). When a banner is used, the banner functions to remind the user of the conditions that are set forth in this User Agreement, regardless of whether the banner describes these conditions in full detail or provides a summary of such conditions, and regardless of whether the banner expressly references this User Agreement.

SECTION 2: RESPONSIBILITIES 18

ACCEPTABLE USE POLICY

• You must comply with all Federal, DoD, and DeCA regulations, policies, procedures, and guidelines regarding the protection of information system resources and data.

• You must comply with copyright and site licenses of proprietary software.

• You must process only data that pertains to official U.S. Government and DeCA business.

• You must use DeCA email for official U.S. Government and DeCA business IAW DeCAM

35-33.1.

• You must report all security incidents or suspected incidents to the DeCA Enterprise Service

Desk, available 24 hours a day, 7 days a week at: (877) 332-2471 (toll free) or (804) 734- 8140.

• You must discontinue use of any system resources that show signs of being infected by a virus or other malware and report the suspected incident to the DeCA Enterprise Service Desk.

• You must challenge unauthorized personnel that appear in your work area.

• You must use only the data for which you have been granted authorization.

• You must notify your DeCA supervisor if access to system resources is beyond that which is required to perform your job.

• You must complete computer security awareness and privacy training as requested by DeCA.

• You must coordinate your user access requirements, and user access parameters, with your

DeCA supervisor.

• You must ensure that access to application-specific sensitive data is based on your job function.

• You must safeguard resources against waste, loss, abuse, unauthorized users, and misappropriation.

• You must ensure that access is assigned based on your DeCA supervisor’s approval.

• You must familiarize yourself with any special requirements for accessing, protecting, and utilizing data, including privacy act requirements, payment card industry requirements, copyright requirements, and procurement of sensitive data.

• You must ensure electronic official records (including attachments) are maintained according to DeCA Records Management policy and standards.

SECTION 2: RESPONSIBILITIES 19

• You must ensure that sensitive information sent to a fax or printer is handled in a secure manner, e.g., cover sheet to contain statement that information being faxed is Controlled Unclassified Information, etc.

• You must ensure that hard copy sensitive information is destroyed (after it is no longer needed) commensurate with the sensitivity of the data.

• You must ensure that sensitive information is protected against unauthorized access using encryption, according to DeCA standards contained in DeCAD 30-18 and DeCAM 35-33.1, when sending it via electronic means (telecommunications networks, email, and/or facsimile).

• You must not process U.S. classified national security information on any system at DeCA or on any commercial, personal, privately owned system for any reason.

• You must not install DeCA unapproved software onto the system. Only DeCA designated personnel with appropriate administrator privileges are authorized to load software.

• You must not add additional hardware or peripheral devices to the system. Only designated personnel with appropriate administrator privileges can direct the installation of hardware on the system.

• You must not insert or connect devices that are not owned by DeCA to DeCA computers or

Government Furnished Equipment. This includes personal or privately-owned devices such as computers, cell phones, tablets, iPods, MP3 players, storage devices, mice/mouse, Universal Serial Bus (USB), compact disc (CD), etc.

• Removable media containing flash memory are prohibited from use on all DeCA systems.

This means you must not insert or connect removable media containing flash memory (e.g., flash drives/sticks, thumb drives, USB sticks, digital audio players, etc.) unless formal written approval is obtained from the DeCA Authorizing Official.

• You must not reconfigure hardware or software on any DeCA systems, networks, or interfaces.

• You must follow all DeCA wireless access policies.

• You must not retrieve information for someone who does not have authority to access that information.

• You must not access another person’s account without written approval from a DeCA supervisor.

• You must not remove computer resources from the facility without prior approval from a DeCA supervisor. Resources may only be removed for official use.

SECTION 2: RESPONSIBILITIES 20

• You must not store or process DeCA information on a device that is not owned by DeCA.

• You must not insert DeCA portable storage devices on a device that is not owned by DeCA.

• You must ensure that sensitive information entered into systems is restricted to team members on a Need-To-Know basis.

• You understand that any person who obtains information from a computer connected to the

Internet that is in violation of Internet-use restrictions as defined in DeCAM 35-33.1 is in violation of the Computer Fraud and Abuse Act.

• You must use official DeCA or DoD email or other official DoD messaging account when conducting DoD business and follow guidelines specified in DeCAM 35-33.1.

• You must not use non-official messaging accounts (e.g., personal or privately owned email or messaging accounts) to send DoD communications or conduct DoD business. Additional policy related to this requirement is defined in DeCAM 35-31.01.

• You must use social media for official U.S. Government and DeCA business IAW the use restrictions defined in DeCAM 100-4.1.

• You must not process cardholder data on resources that are not designated for this use.

• You must maintain the confidentiality of your authentication credentials such as your password and Personal Identification Number (PIN). Do not reveal your authentication credentials to anyone; a DeCA employee should never ask you to reveal them.

• You must not share authentication credentials with anyone.

• You must not use entertainment software (e.g., games) or peer-to-peer services.

• You must protect resources from physical hazards such as liquids, food, etc.

• You must follow proper logon/logoff procedures. You must manually logon to your session;

do not store your password locally on your system or use any automated logon capabilities.

You must promptly logoff when session access is no longer needed. If a logoff function is unavailable, you must close your browser. Never leave your computer unattended while logged into the system.

SECTION 2: RESPONSIBILITIES 21

2.9. AUTHORIZED USER. The authorized user shall:

a. Use devices within DeCA’s environment IAW the DeCA User Agreement and Acceptable Use Policy (Figure 2).

b. Ensure that sensitive data is not stored on local hard drives or removable media without a DeCA approved file and/or device encryption solution.

c. Encrypt all email messages containing sensitive data. If encryption is unavailable then email will not be used.

d. Report suspected security incidents or compromises to the Enterprise Service Desk (ESD) immediately.

e. Register to receive DoD policy updates by registering your DeCA email address on the DoD Issuances website.

f. Review and sign the latest User Agreement and Acceptable Use Policy (Figure 2) prior to receiving initial network access and annually thereafter. The signed document must be provided to the employee’s supervisor for filing.

g. Not connect privately-owned media or peripheral devices (including, but not limited to, CD/Digital Video Disc [DVDs], i-devices, commercial MP3 players, phones, mouse/mice, and USB drives) to any DeCA ISs and Government Furnished Equipment under any circumstance.

ACCEPTANCE AND SIGNATURE

I have read the above User Agreement and Acceptable Use Policy for DeCA systems and networks. By my electronic acceptance and/or signature below, I acknowledge and agree that my access to all DeCA systems and networks is covered by, and subject to, such Rules. Further, I acknowledge and accept that any violation by me of these Rules may subject me to civil and/or criminal actions and that DeCA retains the right, at its sole discretion, to terminate, cancel or suspend my access rights to the DeCA system at any time, without notice.

User’s Legal Name: (printed)

User’s Signature: (signature)

Date:

Comments here:

SECTION 3: RISK MANAGEMENT FRAMEWORK 22

SECTION 3: RISK MANAGEMENT FRAMEWORK

3.1. RISK MANAGEMENT FRAMEWORK (RMF). The RMF is used to identify, implement, assess, and manage cybersecurity capabilities and services expressed as security controls and authorize the operation of IS, pit systems, IT products, and IT services within DoD. This manual is designed to be a companion guide to DoDI 8500.01 and DoDI 8510.01, providing specific guidance for implementation within DeCA. DeCA personnel serving in RMF roles at every level should refer to DoDI 8510.01 for a full description of the process, definitions, roles, responsibilities, and activities. In cases where DoDI 8510.01 conflicts with this manual, compliance with DoDI 8510.01 takes precedence and is required.

3.2. GUIDING PRINCIPLES.

a. All IS and PIT systems are authorized for operation by the DeCA AO through the RMF process. Authorization is required prior to connection to the DeCA production network or testing with “live” data.

(1) IS and PIT systems must have a system security plan that provides the system categorization, the security requirements applicable to the system, and the system-level continuous monitoring strategy, at a minimum. The AO must formally sign the security plan prior to the Security Control Accessor commencing the assessment of security controls. For acquisition programs, approval should be accomplished before Milestone B and the issuance of the design and development request for proposals.

(2) Systems with deficiencies that pose a high risk that is determined to be acceptable due to mission criticality may be authorized by the AO to operate for a limited period of time. This approval is contingent upon CIO permission and certain conditions being met (e.g., maintaining a plan of action and milestones (POA&M) to address deficiencies and implementing the required safeguards).

(3) System deficiencies shall be recorded and maintained on a single system POA&M for the life of the system. Deficiencies include findings from security control assessments, security impact analysis, and continuous monitoring activities (e.g., vulnerability scans).

(4) All systems authorized by the AO will be re-assessed annually against a sub-set of security controls assigned to the IS or PIT system. The AO will be provided the results of the annual assessment, which will recommend either no change to the authorization status or downgrade of the current authorization decision (e.g., change from an Authorization to Operate (ATO) with a 3-year term to an ATO with conditions). The AO will determine the final course of action.

(5) Systems shall be re-assessed and re-authorized by the AO before expiration of the current authorization decision, as a result of a significant change to the system, or upon request by the ISSM. A significant change will be defined by the ISSM or SISO.

SECTION 3: RISK MANAGEMENT FRAMEWORK 23

(6) System information recorded in the DoD Information Technology Portfolio Repository must be accurate at all times.

(7) An AO may downgrade or revoke an authorization decision at any time if risk conditions or concerns so warrant.

b. POA&Ms should include the following, at a minimum:

(1) Mitigating policies, processes, and procedures that have been implemented (e.g., actions that have been prohibited or…