V2R3 changes
Microsoft Exchange 2013 Mailbox Server STIG V2R3 (2024-07-24) replaced V2R2 (2021-12-15): 1 check updated. It has 70 checks, against 70 in V2R2.
V2R3 checklistV2R2 checklist Compare V2R2 and V2R3 in STIG Compare
- 0 added
- 0 removed
- 1 updated
Updated fields: Check text 1Fix text 1Title 1Discussion 1
Updated in V2R3 (1)
V-207333CAT IIThe version of Exchange running on the system must be a supported version.Title, Check text, Fix text, Discussion
Title
Exchange must have the most current, approved service pack installed.The version of Exchange running on the system must be a supported version.
Check text
DetermineExchange the2013 mostis current,no approvedlonger servicesupported pack.
Openby the Exchangevendor. Management Shell and enter the following command:
Get-ExchangeServer | fl Name, AdminDisplayVersion
If the valuesystem ofis AdminDisplayVersionrunning doesExchange not return the most current2013, approved service pack, this is a finding.
Fix text
Install the most current, approved service pack.Upgrade to a supported version.
Discussion
FailureSecurity flaws with software applications are discovered daily. Vendors are constantly updating and patching their products to installaddress newly discovered security vulnerabilities. Organizations (including any contractor to the mostorganization) currentare Exchangerequired to promptly install security-relevant software updates (e.g., patches, service packpacks, leavesand hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.
Organization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system vulnerableor the criticality of the update (i.e., severity of the vulnerability related to exploitationthe discovered flaw).
This Currentrequirement servicewill packsapply correctto knownsoftware securitypatch management solutions used to install patches across the enclave and also to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system vulnerabilitiescriticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period used must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.
The application will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).
How these changes are found
Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V2R3 no longer has.
Comparing other releases, or this one against an older release? Pick any two in STIG Compare.