last sync: 2023-Jan-27 18:40:07 UTC

Azure Policy definition

Develop SSP that meets criteria

Name Develop SSP that meets criteria
Azure Portal
Id 6b957f60-54cd-5752-44d5-ff5a64366c93
Version 1.1.0
details on versioning
Category Regulatory Compliance
Microsoft docs
Description CMA_C1492 - Develop SSP that meets criteria
Mode All
Type BuiltIn
Preview FALSE
Deprecated FALSE
Effect Default
Manual
Allowed
Manual, Disabled
RBAC
Role(s)
none
Rule
Aliases
Rule
ResourceTypes
IF (1)
Microsoft.Resources/subscriptions
Compliance The following 21 compliance controls are associated with this Policy definition 'Develop SSP that meets criteria' (6b957f60-54cd-5752-44d5-ff5a64366c93)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
FedRAMP_High_R4 PL-2 FedRAMP_High_R4_PL-2 FedRAMP High PL-2 Planning System Security Plan Shared n/a The organization: a. Develops a security plan for the information system that: 1. Is consistent with the organization’s enterprise architecture; 2. Explicitly defines the authorization boundary for the system; 3. Describes the operational context of the information system in terms of missions and business processes; 4. Provides the security categorization of the information system including supporting rationale; 5. Describes the operational environment for the information system and relationships with or connections to other information systems; 6. Provides an overview of the security requirements for the system; 7. Identifies any relevant overlays, if applicable; 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation; b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles]; c. Reviews the security plan for the information system [Assignment: organization-defined frequency]; d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and e. Protects the security plan from unauthorized disclosure and modification. Supplemental Guidance: Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17. References: NIST Special Publication 800-18. link 6
FedRAMP_Moderate_R4 PL-2 FedRAMP_Moderate_R4_PL-2 FedRAMP Moderate PL-2 Planning System Security Plan Shared n/a The organization: a. Develops a security plan for the information system that: 1. Is consistent with the organization’s enterprise architecture; 2. Explicitly defines the authorization boundary for the system; 3. Describes the operational context of the information system in terms of missions and business processes; 4. Provides the security categorization of the information system including supporting rationale; 5. Describes the operational environment for the information system and relationships with or connections to other information systems; 6. Provides an overview of the security requirements for the system; 7. Identifies any relevant overlays, if applicable; 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation; b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles]; c. Reviews the security plan for the information system [Assignment: organization-defined frequency]; d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and e. Protects the security plan from unauthorized disclosure and modification. Supplemental Guidance: Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17. References: NIST Special Publication 800-18. link 6
hipaa 0119.05a1Organizational.3-05.a hipaa-0119.05a1Organizational.3-05.a 0119.05a1Organizational.3-05.a 01 Information Protection Program 0119.05a1Organizational.3-05.a 05.01 Internal Organization Shared n/a Security contacts are appointed by name for each major organizational area or business unit. 6
hipaa 0816.01w1System.1-01.w hipaa-0816.01w1System.1-01.w 0816.01w1System.1-01.w 08 Network Protection 0816.01w1System.1-01.w 01.06 Application and Information Access Control Shared n/a The sensitivity of applications/systems is explicitly identified and documented by the application/system owner. 6
hipaa 0863.09m2Organizational.910-09.m hipaa-0863.09m2Organizational.910-09.m 0863.09m2Organizational.910-09.m 08 Network Protection 0863.09m2Organizational.910-09.m 09.06 Network Security Management Shared n/a The organization builds a firewall configuration that restricts connections between untrusted networks and any system components in the covered information environment; and any changes to the firewall configuration are updated in the network diagram. 25
hipaa 0866.09m3Organizational.1516-09.m hipaa-0866.09m3Organizational.1516-09.m 0866.09m3Organizational.1516-09.m 08 Network Protection 0866.09m3Organizational.1516-09.m 09.06 Network Security Management Shared n/a The organization describes the groups, roles, and responsibilities for the logical management of network components, and ensures coordination of and consistency in the elements of the network infrastructure. 11
hipaa 1781.10a1Organizational.23-10.a hipaa-1781.10a1Organizational.23-10.a 1781.10a1Organizational.23-10.a 17 Risk Management 1781.10a1Organizational.23-10.a 10.01 Security Requirements of Information Systems Shared n/a Information system specifications for security control requirements state that security controls are to be incorporated in the information system, supplemented by manual controls as needed, and these considerations are also applied when evaluating software packages, developed or purchased. 4
hipaa 1782.10a1Organizational.4-10.a hipaa-1782.10a1Organizational.4-10.a 1782.10a1Organizational.4-10.a 17 Risk Management 1782.10a1Organizational.4-10.a 10.01 Security Requirements of Information Systems Shared n/a Security requirements and controls reflect the business value of the information assets involved, and the potential business damage that might result from a failure or absence of security. 6
hipaa 1790.10a2Organizational.45-10.a hipaa-1790.10a2Organizational.45-10.a 1790.10a2Organizational.45-10.a 17 Risk Management 1790.10a2Organizational.45-10.a 10.01 Security Requirements of Information Systems Shared n/a The organization includes business requirements for the availability of information systems when specifying the security requirements; and, where availability cannot be guaranteed using existing architectures, redundant components or architectures are considered along with the risks associated with implementing such redundancies. 6
hipaa 1793.10a2Organizational.91011-10.a hipaa-1793.10a2Organizational.91011-10.a 1793.10a2Organizational.91011-10.a 17 Risk Management 1793.10a2Organizational.91011-10.a 10.01 Security Requirements of Information Systems Shared n/a The requirement definition phase includes (i) consideration of system requirements for information security and the processes for implementing security, and (ii) data classification and risk to information assets are assigned and approved (signed-off) by management to ensure appropriate controls are considered and the correct project team members are involved. 6
hipaa 19143.06c1Organizational.9-06.c hipaa-19143.06c1Organizational.9-06.c 19143.06c1Organizational.9-06.c 19 Data Protection & Privacy 19143.06c1Organizational.9-06.c 06.01 Compliance with Legal Requirements Shared n/a Designated senior management within the organization reviews and approves the security categorizations and associated guidelines. 6
ISO27001-2013 A.14.1.1 ISO27001-2013_A.14.1.1 ISO 27001:2013 A.14.1.1 System Acquisition, Development And Maintenance Information security requirements analysis and specification Shared n/a The information security related requirements shall be included in the requirements for new information systems or enhancements to existing information systems. link 24
ISO27001-2013 C.4.3.a ISO27001-2013_C.4.3.a ISO 27001:2013 C.4.3.a Context of the organization Determining the scope of the information security management system Shared n/a The organization shall determine the boundaries and applicability of the information security management system to establish its scope. When determining this scope, the organization shall consider: a) the external and internal issues referred to in 4.1; The scope shall be available as documented information. link 3
ISO27001-2013 C.4.3.b ISO27001-2013_C.4.3.b ISO 27001:2013 C.4.3.b Context of the organization Determining the scope of the information security management system Shared n/a The organization shall determine the boundaries and applicability of the information security management system to establish its scope. When determining this scope, the organization shall consider: b) the requirements referred to in 4.2. The scope shall be available as documented information. link 3
ISO27001-2013 C.4.3.c ISO27001-2013_C.4.3.c ISO 27001:2013 C.4.3.c Context of the organization Determining the scope of the information security management system Shared n/a The organization shall determine the boundaries and applicability of the information security management system to establish its scope. When determining this scope, the organization shall consider: c) interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations. The scope shall be available as documented information. link 18
ISO27001-2013 C.6.1.3.d ISO27001-2013_C.6.1.3.d ISO 27001:2013 C.6.1.3.d Planning Information security risk treatment Shared n/a The organization shall define and apply an information security risk treatment process to: d) produce a Statement of Applicability that contains the necessary controls (see 6.1.3 b) and c)) and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A; NOTE Organizations can design controls as required, or identify them from any source. NOTE 1 AnnexA contains a comprehensive list of control objectives and controls. Users of this International Standard are directed to Annex A to ensure that no necessary controls are overlooked. NOTE 2 Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A are not exhaustive and additional control objectives and controls may be needed. The organization shall retain documented information about the information security risk treatment process. link 1
ISO27001-2013 C.7.5.2.c ISO27001-2013_C.7.5.2.c ISO 27001:2013 C.7.5.2.c Support Creating and updating Shared n/a When creating and updating documented information the organization shall ensure appropriate: c) review and approval for suitability and adequacy. link 1
NIST_SP_800-171_R2_3 .12.4 NIST_SP_800-171_R2_3.12.4 NIST SP 800-171 R2 3.12.4 Security Assessment Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. System security plans relate security requirements to a set of security controls. System security plans also describe, at a high level, how the security controls meet those security requirements, but do not provide detailed, technical descriptions of the design or implementation of the controls. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk if the plan is implemented as intended. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization. [SP 800-18] provides guidance on developing security plans. [NIST CUI] provides supplemental material for Special Publication 800-171 including templates for system security plans. link 8
NIST_SP_800-53_R4 PL-2 NIST_SP_800-53_R4_PL-2 NIST SP 800-53 Rev. 4 PL-2 Planning System Security Plan Shared n/a The organization: a. Develops a security plan for the information system that: 1. Is consistent with the organization’s enterprise architecture; 2. Explicitly defines the authorization boundary for the system; 3. Describes the operational context of the information system in terms of missions and business processes; 4. Provides the security categorization of the information system including supporting rationale; 5. Describes the operational environment for the information system and relationships with or connections to other information systems; 6. Provides an overview of the security requirements for the system; 7. Identifies any relevant overlays, if applicable; 8. Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and 9. Is reviewed and approved by the authorizing official or designated representative prior to plan implementation; b. Distributes copies of the security plan and communicates subsequent changes to the plan to [Assignment: organization-defined personnel or roles]; c. Reviews the security plan for the information system [Assignment: organization-defined frequency]; d. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments; and e. Protects the security plan from unauthorized disclosure and modification. Supplemental Guidance: Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended. Organizations can also apply tailoring guidance to the security control baselines in Appendix D and CNSS Instruction 1253 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DoD-tactical, Federal Public Key Infrastructure, or Federal Identity, Credential, and Access Management, space operations). Appendix I provides guidance on developing overlays. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition. For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, PM-1, PM-7, PM-8, PM-9, PM-11, SA-5, SA-17. References: NIST Special Publication 800-18. link 6
NIST_SP_800-53_R5 PL-2 NIST_SP_800-53_R5_PL-2 NIST SP 800-53 Rev. 5 PL-2 Planning System Security and Privacy Plans Shared n/a a. Develop security and privacy plans for the system that: 1. Are consistent with the organization???s enterprise architecture; 2. Explicitly define the constituent system components; 3. Describe the operational context of the system in terms of mission and business processes; 4. Identify the individuals that fulfill system roles and responsibilities; 5. Identify the information types processed, stored, and transmitted by the system; 6. Provide the security categorization of the system, including supporting rationale; 7. Describe any specific threats to the system that are of concern to the organization; 8. Provide the results of a privacy risk assessment for systems processing personally identifiable information; 9. Describe the operational environment for the system and any dependencies on or connections to other systems or system components; 10. Provide an overview of the security and privacy requirements for the system; 11. Identify any relevant control baselines or overlays, if applicable; 12. Describe the controls in place or planned for meeting the security and privacy requirements, including a rationale for any tailoring decisions; 13. Include risk determinations for security and privacy architecture and design decisions; 14. Include security- and privacy-related activities affecting the system that require planning and coordination with [Assignment: organization-defined individuals or groups]; and 15. Are reviewed and approved by the authorizing official or designated representative prior to plan implementation. b. Distribute copies of the plans and communicate subsequent changes to the plans to [Assignment: organization-defined personnel or roles]; c. Review the plans [Assignment: organization-defined frequency]; d. Update the plans to address changes to the system and environment of operation or problems identified during plan implementation or control assessments; and e. Protect the plans from unauthorized disclosure and modification. link 6
SOC_2 CC3.1 SOC_2_CC3.1 SOC 2 Type 2 CC3.1 Risk Assessment COSO Principle 6 Shared The customer is responsible for implementing this recommendation. • Reflects Management's Choices — Operations objectives reflect management's choices about structure, industry considerations, and performance of the entity. • Considers Tolerances for Risk — Management considers the acceptable levels of variation relative to the achievement of operations objectives. • Includes Operations and Financial Performance Goals — The organization reflects the desired level of operations and financial performance for the entity within operations objectives. • Forms a Basis for Committing of Resources — Management uses operations objectives as a basis for allocating resources needed to attain desired operations and financial performance. External Financial Reporting Objectives • Complies With Applicable Accounting Standards — Financial reporting objectives are consistent with accounting principles suitable and available for that entity. The accounting principles selected are appropriate in the circumstances. • Considers Materiality — Management considers materiality in financial statement presentation. • Reflects Entity Activities — External reporting reflects the underlying transactions and events to show qualitative characteristics and assertions. External Nonfinancial Reporting Objectives • Complies With Externally Established Frameworks — Management establishes objectives consistent with laws and regulations or standards and frameworks of recognized external organizations. • Considers the Required Level of Precision — Management reflects the required level of precision and accuracy suitable for user needs and based on criteria established by third parties in nonfinancial reporting. • Reflects Entity Activities — External reporting reflects the underlying transactions and events within a range of acceptable limits. Internal Reporting Objectives • Reflects Management's Choices — Internal reporting provides management with accurate and complete information regarding management's choices and information Page 22 TSP Ref. # TRUST SERVICES CRITERIA AND POINTS OF FOCUS needed in managing the entity. • Considers the Required Level of Precision — Management reflects the required level of precision and accuracy suitable for user needs in nonfinancial reporting objectives and materiality within financial reporting objectives. • Reflects Entity Activities — Internal reporting reflects the underlying transactions and events within a range of acceptable limits. Compliance Objectives • Reflects External Laws and Regulations — Laws and regulations establish minimum standards of conduct, which the entity integrates into compliance objectives. • Considers Tolerances for Risk — Management considers the acceptable levels of variation relative to the achievement of operations objectives 7
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-27 16:35:32 change Minor (1.0.0 > 1.1.0)
2022-09-13 16:35:29 add 6b957f60-54cd-5752-44d5-ff5a64366c93
Initiatives
usage
Initiative DisplayName Initiative Id Initiative Category State Type
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
JSON
changes

JSON